tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2543


SIP: Session Initiation Protocol

Part 3 of 6, p. 50 to 75
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 50 
6.14 Content-Encoding

        Content-Encoding  =  ( "Content-Encoding" | "e" ) ":"

   The Content-Encoding entity-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, 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 [3.5] for a definition of the syntax for 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 Accept-Encoding

Top      Up      ToC       Page 51 
   header. A server MAY apply content encodings to the bodies in
   responses. The server MUST only use encodings listed in the Accept-
   Encoding header in the request.

6.15 Content-Length

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

        Content-Length  =  ( "Content-Length" | "l" ) ":" 1*DIGIT

   An example is

     Content-Length: 3495

   Applications SHOULD use this field to indicate the size of the
   message-body to be transferred, regardless of the media type of the
   entity. 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 MUST be set to zero. If a server receives a UDP request
   without Content-Length, it MUST assume that the request encompasses
   the remainder of the packet.  If a server receives a UDP request with
   a Content-Length, but the value is larger than the size of the body
   sent in the request, the client SHOULD generate a 400 class response.
   If there is additional data in the UDP packet after the last byte of
   the body has been read, the server MUST treat the remaining data as a
   separate message. This allows several messages to be placed in a
   single UDP packet.

   If a response does not contain a Content-Length, the client assumes
   that it encompasses the remainder of the UDP packet or the data until
   the TCP connection is closed, as applicable.  Section 8 describes how
   to determine the length of the message body.

6.16 Content-Type

   The Content-Type entity-header field indicates the media type of the
   message-body sent to the recipient. The "media-type" element is
   defined in [H3.7].

        Content-Type  =  ( "Content-Type" | "c" ) ":" media-type

Top      Up      ToC       Page 52 
   Examples of this header field are

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

6.17 CSeq

   Clients MUST add the CSeq (command sequence) general-header field to
   every request. A CSeq header field in a request contains the request
   method and a single decimal sequence number chosen by the requesting
   client, unique within a single value of Call-ID. The sequence number
   MUST be expressible as a 32-bit unsigned integer. The initial value
   of the sequence number is arbitrary, but MUST be less than 2**31.
   Consecutive requests that differ in request method, headers or body,
   but have the same Call-ID MUST contain strictly monotonically
   increasing and contiguous sequence numbers; sequence numbers do not
   wrap around.  Retransmissions of the same request carry the same
   sequence number, but an INVITE with a different message body or
   different header fields (a "re-invitation") acquires a new, higher
   sequence number. A server MUST echo the CSeq value from the request
   in its response.  If the Method value is missing in the received CSeq
   header field, the server fills it in appropriately.

   The ACK and CANCEL requests MUST contain the same CSeq value as the
   INVITE request that it refers to, while a BYE request cancelling an
   invitation MUST have a higher sequence number. A BYE request with a
   CSeq that is not higher should cause a 400 response to be generated.

   A user agent server MUST remember the highest sequence number for any
   INVITE request with the same Call-ID value. The server MUST respond
   to, and then discard, any INVITE request with a lower sequence

   All requests spawned in a parallel search have the same CSeq value as
   the request triggering the parallel search.

        CSeq  =  "CSeq" ":" 1*DIGIT Method

        Strictly speaking, CSeq header fields are needed for any
        SIP request that can be cancelled by a BYE or CANCEL
        request or where a client can issue several requests for
        the same Call-ID in close succession. Without a sequence

Top      Up      ToC       Page 53 
        number, the response to an INVITE could be mistaken for the
        response to the cancellation (BYE or CANCEL). Also, if the
        network duplicates packets or if an ACK is delayed until
        the server has sent an additional response, the client
        could interpret an old response as the response to a re-
        invitation issued shortly thereafter. Using CSeq also makes
        it easy for the server to distinguish different versions of
        an invitation, without comparing the message body.

   The Method value allows the client to distinguish the response to an
   INVITE request from that of a CANCEL response. 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.

   Forked requests MUST have the same CSeq as there would be ambiguity
   otherwise between these forked requests and later BYE issued by the
   client user agent.


     CSeq: 4711 INVITE

6.18 Date

   Date is a general-header field. Its syntax is:

        SIP-date  =  rfc1123-date

   See [H14.19] for a definition of rfc1123-date. Note that unlike
   HTTP/1.1, SIP only supports the most recent RFC1123 [29] formatting
   for dates.

Top      Up      ToC       Page 54 
   The Date header field reflects the time when the request or response
   is first sent. Thus, retransmissions have the same Date header field
   value as the original.

        The Date header field can be used by simple end systems
        without a battery-backed clock to acquire a notion of
        current time.

6.19 Encryption

   The Encryption general-header field specifies that the content has
   been encrypted. Section 13 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 To
   header field. Responses are encrypted based on the public key
   conveyed in the 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 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 CRLF to allow proper
   concatenation.) Note that the request method and Request-URI cannot
   be encrypted.

        Encryption only provides privacy; the recipient has no
        guarantee that the request or response came from the party
        listed in the 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.

        Encryption         =  "Encryption" ":" encryption-scheme 1*SP
        encryption-scheme  =  token
        encryption-params  =  token "=" ( token | quoted-string )

        The token indicates the form of encryption used; it is
        described in section 13.

Top      Up      ToC       Page 55 
   The example in Figure 10 shows a message encrypted with ASCII-armored
   PGP that was generated by applying "pgp -ea" to the payload to be

   Via: SIP/2.0/UDP
   From: <>
   To: T. A. Watson <>
   Content-Length: 885
   Encryption: PGP version=2.6.2,encoding=ascii


   Figure 10: PGP Encryption Example

   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.

6.20 Expires

   The 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 and
   INVITE methods. For REGISTER, it is a request and response-header
   field. In a REGISTER request, the client indicates how long it wishes
   the registration to be valid. In the response, the server indicates

Top      Up      ToC       Page 56 
   the earliest expiration time of all registrations. The server MAY
   choose a shorter time interval than that requested by the client, but
   SHOULD NOT choose a longer one.

   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.

   The value of this field can be either a 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.

        Expires  =  "Expires" ":" ( SIP-date | delta-seconds )

   Two examples of its use are

     Expires: Thu, 01 Dec 1994 16:00:00 GMT
     Expires: 5

6.21 From

   Requests and responses MUST contain a From general-header field,
   indicating the initiator of the request. The From field MAY contain
   the "tag" parameter. The server copies the From header field from the
   request to the response. 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.

   The SIP-URL MUST NOT contain the "transport-param", "maddr-param",
   "ttl-param", or "headers" elements. A server that receives a SIP-URL
   with these elements removes them before further processing.

Top      Up      ToC       Page 57 
   Even if the "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, question mark, or

        From         =  ( "From" | "f" ) ":" ( name-addr | addr-spec )
                        *( ";" addr-params )
        addr-params  =  tag-param
        tag-param    =  "tag=" UUID
        UUID         =  1*( hex | "-" )


     From: "A. G. Bell" <>
     From: Anonymous <>

   The "tag" MAY appear in the From field of a request. It MUST be
   present when it is possible that two instances of a user sharing a
   SIP address can make call invitations with the same Call-ID.

   The "tag" value MUST be globally unique and cryptographically random
   with at least 32 bits of randomness. A single user maintains the same
   tag throughout the call identified by the Call-ID.

        Call-ID, To and From are needed to identify a 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 [24] header, but with a
        URI instead of just an email address.

6.22 Hide

   A client uses the Hide request header field to indicate that it wants
   the path comprised of the Via header fields (Section 6.40) to be
   hidden from subsequent proxies and user agents. It can take two
   forms: Hide: route and Hide:  hop. Hide header fields are typically
   added by the client user agent, but MAY be added by any proxy along
   the path.

Top      Up      ToC       Page 58 
   If a request contains the "Hide: route" header field, all following
   proxies SHOULD hide their previous hop. If a request contains the
   "Hide: hop" header field, only the next proxy SHOULD hide the
   previous hop and then remove the Hide option unless it also wants to
   remain anonymous.

   A server hides the previous hop by encrypting the "host" and "port"
   parts of the top-most Via header field with an algorithm of its
   choice. Servers SHOULD add additional "salt" to the "host" and "port"
   information prior to encryption to prevent malicious downstream
   proxies from guessing earlier parts of the path based on seeing
   identical encrypted Via headers. Hidden Via fields are marked with
   the "hidden" Via option, as described in Section 6.40.

   A server that is capable of hiding Via headers MUST attempt to
   decrypt all Via headers marked as "hidden" to perform loop detection.
   Servers that are not capable of hiding can ignore hidden Via fields
   in their loop detection algorithm.

        If hidden headers were not marked, a proxy would have to
        decrypt all headers to detect loops, just in case one was
        encrypted, as the Hide: Hop option may have been removed
        along the way.

   A host MUST NOT add such a "Hide: hop" header field unless it can
   guarantee it will only send a request for this destination to the
   same next hop. The reason for this is that it is possible that the
   request will loop back through this same hop from a downstream proxy.
   The loop will be detected by the next hop if the choice of next hop
   is fixed, but could loop an arbitrary number of times otherwise.

   A client requesting "Hide: route" can only rely on keeping the
   request path private if it sends the request to a trusted proxy.
   Hiding the route of a SIP request is of limited value if the request
   results in data packets being exchanged directly between the calling
   and called user agent.

   The use of Hide header fields is discouraged unless path privacy is
   truly needed; Hide fields impose extra processing costs and
   restrictions for proxies and can cause requests to generate 482 (Loop
   Detected) responses that could otherwise be avoided.

   The encryption of Via header fields is described in more detail in
   Section 13.

   The Hide header field has the following syntax:

Top      Up      ToC       Page 59 
        Hide  =  "Hide" ":" ( "route" | "hop" )

6.23 Max-Forwards

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

        Max-Forwards  =  "Max-Forwards" ":" 1*DIGIT

   The 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 Max-
   Forwards header field MUST check and update its value prior to
   forwarding the request. If the received value is zero (0), the
   recipient MUST NOT forward the request. Instead, for the OPTIONS and
   REGISTER methods, it MUST respond as the final recipient. For all
   other methods, the server returns 483 (Too many hops).

   If the received 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).


     Max-Forwards: 6

6.24 Organization

   The 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

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

Top      Up      ToC       Page 60 
        Organization  =  "Organization" ":" *TEXT-UTF8

6.25 Priority

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

        Priority        =  "Priority" ":" priority-value
        priority-value  =  "emergency" | "urgent" | "normal"
                        |  "non-urgent"

   It is RECOMMENDED that the value of "emergency" only be used when
   life, limb or property are in imminent danger.


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

     Subject: Weekend plans
     Priority: non-urgent

        These are the values of RFC 2076 [30], with the addition of

6.26 Proxy-Authenticate

   The Proxy-Authenticate response-header field MUST be included as part
   of a 407 (Proxy Authentication Required) response. The field value
   consists of a challenge that indicates the authentication scheme and
   parameters applicable to the proxy for this Request-URI.

   Unlike its usage within HTTP, the 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 14 for further
   details on its usage.

Top      Up      ToC       Page 61 
   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 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 Request-URI, it MAY attempt to use the
   most-recently used credential. The server responds with 401
   (Unauthorized) if the client guessed wrong.

        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.

6.27 Proxy-Authorization

   The Proxy-Authorization request-header field allows the client to
   identify itself (or its user) to a proxy which requires
   authentication. The 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 Authorization, the Proxy-Authorization header field applies
   only to the next outbound proxy that demanded authentication using
   the Proxy- Authenticate field. When multiple proxies are used in a
   chain, the 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 14 for a
   discussion of its usage.

6.28 Proxy-Require

   The Proxy-Require header field is used to indicate proxy-sensitive
   features that MUST be supported by the proxy. Any Proxy-Require
   header field features that are not supported by the proxy MUST be
   negatively acknowledged by the proxy to the client if not supported.
   Proxy servers treat this field identically to the Require field.

   See Section 6.30 for more details on the mechanics of this message
   and a usage example.

Top      Up      ToC       Page 62 
6.29 Record-Route

   The Record-Route request and response header field is added to a
   request by any proxy that insists on being in the path of subsequent
   requests for the same call leg. It contains a globally reachable
   Request-URI that identifies the proxy server. Each proxy server adds
   its Request-URI to the beginning of the list.

   The server copies the Record-Route header field unchanged into the
   response. (Record-Route is only relevant for 2xx responses.)

   The calling user agent client copies the Record-Route header into a
   Route header field of subsequent requests within the same call leg,
   reversing the order of requests, so that the first entry is closest
   to the user agent client. If the response contained a Contact header
   field, the calling user agent adds its content as the last Route
   header. Unless this would cause a loop, any client MUST send any
   subsequent requests for this call leg to the first Request-URI in the
   Route request header field and remove that entry.

   The calling user agent MUST NOT use the Record-Route header field in
   requests that contain Route header fields.

        Some proxies, such as those controlling firewalls or in an
        automatic call distribution (ACD) system, need to maintain
        call state and thus need to receive any BYE and ACK packets
        for the call.

   The Record-Route header field has the following syntax:

        Record-Route  =  "Record-Route" ":" 1# name-addr

   Proxy servers SHOULD use the "maddr" URL parameter containing their
   address to ensure that subsequent requests are guaranteed to reach
   exactly the same server.

   Example for a request that has traversed the hosts and , in that order:

     Record-Route: <>,

Top      Up      ToC       Page 63 
6.30 Require

   The Require request-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 Unsupported header.

        Require  =  "Require" ":" 1#option-tag


   C->S:   INVITE SIP/2.0
           Require: com.example.billing
           Payment: sheep_skins, conch_shells

   S->C:   SIP/2.0 420 Bad Extension
           Unsupported: com.example.billing

        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 Proxy-Require
   field as well (see Section 6.28).

6.31 Response-Key

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

Top      Up      ToC       Page 64 
        Response-Key  =  "Response-Key" ":" key-scheme 1*SP #key-param
        key-scheme    =  token
        key-param     =  token "=" ( token | quoted-string )

   The "key-scheme" gives the type of encryption to be used for the
   response. Section 13 describes security schemes.

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

                  Require: org.ietf.sip.encrypt-response

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

6.32 Retry-After

   The Retry-After general-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 SIP-date or an integer number of seconds (in decimal)
   after the time of the response.

   A REGISTER request MAY include this header field when deleting
   registrations with "Contact: * ;expires: 0". The Retry-After value
   then indicates when the user might again be reachable. The registrar
   MAY then include this information in responses to future calls.

   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.

        Retry-After  =  "Retry-After" ":" ( SIP-date | delta-seconds )
                        [ comment ] [ ";" "duration" "=" delta-seconds ]

   Examples of its use are

     Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting)

Top      Up      ToC       Page 65 
     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

   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.

6.33 Route

   The Route request-header field determines the route taken by a
   request. Each host removes the first entry and then proxies the
   request to the host listed in that entry, also using it as the
   Request-URI. The operation is further described in Section 6.29.

   The Route header field has the following syntax:

        Route  =  "Route" ":" 1# name-addr

6.34 Server

   The 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.39].

6.35 Subject

   This is intended to provide a summary, or to indicate the nature, of
   the call, allowing call filtering without having to parse the session
   description. (Also, the session description does not have to use the
   same subject indication as the invitation.)

        Subject  =  ( "Subject" | "s" ) ":" *TEXT-UTF8


     Subject: Tune in - they are talking about your work!

Top      Up      ToC       Page 66 
6.36 Timestamp

   The timestamp general-header field describes when the client sent the
   request to the server. 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 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.

        Timestamp  =  "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
        delay      =  *(DIGIT) [ "." *(DIGIT) ]

   Note that there MUST NOT be any LWS between a DIGIT and the decimal

6.37 To

   The To general-header field specifies recipient of the request, with
   the same SIP URL syntax as the From field.

        To  =  ( "To" | "t" ) ":" ( name-addr | addr-spec )
               *( ";" addr-params )

   Requests and responses MUST contain a To general-header field,
   indicating the desired recipient of the request. The optional
   "display-name" is meant to be rendered by a human-user interface.
   The UAS or redirect server copies the To header field into its
   response, and MUST add a "tag" parameter if the request contained
   more than one Via header field.

        If there was more than one Via header field, the request
        was handled by at least one proxy server. Since the
        receiver cannot know whether any of the proxy servers
        forked the request, it is safest to assume that they might

   The SIP-URL MUST NOT contain the "transport-param", "maddr-param",
   "ttl-param", or "headers" elements. A server that receives a SIP-URL
   with these elements removes them before further processing.

Top      Up      ToC       Page 67 
   The "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 To header field serves to distinguish
   responses at the UAC. It MUST be placed in the To field of the
   response by each instance when there is a possibility that the
   request was forked at an intermediate proxy. The "tag" MUST be added
   by UAS, registrars and redirect servers, but MUST NOT be inserted
   into responses forwarded upstream by proxies. The "tag" is added for
   all definitive responses for all methods, and MAY be added for
   informational responses from a UAS or redirect server. All subsequent
   transactions between two entities MUST include the "tag" parameter,
   as described in Section 11.

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

   The "tag" parameter in To headers is ignored when matching responses
   to requests that did not contain a "tag" in their To header.

   A SIP server returns a 400 (Bad Request) response if it receives a
   request with a To header field containing a URI with a scheme it does
   not recognize.

   Even if the "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, question mark, or

   The following are examples of valid To headers:

     To: The Operator <>;tag=287447

        Call-ID, To and From are needed to identify a call leg.
        The distinction between call and call leg matters in calls
        with multiple responses from a forked request. The "tag" is
        added to the 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

Top      Up      ToC       Page 68 
6.38 Unsupported

   The Unsupported response-header field lists the features not
   supported by the server. See Section 6.30 for a usage example and


        Unsupported  =  "Unsupported" ":" 1#option-tag

6.39 User-Agent

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

6.40 Via

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

6.40.1 Requests

   The client originating the request MUST insert into the request a Via
   field containing its 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 Via field before any existing Via
   fields. A proxy that receives a redirection (3xx) response and then
   searches recursively, MUST use the same Via headers as on the
   original proxied request.

   A proxy SHOULD check the top-most Via header field to ensure that it
   contains the sender's correct network address, as seen from that
   proxy. If the sender's address is incorrect, the proxy MUST add an
   additional "received" attribute, as described 6.40.2.

        A host behind a network address translator (NAT) or
        firewall may not be able to insert a network address into
        the Via header that can be reached by the next hop beyond

Top      Up      ToC       Page 69 
        the NAT. Use of the received attribute allows SIP requests
        to traverse NAT's which only modify the source IP address.
        NAT's which modify port numbers, called Network Address
        Port Translator's (NAPT) will not properly pass SIP when
        transported on UDP, in which case an application layer
        gateway is required. When run over TCP, SIP stands a better
        chance of traversing NAT's, since its behavior is similar
        to HTTP in this case (but of course on different ports).

   A proxy sending a request to a multicast address MUST add the "maddr"
   parameter to its Via header field, and SHOULD add the "ttl"
   parameter. If a server receives a request which contained an "maddr"
   parameter in the topmost Via field, it SHOULD send the response to
   the multicast address listed in the "maddr" parameter.

   If a proxy server receives a request which contains its own address
   in the Via header value, it MUST respond with a 482 (Loop Detected)
   status code.

   A proxy server MUST NOT forward a request to a multicast group which
   already appears in any of the Via headers.

        This prevents a malfunctioning proxy server from causing
        loops. Also, it cannot be guaranteed that a proxy server
        can always detect that the address returned by a location
        service refers to a host listed in the Via list, as a
        single host may have aliases or several network interfaces.

6.40.2 Receiver-tagged Via Header Fields

   Normally, every host that sends or forwards a SIP message adds a Via
   field indicating the path traversed. However, it is possible that
   Network Address Translators (NATs) changes the source address and
   port of the request (e.g., from net-10 to a globally routable
   address), in which case the Via header field cannot be relied on to
   route replies. To prevent this, a proxy SHOULD check the top-most Via
   header field to ensure that it contains the sender's correct network
   address, as seen from that proxy. If the sender's address is
   incorrect, the proxy MUST add a "received" parameter to the Via
   header field inserted by the previous hop. Such a modified Via header
   field is known as a receiver-tagged Via header field. An example is:

     Via: SIP/2.0/UDP
     Via: SIP/2.0/UDP ;received=

Top      Up      ToC       Page 70 
   In this example, the message originated from and traversed a
   NAT with the external address ( to
   reach  The latter noticed the mismatch,
   and added a parameter to the previous hop's Via header field,
   containing the address that the packet actually came from. (Note that
   the NAT is not a SIP server.)

6.40.3 Responses

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

        1.   The first Via header field should indicate the proxy or
             client processing this response. If it does not, discard
             the message.  Otherwise, remove this Via field.

        2.   If there is no second Via header field, this response is
             destined for this client. Otherwise, the processing depends
             on whether the Via field contains a "maddr" parameter or is
             a receiver-tagged field:

             - If the second Via header field contains a "maddr"
               parameter, send the response to the multicast address
               listed there, using the port indicated in "sent-by", or
               port 5060 if none is present. The response SHOULD be sent
               using the TTL indicated in the "ttl" parameter, or with a
               TTL of 1 if that parameter is not present. For
               robustness, responses MUST be sent to the address
               indicated in the "maddr" parameter even if it is not a
               multicast address.

             - If the second Via header field does not contain a "maddr"
               parameter and is a receiver-tagged field (Section
               6.40.2), send the message to the address in the
               "received" parameter, using the port indicated in the
               "sent-by" value, or using port 5060 if none is present.

             - If neither of the previous cases apply, send the message
               to the address indicated by the "sent-by" value in the
               second Via header field.

6.40.4 User Agent and Redirect Servers

   A UAS or redirect server sends a response based on one of the
   following rules:

        o  If the first Via header field in the request contains a
          "maddr" parameter, send the response to the multicast address

Top      Up      ToC       Page 71 
          listed there, using the port indicated in "sent-by", or port
          5060 if none is present. The response SHOULD be sent using the
          TTL indicated in the "ttl" parameter, or with a TTL of 1 if
          that parameter is not present. For robustness, responses MUST
          be sent to the address indicated in the "maddr" parameter even
          if it is not a multicast address.

        o  If the address in the "sent-by" value of the first Via field
          differs from the source address of the packet, send the
          response to the actual packet source address, similar to the
          treatment for receiver-tagged Via header fields (Section

        o  If neither of these conditions is true, send the response to
          the address contained in the "sent-by" value. If the request
          was sent using TCP, use the existing TCP connection if

6.40.5 Syntax

   The format for a Via header field is shown in Fig. 11. The defaults
   for "protocol-name" and "transport" are "SIP" and "UDP",
   respectively. The "maddr" parameter, designating the multicast
   address, and the "ttl" parameter, designating the time-to-live (TTL)
   value, are included only if the request was sent via multicast. The
   "received" parameter is added only for receiver-added Via fields
   (Section 6.40.2). For reasons of privacy, a client or proxy may wish
   to hide its Via information by encrypting it (see Section 6.22). The
   "hidden" parameter is included if this header field was hidden by the
   upstream proxy (see 6.22). Note that privacy of the proxy relies on
   the cooperation of the next hop, as the next-hop proxy will, by
   necessity, know the IP address and port number of the source host.

   The "branch" parameter is included by every forking proxy.  The token
   MUST be unique for each distinct request generated when a proxy
   forks. CANCEL requests MUST have the same branch value as the
   corresponding forked request. When a response arrives at the proxy it
   can use the branch value to figure out which branch the response
   corresponds to. A proxy which generates a single request (non-
   forking) MAY also insert the "branch" parameter. The identifier has
   to be unique only within a set of isomorphic requests.

     Via: SIP/2.0/UDP;ttl=16
       ;maddr= ;branch=a7c6a8dlze (Example)
     Via: SIP/2.0/UDP adk8

Top      Up      ToC       Page 72 
  Via              = ( "Via" | "v") ":" 1#( sent-protocol sent-by
                     *( ";" via-params ) [ comment ] )
  via-params       = via-hidden | via-ttl | via-maddr 
                   | via-received | via-branch
  via-hidden       = "hidden"
  via-ttl          = "ttl" "=" ttl
  via-maddr        = "maddr" "=" maddr
  via-received     = "received" "=" host
  via-branch       = "branch" "=" token
  sent-protocol    = protocol-name "/" protocol-version "/" transport
  protocol-name    = "SIP" | token
  protocol-version = token
  transport        = "UDP" | "TCP" | token
  sent-by          = ( host [ ":" port ] ) | ( concealed-host )
  concealed-host   = token
  ttl              = 1*3DIGIT     ; 0 to 255

   Figure 11: Syntax of Via header field

6.41 Warning

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

        Warning        =  "Warning" ":" 1#warning-value
        warning-value  =  warn-code SP warn-agent SP warn-text
        warn-code      =  3DIGIT
        warn-agent     =  ( host [ ":" port ] ) | pseudonym
                          ;  the name or pseudonym of the server adding
                          ;  the Warning header, for use in debugging
        warn-text      =  quoted-string

   A response MAY carry more than one Warning header.

   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 cache or user, the Accept-Language field in a
   request, or the Content-Language field in a response. The default
   language is i-default [31].

Top      Up      ToC       Page 73 
   Any server MAY add Warning headers to a response. Proxy servers MUST
   place additional Warning headers before any Authorization headers.
   Within that constraint, Warning headers MUST be added after any
   existing Warning headers not covered by a signature. A proxy server
   MUST NOT delete any Warning header field that it received with a

   When multiple 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 "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

   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

   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.

Top      Up      ToC       Page 74 
   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

   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, as in the example below, can be defined
   through IANA.


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

6.42 WWW-Authenticate

   The 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 Request-URI. See [H14.46] for a
   definition of the syntax, and section 14 for an overview of usage.

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

Top      Up      ToC       Page 75 
   In addition to the "basic" and "digest" authentication schemes
   defined in the specifications cited above, SIP defines a new scheme,
   PGP (RFC 2015, [32]), Section 15. Other schemes, such as S/MIME, are
   for further study.

(page 75 continued on part 4)

Next RFC Part