Registrations in SIP
SIP offers a discovery capability. If a user wants to initiate a
session with another user, SIP must discover the current host(s) at
which the destination user is reachable. This discovery process is
frequently accomplished by SIP network elements such as proxy servers
and redirect servers which are responsible for receiving a request,
determining where to send it based on knowledge of the location of
the user, and then sending it there. To do this, SIP network
elements consult an abstract service known as a location service,
which provides address bindings for a particular domain. These
address bindings map an incoming SIP or SIPS URI, sip:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
,
for example, to one or more URIs that are somehow "closer" to the
desired user, sip:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
, for example.
Ultimately, a proxy will consult a location service that maps a
received URI to the user agent(s) at which the desired recipient is
currently residing.
10.1 Overview
Registration creates bindings in a location service for a particular
domain that associates an address-of-record URI with one or more
contact addresses. Thus, when a proxy for that domain receives a
request whose Request-URI matches the address-of-record, the proxy
will forward the request to the contact addresses registered to that
address-of-record. Generally, it only makes sense to register an
address-of-record at a domain's location service when requests for
that address-of-record would be routed to that domain. In most
cases, this means that the domain of the registration will need to
match the domain in the URI of the address-of-record.
There are many ways by which the contents of the location service can
be established. One way is administratively. In the above example,
Bob is known to be a member of the engineering department through
access to a corporate database. However, SIP provides a mechanism
for a UA to create a binding explicitly. This mechanism is known as
registration.
Registration entails sending a REGISTER request to a special type of
UAS known as a registrar. A registrar acts as the front end to the
location service for a domain, reading and writing mappings based on
the contents of REGISTER requests. This location service is then
typically consulted by a proxy server that is responsible for routing
requests for that domain.
An illustration of the overall registration process is given in
Figure 2. Note that the registrar and proxy server are logical roles
that can be played by a single device in a network; for purposes of
clarity the two are separated in this illustration. Also note that
UAs may send requests through a proxy server in order to reach a
registrar if the two are separate elements.
SIP does not mandate a particular mechanism for implementing the
location service. The only requirement is that a registrar for some
domain MUST be able to read and write data to the location service,
and a proxy or a redirect server for that domain MUST be capable of
reading that same data. A registrar MAY be co-located with a
particular SIP proxy server for the same domain.
10.2 Constructing the REGISTER Request
REGISTER requests add, remove, and query bindings. A REGISTER
request can add a new binding between an address-of-record and one or
more contact addresses. Registration on behalf of a particular
address-of-record can be performed by a suitably authorized third
party. A client can also remove previous bindings or query to
determine which bindings are currently in place for an address-of-
record.
Except as noted, the construction of the REGISTER request and the
behavior of clients sending a REGISTER request is identical to the
general UAC behavior described in Section 8.1 and Section 17.1.
A REGISTER request does not establish a dialog. A UAC MAY include a
Route header field in a REGISTER request based on a pre-existing
route set as described in Section 8.1. The Record-Route header field
has no meaning in REGISTER requests or responses, and MUST be ignored
if present. In particular, the UAC MUST NOT create a new route set
based on the presence or absence of a Record-Route header field in
any response to a REGISTER request.
The following header fields, except Contact, MUST be included in a
REGISTER request. A Contact header field MAY be included:
Request-URI: The Request-URI names the domain of the location
service for which the registration is meant (for example,
"sip:chicago.com"). The "userinfo" and "@" components of the
SIP URI MUST NOT be present.
To: The To header field contains the address of record whose
registration is to be created, queried, or modified. The To
header field and the Request-URI field typically differ, as
the former contains a user name. This address-of-record MUST
be a SIP URI or SIPS URI.
From: The From header field contains the address-of-record of the
person responsible for the registration. The value is the
same as the To header field unless the request is a third-
party registration.
Call-ID: All registrations from a UAC SHOULD use the same Call-ID
header field value for registrations sent to a particular
registrar.
If the same client were to use different Call-ID values, a
registrar could not detect whether a delayed REGISTER request
might have arrived out of order.
CSeq: The CSeq value guarantees proper ordering of REGISTER
requests. A UA MUST increment the CSeq value by one for each
REGISTER request with the same Call-ID.
Contact: REGISTER requests MAY contain a Contact header field with
zero or more values containing address bindings.
UAs MUST NOT send a new registration (that is, containing new Contact
header field values, as opposed to a retransmission) until they have
received a final response from the registrar for the previous one or
the previous REGISTER request has timed out.
bob
+----+
| UA |
| |
+----+
|
|3)INVITE
|
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
chicago.com +--------+ V
+---------+ 2)Store|Location|4)Query +-----+
|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
+---------+ +--------+=======>+-----+
A 5)Resp |
| |
| |
1)REGISTER| |
| |
+----+ |
| UA |<-------------------------------+
cube2214a| | 6)INVITE
+----+
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
carol
Figure 2: REGISTER example
The following Contact header parameters have a special meaning in
REGISTER requests:
action: The "action" parameter from RFC 2543 has been deprecated.
UACs SHOULD NOT use the "action" parameter.
expires: The "expires" parameter indicates how long the UA would
like the binding to be valid. The value is a number
indicating seconds. If this parameter is not provided, the
value of the Expires header field is used instead.
Implementations MAY treat values larger than 2**32-1
(4294967295 seconds or 136 years) as equivalent to 2**32-1.
Malformed values SHOULD be treated as equivalent to 3600.
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.
10.2.1.2 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. This list can be prioritized with the "q" parameter in the
Contact header field. The "q" parameter indicates a relative
preference for the particular Contact header field value compared to
other bindings for this address-of-record. Section 16.6 describes
how a proxy server uses this preference indication.
10.2.2 Removing Bindings
Registrations are soft state and expire unless refreshed, but can
also be explicitly removed. A client can attempt to influence the
expiration interval selected by the registrar as described in Section
10.2.1. 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
bindings can be removed before their expiration interval has passed.
The REGISTER-specific Contact header field value of "*" applies to
all registrations, but it MUST NOT be used unless the Expires header
field is present with a value of "0".
Use of the "*" Contact header field value allows a registering UA
to remove all bindings associated with an address-of-record
without knowing their precise values.
10.2.3 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.
10.2.4 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. If so, it updates the expiration
time interval according to the expires parameter or, if absent, the
Expires field value. The UA then issues a REGISTER request for each
of its bindings before the expiration interval has elapsed. It MAY
combine several updates into one REGISTER request.
A UA SHOULD use the same Call-ID for all registrations during a
single boot cycle. Registration refreshes SHOULD be sent to the same
network address as the original registration, unless redirected.
10.2.5 Setting the Internal Clock
If the response for a REGISTER request contains a Date header field,
the client MAY use this header field to learn the current time in
order to set any internal clocks.
10.2.6 Discovering a Registrar
UAs can use three ways to determine the address to which to send
registrations: by configuration, using the address-of-record, and
multicast. A UA can be configured, in ways beyond the scope of this
specification, with a registrar address. If there is no configured
registrar address, 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 mechanisms [4]. For example, the UA for
the user "sip:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
" addresses the REGISTER request to
"sip:chicago.com".
Finally, 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 (see [33]); however, they do not respond to the request.
Multicast registration may be inappropriate in some environments,
for example, if multiple businesses share the same local area
network.
10.2.7 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 a timeout error because the REGISTER
yielded no response, the UAC SHOULD NOT immediately re-attempt a
registration to the same registrar.
An immediate re-attempt is likely to also timeout. Waiting some
reasonable time interval for the conditions causing the timeout to
be corrected reduces unnecessary load on the network. No specific
interval is mandated.
10.2.8 Error Responses
If a UA receives a 423 (Interval Too Brief) response, it MAY retry
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
(Interval Too Brief) response.
10.3 Processing REGISTER Requests
A registrar is a UAS that responds to REGISTER requests and maintains
a list of bindings that are accessible to proxy servers and redirect
servers within its administrative domain. A registrar handles
requests according to Section 8.2 and Section 17.2, but it accepts
only REGISTER requests. A registrar MUST not generate 6xx responses.
A registrar MAY redirect REGISTER requests as appropriate. One
common usage would be for a registrar listening on a multicast
interface to redirect multicast REGISTER requests to its own unicast
interface with a 302 (Moved Temporarily) response.
Registrars MUST ignore the Record-Route header field if it is
included in a REGISTER request. Registrars MUST NOT include a
Record-Route header field in any response to a REGISTER request.
A registrar might receive a request that traversed a proxy which
treats REGISTER as an unknown request and which added a Record-
Route header field value.
A registrar has to know (for example, through configuration) the set
of domain(s) for which it maintains bindings. REGISTER requests MUST
be processed by a registrar in the order that they are received.
REGISTER requests MUST also be processed atomically, meaning that a
particular REGISTER request is either processed completely or not at
all. Each REGISTER message MUST be processed independently of any
other registration or binding changes.
When receiving a REGISTER request, a registrar follows these steps:
1. The registrar inspects the Request-URI to determine whether it
has access to bindings for the domain identified in the
Request-URI. If not, and if the server also acts as a proxy
server, the server SHOULD forward the request to the addressed
domain, following the general behavior for proxying messages
described in Section 16.
2. To guarantee that the registrar supports any necessary
extensions, the registrar MUST process the Require header field
values as described for UASs in Section 8.2.2.
3. A registrar SHOULD authenticate the UAC. Mechanisms for the
authentication of SIP user agents are described in Section 22.
Registration behavior in no way overrides the generic
authentication framework for SIP. If no authentication
mechanism is available, the registrar MAY take the From address
as the asserted identity of the originator of the request.
4. The registrar SHOULD determine if the authenticated user is
authorized to modify registrations for this address-of-record.
For example, a registrar might consult an authorization
database that maps user names to a list of addresses-of-record
for which that user has authorization to modify bindings. If
the authenticated user is not authorized to modify bindings,
the registrar MUST return a 403 (Forbidden) and skip the
remaining steps.
In architectures that support third-party registration, one
entity may be responsible for updating the registrations
associated with multiple addresses-of-record.
5. The registrar extracts the address-of-record from the To header
field of the request. If the address-of-record is not valid
for the domain in the Request-URI, the registrar MUST send a
404 (Not Found) response and skip the remaining steps. The URI
MUST then be converted to a canonical form. To do that, all
URI parameters MUST be removed (including the user-param), and
any escaped characters MUST be converted to their unescaped
form. The result serves as an index into the list of bindings.
6. The registrar checks whether the request contains the Contact
header field. If not, it skips to the last step. If the
Contact header field is present, the registrar checks if there
is one Contact field value that contains the special value "*"
and an Expires field. If the request has additional Contact
fields or an expiration time other than zero, the request is
invalid, and the server MUST return a 400 (Invalid Request) and
skip the remaining steps. If not, the registrar checks whether
the Call-ID agrees with the value stored for each binding. If
not, it MUST remove the binding. If it does agree, it MUST
remove the binding only if the CSeq in the request is higher
than the value stored for that binding. Otherwise, the update
MUST be aborted and the request fails.
7. The registrar now processes each contact address in the Contact
header field in turn. For each address, it determines the
expiration interval as follows:
- If the field value has an "expires" parameter, that value
MUST be taken as the requested expiration.
- If there is no such parameter, but the request has an
Expires header field, that value MUST be taken as the
requested expiration.
- If there is neither, a locally-configured default value MUST
be taken as the requested expiration.
The registrar MAY choose an expiration less than the requested
expiration interval. If and only if the requested expiration
interval is greater than zero AND smaller than one hour AND
less than a registrar-configured minimum, the registrar MAY
reject the registration with a response of 423 (Interval Too
Brief). This response MUST contain a Min-Expires header field
that states the minimum expiration interval the registrar is
willing to honor. It then skips the remaining steps.
Allowing the registrar to set the registration interval
protects it against excessively frequent registration refreshes
while limiting the state that it needs to maintain and
decreasing the likelihood of registrations going stale. The
expiration interval of a registration is frequently used in the
creation of services. An example is a follow-me service, where
the user may only be available at a terminal for a brief
period. Therefore, registrars should accept brief
registrations; a request should only be rejected if the
interval is so short that the refreshes would degrade registrar
performance.
For each address, the registrar then searches the list of
current bindings using the URI comparison rules. If the
binding does not exist, it is tentatively added. If the
binding does exist, the registrar checks the Call-ID value. If
the Call-ID value in the existing binding differs from the
Call-ID value in the request, the binding MUST be removed if
the expiration time is zero and updated otherwise. If they are
the same, the registrar compares the CSeq value. If the value
is higher than that of the existing binding, it MUST update or
remove the binding as above. If not, the update MUST be
aborted and the request fails.
This algorithm ensures that out-of-order requests from the same
UA are ignored.
Each binding record records the Call-ID and CSeq values from
the request.
The binding updates MUST be committed (that is, made visible to
the proxy or redirect server) if and only if all binding
updates and additions succeed. If any one of them fails (for
example, because the back-end database commit failed), the
request MUST fail with a 500 (Server Error) response and all
tentative binding updates MUST be removed.
8. The registrar returns a 200 (OK) response. The response MUST
contain Contact header field values enumerating all current
bindings. Each Contact value MUST feature an "expires"
parameter indicating its expiration interval chosen by the
registrar. The response SHOULD include a Date header field.
