20 Header Fields

   The general syntax for header fields is covered in Section 7.3.  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 [8].  Examples of each header field are given.

   Information about header fields in relation to methods and proxy
   processing is summarized in Tables 2 and 3.

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

      R: header field may only appear in requests;

      r: header field may only appear in responses;

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

      c: header field is copied from the request to the response.

      An empty entry in the "where" column indicates that the header
           field may be present in all requests and responses.

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

      a: A proxy can add or concatenate the header field if not present.

      m: A proxy can modify an existing header field value.

      d: A proxy can delete a header field value.

      r: A proxy must be able to read the header field, and thus this
           header field cannot be encrypted.

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

      c: Conditional; requirements on the header field depend on the
           context of the message.

      m: The header field is mandatory.

      m*: The header field SHOULD be sent, but clients/servers need to
           be prepared to receive messages without that header field.

      o: The header field is optional.

      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.

      *: The header field is required if the message body is not empty.
           See Sections 20.14, 20.15 and 7.4 for details.

      -: The header field is not applicable.

   "Optional" means that an element 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 Require
   header field discussed in 20.32).  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 MUST NOT 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 MUST NOT 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.

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

   The Contact, From, and 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.

20.1 Accept

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

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

   Example:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Accept                  R            -   o   -   o   m*  o
      Accept                 2xx           -   -   -   o   m*  o
      Accept                 415           -   c   -   c   c   c
      Accept-Encoding         R            -   o   -   o   o   o
      Accept-Encoding        2xx           -   -   -   o   m*  o
      Accept-Encoding        415           -   c   -   c   c   c
      Accept-Language         R            -   o   -   o   o   o
      Accept-Language        2xx           -   -   -   o   m*  o
      Accept-Language        415           -   c   -   c   c   c
      Alert-Info              R      ar    -   -   -   o   -   -
      Alert-Info             180     ar    -   -   -   o   -   -
      Allow                   R            -   o   -   o   o   o
      Allow                  2xx           -   o   -   m*  m*  o
      Allow                   r            -   o   -   o   o   o
      Allow                  405           -   m   -   m   m   m
      Authentication-Info    2xx           -   o   -   o   o   o
      Authorization           R            o   o   o   o   o   o
      Call-ID                 c       r    m   m   m   m   m   m
      Call-Info                      ar    -   -   -   o   o   o
      Contact                 R            o   -   -   m   o   o
      Contact                1xx           -   -   -   o   -   -
      Contact                2xx           -   -   -   m   o   o
      Contact                3xx      d    -   o   -   o   o   o
      Contact                485           -   o   -   o   o   o
      Content-Disposition                  o   o   -   o   o   o
      Content-Encoding                     o   o   -   o   o   o
      Content-Language                     o   o   -   o   o   o
      Content-Length                 ar    t   t   t   t   t   t
      Content-Type                         *   *   -   *   *   *
      CSeq                    c       r    m   m   m   m   m   m
      Date                            a    o   o   o   o   o   o
      Error-Info           300-699    a    -   o   o   o   o   o
      Expires                              -   -   -   o   -   o
      From                    c       r    m   m   m   m   m   m
      In-Reply-To             R            -   -   -   o   -   -
      Max-Forwards            R      amr   m   m   m   m   m   m
      Min-Expires            423           -   -   -   -   -   m
      MIME-Version                         o   o   -   o   o   o
      Organization                   ar    -   -   -   o   o   o

             Table 2: Summary of header fields, A--O

   Header field              where       proxy ACK BYE CAN INV OPT REG
   ___________________________________________________________________
   Priority                    R          ar    -   -   -   o   -   -
   Proxy-Authenticate         407         ar    -   m   -   m   m   m
   Proxy-Authenticate         401         ar    -   o   o   o   o   o
   Proxy-Authorization         R          dr    o   o   -   o   o   o
   Proxy-Require               R          ar    -   o   -   o   o   o
   Record-Route                R          ar    o   o   o   o   o   -
   Record-Route             2xx,18x       mr    -   o   o   o   o   -
   Reply-To                                     -   -   -   o   -   -
   Require                                ar    -   c   -   c   c   c
   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
   Route                       R          adr   c   c   c   c   c   c
   Server                      r                -   o   o   o   o   o
   Subject                     R                -   -   -   o   -   -
   Supported                   R                -   o   o   m*  o   o
   Supported                  2xx               -   o   o   m*  m*  o
   Timestamp                                    o   o   o   o   o   o
   To                        c(1)          r    m   m   m   m   m   m
   Unsupported                420               -   m   -   m   m   m
   User-Agent                                   o   o   o   o   o   o
   Via                         R          amr   m   m   m   m   m   m
   Via                        rc          dr    m   m   m   m   m   m
   Warning                     r                -   o   o   o   o   o
   WWW-Authenticate           401         ar    -   m   -   m   m   m
   WWW-Authenticate           407         ar    -   o   -   o   o   o

   Table 3: Summary of header fields, P--Z; (1): copied with possible
   addition of tag

      Accept: application/sdp;level=1, application/x-private, text/html

20.2 Accept-Encoding

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

   An empty Accept-Encoding header field is permissible.  It is
   equivalent to Accept-Encoding: identity, that is, only the identity
   encoding, meaning no encoding, is permissible.

   If no Accept-Encoding header field is present, the server SHOULD
   assume a default value of 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:

      Accept-Encoding: gzip

20.3 Accept-Language

   The 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
   Accept-Language header field is present, the server SHOULD assume all
   languages are acceptable to the client.

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

   Example:

      Accept-Language: da, en-gb;q=0.8, en;q=0.7

20.4 Alert-Info

   When present in an INVITE request, the Alert-Info header field
   specifies an alternative ring tone to the UAS.  When present in a 180
   (Ringing) response, the 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 Alert-Info header field can introduce security risks.  These
   risks and the ways to handle them are discussed in Section 20.9,
   which discusses the Call-Info header field since the risks are
   identical.

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

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

   Example:

      Alert-Info: <http://www.example.com/sounds/moo.wav>

20.5 Allow

   The 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 Allow header field, when
   present.  The absence of an Allow header field MUST NOT 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 Allow header field in responses to methods other than
   OPTIONS reduces the number of messages needed.

   Example:

      Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

20.6 Authentication-Info

   The 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 Authorization header field.

   Syntax and semantics follow those specified in RFC 2617 [17].

   Example:

      Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

20.7 Authorization

   The Authorization header field contains authentication credentials of
   a UA.  Section 22.2 overviews the use of the Authorization header
   field, and Section 22.4 describes the syntax and semantics when used
   with HTTP authentication.

   This header field, along with 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 MUST NOT be combined into a single header line using the usual
   rules described in Section 7.3.

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

      Authorization: Digest username="Alice", realm="atlanta.com",
       nonce="84a4cc6f3082121f32b42a2187831a9e",
       response="7587245234b3434cc3412213e5f113a5432"

20.8 Call-ID

   The 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 Call-IDs,
   for example, if a user invites a single individual several times to
   the same (long-running) conference.  Call-IDs are case-sensitive and
   are simply compared byte-by-byte.

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

   Examples:

      Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
      i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4

20.9 Call-Info

   The 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 "purpose"
   parameter.  The "icon" parameter designates an image suitable as an
   iconic representation of the caller or callee.  The "info" parameter
   describes the caller or callee in general, for example, through a web
   page.  The "card" parameter provides a business card, for example, in
   vCard [36] or LDIF [37] formats.  Additional tokens can be registered
   using IANA and the procedures in Section 27.

   Use of the 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 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:

   Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
     <http://www.example.com/alice/> ;purpose=info

20.10 Contact

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

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

   This document defines the Contact parameters "q" and "expires".
   These parameters are only used when the 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 "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, semicolon, or question
   mark.  There may or may not be LWS between the display-name and the
   "<".

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

      The Contact header field has a role similar to the 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 Contact header field is m (for "moved").

   Examples:

      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

20.11 Content-Disposition

   The 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 Content-
   Type (RFC 2183 [18]).

   Several new "disposition-types" of the Content-Disposition header are
   defined by SIP.  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.  Note that the value "render" is used
   rather than "inline" to avoid the connotation that the MIME body is
   displayed as a part of the rendering of the entire message (since the
   MIME bodies of SIP messages oftentimes are not displayed to users).
   For backward-compatibility, if the Content-Disposition header field
   is missing, the server SHOULD assume bodies of Content-Type
   application/sdp are the disposition "session", while other content
   types are "render".

   The disposition type "icon" indicates that the body part contains an
   image suitable as an iconic representation of the caller or callee
   that could be rendered informationally by a user agent when a message
   has been received, or persistently while a dialog takes place.  The
   value "alert" indicates that the body part contains information, such
   as an audio clip, that should be rendered by the user agent in an
   attempt to alert the user to the receipt of a request, generally a
   request that initiates a dialog; this alerting body could for example
   be rendered as a ring tone for a phone call after a 180 Ringing
   provisional response has been sent.

   Any MIME body with a "disposition-type" that renders content to the
   user should only be processed when a message has been properly
   authenticated.

   The handling parameter, 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
   "optional" and "required".  If the handling parameter is missing, or if
   the Content-Disposition header field is missing, the value "required"
   SHOULD be assumed.  The handling parameter is described in RFC 3204 [19].

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

   Example:

      Content-Disposition: session

20.12 Content-Encoding

   The Content-Encoding header field is used as a modifier to the
   "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 Content-Type header field.  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 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 Accept-Encoding header
   field in the request.

   The compact form of the Content-Encoding header field is e.
   Examples:

      Content-Encoding: gzip
      e: tar

20.13 Content-Language

   See [H14.12]. Example:

      Content-Language: fr

20.14 Content-Length

   The 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 not include the CRLF separating
   header fields and body.  Any Content-Length greater than or equal to
   zero is a valid value.  If no body is present in a message, then the
   Content-Length header field value MUST be set to zero.

      The ability to omit Content-Length simplifies the creation of
      cgi-like scripts that dynamically generate responses.

   The compact form of the header field is l.

   Examples:

      Content-Length: 349
      l: 173

20.15 Content-Type

   The Content-Type header field indicates the media type of the
   message-body sent to the recipient.  The "media-type" element is
   defined in [H3.7].  The Content-Type header field MUST be present if
   the body is not empty.  If the body is empty, and a 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 c.

   Examples:

      Content-Type: application/sdp
      c: text/html; charset=ISO-8859-4

20.16 CSeq

   A 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 CSeq is
   case-sensitive.  The 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.  Two CSeq header fields are considered equal if the
   sequence number and the request method are identical.  Example:

      CSeq: 4711 INVITE

20.17 Date

   The Date header field contains the date and time.  Unlike HTTP/1.1,
   SIP only supports the most recent RFC 1123 [20] format for dates.  As
   in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while
   RFC 1123 allows any time zone.  An RFC 1123 date is case-sensitive.

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

      The 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:

      Date: Sat, 13 Nov 2010 23:29:00 GMT

20.18 Error-Info

   The Error-Info header field provides a pointer to additional
   information about the error status response.

      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 Error-Info header field as if
   it were a 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:

      SIP/2.0 404 The number you have dialed is not in service
      Error-Info: <sip:not-in-service-recording@atlanta.com>

20.19 Expires

   The 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 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 is an integral number of seconds (in decimal)
   between 0 and (2**32)-1, measured from the receipt of the request.

   Example:

      Expires: 5

20.20 From

   The 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 From header
   field.

   The optional "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 "display-
   name" is empty, the "name-addr" form MUST be used if the "addr-spec"
   contains a comma, question mark, or semicolon.  Syntax issues are
   discussed in Section 7.3.1.

   Two From header fields are equivalent if their URIs match, and their
   parameters match. Extension parameters in one header field, not
   present in the other are ignored for the purposes of comparison. This
   means that the display name and presence or absence of angle brackets
   do not affect matching.

   See Section 20.10 for the rules for parsing a display name, URI and
   URI parameters, and header field parameters.

   The compact form of the From header field is f.

   Examples:

      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

20.21 In-Reply-To

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

      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:

      In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com

20.22 Max-Forwards

   The 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 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 initial 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 Max-Forwards header field.

   Example:

      Max-Forwards: 6

20.23 Min-Expires

   The Min-Expires header field conveys the minimum refresh interval
   supported for soft-state elements managed by that server.  This
   includes 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.  The use of the header field in a 423 (Interval Too Brief)
   response is described in Sections 10.2.8, 10.3, and 21.4.17.

   Example:

      Min-Expires: 60

20.24 MIME-Version

   See [H19.4.1].

   Example:

      MIME-Version: 1.0

20.25 Organization

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

      The field MAY be used by client software to filter calls.

   Example:

      Organization: Boxes by Bob

20.26 Priority

   The Priority header field indicates the urgency of the request as
   perceived by the client.  The 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.  For these decisions, a message containing no
   Priority header field SHOULD be treated as if it specified a Priority
   of "normal".  The Priority header field 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.

      These are the values of RFC 2076 [38], with the addition of
      "emergency".

   Examples:

      Subject: A tornado is heading our way!
      Priority: emergency

   or

      Subject: Weekend plans
      Priority: non-urgent

20.27 Proxy-Authenticate

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

   The use of this header field is defined in [H14.33].  See Section
   22.3 for further details on its usage.

   Example:

      Proxy-Authenticate: Digest realm="atlanta.com",
       domain="sip:ss1.carrier.com", qop="auth",
       nonce="f84f1cec41e6cbe5aea9c8e88d359",
       opaque="", stale=FALSE, algorithm=MD5

20.28 Proxy-Authorization

   The Proxy-Authorization header field allows the client to identify
   itself (or its user) to a proxy that requires authentication.  A
   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 Section 22.3 for a definition of the usage of this header field.

   This header field, along with 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 MUST
   NOT be combined into a single header line using the usual rules
   described in Section 7.3.1.

   Example:

   Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
      nonce="c60f3082ee1212b402a21831ae",
      response="245f23415f11432b3434341c022"

20.29 Proxy-Require

   The Proxy-Require header field is used to indicate proxy-sensitive
   features that must be supported by the proxy.  See Section 20.32 for
   more details on the mechanics of this message and a usage example.

   Example:

      Proxy-Require: foo

20.30 Record-Route

   The 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 Route header field are described in
   Sections 16.12.1.

   Example:

      Record-Route: <sip:server10.biloxi.com;lr>,
                    <sip:bigbox3.site3.atlanta.com;lr>

20.31 Reply-To

   The Reply-To header field contains a logical return URI that may be
   different from the 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 "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, question mark, or
   semicolon.  Syntax issues are discussed in Section 7.3.1.

   Example:

      Reply-To: Bob <sip:bob@biloxi.com>

20.32 Require

   The 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 Require MUST NOT be
   ignored if it is present.

   The Require header field contains a list of option tags, described in
   Section 19.2.  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:

      Require: 100rel

20.33 Retry-After

   The Retry-After header field can be used with a 500 (Server Internal
   Error) or 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), 413 (Request Entity Too Large), 480
   (Temporarily Unavailable), 486 (Busy Here), 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 "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:

      Retry-After: 18000;duration=3600
      Retry-After: 120 (I'm in a meeting)

20.34 Route

   The Route header field is used to force routing for a request through
   the listed set of proxies.  Examples of the use of the Route header
   field are in Section 16.12.1.

   Example:

      Route: <sip:bigbox3.site3.atlanta.com;lr>,
             <sip:server10.biloxi.com;lr>

20.35 Server

   The Server header field contains information about the software used
   by the UAS to handle the request.

   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 Server
   header field a configurable option.

   Example:

      Server: HomeServer v2

20.36 Subject

   The 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 Subject header field is s.

   Example:

      Subject: Need more boxes
      s: Tech Support

20.37 Supported

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

   The Supported header field contains a list of option tags, described
   in Section 19.2, 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.

   The compact form of the Supported header field is k.

   Example:

      Supported: 100rel

20.38 Timestamp

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

   See Section 8.2.6 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.

   Example:

      Timestamp: 54

20.39 To

   The To header field specifies the logical recipient of the request.

   The optional "display-name" is meant to be rendered by a human-user
   interface.  The "tag" parameter serves as a general mechanism for
   dialog identification.

   See Section 19.3 for details of the "tag" parameter.

   Comparison of To header fields for equality is identical to
   comparison of From header fields.  See Section 20.10 for the rules
   for parsing a display name, URI and URI parameters, and header field
   parameters.

   The compact form of the To header field is t.

   The following are examples of valid To header fields:

      To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
      t: sip:+12125551212@server.phone2net.com

20.40 Unsupported

   The Unsupported header field lists the features not supported by the
   UAS.  See Section 20.32 for motivation.

   Example:

      Unsupported: foo

20.41 User-Agent

   The User-Agent header field contains information about the UAC
   originating the request.  The semantics of this header field 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 User-Agent header field a configurable option.

   Example:

      User-Agent: Softphone Beta1.5

20.42 Via

   The 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 Via header field values serves as a
   transaction identifier, and is used by proxies to detect loops.

   A 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 Via
   header field value can also contain parameters such as "maddr",
   "ttl", "received", and "branch", whose meaning and use are described

   in other sections.  For implementations compliant to this
   specification, the value of the branch parameter MUST start with the
   magic cookie "z9hG4bK", as discussed in Section 8.1.1.7.

   Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".
   "TLS" means TLS over TCP.  When a request is sent to a SIPS URI, the
   protocol still indicates "SIP", and the transport protocol is TLS.

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

   The compact form of the Via header field is 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 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:

      Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
        ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1

   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.

   Two Via header fields are equal if their sent-protocol and sent-by
   fields are equal, both have the same set of parameters, and the
   values of all parameters are equal.

20.43 Warning

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

   The "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 Accept-Language field in a request, or the

   Content-Language field in a response.  The default language is i-
   default [21].

   The currently-defined "warn-code"s are listed below, with a
   recommended 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.

      300 Incompatible network protocol: One or more network protocols
          contained in the session description are not available.

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

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

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

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

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

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

      307 Session description parameter not understood: A parameter
          other than those listed above was not understood.

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

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

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

      399 Miscellaneous warning: The warning text can include arbitrary
          information to be presented to a human user or logged.  A
          system receiving this warning MUST NOT take any automated
          action.

             1xx and 2xx have been taken by HTTP/1.1.

   Additional "warn-code"s can be defined through IANA, as defined in
   Section 27.2.

   Examples:

      Warning: 307 isi.edu "Session parameter 'foo' not understood"
      Warning: 301 isi.edu "Incompatible network address type 'E.164'"

20.44 WWW-Authenticate

   A WWW-Authenticate header field value contains an authentication
   challenge.  See Section 22.2 for further details on its usage.

   Example:

      WWW-Authenticate: Digest realm="atlanta.com",
        domain="sip:boxesbybob.com", qop="auth",
        nonce="f84f1cec41e6cbe5aea9c8e88d359",
        opaque="", stale=FALSE, algorithm=MD5