SIP Protocol Resolution and implementation (C and C ++ use Osip) 10

Chapter 7 Registration

Section 1 Overview

SIP provides a capability to discover users. If a user wants to enable a session with another user, the SIP must be able to discover the current host of the target user. This discovery process is often used by SIP network elements, such as proxy servers or redirection servers. These servers can receive a request and detect where to send the request based on the user's location information. The SIP network element considers a location service. This Service supports binding an address to a specific domain name. These address binding information maps the received sip or sips uri information like the SIP: bob@biloxi.com into one or more sip or sips Uris that are more accurate to users like the SIP: bob@engineering.biloxi.com. Finally, a proxy maps the received URI to the current used user proxy Location Based on the location service.

The registration server creates a binding relationship for the location service under a specific domain name. This binding relationship refers to binding one or more addresses to an AOR (address-of-record) Uri. Therefore, when a proxy receives a request under the current domain name and the request-Uri matches the AOR, the proxy sends the request to the contact address registered on the AOR. Generally, it makes sense to register an AOR under a domain name when the request sent to this AOR can be sent to the domain name where AOR is located. In most cases, this means that the Domain Name of the registration service must be consistent with the domain name in the URI of AOR.

There are many ways to create location service content. One of the methods is background management. In the preceding example, Bob is an employee of many engineering departments by reading the company database. Even so, SIP provides a mechanism for UA to explicitly create a binding mechanism. This mechanism is to register the service.

The registration service must send a register request to a special type of UAs, which is the registration server. A registration server is the frontend of the location service under a domain name. It reads and writes ing relationships based on the content of the register request. This location service usually provides services for the proxy server under the current domain name, and this proxy server provides responses for requests routed to the current domain name.

The flowchart of the entire registration process is shown in figure 2. Note that both the registered server and the proxy server are logical roles, which may be a device on the network. For clarity, the two parts are separated in the figure. Note that if the two servers are separated elements, the UA may send a request to the registration server through a proxy server.

SIP has no special requirements on location service implementation. The only requirement is that the registration server under some domain names must be able to read and write data to the location service, and the proxy server and redirection server under the domain name must also be able to read the data. The registration servers under some domain names may be deployed with specific sip proxy servers.

Section 2 construct a register request

The register request can be used to add, delete, and query binding information. A register request can create a new binding for an AOR and one or more contact addresses. The registered server can be used as a special AOR after being authenticated by a third party. A customer can also delete earlier bindings and query the current bindings of AOR.

Unless otherwise stated, the structure of the register request and the behavior of the client sending a register request is the same as that of the UAC described in rfc3261 sections 8.1 and 17.1.

A register request does not create a dialog. When there is a pre-existing route set as described in section 8.1 of rfc3261, a UAC may include a Route Header domain in a register request. In a register request or response, the record-Route Header field is meaningless and must be ignored if it exists. In addition, UAC must not create a new route set based on the record-Route Header domain that appears or does not appear in a response to the Register request.

Except for contact, the following header fields must be included in the register request. A contact header may contain:

Request-Uri: This request-Uri specifies the Domain Name of the service at the current location, which is known to the registration server (for example, "SIP: chicago.com "). The "userinfo" and "@" sections that constitute the sip uri cannot appear.
To: The to header includes the AOR to be created, queried, or modified by the registered server. The to header field contains a user name, so it is different from the request-Uri header field. This AOR must be a sip or sips uri.
From: AOR of the user whose From header field contains this information. Unless the request is a third-party registration request, this value is the same as the to header domain.
Call-ID: All registration information of a UAC should use the same value of the call-ID header field, so that the registration information can be sent to a registration server.
If the same customer uses different call-IDs, the registration server cannot detect whether the register request is not received in sequence due to latency.
CSeq: the value of the CSeq Header field ensures the proper order of the register request. For each register request with the same call-ID, the UA must be added to the CSeq value by one.
Contact: A register request may contain a contact header domain that contains information bound to zero or multiple addresses.

When the UA does not receive a final response to the previous register request sent by the registration server or before the previous request has not timed out, it cannot send a new registration information (that is, contains the value of the new contact header field, rather than resending it)

Bob
+ ---- +
| UA |
|
+ ---- +
|
| 3) invite
Carol@chicago.com
Chicago.com + -------- + V
+ --------- + 2) store | location | 4) query + ----- +
| Registrar | ======>| service | <=======| proxy | sip.chicago.com
+ --------- ++ -------- + ======> + ----- +
A 5) resp |
|
|
1) Register |
|
+ ---- + |
| UA | <--------------------------------- +
Cube2214a | 6) invite
+ ---- + Carol@cube2214a.chicago.com
Carol

Figure 2: Register example

The following lists the parameters of the contact header fields with special meanings in the register request:

The action: "action" parameter is not recommended in rfc2543. Therefore, UAC should not use the "Action" parameter.
Expires: the "expires" parameter indicates how long the UA wants the current binding to be valid. This value is a number in seconds. If this parameter is not specified, this value is replaced by the value in the Expires header field. In some implementations, values larger than 2 ** 32-1 (4294967295 seconds or 136 seconds) are considered to be equal to 2 ** 32-1. Invalid value should be regarded as 3600.

Add binding

The register request sends a request containing the contact address to the registration server. The contact address is the address of the other SIP requests sent to the AOR. AOR is included in the to header field of the register request.

The value of the contact header field in a request typically consists of a sip or sips uri that identifies a specified SIP terminal (for example, "SIP: carol@cube2214a.chicago.com"), but they may use any URI mode. For example, a sip ua can decide to register a phone number (using Tel Uri, ref2806 [9]) or an email address (using a mailto Uri, rfc2368 [32]) as the Contact Header of an AOR contact address.

For example, Carol, the AOR used is "SIP: carol@chicago.com" and will be registered in the SIP registration server under the chicago.com domain name. Her registration information will be used by the proxy server under the chicago.com domain name to route requests sent to Carol's AOR to her SIP terminal.

Once a customer creates a binding on the registration server, it may send some subsequent registration information, including the new binding or modification information for the existing binding. The 2XX response to the Register request must contain the following information. The contact header field must be included in the current registration server, and a complete list of bound information has been registered for this AOR.

If aor in the to header field in the register request is a sips uri, the value of any contact header field in the request should also be a sip Uri. The customer should be able to use non-Sip URI to register with the customer's AOR only when other methods are used to ensure the contact address security. This can be used to handle security issues of non-SIP protocol Uris or non-Sip devices under non-TLS protocols.

Registration Information does not need to be updated. Generally, a UA only updates its own contact address.

Set the contact address Validity Period

When a customer sends a register request, it may provide a suggested validity period to indicate how long the customer wants the registration information to be valid. (In rfc3261, section 10.3 describes the actual interval selected by the registration server based on the local policy .)

You can use either of the following methods to set the validity period for a binding: use the "expires" parameter of an Expires header domain or a contact header domain. This method can be used to set the validity period for each binding information when multiple binding information exists in the same register request. The previous method sets the validity period for all the contact header fields that do not contain the "expires" parameter.

If neither of the two methods sets the validity period is used, this indicates that the validity period the customer wants is determined by the server.

Priority between multiple contact addresses

If there are multiple contact header fields in the register request, this indicates that the UA registering the contact header field wants to bind the values of these contact header fields to the aor in the to header field. You can use the "Q" parameter in the list of contact header fields to specify their priority. The "Q" parameter indicates the priority of the value of this contact header field and the value of other contact header fields for the current AOR. Rfc3261 section 16.6 describes how a proxy server uses this priority.

Remove binding information

Registration Information is in a soft state and will expire without refreshing, but it can still be removed directly. The customer can adjust the validity period selected on the registration server described in rfc3261 10.2.1. UA uses the register request to specify a "0" validity period for a contact address to immediately remove a binding information. UA should support this mechanism to remove the binding information before the binding validity period expires.

The value of the contact header field specified by register is "*", indicating that all registration information is processed, but it must be used only when the value of the Expires header field is "0.

Use "*" as the value of the contact header field to allow a registered UA to remove all binding information for this AOR, but you do not need to know the value of these contact addresses.

Obtain binding information

A successful response to any register request contains a complete list of existing bindings, regardless of whether the request contains the Contact Header domain. If there is no contact header field in a register, the binding list will not change.

Refresh binding information

Every UA must refresh the previously created binding information. A UA should not refresh the binding information created by other UA.

The contact header domain of the 200 (OK) Response sent by the registration server contains a list of all currently bound information. UA uses the comparison rules described in section 19.1.4 of rfc3261 to compare whether each contact address is valid. If valid, the validity period is updated based on the expires parameter or the Expires header. Before the expiration date, UA sends a register request for each bound message to update the validity period. Some update requests may also be merged into a register request.

UA should use the same call-ID to send registration information within a period. The registration information used for refreshing should be sent to the same network address as the original registration information, unless the request is redirected.

Set internal clock

If a response to a register request contains a date header field, the customer may use this header field to set the current time to set all internal clocks.

A registration server is found

UA can use three methods to determine which address to send a registration request: Configure, use AOR, and use broadcast. An ua can obtain the address of the registration server through configuration, which is beyond the scope of this Manual. If the address of the registration server is not configured, UA should use the AOR host name section in request-Uri and send the request to [4] here using the general SIP Server location mechanism. For example, the UA of the "SIP: carol@chicago.com" User directs the register request to "SIP: chicago.com ".

Finally, an ua can use the configured broadcast. Broadcast registers a message to the broadcast address "sip.mcast.net" (224.0.1.75 of IPv4) of the known "all sip servers ). The broadcast address of IPv6 has not been assigned yet. This address is described separately in the document when necessary. Sip ua may listen to this address and use it to obtain other local users (see [33]); despite this, their troops request to respond.
Broadcast registration information may not be used in some environments. For example, if multiple business applications share the same local LAN.

Send a request

Once the register method is constructed and the target of the message to be sent is determined, UAC transfers the register message to the Transaction Layer according to the program described in Section 8.1.2 of rfc3261.

If the transaction layer does not respond to the Register request and a timeout error is returned, UAC should not immediately attempt to send registration information to the same registration server.
Retry now may still time out. Because timeout occurs, waiting for a reasonable interval before Retry is a good way to reduce unnecessary network load. The waiting interval is not specified here.

Error Response

If a UA receives a 423 (interval too brief) response, it may need to set a greater validity period for all the contact addresses in the register request, the new validity period must be greater than or equal to the value of the Min-Expires header field in the 423 (interval too brief) response.

Process register requests

A registration server is a UAS. the UAS responds to the Register request and maintains a binding list, which is provided to the proxy server and redirect server within its domain name management scope. A registration server processes requests according to rfc3261 section 8.2 and section 17.2, but it only accepts register requests. A registered server must not create a 6xx response.

A registration server can properly redirect the register request. It is usually used to register a server to listen on a multicast address and redirect the multicast register message to its own Unicast address using the 302 (moved temporarily) response.

The registration server must ignore the record-Route Header field in the register request. The registration server must not include the record-Route Header field in any response to the Register request.
A registration server may receive a register request through the proxy server, which considers this request as an unknown request and adds a record-Route Header domain to this request.

A registration server knows (for example, through configuration) the Domain Name of the bound list it manages. The register request must be processed by the registration server that receives the request in order. The register request must also be atomic, which means that a specified register request is either completely processed or not processed. When a register message is processed, it must be independent of any other registration information or changed binding information.

When a register request is received, the registration server performs the following steps:
1. The registration server checks request-URI to determine whether it has the permission to bind the domain name specified in request-Uri. If you do not have the permission and the server acts as a proxy server, it should send the request to that domain name and send the message as a proxy according to the method described in rfc3261 section 16th.

2. To ensure that the proxy server supports any needed extensions, the registration server must process the value of the require header domain as described in rfc3261 8.2.2.

3. A registration server should verify UAC. The authentication mechanism for sip ua is described in Section rfc3261 22nd. Registration behaviors cannot go beyond the SIP verification framework. If there is no authentication mechanism, the registration server can obtain the address of the From header domain as the basis for verification.

4. The registration server should decide whether the authenticated user has the right to modify its AOR-related registration information. For example, a registration server may use a verification database to verify the ing between the database storage username and the AOR list. Users with tokens can modify the binding information. If the authenticated user is not authorized to modify the binding information, the registration server must return a 403 (Forbidden) response and skip the following steps.

In a third-party registration-supported architecture, an entity may be authorized to update registration information for multiple AOR associated with it.

5. The registration server parses the AOR from the requested to header domain. If AOR is not valid under the domain name specified by request-Uri, the registration server must send a 404 (not found) response and skip the remaining steps. Then the URI must be immediately converted into a standard format. All URI parameters must be removed (including the user-Param parameter) and any invalid characters must be converted to a valid format. It is used as the index of the bound information.

6. The registration server checks whether the request contains the Contact Header domain. If it does not exist, it will skip other steps to the last step. If the contact header field exists, the registration server checks whether the specified "*" and Expires header fields are contained in the value of the contact header field. If the request has an external contact header or a non-zero validity period, the request is invalid. The server must return 400 (invalid request) and skip the remaining steps. Otherwise, the registration server checks whether the call-id value matches the value of each binding information. If not, it removes the binding. If yes, it only removes the binding information where the CSeq value in the binding information is smaller than the requested CSeq value. Otherwise, the update must be terminated and the request fails.

7. The registration server processes each contact address in the contact header domain in sequence. For each address, it determines the validity period according to the following steps:
-If the value of the header field has the "expires" parameter, This value must be used as the validity period of the request.
-If there is no such parameter but the request has an Expires header field, the value of this header field must be valid.
-If none of them exist, you must specify the local default value as the validity period.
The registration server may determine a value less than the request validity period. If and only when the request is valid for less than zero and less than one hour and less than the minimum value configured by a registration server, the registration server sends a 423 (interval too brief) Response to reject registration information. This response must contain a min-Expires header field. The value of this header field is the minimum validity period expected by the registration server. Then it skips the remaining steps.
When you need to maintain the registration status and the registration information becomes invalid, you can allow the server to set the validity period of registration information to avoid frequent refreshing of registration information. The validity period of registration information is often used during service creation. One example is the follow-me (Follow Me) service when the user may only stay on a terminal for a short time. Therefore, the registration server should accept registration information with a short validity period. A request is rejected only when the refresh time is too short that it will degrade the performance of the registration server.
For each address, the registration server uses the URI comparison principle to search for the list of currently bound information. If the binding information does not exist, it will try to add one. If the binding information exists, the registration server checks the call-id value. If the call-id value of the existing binding information is different from the call-id value in the request, if the binding information is valid for 0, delete it, if the binding information is not valid for 0, update it. If the call-id value is the same, the registration server compares the CSeq value. If the CSeq value in the request is greater than the value in the binding information, the registration server must update or delete the binding information as above. Otherwise, update is not allowed and a response to failure is returned.
This is an algorithm that ensures that requests are sent from the same UA but are not ignored in the correct sequence.
Each binding record records the call-ID and CSeq values from the request.
The binding information must be submitted only when all the bindings are updated and the append operations are successful. (The modification is made visible to the proxy server and the redirection server ). If some operations fail (for example, the backend database fails to be submitted), 500 (server error) must be used to respond to the request, and all binding information for temporary updates must be removed.

8. The registration server returns a 200 (OK) response. This response must contain the contact header fields listing all currently bound information. The value of each contact header field must be given an "expires" parameter, which indicates the validity period determined by the registration server. This response should contain a date header field.