\section{SIP Messages}
\label{sec:message}

SIP is a text-based protocol and uses the ISO~10646 character set in
UTF-8 encoding (RFC~2279~\citenorm{rfc2279}).

A SIP message is either a request from a client to a server, or a
response from a server to a client.

Both \header{Request} (section~\ref{sec:request}) and \header{Response}
(section~\ref{sec:response}) messages use the basic format of 
RFC~2822~\citenorm{rfc2822}, even though the syntax differs in character set and
syntax specifics.  (SIP allows header fields that would not be valid 
RFC~2822 header fields, for example.) Both types of messages consist of 
a \header{start-line}, one or more
header fields, an empty line indicating the
end of the header fields, and an optional \header{message-body}. 

\begin{syntax}
generic-message & = & start-line\\
                &   & *message-header\\
                &   & CRLF\\
                &   & [ message-body ]\\
start-line      & = & Request-Line $/$ Status-Line\\
\end{syntax}
 
The start-line, each message-header line, and the empty line {\MUST} be
terminated by a carriage-return line-feed sequence (\header{CRLF}). 
Note that the empty line {\MUST} be present even if the message-body is
not. 

Except for the above difference in character sets, much of SIP's message
and header field syntax is identical to HTTP/1.1.  Rather than repeating
the syntax and semantics here, we use [HX.Y] to refer to Section X.Y of
the current HTTP/1.1 specification (RFC~2616~\citenorm{rfc2616}). 

However, SIP is not an extension of HTTP.

\subsection{Requests}
\label{sec:message-requests}
\label{sec:request}
\label{sec:Request-Line}

SIP requests are distinguished by having a \header{Request-Line} for a
\header{start-line}.  A \header{Request-Line} contains a method name, a
\header{Request-URI}, and the protocol version separated by
a single space (\header{SP}) character.

The \header{Request-Line} ends with \header{CRLF}.  No \header{CR} or
\header{LF} are allowed except in the end-of-line \header{CRLF}
sequence.  No linear whitespace (LWS) is allowed in any of the elements. 

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

\begin{description}
\item[Method:]


\begin{changebar} This specification defines six methods:  {\REGISTER} for registering
contact information, {\INVITE}, {\ACK}, and {\CANCEL} for
setting up sessions,  {\BYE} for terminating sessions, and {\OPTIONS} for
querying servers about their capabilities. SIP extensions, documented in standards track RFCs, may define additional methods. 
\end{changebar}


\item[Request-URI:] The \header{Request-URI} is a SIP or SIPS URI as
described in Section~\ref{sec:sip-url} or a general URI
(RFC~2396~\citenorm{rfc2396}).  It indicates the user or service to
which this request is being addressed.  The \header{Request-URI}
{\MUSTNOT} contain unescaped spaces or control characters and {\MUSTNOT}
be enclosed in "$<>$".

SIP elements {\MAY} support \header{Request-URI}s with schemes other
than ``sip'' and ``sips'', for example the ``tel'' URI scheme of
RFC~2806~\citenorm{rfc2806}.  SIP elements {\MAY} translate non-SIP URIs
using any mechanism at their disposal, resulting in either SIP URI, SIPS
URI, or some other scheme.

\item[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 \header{SIP-Version} string is
case-insensitive, but implementations {\MUST} send upper-case.

\motivation{Unlike HTTP/1.1, SIP treats the version number as a literal
string.  In practice, this should make no difference.}

\end{description}

\subsection{Responses}
\label{sec:message-responses}
\label{sec:response}
\label{sec:Status-Line}

SIP responses are distinguished from requests by having a
\header{Status-Line} as their \header{start-line}.  A
\header{Status-Line} consists of the protocol version followed by a
numeric \header{Status-Code} and its associated textual phrase, with
each element separated by a single \header{SP} character.
 
No \header{CR} or \header{LF} is allowed except in the final
\header{CRLF} sequence.

\begin{syntax}
Status-Line      & = & SIP-Version SP Status-Code SP Reason-Phrase CRLF \\
\end{syntax}

The \header{Status-Code} is a 3-digit integer result code that indicates
the outcome of an attempt to understand and satisfy a request.  The
\header{Reason-Phrase} is intended to give a short textual description
of the \header{Status-Code}.  The \header{Status-Code} is intended for
use by automata, whereas the \header{Reason-Phrase} is intended for the
human user.  A client is not required to examine or display the
\header{Reason-Phrase}.

While this specification suggests specific wording for the reason
phrase, implementations {\MAY} choose other text, for example, in the language
indicated in the \header{Accept-Language} header field of the request.


The first digit of the \header{Status-Code} defines the class of
response.  The last two digits do not have any categorization role.  For
this reason, any response with a status code between 100 and 199 is
referred to as a ``1xx response'', any response with a status code
between 200 and 299 as a ``2xx response'', and so on.  SIP/2.0 allows
six values for the first digit:

\begin{description}
\item[1xx:] Provisional -- request received, continuing to process the
request;

\item[2xx:] Success -- the action was successfully received, understood,
and accepted;

\item[3xx:] Redirection -- further action needs to be taken in order to
complete the request;

\item[4xx:] Client Error -- the request contains bad syntax or cannot be
fulfilled at this server;

\item[5xx:] Server Error -- the server failed to fulfill an apparently
valid request;

\item[6xx:] Global Failure -- the request cannot be fulfilled at any
server.

\end{description}

Section~\ref{sec:response-codes} defines these classes and describes the
individual codes.

\subsection{Header Fields}
\label{sec:message-header-fields}

SIP header fields are similar to HTTP header fields in both syntax and
semantics.  In particular, SIP header fields follow the [H4.2]
definitions of syntax for \header{message-header} and the rules for
extending header fields over multiple lines.  However, the latter is
specified in HTTP with implicit whitespace and folding.  This
specification conforms with RFC~2234~\citenorm{rfc2234} and uses only
explicit whitespace and folding as an integral part of the grammar.

[H4.2] also specifies that multiple header fields of the same field name
whose value is a comma-separated list can be combined into one header
field.  That applies to SIP as well, but the specific rule is different
because of the different grammars.  Specifically, any SIP header whose
grammar is of the form:

\begin{syntax}
header & = & "header-name" HCOLON header-value *(COMMA header-value) \\
\end{syntax}

allows for combining header fields of the same name into a
comma-separated list.  This is also true for the \header{Contact}
header, as long as none of the header field values are ``*''.

\subsubsection{Header Field Format}
\label{sec:header-format}

Header fields follow the same generic header format as that given in 
Section 2.2 of RFC~2822~\citenorm{rfc2822}.  Each header field consists 
of a field name followed by a colon (":") and the field value.
\begin{center}
\begin{sf}
field-name: field-value
\end{sf}
\end{center}
The formal grammar for a \header{message-header} specified in
Section~\ref{sec:abnf} allows for an arbitrary amount of whitespace on
either side of the colon; however, implementations should avoid spaces
between the field name and the colon and use a single space
(\header{SP}) between the colon and the \header{field-value}.  Thus,
\begin{verbatim}
Subject:            lunch
Subject      :      lunch
Subject            :lunch
Subject: lunch
\end{verbatim}
are all valid and equivalent, but the last is the preferred form.

Header fields can be extended over multiple lines by preceding each
extra line with at least one \header{SP} or horizontal tab
(\header{HT}).  The line break and the whitespace at the beginning of
the next line are treated as a single \header{SP} character.  Thus, the
following are equivalent:

\begin{verbatim}
Subject: I know you're there, pick up the phone and talk to me!
Subject: I know you're there,
         pick up the phone
         and talk to me!
\end{verbatim}

The relative order of header fields with different field names is not
significant.  However, it is {\RECOMMENDED} that header fields which are
needed for proxy processing (\header{Via}, \header{Route},
\header{Record-Route}, \header{Proxy-Require}, \header{Max-Forwards},
and \header{Proxy-Authorization}, for example) appear towards the top of
the message to facilitate rapid parsing.  The relative order of header
field rows with the same field name is important.  Multiple header field
rows with the same \header{field-name} {\MAY} be present in a message if
and only if the entire field-value for that header field is defined as a
comma-separated list (that is, if follows the grammar defined in 
Section~\ref{sec:message-header-fields}).  It {\MUST} be possible to combine the
multiple header field rows into one ``field-name:  field-value'' pair,
without changing the semantics of the message, by appending each
subsequent \header{field-value} to the first, each separated by a comma. 
The exceptions to this rule are the \header{WWW-Authenticate},
\header{Authorization}, \header{Proxy-Authenticate}, and
\header{Proxy-Authorization} header fields.  Multiple header field rows
with these names {\MAY} be present in a message, but since their grammar
does not follow the general form listed in 
Section~\ref{sec:message-header-fields}, they {\MUSTNOT} be combined into a
single header field row. 

Implementations {\MUST} be able to process multiple header field rows with
the same name in any combination of the single-value-per-line or
comma-separated value forms.

The following groups of header field rows are valid and equivalent:
\begin{verbatim}
Route: <sip:alice@atlanta.com>
Subject: Lunch
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>

Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Subject: Lunch

Subject: Lunch
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, <sip:carol@chicago.com>
\end{verbatim}

Each of the following blocks is valid but not equivalent to the others:
\begin{verbatim}
Route: <sip:alice@atlanta.com>
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>

Route: <sip:bob@biloxi.com>
Route: <sip:alice@atlanta.com>
Route: <sip:carol@chicago.com>

Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,<sip:bob@biloxi.com>
\end{verbatim}

The format of a header field-value is defined per header-name.  It will
always be either an opaque sequence of TEXT-UTF8 octets, or a
combination of whitespace, tokens, separators, and quoted strings.  Many
existing header fields will adhere to the general form of a value followed by
a semi-colon separated sequence of parameter-name, parameter-value
pairs:
\begin{center}
\begin{sf}
field-name: field-value *(;parameter-name=parameter-value)
\end{sf}
\end{center}


Even though an arbitrary number of parameter pairs may be attached to a
header field value, any given \header{parameter-name} {\MUSTNOT} appear
more than once. 

When comparing header fields, field names are always case-insensitive. 
Unless otherwise stated in the definition of a particular header field,
field values, parameter names, and parameter values are
case-insensitive.  Tokens are always case-insensitive.  Unless specified
otherwise, values expressed as quoted strings are case-sensitive.

For example,
\begin{verbatim}
Contact: <sip:alice@atlanta.com>;expires=3600
\end{verbatim}
is equivalent to
\begin{verbatim}
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
\end{verbatim}
and
\begin{verbatim}
Content-Disposition: session;handling=optional
\end{verbatim}
is equivalent to
\begin{verbatim}
content-disposition: Session;HANDLING=OPTIONAL
\end{verbatim}

The following two header fields are not equivalent:
\begin{verbatim}
Warning: 370 devnull "Choose a bigger pipe"
Warning: 370 devnull "CHOOSE A BIGGER PIPE"
\end{verbatim}

\subsubsection{Header Field Classification}
\label{sec:general-header} 

Some header fields only make sense in requests or responses.  These are
called request header fields and response header fields, respectively. 
If a header field appears in a message not matching its category (such as a
request header field in a response), it {\MUST} be ignored. 
Section~\ref{sec:header-fields} defines the classification of each
header field.

\subsubsection{Compact Form}
\label{sec:message-compact}

SIP provides a mechanism to represent common header field names in an
abbreviated form.  This may be useful when messages would otherwise
become too large to be carried on the transport available to it
(exceeding the maximum transmission unit (MTU) when using UDP, for
example).  These compact forms are defined in
Section~\ref{sec:header-fields}.  A compact form {\MAY} be substituted
for the longer form of a header field name at any time without changing the
semantics of the message.  A header field name {\MAY} appear
in both long and short forms within the same message.  Implementations
{\MUST} accept both the long and short forms of each header name.

\subsection{Bodies}
\label{sec:message-bodies}
\label{sec:message-body}

Requests, including new requests defined in extensions to this
specification, {\MAY} contain message bodies unless otherwise noted. 
 The interpretation of the body depends on the request
method.  

For response messages, the request method and the response status code
determine the type and interpretation of any message body.  All
responses {\MAY} include a body. 

\subsubsection{Message Body Type}
\label{sec:message-body-type}

The Internet media type of the message body {\MUST} be given by the
\header{Content-Type} header field.  If the body has undergone any
encoding such as compression, then this {\MUST} be indicated by the
\header{Content-Encoding} header field; otherwise,
\header{Content-Encoding} {\MUST} be omitted.  If applicable, the
character set of the message body is indicated as part of the
\header{Content-Type} header-field value.

The ``multipart'' MIME type defined in RFC~2046~\citenorm{rfc2046}
{\MAY} be used within the body of the message.  Implementations that
send requests containing multipart message bodies {\MUST} send a session
description as a non-multipart message body if the remote implementation
requests this through an \header{Accept} header field that does not
contain \header{multipart}.

Note that SIP messages {\MAY} contain binary bodies or body parts.

\subsubsection{Message Body Length}
\label{sec:message-body-length}

The body length in bytes is provided by the
\header{Content-Length} header field.  Section~\ref{sec:Content-Length}
describes the necessary contents of this header field in detail.

The ``chunked'' transfer encoding of HTTP/1.1 {\MUSTNOT} be used for
SIP.  (Note:  The chunked encoding modifies the body of a message in
order to transfer it as a series of chunks, each with its own size
indicator.)

\subsection{Framing SIP messages}
\label{sec:message-framing}


Unlike HTTP, SIP implementations can use UDP or other unreliable
datagram protocols.  Each such datagram carries one request or response. 
See Section~\ref{sec:transport} on constraints on usage of unreliable
transports.

Implementations processing SIP messages over stream-oriented
transports {\MUST} ignore any \header{CRLF} appearing before the
\header{start-line} [H4.1]. 
\begin{changebar}
\motivation{
The \header{Content-Length} header field value is used to locate
the end of each SIP message in a stream. It will always be present
when SIP messages are sent over stream-oriented transports.
}
\end{changebar}

