\section{Header Fields}
\label{sec:header-fields}

The general syntax for header fields is covered in
Section~\ref{sec:message-header-fields}.  This section lists the full
set of header fields along with notes on syntax, meaning, and usage. 
Throughout this section, we use [HX.Y] to refer to Section X.Y of the
current HTTP/1.1 specification RFC~2616~\citenorm{rfc2616}.  Examples of
each header field are given.

Information about header fields in relation to methods and proxy
processing is summarized in Tables~\ref{tab:headers1} 
and~\ref{tab:headers2}. 

The ``where'' column describes the request and response types in which
the header field can be used.  Values in this column are:

\begin{description}

\item[R:] header field may only appear in requests;

\item[r:] header field may only appear in responses;

\item[2xx, 4xx, etc.:] A numerical value or range indicates response
codes with which the header field can be used;

\item[c:] header field is copied from the request to the response.

\item An empty entry in the ``where'' column indicates that the header
field may be present in all requests and responses.

\end{description}

The ``proxy'' column describes the operations a proxy may perform on a
header field:

\begin{description}

\begin{changebar}
\item[a:] A proxy can add or concatenate the header field if not present.

\item[m:] A proxy can modify an existing header field value.

\item[d:] A proxy can delete a header field value.

\item[r:] A proxy must be able to read the header field, and thus this
header field cannot be encrypted.
\end{changebar}

\end{description}

The next six columns relate to the presence of a header field in a
method:

\begin{description}

\item[c:] Conditional; requirements on the header field depend on
the context of the message. 

\item[m:] The header field is mandatory.

\item[m*:] The header field {\SHOULD} be sent, but clients/servers need to be
prepared to receive messages without that header field. 

\item[o:] The header field is optional.

\item[t:] The header field {\SHOULD} be sent, but clients/servers need to be
prepared to receive messages without that header field.  If a 
stream-based protocol (such as TCP) is used
as a transport, then the header field {\MUST} be sent.

\item[*:] The header field is required if the message body is not
empty.  See sections~\ref{sec:Content-Length}, \ref{sec:Content-Type}
and~\ref{sec:message-body} for details.

\begin{changebar}
\item[-:] The header field is not applicable.
\end{changebar}

\end{description}

``Optional'' means that a UA {\MAY} include the header field in a
request or response, and a UA {\MAY} ignore the header field if present
in the request or response (The exception to this rule is the
\header{Require} header field discussed in~\ref{sec:Require}).  A
``mandatory'' header field {\MUST} be present in a request, and {\MUST}
be understood by the UAS receiving the request.  A mandatory response
header field {\MUST} be present in the response, and the header field
{\MUST} be understood by the UAC processing the response.  ``Not
applicable'' means that the header field {\MUSTNOT} be present in a
request.  If one is placed in a request by mistake, it {\MUST} be
ignored by the UAS receiving the request.  Similarly, a header field
labeled ``not applicable'' for a response means that the UAS {\MUSTNOT}
place the header field in the response, and the UAC {\MUST} ignore the header
field in the response.

A UA {\SHOULD} ignore extension header parameters that are not understood.

\begin{changebar}
\begin{table}[htpb]
\begin{center}
\begin{tabular}{lcccccccc}
Header field                & where & proxy &ACK&BYE&CAN&INV&OPT&REG\\
\hline
\header{Accept}             &  R     &    & - & o & - & o & m* & o\\
\header{Accept}             & 2xx    &    & - & - & - & o & m* & o\\
\header{Accept}             & 415    &    & - & c & - & c & c & c\\
\header{Accept-Encoding}    &  R     &    & - & o & - & o & o & o\\
\header{Accept-Encoding}    & 2xx    &    & - & - & - & o & m* & o\\
\header{Accept-Encoding}    & 415    &    & - & c & - & c & c & c\\
\header{Accept-Language}    &  R     &    & - & o & - & o & o & o\\
\header{Accept-Language}    & 2xx    &    & - & - & - & o & m* & o\\
\header{Accept-Language}    & 415    &    & - & c & - & c & c & c\\
\header{Alert-Info}         &  R     & ar & - & - & - & o & - & -\\
\header{Alert-Info}         & 180    & ar & - & - & - & o & - & -\\
\header{Allow}              &  R     &    & - & o & - & o & o & o\\
\header{Allow}              & 2xx    &    & - & o & - & m* & m* & o\\
\header{Allow}              &  r     &    & - & o & - & o & o & o\\
\header{Allow}              & 405    &    & - & m & - & m & m & m\\
\header{Authentication-Info}& 2xx    &    & - & o & - & o & o & o\\
\header{Authorization}      &  R     &    & o & o & o & o & o & o\\
\header{Call-ID}            &  c    & r  & m & m & m & m & m & m\\
\header{Call-Info}          &       & ar & - & - & - & o & o & o\\
\header{Contact}            &  R     &    & o & - & - & m & o & o\\
\header{Contact}            & 1xx    &    & - & - & - & o & - & -\\
\header{Contact}            & 2xx    &    & - & - & - & m & o & o\\
\header{Contact}            & 3xx    & d  & - & o & - & o & o & o\\
\header{Contact}            & 485    &    & - & o & - & o & o & o\\
\header{Content-Disposition}&       &    & o & o & - & o & o & o\\
\header{Content-Encoding}   &       &    & o & o & - & o & o & o\\
\header{Content-Language}   &       &    & o & o & - & o & o & o\\
\header{Content-Length}     &       & ar & t & t & t & t & t & t\\
\header{Content-Type}       &       &    & * & * & - & * & * & *\\
\header{CSeq}               &  c    & r  & m & m & m & m & m & m\\
\header{Date}               &       & a  & o & o & o & o & o & o\\
\header{Error-Info}         & 300-699 & a & - & o & o & o & o & o\\
\header{Expires}            &       &    & - & - & - & o & - & o\\
\header{From}               &  c    & r  & m & m & m & m & m & m\\
\header{In-Reply-To}        &  R    &    & - & - & - & o & - & -\\
\header{Max-Forwards}       &  R    & amr & m & m & m & m & m & m\\
\header{Min-Expires}        &  423  &    & - & - & - & - & - & m\\
\header{MIME-Version}       &       &    & o & o & - & o & o & o\\
\header{Organization}       &       & ar & - & - & - & o & o & o\\
\end{tabular}
\end{center}
\caption{Summary of header fields, A--O}

\label{tab:headers1}
\end{table}

\begin{table}[htpb]
\begin{center}
\begin{tabular}{lcccccccc}
Header field                & where & proxy &ACK&BYE&CAN&INV&OPT&REG\\
\hline
\header{Priority}           &  R     & ar   & - & - & - & o & - & -\\
\header{Proxy-Authenticate} & 407    & ar   & - & m & - & m & m & m\\
\header{Proxy-Authenticate} & 401    & ar   & - & o & o & o & o & o\\
\header{Proxy-Authorization}&  R     & dr   & o & o & - & o & o & o\\
\header{Proxy-Require}      &  R     & ar   & - & o & - & o & o & o\\
\header{Record-Route}       &  R     & ar   & o & o & o & o & o & -\\
\header{Record-Route}       & 2xx,18x & mr   & - & o & o & o & o & -\\
\header{Reply-To}           &        &      & - & - & - & o & - & -\\
\header{Require}            &        & ar   & - & c & - & c & c & c\\
\header{Retry-After}& 404,413,480,486&      & - & o & o & o & o & o\\
                    & 500,503        &      & - & o & o & o & o & o\\
                    & 600,603        &      & - & o & o & o & o & o\\
\header{Route}              &  R     & adr  & c & c & c & c & c & c\\
\header{Server}             &  r     &      & - & o & o & o & o & o\\
\header{Subject}            &  R     &      & - & - & - & o & - & -\\
\header{Supported}          &  R     &      & - & o & o & m* & o & o\\
\header{Supported}          & 2xx    &      & - & o & o & m* & m* & o\\
\header{Timestamp}          &        &      & o & o & o & o & o & o\\
\header{To}                 &  c(1)  & r    & m & m & m & m & m & m\\
\header{Unsupported}        & 420    &      & - & m & - & m & m & m\\
\header{User-Agent}         &        &      & o & o & o & o & o & o\\
\header{Via}                &  R     & amr  & m & m & m & m & m & m\\
\header{Via}                &  rc    & dr   & m & m & m & m & m & m\\
\header{Warning}            &  r     &      & - & o & o & o & o & o\\
\header{WWW-Authenticate}   & 401    & ar   & - & m & - & m & m & m\\
\header{WWW-Authenticate}   & 407    & ar   & - & o & - & o & o & o\\
\end{tabular}
\end{center}
\caption{Summary of header fields, P--Z; (1): copied with possible
addition of tag}

\label{tab:headers2}
\end{table}
\end{changebar}

A compact form of some common header field names is also defined for use when
overall message size is an issue. 

The \header{Contact}, \header{From}, and \header{To} header fields
contain a URI.  If the URI contains a comma, question mark or semicolon,
the URI {\MUST} be enclosed in angle brackets ($<$ and $>$).  Any URI
parameters are contained within these brackets.  If the URI is not
enclosed in angle brackets, any semicolon-delimited parameters are
header-parameters, not URI parameters.

\subsection{\header{Accept}}
\label{sec:Accept}

The \header{Accept} header field follows the syntax defined in [H14.1]. The
semantics are also identical, with the exception that if no
\header{Accept} header field is present, the server {\SHOULD} assume a
default value of {\tt application/sdp}. 

An empty \header{Accept} header field means that no formats are
acceptable.

Example:

\begin{verbatim}
  Accept: application/sdp;level=1, application/x-private, text/html
\end{verbatim}

\subsection{\header{Accept-Encoding}}
\label{sec:Accept-Encoding}

The \header{Accept-Encoding} header field is similar to \header{Accept},
but restricts the content-codings [H3.5] that are acceptable in the
response.  See [H14.3].  The syntax of this header field is defined in
[H14.3].  The semantics in SIP are identical to those defined in
[H14.3].

An empty \header{Accept-Encoding} header field is permissible, even
though the syntax in [H14.3] does not provide for it.  It is equivalent
to \header{Accept-Encoding: identity}, that is, only the identity
encoding, meaning no encoding, is permissible.  

If no \header{Accept-Encoding} header field is present, the server {\SHOULD} assume a
default value of \header{identity}. 

This differs slightly from the HTTP definition, which indicates that
when not present, any encoding can be used, but the identity encoding is
preferred. 

Example:

\begin{verbatim}
  Accept-Encoding: gzip
\end{verbatim}

\subsection{\header{Accept-Language}}
\label{sec:Accept-Language}

The \header{Accept-Language} header field is used in requests to indicate the
preferred languages for reason phrases, session descriptions, or status
responses carried as message bodies in the response.  If no
\header{Accept-Language} header field is present, the server {\SHOULD} assume
all languages are acceptable to the client. 

The \header{Accept-Language} header field follows the syntax defined in [H14.4]. 
The rules for ordering the languages based on the ``\header{q}''
parameter apply to SIP as well. 

Example:

\begin{verbatim}
  Accept-Language: da, en-gb;q=0.8, en;q=0.7  
\end{verbatim}

\subsection{\header{Alert-Info}}
\label{sec:Alert-Info}

When present in an {\INVITE} request, the \header{Alert-Info} header
field specifies an alternative ring tone to the UAS.  When present in a
180 (Ringing) response, the \header{Alert-Info} header field specifies
an alternative ringback tone to the UAC.  A typical usage is for a proxy
to insert this header field to provide a distinctive ring feature.

The \header{Alert-Info} header field can introduce security risks.  These
risks and the ways to handle them are discussed in 
Section~\ref{sec:Call-Info}, which discusses the \header{Call-Info} header field since
the risks are identical.

In addition, a user {\SHOULD} be able to disable this feature selectively.  

\motivation{This helps prevent disruptions that could result from the
use of this header field by untrusted elements.}

Example:
\begin{verbatim}
Alert-Info: <http://www.example.com/sounds/moo.wav>
\end{verbatim}

\subsection{\header{Allow}}
\label{sec:Allow}

The \header{Allow} header field lists the set of methods supported by
the UA generating the message. 

All methods, including {\ACK} and {\CANCEL}, understood by the UA
{\MUST} be included in the list of methods in the \header{Allow} header field,
when present.  The absence of an \header{Allow} header field {\MUSTNOT} be
interpreted to mean that the UA sending the message supports no methods. 
Rather, it implies that the UA is not providing any information on what
methods it supports.

Supplying an \header{Allow} header field in responses to methods other than
{\OPTIONS} reduces the number of messages needed.

Example:
\begin{verbatim}
  Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
\end{verbatim}

\subsection{\header{Authentication-Info}}
\label{sec:Authentication-Info}

The \header{Authentication-Info} header field provides for mutual
authentication with HTTP Digest.  A UAS {\MAY} include this header field in a
2xx response to a request that was successfully authenticated using
digest based on the \header{Authorization} header field.

Syntax and semantics follow those specified in RFC~2617~\citenorm{rfc2617}.

Example:
\begin{verbatim}
  Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
\end{verbatim}

\subsection{\header{Authorization}}
\label{sec:Authorization}

The \header{Authorization} header field contains authentication
credentials of a UA.  Section~\ref{sec:security:auth:u2u} overviews the
use of the \header{Authorization} header field, and
Section~\ref{sec:security:auth:scheme} describes the syntax and semantics 
when used with HTTP authentication.  

This header field, along with \header{Proxy-Authorization},
breaks the general rules about multiple header field values.  Although not a
comma-separated list, this header field name may be present multiple times,
and {\MUSTNOT} be combined into a single header line using the usual rules
described in Section~\ref{sec:message-header-fields}.

In the example below, there are no quotes around the Digest parameter:

\begin{changebar}
\begin{verbatim}
  Authorization: Digest username="Alice", realm="atlanta.com",
   nonce="84a4cc6f3082121f32b42a2187831a9e",
   response="7587245234b3434cc3412213e5f113a5432" 
\end{verbatim}
\end{changebar}

\subsection{\header{Call-ID}}
\label{sec:Call-ID}

The \header{Call-ID} header field uniquely identifies a particular
invitation or all registrations of a particular client.  A single
multimedia conference can give rise to several calls with different
\header{Call-ID}s, for example, if a user invites a single individual
several times to the same (long-running) conference.  \header{Call-ID}s
are case-sensitive and are simply compared byte-by-byte.

The compact form of the \header{Call-ID} header field is \header{i}.

Examples:
\begin{verbatim}
  Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
  i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
\end{verbatim}

\subsection{\header{Call-Info}}
\label{sec:Call-Info}

The \header{Call-Info} header field provides additional information
about the caller or callee, depending on whether it is found in a
request or response.  The purpose of the URI is described by the
``\header{purpose}'' parameter.  The ``\header{icon}'' parameter
designates an image suitable as an iconic representation of the caller
or callee.  The ``\header{info}'' parameter describes the caller or
callee in general, for example, through a web page.  The
``\header{card}'' parameter provides a business card, for example, in
vCard~\citenonnorm{rfc2426} or LDIF~\citenonnorm{rfc2849} formats.  Additional tokens
can be registered using IANA and the procedures in
Section~\ref{sec:iana}.

Use of the \header{Call-Info} header field can pose a security risk.  If
a callee fetches the URIs provided by a malicious caller, the callee may
be at risk for displaying inappropriate or offensive content, dangerous
or illegal content, and so on.  Therefore, it is {\RECOMMENDED} that a
UA only render the information in the \header{Call-Info} header field if it
can verify the authenticity of the element that originated the header field
and trusts that element.  This need not be the peer UA; a proxy can
insert this header field into requests. 

Example:
\begin{verbatim}
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
  <http://www.example.com/alice/> ;purpose=info
\end{verbatim}

\subsection{\header{Contact}}
\label{sec:Contact}

A \header{Contact} header field value provides a URI whose meaning depends
on the type of request or response it is in.

A \header{Contact} header field value can contain a display name, a URI with
URI parameters, and header parameters. 

This document defines the \header{Contact} parameters ``\header{q}''
and ``\header{expires}''.  These parameters are only used when the
\header{Contact} is present in a {\REGISTER} request or response, or
in a 3xx response. Additional parameters may be defined in other
specifications.

When the header field value contains a display name, the URI including all URI
parameters is enclosed in ``$<$'' and ``$>$''.  If no ``$<$'' and
``$>$'' are present, all parameters after the URI are header parameters,
not URI parameters. The display name can be tokens, or a quoted string, if a larger character set is desired.

Even if the ``\header{display-name}'' is empty, the
``\header{name-addr}'' form {\MUST} be used if the
``\header{addr-spec}'' contains a comma, semicolon, or question mark. 
There may or may not be LWS between the \header{display-name}
and the ``$<$''. 

These rules for parsing a display name, URI and URI parameters, and
header parameters also apply for the header fields \header{To} and
\header{From}.

\motivation{The \header{Contact} header field has a role
similar to the \header{Location} header field in HTTP. However, the HTTP
header field only allows one address, unquoted. Since URIs can contain commas
and semicolons as reserved characters, they can be mistaken for header
or parameter delimiters, respectively.}

The compact form of the \header{Contact} header field is \header{m} (for
``moved'').

The second example below shows a \header{Contact} header field value
containing both a URI parameter (\header{transport}) and a header
parameter (\header{expires}).

\begin{verbatim}
  Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
     ;q=0.7; expires=3600, 
     "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1  
  m: <sips:bob@192.0.2.4>;expires=60
\end{verbatim}

\subsection{\header{Content-Disposition}}
\label{sec:Content-Disposition}

The \header{Content-Disposition} header field describes how the message
body or, for multipart messages, a message body part is to be
interpreted by the UAC or UAS.  This SIP header field extends the MIME
\begin{changebar}
\header{Content-Type} (RFC~2183~\citenorm{rfc2183}).
\end{changebar}

The value ``\header{session}'' indicates that the body part describes a
session, for either calls or early (pre-call) media.  The value
``\header{render}'' indicates that the body part should be displayed or
otherwise rendered to the user.  For backward-compatibility, if the
\header{Content-Disposition} header field is missing, the server {\SHOULD} assume 
bodies of \header{Content-Type}
\texttt{application/sdp} are the disposition ``\header{session}'', while
other content types are ``\header{render}''.

The disposition type ``\header{icon}'' indicates that the body part
contains an image suitable as an iconic representation of the caller or
callee.  The value ``\header{alert}'' indicates that the body part
contains information, such as an audio clip, that should be rendered
instead of ring tone.

The handling parameter, \header{handling-param}, describes how the UAS
should react if it receives a message body whose content type or
disposition type it does not understand.  The parameter has defined
values of ``\header{optional}'' and ``\header{required}''.  If the
handling parameter is missing, the value ``\header{required}'' {\SHOULD}
be assumed. 

If this header field is missing, the MIME type determines the
default content disposition.  If there is none, ``\header{render}'' is
assumed.

Example:
\begin{verbatim}
  Content-Disposition: session
\end{verbatim}

\subsection{\header{Content-Encoding}}
\label{sec:Content-Encoding}

The \header{Content-Encoding} header field is used as a modifier to the
``\header{media-type}''.  When present, its value indicates what
additional content codings have been applied to the entity-body, and
thus what decoding mechanisms {\MUST} be applied in order to obtain the
media-type referenced by the \header{Content-Type} header field. 
\header{Content-Encoding} is primarily used to allow a body to be
compressed without losing the identity of its underlying media type.

If multiple encodings have been applied to an entity-body, the content
codings {\MUST} be listed in the order in which they were applied.

All content-coding values are case-insensitive.  IANA acts as a registry
for content-coding value tokens.  See [H3.5] for a definition of the
syntax for \header{content-coding}.

Clients {\MAY} apply content encodings to the body in requests.  A
server {\MAY} apply content encodings to the bodies in responses.  The
server {\MUST} only use encodings listed in the \header{Accept-Encoding}
header field in the request.

The compact form of the \header{Content-Encoding} header field is
\header{e}.  Examples:
\begin{verbatim}
  Content-Encoding: gzip
  e: tar
\end{verbatim}

\subsection{\header{Content-Language}}
\label{sec:Content-Language}

See [H14.12]. Example:
\begin{verbatim}
  Content-Language: fr
\end{verbatim}

\subsection{\header{Content-Length}}
\label{sec:Content-Length}

The \header{Content-Length} header field indicates the size of the
message-body, in decimal number of octets, sent to the recipient. 
Applications {\SHOULD} use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the
entity.  If a stream-based protocol (such as TCP) is 
used as transport, the header field {\MUST} be used.
 
The size of the message-body does \emph{not} include the CRLF separating
header fields and body.  Any \header{Content-Length} greater than or equal to
zero is a valid value.  If no body is present in a message, then the
\header{Content-Length} header field value {\MUST} be set to zero. 
\motivation{The ability to omit \header{Content-Length} simplifies the
creation of cgi-like scripts that dynamically generate responses.}

The compact form of the header field is \header{l}.

Examples:
\begin{verbatim}
  Content-Length: 349
  l: 173
\end{verbatim}

\subsection{\header{Content-Type}}
\label{sec:Content-Type}

The \header{Content-Type} header field indicates the media type of the
message-body sent to the recipient.  The ``\header{media-type}'' element
is defined in [H3.7].  The \header{Content-Type} header field {\MUST} be
present if the body is not empty.   If the body is
empty, and a \header{Content-Type} header field is present, it indicates that
the body of the specific type has zero length (for example, an empty
audio file).  

The compact form of the header field is \header{c}.

Examples:
\begin{verbatim}
  Content-Type: application/sdp  
  c: text/html; charset=ISO-8859-4
\end{verbatim}

\subsection{\header{CSeq}}
\label{sec:CSeq}

A \header{CSeq} header field in a request contains a single decimal
sequence number and the request method.  The sequence number {\MUST} be
expressible as a 32-bit unsigned integer.  The method part of 
\header{CSeq} is case-sensitive. The \header{CSeq} header field
serves to order transactions within a dialog, to provide a means to
uniquely identify transactions, and to differentiate between new
requests and request retransmissions. 
\begin{changebar}
Two \header{CSeq} header fields are considered equal if the sequence number 
and the request method are identical.
\end{changebar}
Example:

\begin{verbatim}
  CSeq: 4711 INVITE
\end{verbatim}

\subsection{\header{Date}}
\label{sec:Date}

The \header{Date} header field contains a the date and time.
Unlike HTTP/1.1, SIP only supports the most recent 
RFC~1123~\citenorm{rfc1123} format for dates.  As in [H3.3], SIP restricts the
time zone in \header{SIP-date} to ``GMT'', while RFC~1123 allows any
time zone.  \header{rfc1123-date} is case-sensitive.

The \header{Date} header field reflects the time when the request or
response is first sent. 

\motivation{The \header{Date} header field can be used by simple end
systems without a battery-backed clock to acquire a notion of current
time.  However, in its GMT form, it requires clients to know their
offset from GMT.}

Example:
\begin{verbatim}
  Date: Sat, 13 Nov 2010 23:29:00 GMT
\end{verbatim}

\subsection{\header{Error-Info}}
\label{sec:Error-Info}

The \header{Error-Info} header field provides a pointer to additional
information about the error status response.
 
\motivation{SIP UACs have user interface capabilities ranging from
pop-up windows and audio on PC softclients to audio-only on ''black''
phones or endpoints connected via gateways.  Rather than forcing a
server generating an error to choose between sending an error status
code with a detailed reason phrase and playing an audio recording, the
Error-Info header field allows both to be sent.  The UAC then has the
choice of which error indicator to render to the caller.}

A UAC {\MAY} treat a SIP or SIPS URI in an \header{Error-Info} header field as
if it were a \header{Contact} in a redirect and generate a new
{\INVITE}, resulting in a recorded announcement session being
established.  A non-SIP URI {\MAY} be rendered to the user.

Examples:
\begin{verbatim}
  SIP/2.0 404 The number you have dialed is not in service
  Error-Info: <sip:not-in-service-recording@atlanta.com>
\end{verbatim}

\subsection{\header{Expires}}
\label{sec:Expires}


The \header{Expires} header field gives the relative time after which
the message (or content) expires. 
 
The precise meaning of this is method dependent. 

The expiration time in an {\INVITE} does \emph{not} affect the duration
of the actual session that may result from the invitation.  Session
description protocols may offer the ability to express time limits on
the session duration, however.

\begin{changebar}
The value of this field is an integral number of seconds (in decimal) between
0 and (2**31)-1, measured from the receipt of the request. 
\end{changebar}

Example:
\begin{verbatim}
  Expires: 5
\end{verbatim}

\subsection{\header{From}}
\label{sec:From}

The \header{From} header field indicates the initiator of the request. 
This may be different from the initiator of the dialog.  Requests sent
by the callee to the caller use the callee's address in the
\header{From} header field.

The optional ``\header{display-name}'' is meant to be rendered by a
human user interface.  A system {\SHOULD} use the display name
``Anonymous'' if the identity of the client is to remain hidden.  Even
if the ``\header{display-name}'' is empty, the ``\header{name-addr}''
form {\MUST} be used if the ``\header{addr-spec}'' contains a comma,
question mark, or semicolon.  Syntax issues are discussed in
Section~\ref{sec:header-format}.

Section~\ref{sec:dialog} describes how \header{From} header fields are compared for
the purpose of matching requests to dialogs.  See
Section~\ref{sec:Contact} for the rules for parsing a display name, URI
and URI parameters, and header field parameters.

The compact form of the \header{From} header field is \header{f}.

Examples:
\begin{verbatim}
  From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
  From: sip:+12125551212@server.phone2net.com;tag=887s
  f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
\end{verbatim}

\subsection{\header{In-Reply-To}}
\label{sec:In-Reply-To}

The \header{In-Reply-To} header field enumerates the \header{Call-ID}s
that this call references or returns.  These \header{Call-ID}s may have
been cached by the client then included in this header field in a return call.

\motivation{This allows automatic call distribution systems to route
return calls to the originator of the first call.  This also allows
callees to filter calls, so that only return calls for calls they
originated will be accepted.  This field is not a substitute for request
authentication.}

Example:
\begin{verbatim}
  In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com
\end{verbatim}

\subsection{\header{Max-Forwards}}
\label{sec:Max-Forwards}

The \header{Max-Forwards} header field must be used with any SIP method
to limit the number of proxies or gateways that can forward the request
to the next downstream server.  This can also be useful when the client
is attempting to trace a request chain that appears to be failing or
looping in mid-chain.

The \header{Max-Forwards} value is an integer in the range 0-255 indicating the
remaining number of times this request message is allowed to be
forwarded.  This count is decremented by each server that forwards the
request. The recommended value is 70.

This header field should be inserted by elements that can not otherwise
guarantee loop detection.  For example, a B2BUA should insert a
\header{Max-Forwards} header field. 

Example:
\begin{verbatim}
  Max-Forwards: 6
\end{verbatim}                     



\subsection{\header{Min-Expires}}
\label{sec:Min-Expires}

\begin{changebar}
The \header{Min-Expires} header field conveys the minimum refresh interval
supported for soft-state elements managed by that server. This 
includes \header{Contact} header fields that are stored by a registrar. 
The header field contains a decimal integer number of seconds from 0 to 
(2**32)-1.  \end{changebar} The use of the header field in a 423
(Registration Too Brief) response is described in 
Sections~\ref{sec:reg:const:error}, \ref{sec:reg:processing}, 
and~\ref{sec:response-codes:423}.

Example:
\begin{verbatim}
  Min-Expires: 60
\end{verbatim}

\subsection{\header{MIME-Version}}
\label{sec:MIME-Version}

See [H19.4.1].

Example:
\begin{verbatim}
  MIME-Version: 1.0
\end{verbatim}

\subsection{\header{Organization}}
\label{sec:Organization}

The \header{Organization} header field conveys the name of the
organization to which the SIP element issuing the request or response
belongs. 

\motivation{The field {\MAY} be used by client software to filter
calls.}

Example:
\begin{verbatim}
  Organization: Boxes by Bob
\end{verbatim}

\subsection{\header{Priority}}
\label{sec:Priority}

The \header{Priority} header field indicates the urgency of the request
as perceived by the client.   The \header{Priority}
header field describes the priority that the SIP request should have to
the receiving human or its agent.  For example, it may be factored into
decisions about call routing and acceptance.  
\begin{changebar}
For these decisions, a message containing no \header{Priority}
header field {\SHOULD} be treated as if it specified a
\header{Priority} of ``non-urgent''.
The \header{Priority} header field
\end{changebar}
does not influence the
use of communications resources such as packet forwarding priority in
routers or access to circuits in PSTN gateways.  The header field can
have the values ``non-urgent'', ``normal'', ``urgent'', and
``emergency'', but additional values can be defined elsewhere. 
 It is {\RECOMMENDED} that the value of ``emergency''
only be used when life, limb, or property are in imminent danger. 
Otherwise, there are no semantics defined for this header field.



\motivation{These are the values of RFC~2076~\citenonnorm{rfc2076}, with the
addition of ``emergency''.}

Examples:

\begin{verbatim}
  Subject: A tornado is heading our way!
  Priority: emergency
\end{verbatim}
or
\begin{verbatim}
  Subject: Weekend plans
  Priority: non-urgent
\end{verbatim}

\subsection{\header{Proxy-Authenticate}}
\label{sec:Proxy-Authenticate}

A \header{Proxy-Authenticate} header field value contains an authentication
challenge.

The syntax for this header field and its use is defined in [H14.33].
See~\ref{sec:security:auth:p2u} for further details on its usage.  

Example:
\begin{changebar}
\begin{verbatim}
   Proxy-Authenticate: Digest realm="atlanta.com",
    domain="sip:ss1.carrier.com",
    nonce="f84f1cec41e6cbe5aea9c8e88d359",
    opaque="", stale=FALSE, algorithm=MD5
\end{verbatim}
\end{changebar}

\subsection{\header{Proxy-Authorization}}
\label{sec:Proxy-Authorization}

The \header{Proxy-Authorization} header field allows the client to
identify itself (or its user) to a proxy that requires authentication. 
A \header{Proxy-Authorization} field value consists of credentials
containing the authentication information of the user agent for the
proxy and/or realm of the resource being requested.

See [H14.34] for a definition of the syntax, and
section~\ref{sec:security:auth:p2u} for a discussion of its usage.

This header field, along with \header{Authorization}, breaks the general
rules about multiple header field names.  Although not a comma-separated
list, this header field name may be present multiple times, and {\MUSTNOT} be
combined into a single header line using the usual rules described in
Section~\ref{sec:header-format}.

Example:
\begin{changebar}
\begin{verbatim}
Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
   nonce="c60f3082ee1212b402a21831ae",
   response="245f23415f11432b3434341c022"
\end{verbatim}
\end{changebar}

\subsection{\header{Proxy-Require}}
\label{sec:Proxy-Require}
 
The \header{Proxy-Require} header field is used to indicate
proxy-sensitive features that must be supported by the proxy.  See
Section~\ref{sec:Require} for more details on the mechanics of this
message and a usage example.

Example:
\begin{verbatim}
  Proxy-Require: foo
\end{verbatim}

\subsection{\header{Record-Route}}
\label{sec:Record-Route}

The \header{Record-Route} header field is inserted by proxies in 
a request to force future requests in the dialog to be routed through the proxy.

Examples of its use with the \header{Route} header field are described in \begin{changebar}
Sections~\ref{sec:proxy-record-route-example}. \end{changebar}

Example:\begin{verbatim}
  Record-Route: <sip:server10.biloxi.com;lr>, <sip:bigbox3.site3.atlanta.com;lr>
\end{verbatim}

\subsection{\header{Reply-To}}
\label{sec:Reply-To}

The \header{Reply-To} header field contains a logical return URI that 
may be different from the \header{From} header field.  For example, the
URI {\MAY} be used to return missed calls or unestablished sessions.  If
the user wished to remain anonymous, the header field {\SHOULD} either
be omitted from the request or populated in such a way that does not
reveal any private information. 

Even if the ``\header{display-name}'' is empty, the
``\header{name-addr}'' form {\MUST} be used if the
``\header{addr-spec}'' contains a comma, question mark, or semicolon. 
Syntax issues are discussed in Section~\ref{sec:header-format}.

Example:
\begin{verbatim}
  Reply-To: Bob <sip:bob@biloxi.com>
\end{verbatim}

\subsection{\header{Require}}
\label{sec:Require}

The \header{Require} header field is used by UACs to tell UASs about
options that the UAC expects the UAS to support in order to process the
request.  Although an optional header field, the \header{Require} {\MUSTNOT}
be ignored if it is present.

The \header{Require} header field contains a list of option tags, described in
Section~\ref{sec:option_tags}.  Each option tag defines a SIP extension
that {\MUST} be understood to process the request.  Frequently, this is
used to indicate that a specific set of extension header fields need to be
understood.  A UAC compliant to this specification {\MUST} only include
option tags corresponding to standards-track RFCs.

Example:
\begin{verbatim}
  Require: 100rel
\end{verbatim}

\subsection{\header{Retry-After}}
\label{sec:Retry-After}

The \header{Retry-After} header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to be
unavailable to the requesting client and with a 404 (Not Found), \begin{changebar} 413 (Request 
Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), \end{changebar} 600
(Busy), or 603 (Decline) response to indicate when the called party
anticipates being available again.  The value of this
field is a positive integer number of seconds (in decimal) after the
time of the response.  

An optional comment can be used to indicate additional information about
the time of callback.  An optional ``\header{duration}'' parameter
indicates how long the called party will be reachable starting at the
initial time of availability.  If no duration parameter is given, the
service is assumed to be available indefinitely.

Examples:
\begin{verbatim}
  Retry-After: 18000;duration=3600
  Retry-After: 120 (I'm in a meeting)
\end{verbatim}

\subsection{\header{Route}}
\label{sec:Route}

The \header{Route} header field is used to force routing for a request through the
listed set of proxies.  Examples of the use of the 
\header{Record-Route} header field are in
Section~\ref{sec:proxy-record-route-example}.

Example:
\begin{verbatim}
  Route: <sip:bigbox3.site3.atlanta.com;lr>, <sip:server10.biloxi.com;lr>
\end{verbatim}

\subsection{\header{Server}}
\label{sec:Server}

The \header{Server} header field contains information about the software
used by the UAS to handle the request.  The syntax for this field is
defined in [H14.38].

Revealing the specific software version of the server might allow the
server to become more vulnerable to attacks against software that is
known to contain security holes.  Implementers {\SHOULD} make the
\header{Server} header field a configurable option.

Example:
\begin{verbatim}
  Server: HomeProxy v2
\end{verbatim}

\subsection{\header{Subject}}
\label{sec:Subject}

The \header{Subject} header field provides a summary or indicates the
nature of the call, allowing call filtering without having to parse the
session description.  The session description does not have to use the
same subject indication as the invitation.

The compact form of the \header{Subject} header field is \header{s}.

Example:
\begin{verbatim}
  Subject: Need more boxes
  s: Tech Support
\end{verbatim}

\subsection{\header{Supported}}
\label{sec:Supported}

The \header{Supported} header field enumerates all the extensions
supported by the UAC or UAS. 

The \header{Supported} header field contains a list of option tags, described
in Section~\ref{sec:option_tags}, that are understood by the UAC or UAS. 
A UA compliant to this specification {\MUST} only include option tags
corresponding to standards-track RFCs.  If empty, it means that no
extensions are supported.

Example:
\begin{verbatim}
  Supported: 100rel
\end{verbatim}

\subsection{\header{Timestamp}}
\label{sec:Timestamp}

The \header{Timestamp} header field describes when the UAC 
sent the request to the UAS. 

\begin{changebar}
See Section~\ref{sec:general:serv-resp} for details on how to generate a
response to a request that contains the header field. Although there
is no normative behavior defined here that makes use of the header,
it allows for extensions or SIP applications to obtain RTT estimates.
\end{changebar}

Example:
\begin{verbatim}
  Timestamp: 54
\end{verbatim}

\subsection{\header{To}}
\label{sec:To}

The \header{To} header field specifies the logical recipient
of the request.

The optional ``\header{display-name}'' is meant to be rendered by a
human-user interface.  The ``\header{tag}'' parameter serves as a
general mechanism for dialog identification. 

See \begin{changebar}Section~\ref{sec:common-message:tags}\end{changebar} for details of the ``\header{tag}''
parameter.  

Section~\ref{sec:dialog} describes how \header{To} and \header{From} header fields are
compared for the purpose of matching requests to dialogs.  See
Section~\ref{sec:Contact} for the rules for parsing a display name, URI
and URI parameters, and header field parameters.

The compact form of the \header{To} header field is \header{t}.

The following are examples of valid \header{To} header fields:
\begin{verbatim}
  To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
  t: sip:+12125551212@server.phone2net.com
\end{verbatim}

\subsection{\header{Unsupported}}
\label{sec:Unsupported}

The \header{Unsupported} header field lists the features not
supported by the UAS.  See Section~\ref{sec:Require} for 
motivation. 

Example:
\begin{verbatim}
  Unsupported: foo
\end{verbatim}

\subsection{\header{User-Agent}}
\label{sec:User-Agent}

The \header{User-Agent} header field contains information about
the UAC originating the request.  The syntax and semantics
are defined in [H14.43].

Revealing the specific software version of the user agent might allow
the user agent to become more vulnerable to attacks against software
that is known to contain security holes.  Implementers {\SHOULD} make
the \header{User-Agent} header field a configurable option.

Example:
\begin{verbatim}
  User-Agent: Softphone Beta1.5
\end{verbatim}

\subsection{\header{Via}}
\label{sec:Via}

The \header{Via} header field indicates the path taken by the request so far
and indicates the path that should be followed in routing responses. 
The branch ID parameter in the \header{Via} header field values serves as a
transaction identifier, and is used by proxies to detect loops.

A \header{Via} header field value contains the transport protocol used to
send the message, the client's host name or network address, and
possibly the port number at which it wishes to receive
responses.  A \header{Via} header field value can also contain parameters
such as ``\header{maddr}'', ``\header{ttl}'', ``\header{received}'', and
``\header{branch}'', whose meaning and use are described in other
sections. 

Transport protocols defined here are ``\header{UDP}'', ``\header{TCP}'',
``\header{TLS}'', and ``\header{SCTP}''.  ``\header{TLS}'' means TLS
over TCP. \begin{changebar} When a request is sent to a SIPS URI,
the protocol still indicates ``SIP'', and the transport protocol is TLS. 
\end{changebar}


\begin{verbatim}
  Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
  Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207;branch=z9hG4bK77asjd
\end{verbatim}

The compact form of the \header{Via} header field is \header{v}.

In this example, the message originated from a multi-homed host with two
addresses, 192.0.2.1 and 192.0.2.207.  The sender guessed wrong as to
which network interface would be used.  Erlang.bell-telephone.com
noticed the mismatch and added a parameter to the previous hop's
\header{Via} header field value, containing the address that the packet
actually came from. 
 
The host or network address and port number are not required to follow
the SIP URI syntax.  Specifically, LWS on either side of the ``:'' or
``/'' is allowed, as shown here:

\begin{verbatim}
  Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
    ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
\end{verbatim}

Even though this specification mandates that the branch parameter be
present in all requests, the BNF for the header field indicates that it is
optional.  This allows interoperation with RFC~2543 elements, which did
not have to insert the branch parameter.

\subsection{\header{Warning}}
\label{sec:Warning}

The \header{Warning} header field is used to carry additional
information about the status of a response.  \header{Warning} header 
field values are sent with responses and contain a three-digit warning code, host
name, and warning text.

The ``\header{warn-text}'' should be in a natural language that is most
likely to be intelligible to the human user receiving the response. 
This decision can be based on any available knowledge, such as the
location of the user, the \header{Accept-Language} field in a request,
or the \header{Content-Language} field in a response.  The default
language is i-default~\citenorm{rfc2277}.

The currently-defined ``\header{warn-code}''s are listed below, with a
recommended \header{warn-text} in English and a description of their
meaning.  These warnings describe failures induced by the session
description.  The first digit of warning codes beginning with ``3''
indicates warnings specific to SIP.  Warnings 300 through 329 are
reserved for indicating problems with keywords in the session
description, 330 through 339 are warnings related to basic network
services requested in the session description, 370 through 379 are
warnings related to quantitative QoS parameters requested in the session
description, and 390 through 399 are miscellaneous warnings that do not
fall into one of the above categories.

\begin{description}
\item[300 Incompatible network protocol:] One or more network
protocols contained in the session description are not available. 

\item[301 Incompatible network address formats:] One or more network
address formats contained in the session description are not available. 

\item[302 Incompatible transport protocol:] One or more transport
protocols described in the session description are not available. 

\item[303 Incompatible bandwidth units:] One or more bandwidth
measurement units contained in the session description were not
understood.

\item[304 Media type not available:] One or more media types contained
in the session description are not available.

\item[305 Incompatible media format:] One or more media formats
contained in the session description are not available.

\item[306 Attribute not understood:] One or more of the media attributes
in the session description are not supported.

\item[307 Session description parameter not understood:] A parameter
other than those listed above was not understood.

\item[330 Multicast not available:] The site where the user is located
does not support multicast.

\item[331 Unicast not available:] The site where the user is located
does not support unicast communication (usually due to the presence of a
firewall).

\item[370 Insufficient bandwidth:] The bandwidth specified in the
session description or defined by the media exceeds that known to be
available.

\item[399 Miscellaneous warning:] The warning text can include arbitrary
information to be presented to a human user or logged.  A system
receiving this warning {\MUSTNOT} take any automated action.

\end{description}

\motivation{1xx and 2xx have been taken by HTTP/1.1.}

Additional ``\header{warn-code}''s \begin{changebar}can be
defined through IANA, as defined in Section~\ref{sec:iana:warn}. \end{changebar}

Examples:
\begin{verbatim}
  Warning: 307 isi.edu "Session parameter 'foo' not understood"
  Warning: 301 isi.edu "Incompatible network address type 'E.164'"
\end{verbatim}

\subsection{\header{WWW-Authenticate}}
\label{sec:WWW-Authenticate}

A \header{WWW-Authenticate} header field value contains an authentication
challenge.  The syntax for this header field and use is defined in
[H14.47].  See~\ref{sec:security:auth:u2u} for further details on its
usage.

Example:
\begin{changebar}
\begin{verbatim}
  WWW-Authenticate: Digest realm="atlanta.com",
    domain="sip:boxesbybob.com",
    nonce="f84f1cec41e6cbe5aea9c8e88d359",
    opaque="", stale=FALSE, algorithm=MD5
\end{verbatim}
\end{changebar}
