\section{Registrars, Registrations and the {\REGISTER} Method}
\label{sec:REGISTER}

A client uses the {\REGISTER} method to bind the address listed in the
\header{To} header field with a SIP server to one or more URIs where the
client can be reached, contained in the \header{Contact} header fields. 
These URIs may use any URI scheme, not limited to SIP.

It is particularly important that {\REGISTER} requests are authenticated
since they allow to redirect future requests (see Section
\ref{sec:authentication}).

\subsection{Where to Register}

A user agent {\SHOULD} attempt to register periodically according to the
rules below.  A UA is said to be ``visiting'' if its \header{From}
address domain differs from the current network domain and is said to be
``at home'' if the two are the same.

\begin{description}
\item[Local server:] If an outbound proxy is configured, the UA
{\SHOULD} send a {\REGISTER} request to it.  If the UA is visiting, it
uses the \header{From} address consisting of the URL-escaped user
identity at the visited domain, e.g., the user identified as
\texttt{alice@wonderland.com} would register as
\texttt{alice\%40wonderland.com@example.com} if she is visiting the
\texttt{example.com} domain.

\item[Multicast:] If no local outbound proxy is configured, multicast
registrations are addressed to the well-known ``all SIP
servers'' multicast address ``sip.mcast.net'' (224.0.1.75).  This
request {\MUST} be scoped to ensure it is not forwarded beyond the
boundaries of the administrative system.  This {\MAY} be done with
either TTL or administrative scopes \cite{rfc2365}, depending on what is
implemented in the network.  SIP user agents {\MAY} listen to that
address and use it to become aware of the location of other local users
\cite{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.}

\item[Home server:] If the UA is visiting, it {\SHOULD} also send a
registration to its home SIP server, identified by its home address. 
For example, \texttt{alice@wonderland.com} would send a registration to
the SIP server for the domain \texttt{wonderland.com} when she is
visiting another network.  TBD:  What Contact should be used?

\end{description}

A user agent {\SHOULD} register with a local server on startup and
periodically thereafter by sending a {\REGISTER} request.  The period is
given by the expiration time indicated in the registration response.  It
is {\RECOMMENDED} that the UA registers via multicast and send a
registration to its ``home'' address, i.e., the server for the domain
that it uses as its \header{From} address in outgoing requests.

\subsection{{\REGISTER} Header Fields}

\begin{description}
\item[\header{Request-URI}:] The \header{Request-URI} names the
destination of the registration request, i.e., the domain of the
registrar.  The user name {\MUST} be empty.  Generally, the domains in
the \header{Request-URI} and the \header{To} header field have the same
value; however, it is possible to register as a ``visitor'', while
maintaining one's name.  For example, a traveler {\tt
sip:alice@acme.com} (\header{To}) might register under the
\header{Request-URI} {\tt sip:atlanta.hiayh.org}, with the former as the
\header{To} header field and the latter as the \header{Request-URI}. 
The {\REGISTER} request is no longer forwarded once it has reached the
server whose authoritative domain is the one listed in the
\header{Request-URI}.

\item[\header{Call-ID}:] All registrations from a client {\SHOULD} use
the same \header{Call-ID} header value, at least within the same reboot
cycle.

\item[\header{Cseq}:] Registrations with the same \header{Call-ID}
{\MUST} have increasing \header{CSeq} header values. However, the server
does not reject out-of-order requests.
\end{description}

\subsection{Registering Contact Locations}

{\REGISTER} requests are processed in the order received.  Clients
{\SHOULD} avoid sending a new registration (as opposed to a
retransmission) until they have received the response from the server
for the previous one.

\motivation{Clients may register from different locations, by necessity
using different \header{Call-ID} values. Thus, the \header{CSeq} value
cannot be used to enforce ordering. Since registrations are additive,
ordering is less of a problem than if each {\REGISTER} request
completely replaced all earlier ones.}

We define ``address-of-record'' as the SIP address that the
registry knows the registrand, typically of the form ``user@domain''
rather than ``user@host''.  In third-party registration, the entity
issuing the request is different from the entity being registered.

\begin{description}
\item[\header{To}:] The \header{To} header field contains the 
address-of-record whose registration is to be created or updated.

\item[\header{From}:] The \header{From} header field contains the
address-of-record of the person responsible for the registration.  For
first-party registration, it is identical to the \header{To} header
field value. It is {\RECOMMENDED} that registrars
authorize whether the entity in the \header{From} field is allowed to
register addresses for the address-of-record in the \header{To}
field. 

\item[\header{Contact}:] The request {\MAY} contain a \header{Contact}
header field.  Future non-{\REGISTER} requests for the URI given in the
\header{To} header field {\SHOULD} be directed to the address(es) given
in the \header{Contact} header. 

If the request does not contain a \header{Contact} header, the
registration remains unchanged.  \motivation{This is useful to obtain
the current list of registrations in the response, as described below.} 

If a SIP URI in a registration \header{Contact} header field differs
from existing registrations according to the rules in
Section~\ref{sec:uri_comparison}, it is added to the list of
registration.  If it is equivalent, according to these rules, to an
existing registration, all \header{Contact} header field parameters for
this entry are updated accordingly.  URIs other than SIP URIs are
compared according to the standard URI equivalency rules for the URI
schema. 

All current registrations {\MUST} share the same \header{action} value. 
Registrations that have a different \header{action} than current
registrations for the same user {\MUST} be rejected with status of 409
(Conflict). 

The \header{q} value governs the order of trying addresses during
sequential search, as described in Section~\ref{sec:}.
A proxy server ignores the \header{q} parameter when processing
non-{\REGISTER} requests, while a redirect server simply returns that
parameter in its \header{Contact} response header field. 

\motivation{Having the proxy server interpret the \header{q} parameter
is not sufficient to guide proxy behavior, as it is not clear, for
example, how long it is supposed to wait between trying addresses.}
\end{description}

If the registration is changed while a user agent or proxy server
processes an invitation, the new information {\SHOULD} be used.

\subsection{Registration Expiration}

An optional ``\header{expires}'' \header{Contact} parameter indicates
the desired expiration time of the registration.  If a \header{Contact}
entry does not have an ``\header{expires}'' parameter, the
\header{Expires} request and response header field is used as the
default value.  If neither of these mechanisms is used, SIP URIs are
assumed to expire after one hour.  Other URI schemes have no expiration
times.  Registrations not refreshed after this amount of time {\SHOULD}
be silently discarded. 

In a {\REGISTER} request, the client indicates how long it wishes the
registration to be valid.  In the response, the server indicates the
earliest expiration time of all registrations.  If a registration
updates an existing registration, the \header{Expires} value of the most
recent registration is used, even if it is shorter than the earlier
registration.

The registrar determines the expiration time; it may be longer or
shorter than the one requested by the registrand.  The {\REGISTER}
response contains the actual registration lifetime; the client {\MUST}
refresh at least as often and {\SHOULDNOT} refresh more frequently.  In
general, the server {\SHOULD} honor the expiration time offered by the
user agent.  A server {\MAY} decide to lengthen the expiration interval
if, for example, the refresh rate of a particular client exceeds a
threshold.

This behavior is different from RFC 2543, which only allowed
registrars to decrease, but not increase, the interval.

\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 chance
for stale registrations that require proxying effort.}

Registration refreshes {\SHOULD} be sent to the same address as
the original registration, unless redirected.

\subsection{List of Current Registrations}

2xx {\REGISTER} responses {\SHOULD} list all current registration in the
\header{Contact} header field.  An ``\header{expires}'' parameter
{\MUST} indicate the expiration time of the registration.

\subsection{Removing Registrations}

Registrations expire as described above or may be removed explicitly by
setting the \header{expires} parameter for an existing registration to
zero or including an \header{Expires:  0} header field.  Registrations
are matched based on the \header{user}, \header{host}, \header{port} and
\header{maddr} parameters.  A client can remove \emph{all} registrations
by including a single \header{Contact} header field with the wildcard
address ``*''. This usage is only allowed in {\REGISTER} requests when
a \header{Expires} header with value of zero is present.

Support of this method is {\RECOMMENDED}; registrars {\MUST} support it.
