The REGISTER request sent to a registrar incldues the contact address to which the SIP requests for the address-of-record should be forwarded. The AOR is included in the To header field of the REGISTER request.
The Contact header field values of the request typically consists of SIP or SIPS URIs that identify particular SIP endpoints (for e.g. “sip:carol@cube22412a.chicago.com”, but MAY use any URI scheme. A SIP UA can choose to register telephone numbers (with the tel URL) or email addresses for e.g.
Once a client has established bindings at the registrar, it MAY send subsequent registrations containing new bindings or modifications to existing bindings as necessary. The 2xx response to REGISTER request will contains, in a Contact header field, a complete list of bindings that have been registered for this address of record at this registrar.
Setting expiration interval of Contact Addresses
When a client sends a REGISTER request, it MAY suggest an expiration interval that indicates how long the client would like the registration to be valid.
There are two ways in which a client can suggest an expiration interval for a binding: through an expires header field or an “expires” Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one bindings is given in a single REGISTER request.
Preferences Among Contact Addresses
If more than one contact is sent in a REGISTER request, the registering UA intends to associate all of the URIs in these contact header field values with the address-of-record present in the To field. The list can be prioritised with the “q” parameter in the Contact header field. The “q” parameter indicates the relative perforce for the particular Contact header field value compared to other bindings for this address-of-record.
Removing Bindings
Registrations are soft stage and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the Registrar. A UA requests the immediate removal of a binding by specifying an expiration interval of “0” for that contact address in a REGISTER request. UAs SHOULD support this mechanism so that the bindings can be removed before their expiration interval has passed.
The use of * Contact header field value allows a registering UA to remove all bindings associated with an address-of-record without knowing their precise values.
Fetching Bindings
A success response to any REGISTER request contains the complete list of existing bindings, regardless of whether the request contained a Contact header field. If no Contact header field is present in a REGISTER request, the list of bindings is left unchanged.
Refreshing Bindings
Each UA is responsible for refreshing the bindings that it has previously established. A UA SHOULD NOT Refresh bindings set up by other UAs.
The 200 OK response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in section 19.1.4.
The UA SHOULD use the same Call-ID for all registrations during a single boot cycle.
Setting internal Clock
If the response for a REGISTER request contains a Date header field, the client MAY use this header to learn the current time in order to set any internal clocks.
Discovering a Registrar
UAs can use three ways to determine the address to which to send registrations. by configuration, using address-of-record, and multicast. The UA should use the host part of the address-of-record as the request-URI and address the request there, using the normal SIP server location mechanism. For e.g. the user sip:carol@chicago.com addresses the REGISTER request to sip:chicago.com
A UA can be configured to use multicast. Multicast registrations are addressed to the well-known “all SIP servers” multicast address “sip:mcast.net” (224.0.1.75 for IPV4). No well known IPV6 multicast address has been allocated. such an allocation will be documented separately when needed.
SIP UAs MAY listen to that address and use it to become aware of the location of other local users; however they do not respond to the request.
Transmitting a Request
Once the REGISTER method has been constructed, and the destination of the message identified, UACs follow the procedures described in section 8.1.2 to hand off the REGISTER to the transaction layer. IF the transaction layer returns timeout error because the REGISTER yielded no response, the UAC SHOULD NOT immediately reattempt a registration to the same registrar.
Error responses:
If the UA Receives 423, interval too brief, it MAY retire the registration after making the expiration interval of all contact addresses in the REGISTER request equal to or greater than the expiration interval within the Min-Expires header field of the 423 response.
Refernces:
https://www.ietf.org/rfc/rfc3261.txt Sections 10.2.1 - 10.2.8
No comments:
Post a Comment