\section{SIP Message Overview}
\label{sec:message}

SIP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 2279 \cite{rfc2279}).  Senders {\MUST} terminate
lines with a CRLF, but receivers {\MUST} also interpret CR and LF by
themselves as line terminators.  Only the combinations CR CR, LF LF and
CRLF CRLF terminate the message header.  Implementations {\MUST} only
send CRLF CRLF.  \motivation{CR and LF instead of CRLF is for
backwards-compatibility; their use is deprecated.}

Except for the above difference in character sets and line termination,
much of the message syntax is and header fields are 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 \cite{rfc2616}).  In addition, we describe SIP in both prose
and an augmented Backus-Naur form (ABNF).  See section \ref{sec:abnf}
for an overview of ABNF.

Note, however, that SIP is not an extension of HTTP.

Unlike HTTP, SIP {\MAY} use UDP or other unreliable datagram protocols. 
Each such datagram carries one request or response.  Datagrams,
including all headers, {\SHOULDNOT} be larger than the path maximum
transmission unit (MTU) if the MTU is known, or 1500 bytes if the MTU is
unknown.  However, implementations {\MUST} be able to handle messages up
to the maximum datagram packet size.  For UDP, this size is 65,535
bytes, including headers.

\motivation{The MTU of 1500 bytes accommodates encapsulation within the
``typical'' ethernet MTU without IP fragmentation.  Recent studies
\cite[p.~154]{Stev94:TCP1} indicate that an MTU of 1500 bytes is a
reasonable assumption.  The next lower common MTU values are 1006 bytes
for SLIP and 296 for low-delay PPP (RFC 1191 \cite{rfc1191}).  Thus,
another reasonable value would be a message size of 950 bytes, to
accommodate packet headers within the SLIP MTU without fragmentation.}

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

\begin{syntax}
SIP-message & = & Request $|$ Response
\end{syntax}

Both \header{Request} (section \ref{sec:request}) and \header{Response}
(section \ref{sec:response}) messages use the \header{generic-message}
format of RFC 822 \cite{rfc822} for transferring entities (the body of
the message).  Both types of messages consist of a \header{start-line},
one or more header fields (also known as ``headers''), an empty line
(i.e., a line with nothing preceding the carriage-return line-feed
(\header{CRLF})) indicating the end of the header fields, and an
optional \header{message-body}.  To avoid confusion with similar-named
headers in HTTP, we refer to the headers describing the message body as
entity headers.  These components are described in detail in the
upcoming sections.

\begin{syntax}
generic-message & = & start-line\\
                &   & *message-header\\
                &   & CRLF\\
                &   & [ message-body ]\\
&&\\
start-line      & = & Request-Line $|$ & {\rm ;Section~\ref{sec:Request-Line}}\\
                &   & Status-Line      & {\rm ;Section~\ref{sec:Status-Line}}\\ 
\end{syntax}

\begin{syntax}
message-header
& = & ( general-header     & \\
&   & $|$ request-header   & \\
&   & $|$ response-header  & \\
&   & $|$ entity-header )  & \\
\end{syntax}

\begin{changebar}
\begin{table}
\begin{syntax}
\header{general-header}
&  =  & \header{Accept}                & ; Section~\ref{sec:Accept}\\
& $|$ & \header{Accept-Encoding}       & ; Section~\ref{sec:Accept-Encoding}\\
& $|$ & \header{Accept-Language}       & ; Section~\ref{sec:Accept-Language}\\
& $|$ & \header{Call-ID}               & ; Section~\ref{sec:Call-ID}\\
& $|$ & \header{Call-Info}             & ; Section~\ref{sec:Call-Info}\\
& $|$ & \header{Contact}               & ; Section~\ref{sec:Contact}\\
& $|$ & \header{CSeq}                  & ; Section~\ref{sec:CSeq}\\
& $|$ & \header{Date}                  & ; Section~\ref{sec:Date}\\
& $|$ & \header{Encryption}            & ; Section~\ref{sec:Encryption}\\
& $|$ & \header{From}                  & ; Section~\ref{sec:From}\\
& $|$ & \header{MIME-Version}          & ; Section~\ref{sec:MIME-Version}\\
& $|$ & \header{Organization}          & ; Section~\ref{sec:Organization}\\
& $|$ & \header{Record-Route}          & ; Section~\ref{sec:Record-Route}\\
& $|$ & \header{Require}               & ; Section~\ref{sec:Require}\\
& $|$ & \header{Supported}             & ; Section~\ref{sec:Supported}\\
& $|$ & \header{Timestamp}             & ; Section~\ref{sec:Timestamp}\\
& $|$ & \header{To}                    & ; Section~\ref{sec:To}\\
& $|$ & \header{User-Agent}            & ; Section~\ref{sec:User-Agent}\\
& $|$ & \header{Via}                   & ; Section~\ref{sec:Via}\\
\header{entity-header}
&  =  & \header{Allow}                 & ; Section~\ref{sec:Allow}\\
& $|$ & \header{Content-Disposition}   & ; Section~\ref{sec:Content-Disposition}\\
& $|$ & \header{Content-Encoding}      & ; Section~\ref{sec:Content-Encoding}\\
& $|$ & \header{Content-Language}      & ; Section~\ref{sec:Content-Language}\\
& $|$ & \header{Content-Length}        & ; Section~\ref{sec:Content-Length}\\
& $|$ & \header{Content-Type}          & ; Section~\ref{sec:Content-Type}\\
& $|$ & \header{Expires}               & ; Section~\ref{sec:Expires}\\
\header{request-header}
& $=$ & \header{Alert-Info}            & ; Section~\ref{sec:Alert-Info}\\
& $|$ & \header{Authorization}         & ; Section~\ref{sec:Authorization}\\
& $|$ & \header{In-Reply-To}           & ; Section~\ref{sec:In-Reply-To}\\
& $|$ & \header{Max-Forwards}          & ; Section~\ref{sec:Max-Forwards}\\
& $|$ & \header{Priority}              & ; Section~\ref{sec:Priority}\\
& $|$ & \header{Proxy-Authorization}   & ; Section~\ref{sec:Proxy-Authorization}\\
& $|$ & \header{Proxy-Require}         & ; Section~\ref{sec:Proxy-Require}\\
& $|$ & \header{Route}                 & ; Section~\ref{sec:Route}\\
& $|$ & \header{Response-Key}          & ; Section~\ref{sec:Response-Key}\\
& $|$ & \header{Subject}               & ; Section~\ref{sec:Subject}\\
\header{response-header}
& $=$ & \header{Authentication-Info}   & ; Section~\ref{sec:Authentication-Info}\\
& $|$ & \header{Error-Info}            & ; Section~\ref{sec:Error-Info}\\
& $|$ & \header{Proxy-Authenticate}    & ; Section~\ref{sec:Proxy-Authenticate}\\
& $|$ & \header{Retry-After}           & ; Section~\ref{sec:Retry-After}\\
& $|$ & \header{Server}                & ; Section~\ref{sec:Server}\\
& $|$ & \header{Unsupported}           & ; Section~\ref{sec:Unsupported}\\
& $|$ & \header{Warning}               & ; Section~\ref{sec:Warning}\\
& $|$ & \header{WWW-Authenticate}      & ; Section~\ref{sec:WWW-Authenticate}\\
\end{syntax}
\caption{SIP headers}
\label{tab:sip-headers}
\end{table}
\end{changebar}

In the interest of robustness, any leading empty line(s) {\MUST} be
ignored.  In other words, if the \header{Request} or \header{Response}
message begins with one or more \header{CRLF}, \header{CR}, or
\header{LF}s, these characters {\MUST} be ignored.

\newpage
