\section{Registrations}
\label{sec:reg}

\subsection{Overview}
\label{sec:reg:overview}

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.  
\begin{changebar}
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
\end{changebar}
abstract service known as a \emph{location service}, which provides
address bindings for a particular domain.  These address bindings map an
incoming SIP or SIPS URI, {\tt sip:bob@biloxi.com}, for example, to one or more
URIs that are somehow ``closer'' to the desired user, {\tt
sip:bob@engineering.biloxi.com}, 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.

Registration creates bindings in a location service for a particular
domain that associate an address-of-record URI with one or more contact
addresses.  Thus, when a proxy for that domain receives a
request whose \header{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. 

\begin{changebar}
An illustration of the overall registration process is given 
in~\ref{fig:register-fig}. 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.
\end{changebar}

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 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.

\txtpsfigsize{!}{!}{register-fig}{{\REGISTER} example}

\subsection{Constructing the {\REGISTER} Request}
\label{sec:reg:const}

{\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~\ref{sec:general:req} and
Section~\ref{sec:transactions:client}.  

\begin{changebar}
A {\REGISTER} request does \emph{not} establish a dialog. A UAC
{\MAY} include a \header{Route} header field in a {\REGISTER} request
based on a pre-existing route set as described in 
Section~\ref{sec:general:req}. 
The \header{Record-Route} header field has no meaning in {\REGISTER}
requests or responses, and {\MUST} be ignored if present.
In particular, the UAC {\MUSTNOT} create a new
route set based on the presence or absence of a \header{Record-Route}
header field in any response to a {\REGISTER} request. 

The following header fields, except \header{Contact}, {\MUST} be included in a {\REGISTER} request. 
A \header{Contact} header field {\MAY} be included:
\end{changebar}

\begin{description}
\item[\header{Request-URI}:] The \header{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 {\MUSTNOT} be present.

\item[\header{To}:] The \header{To} header field contains the address of
record whose registration is to be created, queried, or modified.  The
\header{To} header field and the \header{Request-URI} field typically
differ, as the former contains a user name.  
\begin{changebar}
This address-of-record {\MUST} be a SIP URI or SIPS URI.
\end{changebar}

\item[\header{From}:] The \header{From} header field contains the
address-of-record of the person responsible for the registration.
The value is the same as the \header{To} header field unless the request
is a third-party registration. 

\item[\header{Call-ID}:] All registrations from a UAC
{\SHOULD} use the same \header{Call-ID} header field value for registrations
sent to a particular registrar.

\motivation{If the same client were to use different \header{Call-ID}
values, a registrar could not detect whether a delayed {\REGISTER}
request might have arrived out of order.} 

\item[\header{CSeq}:] The \header{CSeq} value guarantees proper ordering
of {\REGISTER} requests.  A UA {\MUST} increment the \header{CSeq} value
by one for each {\REGISTER} request with the same \header{Call-ID}.

\item[\header{Contact}:] {\REGISTER} requests {\MAY} contain a \header{Contact} header field with zero or more values containing address bindings.

\end{description}

UAs {\MUSTNOT} send a new registration (that is, containing new
\header{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.

The following \header{Contact} header parameters have a special meaning
in {\REGISTER} requests:

\begin{description}

\item[\header{action}:] The ``\header{action}'' parameter from RFC~2543
has been deprecated.  UACs {\SHOULDNOT} use the ``\header{action}''
parameter.

\item[\header{expires}:] The ``\header{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 \header{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. 

\end{description}

\subsubsection{Adding Bindings}
\label{sec:reg:const:add}

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 \header{To} header field of the
{\REGISTER} request.

The \header{Contact} header field values of the request typically
consist of SIP or SIPS URIs that identify particular SIP endpoints (for
example, ``sip:carol@cube2214a.chicago.com''), but they {\MAY} use any
URI scheme.  A SIP UA can choose to register telephone numbers (with the
tel URL, RFC~2806~\citenorm{rfc2806}) or email addresses (with a mailto
URL, RFC~2368\citenonnorm{rfc2368}) as \header{Contact}s for an
address-of-record, for example.

For example, Carol, with address-of-record ``sip:carol@chicago.com'',
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 \header{Contact} header field, a complete list
of bindings that have been registered for this address-of-record at this
registrar. 

\begin{changebar}
If the address-of-record in the \header{To} header field of a {\REGISTER} 
request is a SIPS URI, then any \header{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.
\end{changebar}

Registrations do not need to update all bindings. Typically, a UA only
updates its own contact addresses.

\paragraph{Setting the Expiration Interval of \header{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~\ref{sec:reg:processing}, 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 \header{Expires} header field or an
``\header{expires}'' \header{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 \header{Contact}
header field values that do not contain the ``\header{expires}'' parameter.

If neither mechanism for expressing a suggested expiration time is
present in a {\REGISTER}, a default suggestion of one hour 
{\SHOULD} be assumed.

\paragraph{Preferences among \header{Contact} Addresses} 

If more than one \header{Contact} is sent in a {\REGISTER} request, the
registering UA intends to associate all of the URIs in these
\header{Contact} header field values with the address-of-record present in the
\header{To} field.  This list can be prioritized with the ``\header{q}''
parameter in the \header{Contact} header field.  The ``\header{q}''
parameter indicates a relative preference for the particular
\header{Contact} header field value compared to other bindings present in this
{\REGISTER} message or existing within the location service of the
registrar.  Section~\ref{sec:proxy-request-processing} describes how a
proxy server uses this preference indication.

\subsubsection{Removing Bindings}
\label{sec:reg:const:rem}

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~\ref{sec:reg:const:add}.  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 \header{Contact} header field value of ``*''
applies to all registrations, but it {\MUSTNOT} be used unless the
\header{Expires} header field is present with a value of ``0''.

\motivation{Use of the ``*'' \header{Contact} header field value allows
a registering UA to remove all of its bindings without knowing
their precise values.}


\subsubsection{Fetching Bindings}
\label{sec:reg:const:fetch}

A success response to any {\REGISTER} request contains the complete list
of existing bindings, regardless of whether the request contained a
\header{Contact} header field. If no \header{Contact} header field 
is present in a {\REGISTER}
request, the list of bindings is left unchanged.  

\subsubsection{Refreshing Bindings}
\label{sec:reg:ua:response}

Each UA is responsible for refreshing the bindings that it has previously
established. A UA {\SHOULDNOT} refresh bindings set up by other UAs.

The 200 (OK) response from the registrar contains a list of
\header{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~\ref{sec:uri_comparison}.  If so, it
updates the expiration time interval according to the \header{expires}
parameter or, if absent, the \header{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 \header{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.

\subsubsection{Setting the Internal Clock}
\label{sec:reg:ua:date}

If the response for a {\REGISTER} request contains a \header{Date} header field,
the client {\MAY} use this header field to learn the current time in
order to set any internal clocks.

\subsubsection{Discovering a Registrar}
\label{sec:reg:const:discover}

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
\header{Request-URI} and address the request there, using the normal SIP
server location mechanisms~\citenorm{draft-ietf-sip-srv}.  For example, the
UA for the user ``sip:carol@chicago.com'' 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~\citenonnorm{Scho9608:Multicast});
however, they do not respond to the request.

\motivation{Multicast registration may be inappropriate in some
environments, for example, if multiple businesses share the same local
area network.}

\subsubsection{Transmitting a Request}
\label{sec:reg:const:transmit}

Once the {\REGISTER} method has been constructed, and the destination of
the message identified, UACs follow the procedures described in
Section~\ref{sec:general:sending} 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 
\begin{changebar} {\SHOULDNOT} immediately
re-attempt a registration to the same registrar. 
\motivation{
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.
}
\end{changebar}

\subsubsection{Error Responses}
\label{sec:reg:const:error}

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 \header{Min-Expires}
header field of the 423 (Interval Too Brief) response.

\subsection{Processing {\REGISTER} Requests}
\label{sec:reg:processing}

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~\ref{sec:general:req-process} and
Section~\ref{sec:transactions:server}, but it accepts only {\REGISTER}
requests.  A registrar 
\begin{changebar}
{\MUST} not 
\end{changebar}
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.

\begin{changebar}
Registrars {\MUST} ignore the \header{Record-Route} header field if
it is included in a {\REGISTER} request. Registrars {\MUSTNOT} include
a \header{Record-Route} header field in any response to a {\REGISTER}
request.

\motivation{A registrar might receive a request that traversed
a proxy which treats {\REGISTER} as an unknown request and which added
a \header{Record-Route} header field value.}

\end{changebar}

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:

\begin{enumerate}
\item The registrar inspects the \header{Request-URI} to determine
whether it has access to bindings for the domain identified in the
\header{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~\ref{sec:proxy}. 

\item To guarantee that the registrar supports any necessary extensions,
the registrar {\MUST} process the \header{Require} header field values as described for
UASs in Section~\ref{sec:general:req-process:header}.

\item A registrar {\SHOULD} authenticate the UAC.  Mechanisms for the
authentication of SIP user agents are described in
Section~\ref{sec:security:auth}. Registration behavior in no way
overrides the generic authentication framework for SIP.  If no
authentication mechanism is available, the registrar {\MAY} take the
\header{From} address as the asserted identity of the originator of the
request.

\item The registrar {\SHOULD} determine if the authenticated user is
authorized to modify registrations for this address-of-record.  For
example, a registrar might consult a authorization database that maps
user names to a list of addresses-of-record for which that user has 
authorization to modify bindings. 
\begin{changebar}
If the authenticated user is not authorized
to modify bindings, the registrar {\MUST} return a 403
(Forbidden) and skip the remaining steps.
\end{changebar}

\motivation{In architectures that support third-party registration, one
entity may be responsible for updating the registrations associated with
multiple addresses-of-record.}

\item The registrar extracts the address-of-record from the \header{To}
header field of the request.  If the address-of-record is not valid for
the domain in the \header{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 
\header{user-param}), and any escaped
characters {\MUST} be converted to their unescaped form. The result serves as
an index into the list of bindings. 

\item The registrar checks whether the request contains the
\header{Contact} header field. If not, it skips to the last step.
\begin{changebar}
If the \header{Contact} header field is present, the registrar checks 
if there is one \header{Contact} field value that
contains the special value ``*'' and an \header{Expires} field.  If the
request has additional \header{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 \header{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 \header{CSeq} in the request is higher than
the value stored for that binding. Otherwise the registrar {\MUST}  leave
 the binding as is.
It then skips to the last step.
\end{changebar}

\item The registrar now processes each contact address in the
\header{Contact} header field in turn. For each address, it determines
the expiration interval as follows:
\begin{itemize}
\item If the field value has an ``\header{expires}'' parameter, that
value {\MUST} be used.

\item If there is no such parameter, but the request has an
\header{Expires} header field, that value {\MUST} be used.

\item If there is neither, a locally-configured default value {\MUST} be used.
\end{itemize}

The registrar {\MAY} shorten the expiration interval.  If and only if
the 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 (Registration Too Brief). 
This response {\MUST} contain a \header{Min-Expires} header field that
states the minimum expiration interval the registrar is willing to
honor.  It then skips the remaining steps.

\motivation{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
\header{Call-ID} value.  If the \header{Call-ID} value in the existing 
binding differs from the \header{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 \header{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.

\motivation{This algorithm ensures that out-of-order requests from the
same UA are ignored.}

Each binding record records the \header{Call-ID} and \header{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.

\item The registrar returns a 200 (OK) response.  The response {\MUST}
contain \header{Contact} header field values enumerating all current bindings. 
Each \header{Contact} value {\MUST} feature an ``\header{expires}''
parameter indicating its expiration interval chosen by the registrar. 
The response {\SHOULD} include a \header{Date} header field.

\end{enumerate}

