Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3261

SIP: Session Initiation Protocol

Pages: 269
Proposed Standard
Errata
Obsoletes:  2543
Updated by:  326538534320491653935621562656305922595460266141666568787462746382178591876088988996
Part 9 of 13 – Pages 159 to 182
First   Prev   Next

Top   ToC   RFC3261 - Page 159   prevText

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.
Top   ToC   RFC3261 - Page 160
   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.
Top   ToC   RFC3261 - Page 161
      *: 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.
Top   ToC   RFC3261 - Page 162
   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
Top   ToC   RFC3261 - Page 163
   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.
Top   ToC   RFC3261 - Page 164
   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>
Top   ToC   RFC3261 - Page 165

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.
Top   ToC   RFC3261 - Page 166
   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
Top   ToC   RFC3261 - Page 167

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
Top   ToC   RFC3261 - Page 168

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, 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
Top   ToC   RFC3261 - Page 169

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.
Top   ToC   RFC3261 - Page 170
      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.
Top   ToC   RFC3261 - Page 171
      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.
Top   ToC   RFC3261 - Page 172
   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.
Top   ToC   RFC3261 - Page 173
   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
Top   ToC   RFC3261 - Page 174

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.
Top   ToC   RFC3261 - Page 175
   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.
Top   ToC   RFC3261 - Page 176
   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
Top   ToC   RFC3261 - Page 177
   (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.
Top   ToC   RFC3261 - Page 178
   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.
Top   ToC   RFC3261 - Page 179
   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
Top   ToC   RFC3261 - Page 180
   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
Top   ToC   RFC3261 - Page 181
   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).
Top   ToC   RFC3261 - Page 182
      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


(page 182 continued on part 10)

Next Section