\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.  No LWS is allowed in any of the elements.  The
\header{Request-URI} {\MUSTNOT} be enclosed in "$<>$". 
\header{absoluteURI} is defined in [H3.2.1].

\begin{syntax}
Request-Line & = & Method SP Request-URI SP SIP-Version CRLF\\
Request-URI  & = & SIP-URL $|$ absoluteURI\\
SIP-Version  & = & "SIP/2.0"\\
\end{syntax}

\subsection{Methods}

The methods are described in detail below:  {\REGISTER}
\ref{sec:REGISTER} for registering contact information, {\INVITE},
{\ACK} and {\CANCEL} (Section~\ref{sec:INVITE}) for setting up sessions,
{\BYE} (Section~\ref{sec:BYE}) for terminating sessions and {\OPTIONS}
(Section~\ref{sec:OPTIONS}) for querying servers about their
capabilities.  SIP extensions may define additional methods
(``\header{extension-method}'').

Proxy and redirect servers treat all methods other than {\INVITE} and
{\CANCEL}, whether the method is defined in this specification or
elsewhere, in the same way.  Thus, no method-specific support is
required in these servers for methods other than {\INVITE} and
{\CANCEL}.  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}).  As in HTTP, the \header{Method} token is
case-sensitive.

\begin{syntax}
Method & = & "INVITE" $|$ "ACK" $|$ "OPTIONS" $|$ "BYE" \\
       &   & $|$ "CANCEL" $|$ "REGISTER" $|$ extension-method\\
extension-method & = & token\\
\end{syntax}

\subsection{Request-URI}
\label{sec:requri}

The \header{Request-URI} is a SIP URL as described in
Section~\ref{sec:sip-url} or a general URI (RFC 2396 \cite{rfc2396}). 
In particular, it {\MUSTNOT} contain unescaped spaces or control
characters.  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.

As shown in Table~\ref{tab:url}, the \header{Request-URI} {\MAY} contain
the \header{user-param} parameter as well as transport-related
parameters.  A server that receives a SIP-URL with illegal elements
removes them before further processing.

\motivation{Transport-related parameters are needed when a UAC proxies
all requests to a default proxy, which would then need this information
to generate the appropriate request.} 

\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 is similar to that of HTTP proxies.

SIP servers {\MAY} support \header{Request-URI}s with schemes other than
``sip'', for example the ``tel'' URI scheme \cite{rfc2806}.  It {\MAY}
translate non-SIP URIs using any mechanism at its disposal, resulting in
either a SIP URI or some other scheme.

If a SIP server receives a request with a URI indicating a scheme the
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, since proxies are
responsible for processing the \header{Request-URI}. (The \header{To}
field is only of interest to the UAS.)

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

Both request and response messages include the version of SIP in use,
and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by
SIP/2.0) regarding version ordering, compliance requirements, and
upgrading of version numbers.  To be compliant with this specification,
applications sending SIP messages {\MUST} include a \header{SIP-Version}
of ``SIP/2.0''.  The string is case-insensitive, but implementations
{\MUST} use upper-case.  \motivation{Unlike HTTP/1.1, SIP treats the
version number as a literal string.  In practice, this should make no
difference.}

\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}),
\header{Supported} (Section~\ref{sec:Supported}) and
\header{Unsupported} (Section~\ref{sec:Unsupported}) header fields.

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

See Section \ref{sec:abnf} for the definition of \header{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).  

An example of a reverse-domain-name option is ``com.foo.mynewfeature'',
whose inventor can be reached at ``foo.com''.  For these features,
individual organizations are responsible for ensuring that option names
do not collide within the same domain.  The host name part of the option
{\MUST} use lower-case; the option name is case-sensitive.

Options registered with IANA do not contain periods and are globally
unique. IANA option tags are case-sensitive.

\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.  The name {\MUST}
consist of alphanum (See Figure \ref{fig:url_syntax}) characters only;

\item A listing of any new SIP header fields, header parameter fields or
parameter values defined by this option.  A SIP option {\MUSTNOT}
redefine header fields or parameters defined in either RFC 2543, any
standards-track extensions to RFC 2543, or other extensions registered
through IANA.

\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;

\item Contact information (postal and email address).

\end{itemize}

Registrations should be sent to {\tt iana@iana.org}.

\motivation{This procedure has been borrowed from RTSP \cite{rfc2326}
and the RTP AVP \cite{rfc1890}.}
