\section{Header Field Definitions}
\label{sec:header-fields}

SIP header fields are similar to HTTP header fields in both syntax and
semantics.  In particular, SIP header fields follow the syntax for
message-header as described in [H4.2].  The rules for extending header
fields over multiple lines, and use of multiple message-header fields
with the same field-name, described in [H4.2] also apply to SIP.
The rules in [H4.2] regarding ordering of header
fields apply to SIP.

The header fields required, optional and not applicable for each
method are listed in Table~\ref{tab:headers1} and
Table~\ref{tab:headers2}.  The table uses ``o'' to indicate optional,
``m'' mandatory and ``-'' for not applicable.  ``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.  A ``mandatory'' request 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 for request header fields 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 in the
response, and the UAC {\MUST} ignore the header in the response.
``m*'' indicates a header that {\SHOULD} be sent,
but servers need to be prepared to receive messages without that
header field. A ``*'' indicates that the header
fields are 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.

The ``where'' column describes the request and response types with which
the header field can be used.  ``R'' refers to header fields that can be
used in requests (that is, request and general header fields).  ``r''
designates a response or general-header field as applicable to all
responses, while a list of numeric values indicates the status codes
with which the header field can be used.  ``g'' and ``e'' designate
general (Section~\ref{sec:general-header}) and entity header
(Section~\ref{sec:entity-header}) fields, respectively.  If a header
field is marked ``c'', it is copied from the request to the response.

The ``proxy'' column describes whether proxies can add comma-separated
elements to headers (``c'', for concatenate or comma), can modify the
header (``m''), can add the header if not present (``a'') or need to
read the header (``r'').  Headers that need to be read cannot be
encrypted.  Proxies {\MUSTNOT} alter any fields that are authenticated
(see Section~\ref{sec:authentication}), but {\MAY} add copies of fields
that were authenticated by the UA if indicated in the table.  Depending
on local policy, proxies {\MAY} inspect any non-encrypted header fields
and {\MAY} modify any non-authenticated header field, but proxies cannot
rely on fields other than the ones indicated in the table to be readable
or modifiable.

If authentication is used, the rules in Section~\ref{sec:authentication}
apply.  Proxies {\SHOULDNOT} re-order header fields. 

\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 & - & m* & o & o \\
\header{Accept}             & 2xx    &    & - & - & - & m* & o & o \\
\header{Accept}             & 415    &    & - & o & - & o & o & o \\
\header{Accept-Encoding}    &  R     &    & - & o & - & m* & o & o \\
\header{Accept-Encoding}    & 2xx    &    & - & - & - & m* & o & o \\
\header{Accept-Encoding}    & 415    &    & - & o & - & o & o & o \\
\header{Accept-Language}    &  R     &    & - & o & - & m* & o & o \\
\header{Accept-Language}    & 2xx    &    & - & - & - & m* & o & o \\
\header{Accept-Language}    & 415    &    & - & o & - & o & o & o \\
\header{Alert-Info}         &  R     & am & - & - & - & o & - & - \\
\header{Allow}              &  R     &    & o & o & o & o & o & o \\
\header{Allow}              & 2xx    &    & o & o & o & m* & m* & o \\
\header{Allow}              &  r     &    & o & o & o & o & o & o \\
\header{Allow}              & 405    &    & m & m & m & m & m & m \\
\header{Authentication-Info}&  2xx   &    & - & o & - & o & o & o \\
\header{Authorization}      &  R     &    & o & o & o & o & o & o \\
\header{Authorization}      &  r     &    & o & o & o & o & o & o \\
\header{Call-ID}            &  gc    & r  & m & m & m & m & m & m \\
\header{Call-Info}          &  g     & am & - & - & - & o & o & o \\
\header{Contact}            &  R     &    & o & - & - & m & o & o \\
\header{Contact}            & 1xx    &    & - & - & - & o & o & - \\
\header{Contact}            & 2xx    &    & - & - & - & m & o & o \\
\header{Contact}            & 3xx    &    & - & o & - & o & o & o \\
\header{Contact}            & 485    &    & - & o & - & o & o & o \\
\header{Content-Disposition}&  e     &    & o & o & - & o & o & o \\
\header{Content-Encoding}   &  e     &    & o & o & - & o & o & o \\
\header{Content-Language}   &  e     &    & o & o & - & o & o & o \\
\header{Content-Length}     &  e     & r  & m* & m* & m* & m* & m* & m* \\
\header{Content-Type}       &  e     &    & * & * & - & * & * & * \\
\header{CSeq}               &  gc    & r  & m & m & m & m & m & m \\
\header{Date}               &  g     & a  & o & o & o & o & o & o \\
\header{Encryption}         &  g     & r  & o & o & o & o & o & o \\
\header{Error-Info}         &  300-699     &    & - & o & o & o & o & o \\
\header{Expires}            &  g     &    & - & - & - & o & - & o \\
\header{From}               &  gc    & r  & m & m & m & m & m & m \\
\header{In-Reply-To}        &  R     &    & - & - & - & o & - & - \\
\header{Max-Forwards}       &  R     & rm & o & o & o & o & o & o \\
\header{MIME-Version}       &  g     &    & o & o & o & o & o & o \\
\header{Organization}       &  g     & am & - & - & - & o & o & o \\
\end{tabular}
\end{center}
\caption{Summary of header fields, A--O}

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


\begin{changebar}
\begin{table}[htpb]
\begin{center}
\begin{tabular}{lcccccccc}
Header field                & where & proxy &ACK&BYE&CAN&INV&OPT&REG\\
\hline
\header{Priority}           &  R     & a    & - & - & - & o & - & - \\
\header{Proxy-Authenticate} & 401,407&      & o & o & o & o & o & o \\
\header{Proxy-Authorization}&  R     & r    & o & o & o & o & o & o \\
\header{Proxy-Require}      &  R     & r    & o & o & o & o & o & o \\
\header{Record-Route}       &  R     & amr  & o & o & o & o & o & o \\
\header{Record-Route} & 2xx,401,484  &      & o & o & o & o & o & o \\
\header{Require}            &  g     & acr  & o & o & o & o & o & o \\
\header{Response-Key}       &  R     &      & - & o & o & o & o & o \\
\header{Retry-After}& 404,413,480,486&      & o & o & o & o & o & o \\
                    & 500,503        &      & o & o & o & o & o & o \\
                    & 600,603        &      & o & o & o & o & o & o \\
\header{Route}              &  R     & r    & o & o & o & o & o & o \\
\header{Server}             &  r     &      & o & o & o & o & o & o \\
\header{Subject}            &  R     &      & - & - & - & o & - & - \\
\header{Supported}          &  g     &      & - & o & o & o & o & o \\
\header{Timestamp}          &  g     &      & o & o & o & o & o & o \\
\header{To}                 &  gc(1) & r    & m & m & m & m & m & m \\
\header{Unsupported}        & 420    &      & o & o & o & o & o & o \\
\header{User-Agent}         &  g     &      & o & o & o & o & o & o \\
\header{Via}                &  gc    & acmr & m & m & m & m & m & m \\
\header{Warning}            &  r     &      & o & o & o & o & o & o \\
\header{WWW-Authenticate}   & 401    &     & o & o & 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}

Other header fields can be added as required; a server {\MUST} ignore
header fields not defined in this specification that it does not
understand.  A proxy {\MUSTNOT} remove or modify header fields not
defined in this specification that it does not understand. A compact
form of these header fields is also defined in Section
\ref{sec:compact} for use over UDP when the request has to fit into a
single packet and size is an issue.

Table \ref{tab:mheaders} in Appendix~\ref{sec:minimal} lists those
header fields that different client and server types {\MUST} be able to
parse.

\subsection{General Header Fields}
\label{sec:general-header}

General header fields apply to both request and response messages.  The
``\header{general-header}'' field names can be extended reliably only in
combination with a change in the protocol version.  However, new or
experimental header fields {\MAY} be given the semantics of general header
fields if all parties in the communication recognize them to be
``\header{general-header}'' fields.  Unrecognized header fields are
treated as ``\header{entity-header}'' fields.

\subsection{Entity Header Fields}
\label{sec:entity-header}

The ``\header{entity-header}'' fields define meta-information about the
message-body or, if no body is present, about the resource identified by
the request.  The term ``entity header'' is an HTTP 1.1 term where the
response body can contain a transformed version of the message body. 
The original message body is referred to as the ``entity''.  We retain
the same terminology for header fields but usually refer to the
``message body'' rather then the entity as the two are the same in SIP.

\subsection{Request Header Fields}

The ``\header{request-header}'' fields allow the client to pass
additional information about the request, and about the client itself,
to the server.  These fields act as request modifiers, with semantics
equivalent to the parameters of a programming language method
invocation.

The ``\header{request-header}'' field names can be extended reliably
only in combination with a change in the protocol version.  However, new
or experimental header fields {\MAY} be given the semantics of
``\header{request-header}'' fields if all parties in the communication
recognize them to be request-header fields.  Unrecognized header fields
are treated as ``\header{entity-header}'' fields.

\subsection{Response Header Fields}
\label{sec:response-header}

The ``\header{response-header}'' fields allow the server to pass
additional information about the response which cannot be placed in the
\header{Status-Line}.  These header fields give information about the
server and about further access to the resource identified by the
\header{Request-URI}.

\header{Response-header} field names can be extended reliably only in
combination with a change in the protocol version.  However, new or
experimental header fields {\MAY} be given the semantics of
``\header{response-header}'' fields if all parties in the communication
recognize them to be ``\header{response-header}'' fields.  Unrecognized
header fields are treated as ``\header{entity-header}'' fields.

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

Header fields (``\header{general-header}'', ``\header{request-header}'',
``\header{response-header}'', and ``\header{entity-header}'') follow the
same generic header format as that given in Section 3.1 of RFC 822
\cite{rfc822}.  Each header field consists of a name followed by a colon
(":") and the field value.  Field names are case-insensitive.  The field
value {\MAY} be preceded by any amount of leading white space (LWS),
though a single space (SP) is preferred.  Header fields can be extended
over multiple lines by preceding each extra line with at least one
\header{SP} or horizontal tab (HT).  Applications {\MUST} follow HTTP
``common form'' when generating these constructs, since there might
exist some implementations that fail to accept anything beyond the
common forms.

\begin{syntax}
message-header  & = & field-name ":" [ field-value ] CRLF\\
field-name      & = & token\\
field-value     & = & *( field-content $|$ LWS )\\
field-content   & = & $<${\rm the} OCTETs {\rm making up the field-value}\\
  & & {\rm and consisting of either} *TEXT-UTF8\\
  & & {\rm or combinations of \header{token},}\\
  & & {\rm \header{separators}, and \header{quoted-string}}$>$
\end{syntax}

The relative order of header fields with different field names is not
significant.  Multiple header fields with the same 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 (i.e.,
\header{\#(values)}).  It {\MUST} be possible to combine the multiple
header fields 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 order
in which header fields with the same field-name are received is
therefore significant to the interpretation of the combined field value,
and thus a proxy {\MUSTNOT} change the order of these field values when
a message is forwarded.

Unless otherwise stated, parameter names, parameter values and tokens
are case-insensitive.  Values expressed as quoted strings are
case-sensitive.

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

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

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

\begin{changebar}
As a request-header field, it is used only with those methods that
take message bodies in the response.  In a 415 (Unsupported Media
Type) response, it indicates which content types are acceptable in
requests.  In {\INVITE}, it lists not only the types allowed in the
response, but the types which can be sent in subsequent requests
within the call initiated (or call leg updated by) the
{\INVITE}. Similarly, in a 2xx class response to {\INVITE}, it lists
the acceptable types which can be sent to the UAS in subsequent
requests within that call leg. In a 2xx response to {\OPTIONS}, it
indicates the types supported by the server. In a 2xx response to
{\REGISTER}, it indicates the types that may be placed in subsequent
requests to the registrar.

If a UA supports types beyond the default, it {\SHOULD} include an
\header{Accept} header in all {\INVITE} requests (both initial and
re-{\INVITE}) and in all 2xx responses to {\INVITE} listing those
types it supports.
\end{changebar}

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} general-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 is
defined in [H14.3]. The semantics in SIP are identical to those
defined in [H14.3].

\begin{changebar}
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}, i.e., only the
identity encoding, meaning no encoding, is permissible. If this header
is not present, the default value is \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. 

The \header{Accept-Encoding} header is only used in requests which can
take bodies in the response. If no \header{Accept-Encoding} header
field is present in a request, the server {\MUST} use the ``identity''
encoding to the body in the response. In a 415 response, it indicates
the allowed encodings that can be used for bodies sent in a request to
the server. In {\INVITE}, it lists not only the encodings allowed for
bodies in the response, but the encodings which can be applied in
subsequent requests within the call initiated (or call leg updated by)
the {\INVITE}. Similarly, in a 2xx class response to {\INVITE}, it
lists the acceptable encodings which can be applied to bodies by the
UAS in subsequent requests within that call leg. In a 2xx response to
{\OPTIONS}, it indicates the encodings supported by the server. In a
2xx response to {\REGISTER}, it indicates the encodings that may be
used on bodies placed in subsequent requests to the registrar.

If a UA supports encodings beyond the default, it {\SHOULD} include an
\header{Accept-Encoding} header in all {\INVITE} requests (both initial and
re-{\INVITE}) and in all 2xx responses to {\INVITE} listing those
encodings it supports.
\end{changebar}

\motivation{HTTP/1.1 [H14.3] states that the server {\SHOULD} use
the ``identity'' encoding unless it has additional information about the
capabilities of the client. This is needed for backwards-compatibility
with old HTTP clients and does not affect SIP.}


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

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

\begin{changebar}
The \header{Accept-Encoding} header 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-Encoding} header
field is present in a request, the server assumes all languages are
acceptable to the client. In a 415 response, it indicates
the allowed languages that can be used for bodies sent in a request to
the server (the language of a body is defined by the
\header{Content-Language} header). In {\INVITE}, it lists not only the
languages allowed for the response, but the languages which can be used in
subsequent requests within the call initiated (or call leg updated by)
the {\INVITE}. Similarly, in a 2xx class response to {\INVITE}, it
lists the acceptable languages which can be used by the
UAS in subsequent requests within that call leg. In a 2xx response to
{\OPTIONS}, it indicates the languages supported by the server. In a
2xx response to {\REGISTER}, it indicates the languages that may be
used in bodies placed in subsequent requests to the registrar.

A UA {\SHOULD} include an
\header{Accept-Language} header in all {\INVITE} requests (both initial and
re-{\INVITE}) and in all 2xx responses to {\INVITE} listing those
languages it supports. This is particularly important to support
international usage of SIP.
\end{changebar}

A proxy {\MAY} use this field to help select the destination for the
call, for example, a human operator conversant in a language spoken by
the caller.

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}

The \header{Alert-Info} header field indicates that the content
indicated in the URLs should be rendered instead of ring tone. A user
{\SHOULD} be able to disable this feature selectively to prevent
unauthorized disruptions.

\begin{syntax}
Alert-Info    & = & "Alert-Info" ":" \# ( "$<$" URI "$>$" *( ";" generic-param ))\\
generic-param & = & token [ "=" ( token $|$ host $|$ quoted-string ) ]\\
\end{syntax}

Example:
\begin{verbatim}
Alert-Info: <http://wwww.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 user agent generating the message.  An \header{Allow} header field
{\MUST} be present in a 405 
(Method Not Allowed) response to any request, and {\SHOULD} be present in a 2xx
{\OPTIONS} response. In this usage, it indicates the set of methods
that can be invoked on the resource identified by the
\header{Request-URI} of the request sent by the UAC. 

\header{Allow} {\SHOULD} be present in an {\INVITE} request (initial
or re-{\INVITE}), and {\SHOULD} be present in any 2xx response to an
{\INVITE}. In this usage, it indicates what methods can be invoked
within the call leg, on the user agent sending the message, for the
duration of the call leg. For example, if a
\header{Allow} was present in a 200 OK to an initial {\INVITE}
listing {\INFO}, the caller would know that it is safe to send an
{\INFO} request on the call leg established by the 200 OK. An
\header{Allow} {\MAY} be sent in any 1xx responses for an 
{\INVITE}; it carries the same meaning as if it appeared in a 2xx, but
conveys this information to the UAC before the call is
established. This is helpful if the UAC wishes to send additional
requests on the call leg before it is accepted. 

\header{Allow} {\MAY} be present in provisional and final responses
for methods besides {\INVITE} and {\OPTIONS}. It carries the same
semantics in this case is it does in a 2xx to {\OPTIONS}. 

All methods, including {\ACK} and {\CANCEL}, understood by
the UA {\MUST} be included in the list of methods in the \header{Allow}
header, when present. The absence of an \header{Allow} header
{\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.

\motivation{Supplying an \header{Allow} header in responses to methods
other than {\OPTIONS} cuts down on the number of messages needed.}


\begin{syntax}
Allow & = & "Allow" ":" 1\#Method
\end{syntax}

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

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

Syntax and semantics follow those specified in RFC2617 \cite{rfc2617}.
\end{changebar}

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


A user agent that wishes to authenticate itself with a UAS or registrar
-- usually, but not necessarily, after receiving a 401 response --
{\MAY} do so by including an \header{Authorization} header field with
the request.  The \header{Authorization} field value consists of
credentials containing the authentication information of the user agent
for the realm of the resource being requested.

Section \ref{sec:authentication} overviews the use of the
\header{Authorization} header field, and Section~\ref{sec:httpauth} describes
the syntax and semantics when used with HTTP Basic and Digest
authentication.


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

The \header{Call-ID} general-header field uniquely identifies a
particular invitation or all registrations of a particular client.  Note
that a single multimedia conference can give rise to several calls with
different \header{Call-ID}s, e.g., if a user invites a single individual
several times to the same (long-running) conference.

For an {\INVITE} request, a callee user agent server {\SHOULDNOT} alert
the user if the user has responded previously to the \header{Call-ID} in
the {\INVITE} request.  If the user is already a member of the
conference and the conference parameters contained in the session
description have not changed, a callee user agent server {\MAY} silently
accept the call, regardless of the \header{Call-ID}.  An invitation for
an existing \header{Call-ID} or session can change the parameters of the
conference.  A client application {\MAY} decide to simply indicate to
the user that the conference parameters have been changed and accept the
invitation automatically or it {\MAY} require user confirmation.

A user may be invited to the same conference or call using several
different \header{Call-ID}s.  If desired, the client {\MAY} use identifiers
within the session description to detect this duplication.  For example,
SDP contains a session id and version number in the origin (\header{o})
field. 

The {\REGISTER} and {\OPTIONS} methods use the \header{Call-ID} value
(in addition to the \header{CSeq} value) to unambiguously match requests
and responses.  All {\REGISTER} requests issued by a single client
{\SHOULD} use the same \header{Call-ID}, at least within the same boot
cycle.  For these requests, it makes no difference whether the
\header{Call-ID} value matches an existing call or not.

\motivation{Since the \header{Call-ID} is generated by and for SIP,
there is no reason to deal with the complexity of URL-encoding and
case-ignoring string comparison.}

\begin{syntax}
callid   & = & token [ "@" token ]\\
Call-ID  & = & ( "Call-ID" $|$ "i" ) ":" callid\\
\end{syntax}

The \header{callid} {\MUST} be a globally unique identifier and
{\MUSTNOT} be reused for later calls.  Use of cryptographically random
identifiers \cite{rfc1750} is {\RECOMMENDED}.  Implementations {\MAY}
use the form ``localid@host''.  \header{Call-IDs} are case-sensitive and
are simply compared byte-by-byte.

\motivation{Using cryptographically random identifiers provides some
protection against session hijacking.  \header{Call-ID}, \header{To} and
\header{From} are needed to identify a {\em call leg.} The distinction
between call and call leg matters in calls with third-party control.}

For systems which have tight bandwidth constraints, many of the
mandatory SIP headers have a compact form, as discussed in
Section~\ref{sec:compact}.  These are alternate names for the headers
which occupy less space in the message.  In the case of
\header{Call-ID}, the compact form is \header{i}.

For example, both of the following are valid:
\begin{verbatim}
  Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
\end{verbatim}
or
\begin{verbatim}
  i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
\end{verbatim}

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

The \header{Call-Info} general 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.  ``\header{icon}'' designates an image
suitable as an iconic representation of the caller or callee;
``\header{info}'' describes the caller or callee in general, e.g.,
through a web page; ``\header{card}'' provides a business card (e.g., in
vCard \cite{rfc2426} or LDIF \cite{rfc2849} formats).

\begin{syntax}
Call-Info  & = & "Call-Info" ":" \# ( "$<$" URI "$>$" *( ";" info-param) )\\
info-param & = & "purpose" "=" ( "icon" $|$ "info" $|$ "card" $|$ token )\\
           &$|$& generic-param \\
\end{syntax}

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}

Among the methods discussed in this specification, the \header{Contact}
general-header field can appear in {\INVITE}, {\OPTIONS}, {\ACK}, and
{\REGISTER} requests, and in 1xx, 2xx, 3xx, and 485 responses.  Other
methods defined elsewhere may allow or require the use of the
\header{Contact} header field.  This is generally necessary if the
recipient of this method needs to send requests to the originator.  In
general, it provides a URL where the user can be reached for further
communications.

In some of the cases below, the client uses information from the
\header{Contact} header field in \header{Request-URI} of future
requests.  In these cases, the client copies all but the
``\header{method-param}'' and ``\header{header}'' elements of the
\header{addr-spec} part of the \header{Contact} header field into the
\header{Request-URI} of the request.  It uses the ``\header{header}''
parameters to create headers for the request, replacing any default
headers normally used.  Unless the client is configured to use a default
proxy for all outgoing requests, it then directs the request to the
address and port specified by the ``\header{maddr}'' and
``\header{port}'' parameters, using the transport protocol given in the
``\header{transport}'' parameter.  If ``\header{maddr}'' is a multicast
address, the value of ``\header{ttl}'' is used as the time-to-live
value.

\begin{description}


\item[{\INVITE}, {\OPTIONS} and {\ACK} requests:] {\INVITE} requests
{\MUST}, and {\ACK} requests {\MAY} contain a single \header{Contact} header
indicating a single URI from which location the request is
originating. The URI
{\SHOULD} contain the address of the client itself (i.e., its IP
address, or a FQDN for the host, or an SRV record with the highest
priority entry beingan FQDN of that host). See Section \ref{sec:rr}
for usage of the \header{Contact} header for routing subsequent
requests. 
For {\OPTIONS}, \header{Contact} provides a hint where
future SIP requests can be sent or the user can be contacted via non-SIP
means.

\item[{\INVITE} 1xx responses:] A UAS sending a provisional response
(1xx) {\MAY} insert a \header{Contact} response header.  It has the same
semantics in a 1xx response as a 2xx {\INVITE} response.  Note that
{\CANCEL} requests {\MUSTNOT} be sent to that address, but rather follow
the same path as the original request.


\item[{\INVITE} and {\OPTIONS} 2xx responses:] A user agent server
sending a definitive, positive response (2xx) {\MUST} insert a single
\header{Contact} response header field indicating a single SIP URI
under which it is reachable most directly for future SIP requests,
such as {\ACK}, within the same call leg.  The URI {\SHOULD} contain
the address of the server itself (i.e., its IP address, or a FQDN for
the host, or an SRV record with the highest priority entry beingan
FQDN of that host). See Section \ref{sec:rr} for usage of the
\header{Contact} header for routing subsequent requests.


If a UA supports both UDP and TCP, it {\SHOULDNOT} indicate a transport
parameter in the URI.

\motivation{The \header{Contact} value {\SHOULDNOT} be cached
across calls, as it may not represent the most desirable location for a
particular destination address.}


\item[{\REGISTER} requests and responses:] See
Section~\ref{sec:REGISTER}. The \header{Contact} header value of ``*''
is only used in {\REGISTER} requests.


\item[3xx and 485 responses:] The \header{Contact} response-header field
can be used with a 3xx or 485 (Ambiguous) response codes to indicate one
or more alternate addresses to try.  It can appear in responses to
{\BYE}, {\INVITE} and {\OPTIONS} methods.  The \header{Contact} header
field contains URIs giving the new locations or user names to try, or
may simply specify additional transport parameters.  A 300 (Multiple
Choices), 301 (Moved Permanently), 302 (Moved Temporarily) or 485
(Ambiguous) response {\SHOULD} contain a \header{Contact} field
containing URIs of new addresses to be tried.  A 301 or 302 response may
also give the same location and username that was being tried but
specify additional transport parameters such as a different server or
multicast address to try or a change of SIP transport from UDP to TCP or
vice versa.  The client copies information from the \header{Contact}
header field into the \header{Request-URI} as described above.

\item[4xx, 5xx and 6xx responses:] The \header{Contact} response-header
field can be used with a 4xx, 5xx or 6xx response to indicate the
location where additional information about the error can be found.

\end{description}

Note that the \header{Contact} header field {\MAY} also refer to a
different entity than the one originally called.  For example, a SIP
call connected to GSTN gateway may need to deliver a special information
announcement such as ``The number you have dialed has been changed.''

A \header{Contact} response header field can contain any suitable URI
indicating where the called party can be reached, not limited to SIP
URLs.  For example, it could contain URL's for phones, fax, or
\header{irc} (if they were defined) or a \header{mailto:} (RFC 2368,
\cite{rfc2368}) URL.

The following parameters are defined. Additional parameters may be
defined in other specifications.

\begin{description}
\item[\header{q}:] The ``\header{qvalue}'' indicates the relative
preference among the locations given.  ``\header{qvalue}'' values are
decimal numbers from 0 to 1, with higher values indicating higher
preference. The default value is 0.5.

\item[\header{action}:] The ``\header{action}'' parameter is used only
when registering with the {\REGISTER} request.  It indicates whether the
client wishes that the server proxy or redirect future requests intended
for the client.  If this parameter is not specified the action taken
depends on server configuration.  In its response, the registrar
{\SHOULD} indicate the mode used.  This parameter is ignored for other
requests. 

\item[\header{expires}:] The ``\header{expires}'' parameter indicates
how long the URI is valid.  The parameter is either a number indicating
seconds or a quoted string containing a \header{SIP-date}.  If this
parameter is not provided, the value of the \header{Expires} header
field determines how long the URI is valid.  Implementations {\MAY}
treat values larger than 2**32-1 (4294967295 seconds or 136 years) as
equivalent to 2**32-1.

\end{description}

\inputtxt{contact_syntax}

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. 
Note that there may or may not be LWS between the \header{display-name}
and the ``$<$''.

\motivation{The \header{Contact} header field fulfills functionality
similar to the \header{Location} header field in HTTP. However, the HTTP
header 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 current syntax corresponds to
that for the \header{To} and \header{From} header, which also allows the
use of display names.}

Example:

\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
\end{verbatim}

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

\begin{syntax}
Content-Disposition  & = & "Content-Disposition" ":" \\
                     &   & disposition-type *( ";" disposition-param )\\
disposition-type     & = & "render" $|$ "session" $|$ "icon" $|$ "alert" \\
                     &$|$& disp-extension-token\\
disposition-param    & = & "handling" "=" \\
                     &   & ( "optional" $|$ "required" $|$ other-handling )\\
                     &$|$& generic-param\\
other-handling       & = & token\\
disp-extension-token & = & token\\
\end{syntax}

The \header{Content-Disposition} header field describes how the message
body or, in the case of multipart messages, a message body part is to be
interpreted by the UAC or UAS. The SIP header extends the MIME
\header{Content-Type} (RFC 1806 \cite{rfc1806}).

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

The disposition type ``icon'' indicates that the body part contains an
image suitable as an iconic representation of the caller or callee.  The
value ``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-parm}, describes how the UAS
should react if it receives a message body whose content type or
disposition type it does not understand.  If the parameter has the value
``optional'', the UAS {\MUST} ignore the message body; if it has the
value ``required'', the UAS {\MUST} return 415 (Unsupported Media Type). 
If the handling parameter is missing, the value ``required'' is to be
assumed.

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

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

\begin{syntax}
Content-Encoding & = & ( "Content-Encoding" $|$ "e" ) ":" \\
                 &   & 1\#content-coding
\end{syntax}

The \header{Content-Encoding} entity-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, the content
codings {\MUST} be listed in the order in which they were applied.

All content-coding values are case-insensitive. The Internet Assigned
Numbers Authority (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. If the
server is not capable of decoding the body, or does not recognize any
of the content-coding values, it {\MUST} send a 415 ``Unsupported
Media Type'' response, listing acceptable encodings in the
\header{Accept-Encoding} header. A server {\MAY} apply content
encodings to the bodies in responses. The server {\MUST} only use
encodings listed in the \header{Accept-Encoding} header in the
request.

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

See [H14.12].

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

The \header{Content-Length} entity-header field indicates the size of the
message-body, in decimal number of octets, sent to the recipient.

\begin{syntax}
Content-Length & = & ( "Content-Length" $|$ "l" ) ":" 1*DIGIT
\end{syntax}

An example is
\begin{verbatim}
  Content-Length: 3495
\end{verbatim}

Applications {\SHOULD} use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the
entity.  (The size of the message-body does \emph{not} include the CRLF
separating headers 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 {\MUST} be set to zero. 
If a server receives a datagram request without \header{Content-Length},
it {\MUST} assume that the request encompasses the remainder of the
packet.  If a server receives a datagram request with a
\header{Content-Length}, but the value differs from the size of the body
sent in the request, the server {\SHOULD} return a 400 (Bad Request)
response. 

If a response does not contain a \header{Content-Length}, the client
assumes that it encompasses the remainder of the datagram packet or the
data until the stream connection is closed, as applicable. 
Section~\ref{sec:message-body} describes how to determine the length of
the message body.

\motivation{The ability to omit \header{Content-Length} simplifies the
creation of cgi-like scripts that dynamically generate responses.}

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


The \header{Content-Type} entity-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 {\MUST}
be present if the body is not empty. If the body is empty, and a
\header{Content-Length} header is present, it indicates that the body
of the specific type has zero length (for example, if it is an emtpy
audio file).


\begin{syntax}
Content-Type & = & ( "Content-Type" $|$ "c" ) ":" media-type
\end{syntax}

Examples of this header field are
\begin{verbatim}
  Content-Type: application/sdp
  Content-Type: text/html; charset=ISO-8859-4
\end{verbatim}

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


Clients {\MUST} add the \header{CSeq} (command sequence)
general-header field to every request.  A \header{CSeq} header field
in a request contains the request method and a single decimal sequence
number.  The sequence number {\MUST} be expressible as a 32-bit
unsigned integer. A server {\MUST} echo the \header{CSeq} value from
the request in its response. The \header{CSeq} header serves to order
transactions within a call leg, and to provide a means to uniquely
identify transactions.

\begin{syntax}
CSeq & = & "CSeq" ":" 1*DIGIT Method
\end{syntax}

For requests that are outside of a call leg, or for a request that
initiates a session, the value of the sequence number is arbitrary,
but {\MUST} be less than 2**31.  For requests which are subsequent
ones within an existing call leg (such as a re-{\INVITE} or {\BYE}),
the \header{CSeq} header {\MUST} contain strictly monotonically
increasing and contiguous (increasing-by-one) sequence numbers;
sequence numbers do not wrap around.  Retransmissions of the same
request carry the same \header{CSeq} value.


For requests outside of a call leg, ordering is irrelevant, and so the
value of the \header{CSeq} number in requests received by a UAS is
not important. For requests within a call leg, ordering is
important. Therefore, a UAS {\MUST} remember the highest sequence number for
any request received within a call leg. The server {\MUST} reject,
using a 400 class response, any request within a call leg with a lower
sequence number. Any request that is received with a sequence number
higher than the highest received so far (even it is higher by more
than one), {\SHOULD} be accepted. \annotation{Its possible to receive
requests that are higher by more than one, even without loss or
reordering. Lets say a caller goes through a proxy that is
authenticating it. The caller sends an initial {\INVITE}, with a
\header{CSeq} of one. This is rejected with a 407. The caller
resubmits the request with a \header{CSeq} of two. The UAS stores this
as the highest sequence number on this call leg. The caller sends a
re-{\INVITE} with a \header{CSeq} of three. The proxy rejects this
with a 407 as well. The caller resubmits the request, with a
\header{CSeq} of four. This is accepted by the proxy, and passed to
the UAS. Now, this second request is higher than the first, but by
two, even though no requests were lost.}

If a client initiates a session, and receives multiple 200-class
responses, each establishes a separate call leg. For subsequent
requests within each of those call legs (each of which differs only by
the tag in the \header{To} field), the \header{CSeq} numbers increment
independently from the other call legs. Furthermore, the
\header{CSeq} numbering space is unique in each direction. That is,
the \header{CSeq} values in requests from A to B are independent of
the values in requests from B to A.

The {\ACK} request {\MUST} contain the same
\header{CSeq} numeric value as the {\INVITE} request that it refers
to, but with a Method of ``ACK''. The {\CANCEL} request {\MUST}
contain the same \header{CSeq} numeric value as the request it
cancels, but with a Method of ``CANCEL''.

The \header{Method} value allows the client to distinguish the response
to a {\CANCEL} request from that of the request it is cancelling.  {\CANCEL}
requests can be generated by proxies; if they were to increase the
sequence number, it might conflict with a later request issued by the
user agent for the same call.


With a length of 32 bits, a server could generate, within a single call,
one request a second for about 136 years before needing to wrap around.
The initial value of the sequence number is chosen so that subsequent
requests within the same call will not wrap around. A non-zero initial
value allows to use a time-based initial sequence number, if the
client desires. A client could, for example, choose the 31 most significant
bits of a 32-bit second clock as an initial sequence number. 

Example:

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

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

\header{Date} is a general-header field. Its syntax is:

\begin{syntax}
Date     & = & "Date" ":" SIP-date\\
SIP-date & = & rfc1123-date \\
\end{syntax}

See [H14.18] for a definition of rfc1123-date.  Note that unlike
HTTP/1.1, SIP only supports the most recent RFC 1123 \cite{rfc1123}
formatting for dates.  As in [H3.3], SIP restricts the timezone in
\header{SIP-date} to ``GMT'', while RFC 1123 allows any timezone. 
\motivation{The consistent use of GMT between \header{Date},
\header{Expires} and \header{Retry-After} headers allows implementation
of simple clients that do not have a notion of absolute time.} Note that
\header{rfc1123-date} is case-sensitive.

The \header{Date} header field reflects the time when the request or
response is first sent.  Thus, retransmissions have the same
\header{Date} header field value as the original. 

Registrars {\MUST} include this header in {\REGISTER} responses if they
use absolute expiration times and {\SHOULD} include it for all responses.

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

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

The \header{Encryption} general-header field specifies that the content
has been encrypted.  Section~\ref{sec:security} describes the overall
SIP security architecture and algorithms.  This header field is intended
for end-to-end encryption of requests and responses.  Requests are
encrypted based on the public key belonging to the entity named in the
\header{To} header field.  Responses are encrypted based on the public key
conveyed in the \header{Response-Key} header field. Note that the
public keys themselves may not be used for the encryption. This
depends on the particular algorithms used.

For any encrypted message, at least the message body and possibly other
message header fields are encrypted.  An application receiving a request
or response containing an \header{Encryption} header field decrypts the
body and then concatenates the plaintext to the request line and headers
of the original message.  Message headers in the decrypted part
completely replace those with the same field name in the plaintext part. 
(Note:  If only the body of the message is to be encrypted, the body has
to be prefixed with \header{CRLF} to allow proper concatenation.) Note
that the request method and \header{Request-URI} cannot be encrypted.

\motivation{Encryption only provides privacy; the recipient has no
guarantee that the request or response came from the party listed in the
\header{From} message header, only that the sender used the recipient's
public key.  However, proxies will not be able to modify the request or
response.}

\begin{syntax}
Encryption & = & "Encryption" ":" encryption-scheme 1*SP\\
           &   & \#encryption-params\\
encryption-scheme & = & token\\
encryption-params & = & generic-param\\
\end{syntax}

The token indicates the form of encryption used; it is described in
Section \ref{sec:security}.

Since proxies can base their forwarding decision on any combination of
SIP header fields, there is no guarantee that an encrypted request
``hiding'' header fields will reach the same destination as an otherwise
identical un-encrypted request. 

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

The \header{Error-Info} response header provides a pointer to additional
information about the error status response. This header field is only
contained in 3xx, 4xx, 5xx and 6xx responses.

\begin{syntax}
Error-Info & = & "Error-Info" ":" \# ( "$<$" URI "$>$" *( ";" generic-param ))\\
\end{syntax}

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

The \header{Expires} entity-header field gives the date and time after
which the message content expires. 

This header field is currently defined only for the {\REGISTER}, as
described in Section \ref{sec:REGISTER}, and
{\INVITE} methods. 


For {\INVITE} requests, it is a request and response-header field.  In a
request, the caller can limit the validity of an invitation, for
example, if a client wants to limit the time duration of a search or a
conference invitation.  A user interface {\MAY} take this as a hint to
leave the invitation window on the screen even if the user is not
currently at the workstation.  This also limits the duration of a
search.  If the request expires before the search completes, the proxy
returns a 408 (Request Timeout) status.  In a 302 (Moved Temporarily)
response, a server can advise the client of the maximal duration of the
redirection.

Note that the expiration time does {\em 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.

The value of this field can be either a \header{SIP-date} or an
integer number of seconds (in decimal), measured from the receipt of the
request.  The latter approach is preferable for short durations, as it
does not depend on clients and servers sharing a synchronized clock.
Implementations {\MAY} treat values larger than 2**32-1 (4294967295 or
136 years) as equivalent to 2**32-1.

\begin{syntax}
Expires & = & "Expires" ":" ( SIP-date $|$ delta-seconds )
\end{syntax}

Two examples of its use are
\begin{verbatim}
  Expires: Thu, 01 Dec 1994 16:00:00 GMT
  Expires: 5
\end{verbatim}

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

Requests and responses {\MUST} contain a \header{From} general-header
field, indicating the initiator of the request.  (Note that this may be
different from the initiator of the call leg.  Requests sent by the
callee to the caller use the callee's address in the \header{From}
header field.) The \header{From} field {\MUST} contain the
``\header{tag}'' parameter.  However, a server {\MUST} be prepared to
receive a request without a tag, in which case the tag is considered to
effectively have a value of zero.  This approach maintains backwards
compatibility with RFC2543, which did not mandate \header{From} tags. 
\annotation{The reason this has become mandatory is to handle the
following scenario.  A calls B, without a From tag.  B accepts, and
places a To tag in the response.  Now, B re-INVITEs A.  This request has
no To tag, since the To field contains the From from the INVITE.  A
receives this, and since the To field doesn't have a tag, adds one to
the response.  This results in the call leg ID changing mid-call, which
is difficult to handle.}.  The server copies the \header{From} header
field from the request to the response.  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.

The \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 ignores them.

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

\begin{syntax}
From       & = & ( "From" $|$ "f" ) ":" ( name-addr $|$ addr-spec ) \\
           &   & *( ";" from-param )\\
from-param & = & tag-param $|$ generic-param\\
tag-param  & = & "tag" "=" token\\
\end{syntax}

Examples:

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

The ``\header{tag}'' value {\MUST} be globally unique and
cryptographically random with at least 32 bits of randomness. It
{\SHOULD} differ for each call leg.

For the purpose of identifying call legs, two \header{From} or
\header{To} header fields are equal if and only if:

\begin{itemize}
\item The \header{addr-spec} component is equal, according to the rules
in Section~\ref{sec:uri_comparison}.

\item Any ``\header{tag}'' and ``\header{generic-param}'' parameters are
equal, compared according to the case-sensitivity rules in
Section~\ref{sec:header-fields}.  Only parameters that appear in both
header fields are compared.

\end{itemize}

\motivation{\header{Call-ID}, \header{To} and \header{From} are needed
to identify a {\em call leg.}  The distinction between call and call
leg matters in calls with multiple responses to a forked request.  The
format is similar to the equivalent RFC 822 \cite{rfc822} header, but
with a URI instead of just an email address.}

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

The \header{In-Reply-To} request header field enumerates the call-IDs
that this call references or returns.

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

\begin{syntax}
In-Reply-To & = & "In-Reply-To" ":" 1\# callid\\
\end{syntax}

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} request-header field may 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 which appears to be
failing or looping in mid-chain.

\begin{syntax}
Max-Forwards & = & "Max-Forwards" ":" 1*DIGIT
\end{syntax}

The \header{Max-Forwards} value is a decimal integer indicating the
remaining number of times this request message is allowed to be
forwarded.

Each proxy or gateway recipient of a request containing a
\header{Max-Forwards} header field {\MUST} check and update its value
prior to forwarding the request.  If the received value is zero (0), the
recipient {\MUSTNOT} forward the request and returns 483 (Too many
hops).  Instead, a server {\MAY} act as a final recipient for {\OPTIONS}
requests.  It is {\RECOMMENDED} that the server include
\header{Supported}, \header{Server} and \header{Allow} header fields in
the response.

If the received \header{Max-Forwards} value is greater than zero, then
the forwarded message {\MUST} contain an updated Max-Forwards field with
a value decremented by one (1).

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

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

See [H19.4.1].

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

The \header{Organization} general-header field conveys the name of the
organization to which the entity issuing the request or response
belongs.  It {\MAY} also be inserted by proxies at the boundary of an
organization.

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

\begin{syntax}
Organization & = & "Organization" ":" TEXT-UTF8-TRIM
\end{syntax}

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

The \header{Priority} request-header field indicates the urgency of the
request as perceived by the client.

\begin{syntax}
Priority       &  =  & "Priority" ":" priority-value\\
priority-value &  =  & "emergency" $|$ "urgent" $|$ "normal"\\
               & $|$ & "non-urgent" $|$ other-priority\\
other-priority &  =  & token\\
\end{syntax}

It is {\RECOMMENDED} that the value of ``emergency'' only be used when
life, limb or property are in imminent danger.

Examples:

\begin{verbatim}
  Subject: A tornado is heading our way!
  Priority: emergency

  Subject: Weekend plans
  Priority: non-urgent
\end{verbatim}

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

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

The \header{Proxy-Authenticate} response-header field {\MUST} be
included as part of a 407 (Proxy Authentication Required) response.  It
may also occur in a 401 (Unauthorized) response if the request was
forked.  The field value consists of a challenge that indicates the
authentication scheme and parameters applicable to the proxy for this
\header{Request-URI}.

Unlike its usage within HTTP, the \header{Proxy-Authenticate} header
{\MUST} be passed upstream in the response to the UAC. In SIP, only
UAC's can authenticate themselves to proxies.

The syntax for this header is defined in
[H14.33]. See \ref{sec:httpauth} for further details on its usage.

A client {\SHOULD} cache the credentials used for a particular proxy
server and realm for the next request to that server.  Credentials are,
in general, valid for a specific value of the \header{Request-URI} at a
particular proxy server.  If a client contacts a proxy server that has
required authentication in the past, but the client does not have
credentials for the particular \header{Request-URI}, it {\MAY} attempt
to use the most-recently used credential. The
server responds with 407 if the client guessed wrong.

\motivation{This suggested caching behavior is motivated by proxies
restricting phone calls to authenticated users.  It seems likely that
in most cases, all destinations require the same password. Note that
end-to-end authentication is likely to be destination-specific.}

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

The \header{Proxy-Authorization} request-header field allows the client
to identify itself (or its user) to a proxy which requires
authentication.  The \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.

Unlike \header{Authorization}, the \header{Proxy-Authorization} header
field applies only to the next outbound proxy that demanded
authentication using the \header{Proxy- Authenticate} field. When
multiple proxies are used in a chain, the \header{Proxy-Authorization}
header field is consumed by the first outbound proxy that was
expecting to receive credentials. A proxy {\MAY} relay the credentials
from the client request to the next proxy if that is the mechanism by
which the proxies cooperatively authenticate a given request.

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

\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. If a
proxy server does not
understand the option, it {\MUST} respond by returning status code 420
(Bad Extension) and list those options it does not understand in the
\header{Unsupported} header. A UAC {\SHOULD} attempt to retry the
request, without using the features listed in the \header{Unsupported}
header.

 
See Section~\ref{sec:Require} for more details on the mechanics of this
message and a usage example.

\begin{syntax}
Proxy-Require & = & "Proxy-Require" ":" 1\#option-tag\\
\end{syntax}

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

The \header{Record-Route} header field has the following syntax:
\begin{syntax}
Record-Route & = & "Record-Route" ":" 1\# ( name-addr *( ";" rr-param ))\\
rr-param     & = & generic-param\\
\end{syntax}


Details of its use are described in Section~\ref{sec:rr}.


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


The \header{Require} general-header field is used by clients to tell
user agent servers about options that the client expects the server to
support in order to properly process the request.  If a server does not
understand the option, it {\MUST} respond by returning status code 420
(Bad Extension) and list those options it does not understand in the
\header{Unsupported} header. A UAC {\SHOULD} attempt to retry the
request, without using the features listed in the \header{Unsupported}
header. 


\begin{syntax}
Require & = & "Require" ":" 1\#option-tag\\
\end{syntax}

Example:
\begin{verbatim}
C->S:   INVITE sip:watson@bell-telephone.com SIP/2.0
        Require: com.example.billing
        Payment: sheep_skins, conch_shells

S->C:   SIP/2.0 420 Bad Extension
        Unsupported: com.example.billing
\end{verbatim}

\motivation{This is to make sure that the client-server interaction will
proceed without delay when all options are understood by both sides, and
only slow down if options are not understood (as in the example above). 
For a well-matched client-server pair, the interaction proceeds quickly,
saving a round-trip often required by negotiation mechanisms.  In
addition, it also removes ambiguity when the client requires features
that the server does not understand. Some features, such as call
handling fields, are only of interest to end systems.}

Proxy and redirect servers {\MUST} ignore features that are not
understood.  If a particular extension requires that intermediate
devices support it, the extension {\MUST} be tagged in the
\header{Proxy-Require} field as well (see
Section~\ref{sec:Proxy-Require}).

\subsection{\header{Response-Key}}
\label{sec:Response-Key}

The \header{Response-Key} request-header field can be used by a client
to request the key that the called user agent {\SHOULD} use to encrypt
the response with.  The syntax is:

\begin{syntax}
Response-Key   & = & "Response-Key" ":" key-scheme 1*SP \#key-param\\
key-scheme     & = & token\\
key-param      & = & generic-param\\
\end{syntax}

The ``\header{key-scheme}'' gives the type of encryption to be used for
the response.  Section \ref{sec:security} describes security schemes.

If the client insists that the server return an encrypted response, it
includes a 

\begin{center}
\header{Require: org.ietf.sip.encrypt-response} 
\end{center}

header field in its request.  If the server cannot encrypt for whatever
reason, it {\MUST} follow normal \header{Require} header field
procedures and return a 420 (Bad Extension) response.  If this
\header{Require} header field is not present, a server {\SHOULD} still
encrypt if it can.

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

The \header{Retry-After} response-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), 600 (Busy), or 603 (Decline) response to indicate when the
called party anticipates being available again.  The value of this field
can be either an \header{SIP-date} or an 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.

\begin{syntax}
Retry-After & = & "Retry-After" ":" ( SIP-date $|$ delta-seconds )\\
            &   & [ comment ] *( ";" retry-param )\\
retry-param & = & "duration" "=" delta-seconds\\
            &$|$& generic-param\\
\end{syntax}

Examples of its use are
\begin{verbatim}
  Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting)
  Retry-After: Mon, 01 Jan 9999 00:00:00 GMT 
    (Dear John: Don't call me back, ever)
  Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600
  Retry-After: 120
\end{verbatim}

In the third example, the callee is reachable for one hour starting at
21:00 GMT.  In the last example, the delay is 2 minutes.

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

The \header{Route} header field has the following syntax:
\begin{syntax}
Route           & = & "Route" ":" 1\# ( name-addr *( ";" rr-param ))\\
\end{syntax}


Details of its use are described in Section~\ref{sec:rr}.


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

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

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

This header field provides a summary or indicates the nature of the
call, allowing call filtering without having to parse the session
description.  (Note that the session description does not have to use
the same subject indication as the invitation.)

\begin{syntax}
Subject & = & ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM
\end{syntax}

Example:

\begin{verbatim}
  Subject: Tune in - they are talking about your work!
\end{verbatim}

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

The \header{Supported} general-header field enumerates all the
capabilities of the client or server.  This header field {\SHOULD} be
included in all requests (except {\ACK}) and in all responses. 

\motivation{Including the header field in all responses greatly
simplifies the use of extensions for call control in subsequent
transactions with the same server.}

Syntax:
\begin{syntax}
Supported & = & ( "Supported" $|$ "k" ) ":" 1\#option-tag\\
\end{syntax}

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

The \header{Timestamp} general-header field describes when the client
sent the request to the server.  The client uses the current time value
at the time of transmission, i.e., each retransmission of a request is
likely to have a different timestamp value. 

The value of the timestamp is of significance only to the client and it
{\MAY} use any timescale.  The server {\MUST} echo the exact same value
in all provisional and final responses and {\MAY}, if it has accurate
information about this, add a floating point number indicating the
number of seconds that have elapsed since it has received the request. 
The timestamp is used by the client to compute the round-trip time to
the server so that it can adjust the timeout value for retransmissions.

\begin{syntax}
Timestamp & = & "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]\\
delay     & = & *(DIGIT) [ "." *(DIGIT) ]\\
\end{syntax}

Note that there {\MUSTNOT} be any LWS between a DIGIT and the decimal
point.

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

The \header{To} general-header field specifies the ``logical'' recipient
of the request.

\begin{syntax}
To       & = & ( "To" $|$ "t" ) ":" ( name-addr $|$ addr-spec ) \\
         &   & *( ";" to-param )\\
to-param & = & tag-param $|$ generic-param\\  
\end{syntax}

Requests and responses {\MUST} contain a \header{To} general-header
field, indicating the desired recipient of the request.  The optional
``\header{display-name}'' is meant to be rendered by a human-user
interface.  The UAS or redirect server copies the \header{To} header
field into its response, and {\MUST} add a ``\header{tag}'' parameter.

The \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.

The ``\header{tag}'' parameter serves as a general mechanism to
distinguish multiple instances of a user identified by a single SIP URL. 
As proxies can fork requests, the same request can reach multiple
instances of a user (mobile and home phones, for example).  As each can
respond, there needs to be a means to distinguish the responses from
each at the caller.  The situation also arises with multicast requests. 
The tag in the \header{To} header field serves to distinguish responses
at the UAC.  It {\MUST} be placed in the \header{To} field of the
response by user agent, registrar and redirect servers, but {\MUSTNOT}
be inserted into responses forwarded upstream by proxies.  However,
responses generated locally by a proxy, and then sent upstream, {\MUST}
contain a tag.

A UAS or redirect server {\MUST} add a ``\header{tag}'' parameter for
all final responses for all transactions within a call leg.  All such
parameters have the same value within the same call leg.  These servers
{\SHOULD} add the \header{tag} for informational responses during the
initial {\INVITE} transaction, but {\MUST} add a tag to informational
responses for all subsequent transactions. 

See Section~\ref{sec:From} for details of the ``\header{tag}''
parameter.  The ``\header{tag}'' parameter in \header{To} headers is
ignored when matching responses to requests that did not contain a
``\header{tag}'' in their \header{To} header.

Section~\ref{sec:ua} describes when the ``tag'' parameter {\MUST} appear
in subsequent requests.  Note that if a request already contained a tag,
this tag {\MUST} be mirrored in the response; a new tag {\MUSTNOT} be
inserted.

Section~\ref{sec:From} describes how \header{To} and \header{From}
header fields are compared for the purpose of matching requests to call
legs.

UAS {\SHOULD} accept requests even if they do not recognize the URI
scheme (e.g., a \texttt{tel:} URI) or if the \header{To} header does not
address the user.  Only \header{Request-URI} that do not match the
recipient should cause requests to be rejected.

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. 
Note that LWS is common, but \textbf{not} mandatory between the
\header{display-name} and the ``$<$''.

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

\motivation{\header{Call-ID}, \header{To} and \header{From} are needed
to identify a {\em call leg.} The distinction between call and call leg
matters in calls with multiple responses from a forked request.  The
``\header{tag}'' is added to the \header{To} header field in the
response to allow forking of future requests for the same call by
proxies, while addressing only one of the possibly several responding
user agent servers.  It also allows several instances of the callee to
send requests that can be distinguished.}

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

The \header{Unsupported} response-header field lists the features not
supported by the server.  See Section~\ref{sec:Require} for a usage
example and motivation. 

Syntax:
\begin{syntax}
Unsupported & = & "Unsupported" ":" 1\#option-tag\\
\end{syntax}

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

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

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

The \header{Via} field indicates the path taken by the request so far. 
This prevents request looping and ensures replies take the same path as
the requests, which assists in firewall traversal and other unusual
routing situations.  

\subsubsection{Requests}
\label{sec:Via:requests}

The client originating the request {\MUST} insert into the request a
\header{Via} field containing the transport protocol used to send the
message, the client's host name or network address and, if not the
default port number, the port number at which it wishes to receive
responses.  (Note that this port number can differ from the UDP source
port number of the request.) A fully-qualified domain name is
{\RECOMMENDED}.  Each subsequent proxy server that sends the request
onwards {\MUST} add its own additional \header{Via} field before any
existing \header{Via} fields.  A proxy that receives a redirection (3xx)
response and then searches recursively, {\MUST} use the same
\header{Via} headers as on the original proxied request.

A client that sends a request to a multicast address {\MUST} add the
``\header{maddr}'' parameter to its \header{Via} header field, and
{\SHOULD} add the ``\header{ttl}'' parameter.  (In that case, the
\header{maddr} parameter {\SHOULD} contain the destination multicast
address, although under exceptional circumstances it {\MAY} contain a
unicast address.) If a server receives a request which contained an
``\header{maddr}'' parameter in the topmost \header{Via} field, it
{\SHOULD} send the response to the address listed in the
``\header{maddr}'' parameter.

Loop detection is described in Section~\ref{sec:proxying}. 

\subsubsection{Receiver-tagged \header{Via} Header Fields}
\label{sec:Via:received}


A proxy or UAS receiving a request {\SHOULD} check the first
\header{Via} header field to ensure that it contains the sender's
correct network address, as seen from that proxy.  If the \header{Via}
header contains a domain name or if it contains an IP address that
differs from the packet source address, the proxy or UAS {\SHOULD} add
a ``\header{received}'' attribute to that \header{Via} header field.

\motivation{A multi-homed host may not be able to insert a network
address into the \header{Via} header field that can be reached by the
next hop, for example because if one of the networks is private.  The
address placed into the \header{Via} header may differ from the
interface actually used, as that interface is selected only at packet
sending time by the IP layer. Similarly, a request traversing a network
address translator (NAT) will also cause the sending address to differ
from the address seen by the next hop. The mechanism described here is
unlikely to be sufficient, however, for allowing packets to traverse a
NAT in the reverse direction.}

An example is:

\begin{verbatim}
  Via: SIP/2.0/UDP erlang.bell-telephone.com:5060
  Via: SIP/2.0/UDP 128.59.16.1:5060 ;received=128.59.19.3
\end{verbatim}

In this example, the message originated from a multi-homed host with two
addresses, 128.59.16.1 and 128.59.19.3.  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, containing the address that the packet
actually came from.


\subsubsection{Receiving Responses}
\label{sec:Via:responses}

\header{Via} header fields in responses received are processed by a
proxy or UAC according to the following rules:

\begin{enumerate}


\item The first \header{Via} header field should indicate the proxy or
client processing this response.  Specifically, the \header{sent-by}
value should equal the value inserted by the proxy or UAC. The
\header{recevied} parameter {\MUSTNOT} be used by a proxy or UAC to
determine if the response is for a request it sent. If the
\header{sent-by} value is not equal to the value inserted by the proxy
or UAC, discard the message. Otherwise, remove this \header{Via}
field.


\item If there is no second \header{Via} header field, this response is
destined for this client. Otherwise, use this \header{Via} field as the
destination, as described in Section~\ref{sec:Via:Forwarding}.

\end{enumerate}

\subsubsection{Generating Responses}
\label{sec:Via:UAS}

A UAS, proxy or redirect that server that generates a response copies
the \header{Via} header fields from the request into the response,
without changing their order, and uses the top (first)
\header{Via} element as the destination, as described in the next
section. 

\subsubsection{Sending Responses}
\label{sec:Via:Forwarding}

Given a destination described by a \header{Via} header field, the
response is sent according to the following rules:

\begin{itemize}

\item If the ``\header{sent-protocol}'' is a reliable transport protocol
such as TCP, TLS or SCTP, send the response using the existing TCP
connection to the source of the original request. If no connection is
open, open a connection to the IP address in the \header{received}
parameter, if present using the port
in the \header{sent-by} value, or port 5060 if none is present. If the
connection attempt fails, or if there was no \header{received}
parameter, the server {\SHOULD} attempt to open a connection to the
address in the \header{sent-by} value, which may be a domain name. To
do this, it constructs a SIP URL of the form
``sip:<sent-by>;transport=<sent-protocol>'' and then uses the
procedures defined in \cite{draft-ietf-sip-srv} to determine the IP
address and port to open the connection and send the response to.


\item Otherwise, if the \header{Via} header field contains a
``\header{maddr}'' parameter, forward the response to the address listed
there, using the port indicated in ``\header{sent-by}'', or port 5060 if
none is present.  If the address is a multicast address, the response
{\SHOULD} be sent using the TTL indicated in the ``\header{ttl}''
parameter, or with a TTL of 1 if that parameter is not present. 


\item Otherwise, if it is a receiver-tagged field
(Section~\ref{sec:Via:received}), send the response to the address in
the ``\header{received}'' parameter, using the port indicated in the
``\header{sent-by}'' value, or using port 5060 if none is specified
explicitly. If this fails, e.g., elicits an ICMP ``port unreachable''
response, send the response to the address in the ``\header{sent-by}''
parameter. The address to send to is determined by constructing a SIP
URL of the form ``sip:<sent-by>'', and then using the DNS procedures
defined in \cite{draft-ietf-sip-srv} to send the response.


\item Otherwise, if it is not receiver-tagged, send the response to the
address indicated by the ``\header{sent-by}'' value.

\end{itemize}


Note that the response to an unreliable datagram request is \textbf{not}
returned to the port from which the request came, but it is always
returned to the source IP that that request came from. 


\subsubsection{Syntax}
\label{sec:Via:syntax}

The format for a \header{Via} header field is shown in
Fig.~\ref{fig:Via}.  The ``\header{maddr}'' parameter, designating the
multicast address, and the ``\header{ttl}'' parameter, designating the
time-to-live (TTL) value, are included only if the request was sent via
multicast.  The ``\header{received}'' parameter is added only for
receiver-added \header{Via} fields (Section~\ref{sec:Via:received}). 

\begin{figure}[htpb]
\inputtxt{via_syntax}
\caption{Syntax of \header{Via} header field}
\label{fig:Via}
\end{figure}

The ``\header{branch}'' parameter is included by every proxy.  The token
{\MUST} be unique for each distinct request.  The precise format of the
token is implementation-defined.  In order to be able to both detect
loops and associate responses with the corresponding request, the
parameter {\SHOULD} consist of two parts separable by the
implementation.  One part, used for loop detection
(Section~\ref{sec:proxying}), {\MAY} be computed as a cryptographic hash
of the \header{To}, \header{From}, \header{Call-ID} header fields, the
\header{Request-URI} of the request received (before translation) and
the sequence number from the \header{CSeq} header field.
 The hash
{\SHOULD} also include any other fields the proxy uses to make a
routing decision on the request. This is to ensure that if the request
is routed back to the proxy, and one of those fields changes, it is
treated as a spiral, and not a loop.  The algorithm
used to compute the hash is implementation-dependent, but MD5
\cite{rfc1321}, expressed in hexadecimal, is a reasonable choice.  (Note
that base64 is not permissible for a \header{token}.) The other part,
used for matching responses to requests, is a globally unique function
of the branch taken, for example, a hash of a sequence number, local IP
address and \header{request-URI} of the request sent on the branch.

For example: \texttt{7a83e5750418bce23d5106b4c06cc632.1}

\motivation{The ``\header{branch}'' parameter {\MUST} depend on the
incoming \header{request-URI}, or any other headers used for
routing, to distinguish looped requests from requests whose
\header{request-URI} (or whatever headers are used for routing) is
changed and which then reach a server visited earlier.} 


{\CANCEL} and {\ACK} requests {\MUST} have the same \header{branch}
value as the corresponding request they cancel or acknowledge.  When a
response arrives at the proxy it can use the branch value to figure
out which branch the response corresponds to.


\begin{verbatim}
  Via: SIP/2.0/UDP first.example.com:4000;ttl=16
    ;maddr=224.2.0.1 ;branch=a7c6a8dlze.1 (Acme server)
  Via: SIP/2.0/UDP adk8%20.8x%fe%03 ;hidden
\end{verbatim}

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

The \header{Warning} response-header field is used to carry additional
information about the status of a response.  \header{Warning} headers
are sent with responses and have the following format:

\begin{syntax}
Warning       & = & "Warning" ":" 1\#warning-value\\
warning-value & = & warn-code SP warn-agent SP warn-text\\
warn-code     & = & 3DIGIT\\
warn-agent    & = & ( host [ ":" port ] ) $|$ pseudonym\\
              &   & ; {\rm the name or pseudonym of the server adding}\\
              &   & ; {\rm the Warning header, for use in debugging}\\
warn-text     & = & quoted-string\\
pseudonym     & = & token
\end{syntax}

A response {\MAY} carry more than one \header{Warning} header.

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 cache or user, the \header{Accept-Language} field in a
request, or the \header{Content-Language} field in a response.  The
default language is i-default \cite{rfc2277}.

Any server {\MAY} add \header{Warning} headers to a response.  Proxy
servers {\MUST} place additional \header{Warning} headers before any
\header{Authorization} headers.  Within that constraint,
\header{Warning} headers {\MUST} be added after any existing
\header{Warning} headers not covered by a signature.  A proxy server
{\MUSTNOT} delete any \header{Warning} header field that it received with a
response. 

When multiple \header{Warning} headers are attached to a response, the
user agent {\SHOULD} display as many of them as possible, in the order
that they appear in the response.  If it is not possible to display all
of the warnings, the user agent first displays warnings that appear
early in the response.

The warn-code consists of three digits. A first digit of ``3'' indicates
warnings specific to SIP.

This is a list of the currently-defined ``\header{warn-code}''s, each
with a recommended warn-text in English, and a description of its
meaning.  Note that these warnings describe failures induced by the
session description.

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


If the warning is caused by the session description, the status response
{\SHOULD} include a session description similar to that included in
{\OPTIONS} responses indicating the capabilities of the UAS.


Additional ``\header{warn-code}''s, as in the example below, 
can be defined through IANA. 

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}

The \header{WWW-Authenticate} response-header field {\MUST} be included
in 401 (Unauthorized) response messages.  The field value consists of at
least one challenge that indicates the authentication scheme(s) and
parameters applicable to the \header{Request-URI}.  See [H14.47] for a
definition of the syntax, and Section~\ref{sec:httpauth} for an overview
of usage.

The content of the ``\header{realm}'' parameter {\SHOULD} be displayed
to the user.  A user agent {\SHOULD} cache the authorization
credentials for a given value of the URL in the
destination (\header{To} header) and
``\header{realm}'' and attempt to re-use these values on the next
request for that destination.
