| Article Index |
|---|
| Registrations in SIP |
| Page 2 |
| Page 3 |
| Page 4 |
| Page 5 |
| Page 6 |
| Page 7 |
| All Pages |
Page 3 of 7
10.2.1 Adding Bindings
The REGISTER request sent to a registrar includes the contact
address(es) to which SIP requests for the address-of-record should be
forwarded. The address-of-record is included in the To header field
of the REGISTER request.
The Contact header field values of the request typically consist of
SIP or SIPS URIs that identify particular SIP endpoints (for example,
"sip: This e-mail address is being protected from spambots. You need JavaScript enabled to view it "), but they MAY use any URI scheme.
A SIP UA can choose to register telephone numbers (with the tel URL,
RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])
as Contacts for an address-of-record, for example.
For example, Carol, with address-of-record "sip: This e-mail address is being protected from spambots. You need JavaScript enabled to view it ",
would register with the SIP registrar of the domain chicago.com. Her
registrations would then be used by a proxy server in the chicago.com
domain to route requests for Carol's address-of-record to her SIP
endpoint.
Once a client has established bindings at a registrar, it MAY send
subsequent registrations containing new bindings or modifications to
existing bindings as necessary. The 2xx response to the REGISTER
request will contain, in a Contact header field, a complete list of
bindings that have been registered for this address-of-record at this
registrar.
If the address-of-record in the To header field of a REGISTER request
is a SIPS URI, then any Contact header field values in the request
SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs
under a SIPS address-of-record when the security of the resource
represented by the contact address is guaranteed by other means.
This may be applicable to URIs that invoke protocols other than SIP,
or SIP devices secured by protocols other than TLS.
Registrations do not need to update all bindings. Typically, a UA
only updates its own contact addresses.
10.2.1.1 Setting the 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. (As described in Section 10.3, the
registrar selects the actual time interval based on its local
policy.)
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
binding is given in a single REGISTER request, whereas the former
suggests an expiration interval for all Contact header field values
that do not contain the "expires" parameter.
If neither mechanism for expressing a suggested expiration time is
present in a REGISTER, the client is indicating its desire for the
server to choose.
