\section{Request}
\label{sec:request}

The \header{Request} message format is shown below:

\begin{syntax}
Request
& = & Request-Line         & ; {\rm Section~\ref{sec:Request-Line}}\\
&   & *( general-header    & \\
&   & $|$ request-header   & \\
&   & $|$ entity-header )  & \\
&   & CRLF                 & \\
&   & [ message-body ]     & ; {\rm Section~\ref{sec:message-body}}\\
\end{syntax}

\subsection{Request-Line}
\label{sec:Request-Line}

The \header{Request-Line} begins with a method token, followed by the
\header{Request-URI} and the protocol version, and ending with
\header{CRLF}.  The elements are separated by \header{SP} characters. 
No \header{CR} or \header{LF} are allowed except in the final
\header{CRLF} sequence.

\begin{syntax}
Request-Line & = & Method SP Request-URI SP SIP-Version CRLF 
\end{syntax}

\subsection{Methods}

The methods are defined below.  Methods that are not supported by a
proxy or redirect server are treated by that server as if they were an
{\OPTIONS} method and forwarded accordingly.
Methods that are not
supported by a user agent server or registrar cause a 501 (Not
Implemented) response to be returned (Section~\ref{sec:status}). 

\begin{changebar}
\begin{syntax}
Method & = & "INVITE" $|$ "ACK" $|$ "OPTIONS" $|$ "BYE" \\
       &$|$& "CANCEL" $|$ "REGISTER"\\
\end{syntax}
\end{changebar}

\subsubsection{{\INVITE}}
\label{sec:INVITE}

The {\INVITE} method indicates that the user or service is being invited
to participate in a session.  The message body contains a description of
the session to which the callee is being invited.  For two-party calls,
the caller indicates the type of media it is able to receive 
\begin{changebar}
and possibly the media it is willing to send as well as their parameters
such as network destination.  A success response {\MUST} indicate in its
message body which media the callee wishes to receive and {\MAY}
indicate the media the callee is going to send.

\motivation{Not all session description formats have the ability to
indicate sending media.}
\end{changebar}

A server {\MAY} automatically respond to an invitation for a conference
the user is already participating in, identified either by the SIP
\header{Call-ID} or a globally unique identifier within the session
description, with a 200 (OK) response.

<<<<<<< request.tex
If a user agent receives an {\INVITE} request for an existing
call leg with a higher \header{CSeq} sequence number than any
previous {\INVITE} for the same \header{Call-ID}, it {\MUST} check any
version identifiers in the session description or, if there are no
version identifiers, the content of the session description to see if it
has changed.  It {\MUST} also inspect any other header fields for
changes and act accordingly.  If the session description has changed,
the user agent server {\MUST} adjust the session parameters accordingly,
possibly after asking the user for confirmation.  (Versioning of the
session description can be used to accommodate the capabilities of new
arrivals to a conference, add or delete media or change from a unicast
to a multicast conference.)
=======
If a user agent receives an {\INVITE} request for an existing call leg
with a higher \header{CSeq} sequence number than any previous
{\INVITE} for the same \header{Call-ID}, it {\MUST} check any version
identifiers in the session description or, if there are no version
identifiers, the content of the session description to see if it has
changed.
\begin{changebar}
It {\MUST} also inspect any other header fields for
changes. If there is a change, the user agent {\MUST} update any internal
state or information generated as a result of that header.
\end{changebar}
If the
session description has changed, the user agent server {\MUST} adjust
the session parameters accordingly, possibly after asking the user for
confirmation.  (Versioning of the session description can be used to
accommodate the capabilities of new arrivals to a conference, add or
delete media or change from a unicast to a multicast conference.)
>>>>>>> 1.26

This method {\MUST} be supported by SIP proxy, redirect and user agent
servers as well as clients.

\subsubsection{{\ACK}}
\label{sec:ACK}

The {\ACK} request confirms that the client has received a final
response to an {\INVITE} request.  ({\ACK} is used {\em only} with
{\INVITE} requests.) 2xx responses are acknowledged by client user
agents, all other final responses by the first proxy or client user
agent to receive the response.  The \header{Via} is always initialized
to the host that originates the {\ACK} request, i.e., the client user
agent after a 2xx response or the first proxy to receive a non-2xx final
response.  The {\ACK} request is forwarded as the corresponding
{\INVITE} request, based on its \header{Request-URI}.  See
Section~\ref{sec:transport} for details.  

The {\ACK} request {\MAY} contain a message body with the final
session description to be used by the callee. If the {\ACK} message body
is empty, the callee uses the session description in the {\INVITE}
request.

A proxy server receiving an {\ACK} request after having sent a 3xx, 4xx,
5xx, or 6xx response must make a determination about whether the {\ACK}
is for it, or for some user agent or proxy server further downstream. 
This determination is made by examining the tag in the \header{To}
field.  If the tag in the {\ACK} \header{To} header field matches the
tag in the \header{To} header field of the response, the {\ACK} is meant
for the proxy server.  Otherwise, the {\ACK} {\SHOULD} be proxied
downstream as any other request.

\motivation{It is possible for a user agent client or proxy server to
receive multiple 3xx, 4xx, 5xx, and 6xx responses to a request along a
single branch.  This can happen under various error conditions,
typically when a forking proxy transitions from stateful to stateless
before receiving all responses.  The various responses will all be
identical, except for the tag in the \header{To} field, which is
different for each one.  It can therefore be used as a means to
disambiguate them.}

This method {\MUST} be supported by SIP proxy, redirect and user agent
servers as well as clients.

\subsubsection{{\OPTIONS}}
\label{sec:OPTIONS}

The server is being queried as to its capabilities.  A server that
believes it can contact the user, such as a user agent where the user is
logged in and has been recently active, {\MAY} respond to this request
with a capability set.  A called user agent {\MAY} return a status
reflecting how it would have responded to an invitation, e.g., 600
(Busy).  Such a server {\SHOULD} return an \header{Allow} header field
indicating the methods that it supports.  Proxy and redirect servers
simply forward the request without indicating their capabilities.

This method {\MUST} be supported by SIP proxy, redirect and user agent
servers, registrars and clients.

\subsubsection{{\BYE}}
\label{sec:BYE}

The user agent client uses {\BYE} to indicate to the server that it
wishes to release the call.  A {\BYE} request is forwarded like an
{\INVITE} request and {\MAY} be issued by either caller or callee.  A
party to a call {\SHOULD} issue a {\BYE} request before releasing a call
(``hanging up'').  A party receiving a {\BYE} request {\MUST} cease
transmitting media streams specifically directed at the party issuing
the {\BYE} request.

\begin{changebar}
If the {\INVITE} request contained a \header{Contact} header, the
callee {\SHOULD} send a {\BYE} request to that address rather than the
\header{From} address.
\end{changebar}

This method {\MUST} be supported by proxy servers and {\SHOULD} be
supported by redirect and user agent SIP servers.

\subsubsection{{\CANCEL}}
\label{sec:CANCEL}

The {\CANCEL} request cancels a pending request with the same
\header{Call-ID}, \header{To}, \header{From} and \header{CSeq} (sequence
number only) header field values, but does not affect a completed
request.  (A request is considered completed if the server has returned
a final status response.)

A user agent client or proxy client {\MAY} issue a {\CANCEL} request at
any time.  A proxy, in particular, {\MAY} choose to send a {\CANCEL} to
destinations that have not yet returned a final response after it has
received a 2xx or 6xx response for one or more of the parallel-search
requests.  A proxy that receives a {\CANCEL} request forwards the
request to all destinations with pending requests.  

The \header{Call-ID}, \header{To}, the numeric part of \header{CSeq} and
\header{From} headers in the {\CANCEL} request are identical to those in
the original request.  This allows a {\CANCEL} request to be matched
with the request it cancels.  However, to allow the client to
distinguish responses to the {\CANCEL} from those to the original
request, the \header{CSeq} \header{Method} component is set to
\header{CANCEL}.  The \header{Via} header field is initialized to the
proxy issuing the {\CANCEL} request.  (Thus, responses to this {\CANCEL}
request only reach the issuing proxy.)

Once a user agent server has received a {\CANCEL}, it {\MUSTNOT} issue a
2xx response for the cancelled original request.

A redirect or user agent server receiving a {\CANCEL} request responds
with a status of 200 (OK) if the transaction exists and a status of 481
(Transaction Does Not Exist) if not, but takes no further action.  In
particular, any existing call is unaffected.

\motivation{The {\BYE} request cannot be used to cancel branches of a
parallel search, since several branches may, through intermediate
proxies, find the same user agent server and then terminate the call. 
To terminate a call instead of just pending searches, the UAC must use
{\BYE} instead of or in addition to {\CANCEL}.  While {\CANCEL} can
terminate any pending request other than {\ACK} or {\CANCEL}, it is
typically useful only for {\INVITE}.  200 responses to {\INVITE} and 200
responses to {\CANCEL} are distinguished by the method in the
\header{Cseq} header field, so there is no ambiguity.}

This method {\MUST} be supported by proxy servers and {\SHOULD} be
supported by all other SIP server types.

\subsubsection{{\REGISTER}}
\label{sec:REGISTER}

A client uses the {\REGISTER} method to register the address listed in
the \header{To} header field with a SIP server.

A user agent {\MAY} register with a local server on startup by sending a
{\REGISTER} request to the well-known ``all SIP servers'' multicast
address ``sip.mcast.net'' (224.0.1.75). 
\begin{changebar}
This request {\SHOULD} 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. However, use of administrative scoping
is {\RECOMMENDED}.
\end{changebar}
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. 
A user agent {\MAY} also be configured with the address of a registrar
server to which it sends a {\REGISTER} request upon startup.

\begin{changebar}
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.}
\end{changebar}

The meaning of the {\REGISTER} request-header fields is defined as
follows.  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.

\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 traveller {\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 request is no longer forwarded once it reached the server whose
authoritative domain is the one listed in the \header{Request-URI}.

\begin{changebar}
\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{changebar}

\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
\begin{changebar}
{\SHOULD}
\end{changebar}
be directed to the address(es) given in
the \header{Contact} header. 

If the request does not contain a \header{Contact} header, the
<<<<<<< request.tex
registration remains unchanged.  \motivation{This is useful to obtain
the current list of registrations in the response.} Registrations using
SIP URIs that differ in one or more of \header{host}, \header{port},
\header{transport-param} or \header{maddr-param} from an existing
registration are added to the list of registrations.  Other URI types
are compared according to the standard URI equivalency rules for the URI
schema.  If the URIs are equivalent to that of an existing registration,
the new registration replaces the old one if it has a higher \header{q}
value or, for the same value of \header{q}, if the \header{ttl} value is
=======
registration remains unchanged.  \motivation{This is useful to obtain
the current list of registrations in the response.} Registrations using
SIP URIs that differ in one or more of \header{host}, \header{port},
\header{transport-param} or \header{maddr-param}
\begin{changebar}
(see Figure \ref{fig:url_syntax})
\end{changebar}
from an existing
registration are added to the list of registrations.  Other URI types
are compared according to the standard URI equivalency rules for the URI
schema.  If the URIs are equivalent to that of an existing registration,
the new registration replaces the old one if it has a higher \header{q}
value or, for the same value of \header{q}, if the \header{ttl} value is
>>>>>>> 1.26
higher.  All current registrations {\MUST} share the same
\header{action} value.
\begin{changebar}
Registrations that have a different
\header{action} than current registrations for the same user {\MUST} be
rejected with status of 409 (Conflict). 
\end{changebar}

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

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

\motivation{This allows a service known as ``directed
pick-up''.
\begin{changebar}
In the telephone network, directed pickup permits a user at
a remote station who hears his own phone ringing to pick up at that
station, dial an access code, and be connected to the calling user as
if he had answered his own phone.
\end{changebar}
}

\end{description}

\begin{changebar}
A server {\MAY} choose any duration for the registration
lifetime. Registrations not refreshed after this amount of time
{\SHOULD} be silently discarded. Responses to a registration {\SHOULD}
include an \header{Expires} header (Section~\ref{sec:Expires}),
indicating the time at which the server will drop the registration. If
none is present, one hour is assumed. Clients {\MAY} request a
registration lifetime by indicating the time in an \header{Expires}
header in the request. A server {\SHOULDNOT} use a higher lifetime
than the one requested, but {\MAY} use a lower one.  A single address
(if host-independent) {\MAY} be registered from several different
clients.
\end{changebar}

A client cancels an existing registration by sending a {\REGISTER}
request with an expiration time (\header{Expires}) of zero seconds for a
particular \header{Contact} or the wildcard \header{Contact}
designated by a ``*'' for all registrations. Registrations are matched
based on the \header{user}, \header{host}, \header{port} and
\header{maddr} parameters. 

The server {\SHOULD} return the current list of registrations in the 200
response as \header{Contact} header fields.

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

\begin{changebar}
\motivation{Beyond its use as a simple location service, this method is
needed if there are several SIP servers on a single host.  In that case,
only one of the servers can use the default port number. }
\end{changebar}

Support of this method is {\RECOMMENDED}.

\subsection{Request-URI}

The \header{Request-URI} is a SIP URL as described in
Section~\ref{sec:sip-url} or a general URI.  It indicates the user or
service to which this request is being addressed.  Unlike the
\header{To} field, the \header{Request-URI} {\MAY} be re-written
by proxies.

When used as a \header{Request-URI}, a \header{SIP-URL} {\MUSTNOT}
contain the \header{transport-param}, \header{maddr-param},
\header{ttl-param}, or \header{headers} elements.  A server that
receives a SIP-URL with these elements removes them before further
processing.

\motivation{\sloppy Typically, the UAC sets the \header{Request-URI} and
\header{To} to the same SIP URL, presumed to remain unchanged over long
time periods.  However, if the UAC has cached a more direct path to the
callee, e.g., from the \header{Contact} header field of a response to a
previous request, the \header{To} would still contain the long-term,
``public'' address, while the \header{Request-URI} would be set to the
cached address.

Proxy and redirect servers {\MAY} use the information in the
\header{Request-URI} and request header fields to handle the request and
possibly rewrite the \header{Request-URI}.  For example, a request
addressed to the generic address {\tt sip:sales@acme.com} is proxied to
the particular person, e.g., {\tt sip:bob@ny.acme.com}, with the
\header{To} field remaining as {\tt sip:sales@acme.com}.  At {\tt ny.acme.com},
Bob then designates Alice as the temporary substitute.}

The host part of the \header{Request-URI} typically agrees with one of
the host names of the receiving server.  If it does not, the server
{\SHOULD} proxy the request to the address indicated or return a 404
(Not Found) response if it is unwilling or unable to do so.  For
example, the \header{Request-URI} and server host name can disagree in
the case of a firewall proxy that handles outgoing calls.  This mode of
operation similar to that of HTTP proxies.

If a SIP server receives a request with a URI indicating a scheme other
than SIP which that server does not understand, the server {\MUST}
return a 400 (Bad Request) response.  It {\MUST} do this even if the
\header{To} header field contains a scheme it does understand.
\begin{changebar}
This is because proxies are responsible for processing the
\header{Request-URI}; the \header{To} field is of end to end
significance.
\end{changebar}

\subsubsection{SIP Version}
\label{sec:SIP-Version}

Both request and response messages include the version of SIP in use,
and basically follow [H3.1], with HTTP replaced by SIP.  To be
compliant with this specification,
\begin{changebar}
applications sending
SIP messages {\MUST} include a \header{SIP-Version} of ``SIP/2.0''.
\end{changebar}

\subsection{Option Tags}
\label{sec:option_tags}

Option tags are unique identifiers used to designate new options in SIP. 
These tags are used in \header{Require} (Section~\ref{sec:Require}) and
\header{Unsupported} (Section~\ref{sec:Unsupported}) fields.

\noindent
Syntax:
\begin{syntax}
option-tag & = & token
\end{syntax}

See Section \ref{sec:abnf} for a definition of token. The creator of a
new SIP option {\MUST} either prefix the option with their reverse
domain name or register the new option with the Internet Assigned
Numbers Authority (IANA).  For example, ``com.foo.mynewfeature'' is an
apt name for a feature whose inventor can be reached at
``foo.com''.
\begin{changebar}
Individual organizations are then responsible for
ensuring that option names don't collide.
\end{changebar}
Options registered with
IANA have the prefix ``org.ietf.sip.'', options described in RFCs have
the prefix ``org.ietf.rfc.$N$'', where $N$ is the RFC number.  Option
tags are case-insensitive.

\subsubsection{Registering New Option Tags with IANA}

When registering a new SIP option, the following information {\MUST}
be provided:

\begin{itemize}
\item Name and description of option.  The name {\MAY} be of any length,
but {\SHOULD} be no more than twenty characters long.
\begin{changebar}
The name
{\MUST} consist of alphanum (See Figure \ref{fig:url_syntax} characters only.
\end{changebar}

\item Indication of who has change control over the option (for example,
IETF, ISO, ITU-T, other international standardization bodies, a
consortium or a particular company or group of companies);

\item A reference to a further description, if available, for example
(in order of preference) an RFC, a published paper, a patent filing, a
technical report, documented source code or a computer manual;

\begin{changebar}
\item Contact information (postal and email
address);
\end{changebar}
\end{itemize}

\motivation{Borrowed from RTSP and the RTP AVP.}
