Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next

RFC 2543

SIP: Session Initiation Protocol

Pages: 151

Obsoleted by:  32613262326332643265
Part 4 of 6 – Pages 75 to 104
First   Prev   Next

ToP   noToC   Page 75   prevText
7 Status Code Definitions

   The response codes are consistent with, and extend, HTTP/1.1 response
   codes. Not all HTTP/1.1 response codes are appropriate, and only
   those that are appropriate are given here. Other HTTP/1.1 response
   codes SHOULD NOT be used. Response codes not defined by HTTP/1.1 have
   codes x80 upwards to avoid clashes with future HTTP response codes.
   Also, SIP defines a new class, 6xx. The default behavior for unknown
   response codes is given for each category of codes.

7.1 Informational 1xx

   Informational responses indicate that the server or proxy contacted
   is performing some further action and does not yet have a definitive
   response. The client SHOULD wait for a further response from the
   server, and the server SHOULD send such a response without further
   prompting. A server SHOULD send a 1xx response if it expects to take
   more than 200 ms to obtain a final response. A server MAY issue zero
   or more 1xx responses, with no restriction on their ordering or
   uniqueness. Note that 1xx responses are not transmitted reliably,
   that is, they do not cause the client to send an ACK. Servers are
   free to retransmit informational responses and clients can inquire
   about the current state of call processing by re-sending the request.

7.1.1 100 Trying

   Some unspecified action is being taken on behalf of this call (e.g.,
   a database is being consulted), but the user has not yet been

7.1.2 180 Ringing

   The called user agent has located a possible location where the user
   has registered recently and is trying to alert the user.

7.1.3 181 Call Is Being Forwarded

   A proxy server MAY use this status code to indicate that the call is
   being forwarded to a different set of destinations.
ToP   noToC   Page 76
7.1.4 182 Queued

   The called party is temporarily unavailable, but the callee has
   decided to queue the call rather than reject it. When the callee
   becomes available, it will return the appropriate final status
   response. The reason phrase MAY give further details about the status
   of the call, e.g., "5 calls queued; expected waiting time is 15
   minutes". The server MAY issue several 182 responses to update the
   caller about the status of the queued call.

7.2 Successful 2xx

   The request was successful and MUST terminate a search.

7.2.1 200 OK

   The request has succeeded. The information returned with the response
   depends on the method used in the request, for example:

   BYE: The call has been terminated. The message body is empty.

   CANCEL: The search has been cancelled. The message body is empty.

   INVITE: The callee has agreed to participate; the message body
        indicates the callee's capabilities.

   OPTIONS: The callee has agreed to share its capabilities, included in
        the message body.

   REGISTER: The registration has succeeded. The client treats the
        message body according to its Content-Type.

7.3 Redirection 3xx

   3xx responses give information about the user's new location, or
   about alternative services that might be able to satisfy the call.
   They SHOULD terminate an existing search, and MAY cause the initiator
   to begin a new search if appropriate.

   Any redirection (3xx) response MUST NOT suggest any of the addresses
   in the Via (Section 6.40) path of the request in the Contact header
   field. (Addresses match if their host and port number match.)

   To avoid forwarding loops, a user agent client or proxy MUST check
   whether the address returned by a redirect server equals an address
   tried earlier.
ToP   noToC   Page 77
7.3.1 300 Multiple Choices

   The address in the request resolved to several choices, each with its
   own specific location, and the user (or user agent) can select a
   preferred communication end point and redirect its request to that

   The response SHOULD include an entity containing a list of resource
   characteristics and location(s) from which the user or user agent can
   choose the one most appropriate, if allowed by the Accept request
   header. The entity format is specified by the media type given in the
   Content-Type header field. The choices SHOULD also be listed as
   Contact fields (Section 6.13).  Unlike HTTP, the SIP response MAY
   contain several Contact fields or a list of addresses in a Contact
   field. User agents MAY use the Contact header field value for
   automatic redirection or MAY ask the user to confirm a choice.
   However, this specification does not define any standard for such
   automatic selection.

        This status response is appropriate if the callee can be
        reached at several different locations and the server
        cannot or prefers not to proxy the request.

7.3.2 301 Moved Permanently

   The user can no longer be found at the address in the Request-URI and
   the requesting client SHOULD retry at the new address given by the
   Contact header field (Section 6.13). The caller SHOULD update any
   local directories, address books and user location caches with this
   new value and redirect future requests to the address(es) listed.

7.3.3 302 Moved Temporarily

   The requesting client SHOULD retry the request at the new address(es)
   given by the Contact header field (Section 6.13).  The duration of
   the redirection can be indicated through an Expires (Section 6.20)
   header. If there is no explicit expiration time, the address is only
   valid for this call and MUST NOT be cached for future calls.

7.3.4 305 Use Proxy

   The requested resource MUST be accessed through the proxy given by
   the Contact field. The Contact field gives the URI of the proxy. The
   recipient is expected to repeat this single request via the proxy.
   305 responses MUST only be generated by user agent servers.
ToP   noToC   Page 78
7.3.5 380 Alternative Service

   The call was not successful, but alternative services are possible.
   The alternative services are described in the message body of the
   response.  Formats for such bodies are not defined here, and may be
   the subject of future standardization.

7.4 Request Failure 4xx

   4xx responses are definite failure responses from a particular
   server.  The client SHOULD NOT retry the same request without
   modification (e.g., adding appropriate authorization). However, the
   same request to a different server might be successful.

7.4.1 400 Bad Request

   The request could not be understood due to malformed syntax.

7.4.2 401 Unauthorized

   The request requires user authentication.

7.4.3 402 Payment Required

   Reserved for future use.

7.4.4 403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help, and the request SHOULD NOT be repeated.

7.4.5 404 Not Found

   The server has definitive information that the user does not exist at
   the domain specified in the Request-URI. This status is also returned
   if the domain in the Request-URI does not match any of the domains
   handled by the recipient of the request.

7.4.6 405 Method Not Allowed

   The method specified in the Request-Line is not allowed for the
   address identified by the Request-URI. The response MUST include an
   Allow header field containing a list of valid methods for the
   indicated address.
ToP   noToC   Page 79
7.4.7 406 Not Acceptable

   The resource identified by the request is only capable of generating
   response entities which have content characteristics not acceptable
   according to the accept headers sent in the request.

7.4.8 407 Proxy Authentication Required

   This code is similar to 401 (Unauthorized), but indicates that the
   client MUST first authenticate itself with the proxy. The proxy MUST
   return a Proxy-Authenticate header field (section 6.26) containing a
   challenge applicable to the proxy for the requested resource. The
   client MAY repeat the request with a suitable Proxy-Authorization
   header field (section 6.27). SIP access authentication is explained
   in section 13.2 and 14.

   This status code is used for applications where access to the
   communication channel (e.g., a telephony gateway) rather than the
   callee requires authentication.

7.4.9 408 Request Timeout

   The server could not produce a response, e.g., a user location,
   within the time indicated in the Expires request-header field. The
   client MAY repeat the request without modifications at any later

7.4.10 409 Conflict

   The request could not be completed due to a conflict with the current
   state of the resource. This response is returned if the action
   parameter in a REGISTER request conflicts with existing

7.4.11 410 Gone

   The requested resource is no longer available at the server and no
   forwarding address is known. This condition is expected to be
   considered permanent. If the server does not know, or has no facility
   to determine, whether or not the condition is permanent, the status
   code 404 (Not Found) SHOULD be used instead.

7.4.12 411 Length Required

   The server refuses to accept the request without a defined Content-
   Length. The client MAY repeat the request if it adds a valid
   Content-Length header field containing the length of the message-body
   in the request message.
ToP   noToC   Page 80
7.4.13 413 Request Entity Too Large

   The server is refusing to process a request because the request
   entity is larger than the server is willing or able to process. The
   server MAY close the connection to prevent the client from continuing
   the request.

   If the condition is temporary, the server SHOULD include a Retry-
   After header field to indicate that it is temporary and after what
   time the client MAY try again.

7.4.14 414 Request-URI Too Long

   The server is refusing to service the request because the Request-URI
   is longer than the server is willing to interpret.

7.4.15 415 Unsupported Media Type

   The server is refusing to service the request because the message
   body of the request is in a format not supported by the requested
   resource for the requested method. The server SHOULD return a list of
   acceptable formats using the Accept, Accept-Encoding and Accept-
   Language header fields.

7.4.16 420 Bad Extension

   The server did not understand the protocol extension specified in a
   Require (Section 6.30) header field.

7.4.17 480 Temporarily Unavailable

   The callee's end system was contacted successfully but the callee is
   currently unavailable (e.g., not logged in or logged in in such a
   manner as to preclude communication with the callee). The response
   MAY indicate a better time to call in the Retry-After header. The
   user could also be available elsewhere (unbeknownst to this host),
   thus, this response does not terminate any searches. The reason
   phrase SHOULD indicate a more precise cause as to why the callee is
   unavailable. This value SHOULD be setable by the user agent. Status
   486 (Busy Here) MAY be used to more precisely indicate a particular
   reason for the call failure.

   This status is also returned by a redirect server that recognizes the
   user identified by the Request-URI, but does not currently have a
   valid forwarding location for that user.
ToP   noToC   Page 81
7.4.18 481 Call Leg/Transaction Does Not Exist

   This status is returned under two conditions: The server received a
   BYE request that does not match any existing call leg or the server
   received a CANCEL request that does not match any existing
   transaction. (A server simply discards an ACK referring to an unknown

7.4.19 482 Loop Detected

   The server received a request with a Via (Section 6.40) path
   containing itself.

7.4.20 483 Too Many Hops

   The server received a request that contains more Via entries (hops)
   (Section 6.40) than allowed by the Max-Forwards (Section 6.23) header

7.4.21 484 Address Incomplete

   The server received a request with a To (Section 6.37) address or
   Request-URI that was incomplete. Additional information SHOULD be

        This status code allows overlapped dialing. With overlapped
        dialing, the client does not know the length of the dialing
        string. It sends strings of increasing lengths, prompting
        the user for more input, until it no longer receives a 484
        status response.

7.4.22 485 Ambiguous

   The callee address provided in the request was ambiguous. The
   response MAY contain a listing of possible unambiguous addresses in
   Contact headers.

   Revealing alternatives can infringe on privacy concerns of the user
   or the organization. It MUST be possible to configure a server to
   respond with status 404 (Not Found) or to suppress the listing of
   possible choices if the request address was ambiguous.

   Example response to a request with the URL :

   485 Ambiguous SIP/2.0
   Contact: Carol Lee <>
ToP   noToC   Page 82
   Contact: Ping Lee <>
   Contact: Lee M. Foote <>

        Some email and voice mail systems provide this
        functionality. A status code separate from 3xx is used
        since the semantics are different: for 300, it is assumed
        that the same person or service will be reached by the
        choices provided. While an automated choice or sequential
        search makes sense for a 3xx response, user intervention is
        required for a 485 response.

7.4.23 486 Busy Here

   The callee's end system was contacted successfully but the callee is
   currently not willing or able to take additional calls. The response
   MAY indicate a better time to call in the Retry-After header. The
   user could also be available elsewhere, such as through a voice mail
   service, thus, this response does not terminate any searches.  Status
   600 (Busy Everywhere) SHOULD be used if the client knows that no
   other end system will be able to accept this call.

7.5 Server Failure 5xx

   5xx responses are failure responses given when a server itself has
   erred. They are not definitive failures, and MUST NOT terminate a
   search if other possible locations remain untried.

7.5.1 500 Server Internal Error

   The server encountered an unexpected condition that prevented it from
   fulfilling the request. The client MAY display the specific error
   condition, and MAY retry the request after several seconds.

7.5.2 501 Not Implemented

   The server does not support the functionality required to fulfill the
   request. This is the appropriate response when the server does not
   recognize the request method and is not capable of supporting it for
   any user.

7.5.3 502 Bad Gateway

   The server, while acting as a gateway or proxy, received an invalid
   response from the downstream server it accessed in attempting to
   fulfill the request.
ToP   noToC   Page 83
7.5.4 503 Service Unavailable

   The server is currently unable to handle the request due to a
   temporary overloading or maintenance of the server. The implication
   is that this is a temporary condition which will be alleviated after
   some delay. If known, the length of the delay MAY be indicated in a
   Retry-After header. If no Retry-After is given, the client MUST
   handle the response as it would for a 500 response.

   Note: The existence of the 503 status code does not imply that a
   server has to use it when becoming overloaded. Some servers MAY wish
   to simply refuse the connection.

7.5.5 504 Gateway Time-out

   The server, while acting as a gateway, did not receive a timely
   response from the server (e.g., a location server) it accessed in
   attempting to complete the request.

7.5.6 505 Version Not Supported

   The server does not support, or refuses to support, the SIP protocol
   version that was used in the request message. The server is
   indicating that it is unable or unwilling to complete the request
   using the same major version as the client, other than with this
   error message. The response MAY contain an entity describing why that
   version is not supported and what other protocols are supported by
   that server. The format for such an entity is not defined here and
   may be the subject of future standardization.

7.6 Global Failures 6xx

   6xx responses indicate that a server has definitive information about
   a particular user, not just the particular instance indicated in the
   Request-URI. All further searches for this user are doomed to failure
   and pending searches SHOULD be terminated.

7.6.1 600 Busy Everywhere

   The callee's end system was contacted successfully but the callee is
   busy and does not wish to take the call at this time. The response
   MAY indicate a better time to call in the Retry-After header. If the
   callee does not wish to reveal the reason for declining the call, the
   callee uses status code 603 (Decline) instead. This status response
   is returned only if the client knows that no other end point (such as
   a voice mail system) will answer the request. Otherwise, 486 (Busy
   Here) should be returned.
ToP   noToC   Page 84
7.6.2 603 Decline

   The callee's machine was successfully contacted but the user
   explicitly does not wish to or cannot participate. The response MAY
   indicate a better time to call in the Retry-After header.

7.6.3 604 Does Not Exist Anywhere

   The server has authoritative information that the user indicated in
   the To request field does not exist anywhere. Searching for the user
   elsewhere will not yield any results.

7.6.4 606 Not Acceptable

   The user's agent was contacted successfully but some aspects of the
   session description such as the requested media, bandwidth, or
   addressing style were not acceptable.

   A 606 (Not Acceptable) response means that the user wishes to
   communicate, but cannot adequately support the session described. The
   606 (Not Acceptable) response MAY contain a list of reasons in a
   Warning header field describing why the session described cannot be
   supported. Reasons are listed in Section 6.41.  It is hoped that
   negotiation will not frequently be needed, and when a new user is
   being invited to join an already existing conference, negotiation may
   not be possible. It is up to the invitation initiator to decide
   whether or not to act on a 606 (Not Acceptable) response.

8 SIP Message Body

8.1 Body Inclusion

   Requests MAY contain message bodies unless otherwise noted. Within
   this specification, the BYE request MUST NOT contain a message body.
   For ACK, INVITE and OPTIONS, the message body is always a session
   description. The use of message bodies for REGISTER requests is for
   further study.

   For response messages, the request method and the response status
   code determine the type and interpretation of any message body. All
   responses MAY include a body. Message bodies for 1xx responses
   contain advisory information about the progress of the request. 2xx
   responses to INVITE requests contain session descriptions. In 3xx
   responses, the message body MAY contain the description of
   alternative destinations or services, as described in Section 7.3.
   For responses with status 400 or greater, the message body MAY
ToP   noToC   Page 85
   contain additional, human-readable information about the reasons for
   failure. It is RECOMMENDED that information in 1xx and 300 and
   greater responses be of type text/plain or text/html

8.2 Message Body Type

   The Internet media type of the message body MUST be given by the
   Content-Type header field. If the body has undergone any encoding
   (such as compression) then this MUST be indicated by the Content-
   Encoding header field, otherwise Content-Encoding MUST be omitted. If
   applicable, the character set of the message body is indicated as
   part of the Content-Type header-field value.

8.3 Message Body Length

   The body length in bytes SHOULD be given by the Content-Length header
   field. Section 6.15 describes the behavior in detail.

   The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
   (Note: The chunked encoding modifies the body of a message in order
   to transfer it as a series of chunks, each with its own size

9 Compact Form

   When SIP is carried over UDP with authentication and a complex
   session description, it may be possible that the size of a request or
   response is larger than the MTU. To address this problem, a more
   compact form of SIP is also defined by using abbreviations for the
   common header fields listed below:

   short field name  long field name   note
   c                 Content-Type
   e                 Content-Encoding
   f                 From
   i                 Call-ID
   m                 Contact           from "moved"
   l                 Content-Length
   s                 Subject
   t                 To
   v                 Via

   Thus, the message in section 16.2 could also be written:
ToP   noToC   Page 86
     INVITE SIP/2.0
     CSeq: 4711 INVITE

     o=user1 53655765 2353687637 IN IP4
     s=Mbone Audio
     i=Discussion of Mbone Engineering Issues
     c=IN IP4
     t=0 0
     m=audio 3456 RTP/AVP 0

   Clients MAY mix short field names and long field names within the
   same request. Servers MUST accept both short and long field names for
   requests. Proxies MAY change header fields between their long and
   short forms, but this MUST NOT be done to fields following an
   Authorization header.

10 Behavior of SIP Clients and Servers

10.1 General Remarks

   SIP is defined so it can use either UDP (unicast or multicast) or TCP
   as a transport protocol; it provides its own reliability mechanism.

10.1.1 Requests

   Servers discard isomorphic requests, but first retransmit the
   appropriate response. (SIP requests are said to be idempotent , i.e.,
   receiving more than one copy of a request does not change the server

   After receiving a CANCEL request from an upstream client, a stateful
   proxy server MAY send a CANCEL on all branches where it has not yet
   received a final response.

   When a user agent receives a request, it checks the Call-ID against
   those of in-progress calls. If the Call-ID was found, it compares the
   tag value of To with the user's tag and rejects the request if the
ToP   noToC   Page 87
   two do not match. If the From header, including any tag value,
   matches the value for an existing call leg, the server compares the
   CSeq header field value. If less than or equal to the current
   sequence number, the request is a retransmission.  Otherwise, it is a
   new request. If the From header does not match an existing call leg,
   a new call leg is created.

   If the Call-ID was not found, a new call leg is created, with entries
   for the To, From and Call-ID headers.  In this case, the To header
   field should not have contained a tag. The server returns a response
   containing the same To value, but with a unique tag added. The tag
   MAY be omitted if the request contained only one Via header field.

10.1.2 Responses

   A server MAY issue one or more provisional responses at any time
   before sending a final response. If a stateful proxy, user agent
   server, redirect server or registrar cannot respond to a request with
   a final response within 200 ms, it SHOULD issue a provisional (1xx)
   response as soon as possible. Stateless proxies MUST NOT issue
   provisional responses on their own.

   Responses are mapped to requests by the matching To, From, Call-ID,
   CSeq headers and the branch parameter of the first Via header.
   Responses terminate request retransmissions even if they have Via
   headers that cause them to be delivered to an upstream client.

   A stateful proxy may receive a response that it does not have state
   for, that is, where it has no a record of an associated request. If
   the Via header field indicates that the upstream server used TCP, the
   proxy actively opens a TCP connection to that address. Thus, proxies
   have to be prepared to receive responses on the incoming side of
   passive TCP connections, even though most responses will arrive on
   the incoming side of an active connection. (An active connection is a
   TCP connection initiated by the proxy, a passive connection is one
   accepted by the proxy, but initiated by another entity.)

   100 responses SHOULD NOT be forwarded, other 1xx responses MAY be
   forwarded, possibly after the server eliminates responses with status
   codes that had already been sent earlier. 2xx responses are forwarded
   according to the Via header. Once a stateful proxy has received a 2xx
   response, it MUST NOT forward non-2xx final responses.  Responses
   with status 300 and higher are retransmitted by each stateful proxy
   until the next upstream proxy sends an ACK (see below for timing
   details) or CANCEL.
ToP   noToC   Page 88
   A stateful proxy SHOULD maintain state for at least 32 seconds after
   the receipt of the first definitive non-200 response, in order to
   handle retransmissions of the response.

        The 32 second window is given by the maximum retransmission
        duration of 200-class responses using the default timers,
        in case the ACK is lost somewhere on the way to the called
        user agent or the next stateful proxy.

10.2 Source Addresses, Destination Addresses and Connections

10.2.1 Unicast UDP

   Responses are returned to the address listed in the Via header field
   (Section 6.40), not the source address of the request.

        Recall that responses are not generated by the next-hop
        stateless server, but generated by either a proxy server or
        the user agent server. Thus, the stateless proxy can only
        use the Via header field to forward the response.

10.2.2 Multicast UDP

   Requests MAY be multicast; multicast requests likely feature a host-
   independent Request-URI. This request SHOULD be scoped to ensure it
   is not forwarded beyond the boundaries of the administrative system.
   This MAY be done with either TTL or administrative scopes[25],
   depending on what is implemented in the network.

   A client receiving a multicast query does not have to check whether
   the host part of the Request-URI matches its own host or domain name.
   If the request was received via multicast, the response is also
   returned via multicast. Responses to multicast requests are multicast
   with the same TTL as the request, where the TTL is derived from the
   ttl parameter in the Via header (Section 6.40).

   To avoid response implosion, servers MUST NOT answer multicast
   requests with a status code other than 2xx or 6xx. The server delays
   its response by a random interval uniformly distributed between zero
   and one second. Servers MAY suppress responses if they hear a lower-
   numbered or 6xx response from another group member prior to sending.
   Servers do not respond to CANCEL requests received via multicast to
   avoid request implosion. A proxy or UAC SHOULD send a CANCEL on
   receiving the first 2xx or 6xx response to a multicast request.
ToP   noToC   Page 89
        Server response suppression is a MAY since it requires a
        server to violate some basic message processing rules. Lets
        say A sends a multicast request, and it is received by B,C,
        and D. B sends a 200 response. The topmost Via field in the
        response will contain the address of A. C will also receive
        this response, and could use it to suppress its own
        response. However, C would normally not examine this
        response, as the topmost Via is not its own. Normally, a
        response received with an incorrect topmost Via MUST be
        dropped, but not in this case. To distinguish this packet
        from a misrouted or multicast looped packet is fairly
        complex, and for this reason the procedure is a MAY. The
        CANCEL, instead, provides a simpler and more standard way
        to perform response suppression. It is for this reason that
        the use of CANCEL here is a SHOULD

10.3 TCP

   A single TCP connection can serve one or more SIP transactions. A
   transaction contains zero or more provisional responses followed by
   one or more final responses. (Typically, transactions contain exactly
   one final response, but there are exceptional circumstances, where,
   for example, multiple 200 responses can be generated.)

   The client SHOULD keep the connection open at least until the first
   final response arrives. If the client closes or resets the TCP
   connection prior to receiving the first final response, the server
   treats this action as equivalent to a CANCEL request.

        This behavior makes it less likely that malfunctioning
        clients cause a proxy server to keep connection state

   The server SHOULD NOT close the TCP connection until it has sent its
   final response, at which point it MAY close the TCP connection if it
   wishes to. However, normally it is the client's responsibility to
   close the connection.

   If the server leaves the connection open, and if the client so
   desires it MAY re-use the connection for further SIP requests or for
   requests from the same family of protocols (such as HTTP or stream
   control commands).
ToP   noToC   Page 90
   If a server needs to return a response to a client and no longer has
   a connection open to that client, it MAY open a connection to the
   address listed in the Via header. Thus, a proxy or user agent MUST be
   prepared to receive both requests and responses on a "passive"

10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER Requests

10.4.1 UDP

   A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or
   REGISTER request with an exponential backoff, starting at a T1 second
   interval, doubling the interval for each packet, and capping off at a
   T2 second interval. This means that after the first packet is sent,
   the second is sent T1 seconds later, the next 2*T1 seconds after
   that, the next 4*T1 seconds after that, and so on, until the interval
   hits T2. Subsequent retransmissions are spaced by T2 seconds. If the
   client receives a provisional response, it continues to retransmit
   the request, but with an interval of T2 seconds.  Retransmissions
   cease when the client has sent a total of eleven packets, or receives
   a definitive response. Default values for T1 and T2 are 500 ms and 4
   s, respectively. Clients MAY use larger values, but SHOULD NOT use
   smaller ones. Servers retransmit the response upon receipt of a
   request retransmission. After the server sends a final response, it
   cannot be sure the client has received the response, and thus SHOULD
   cache the results for at least 10*T2 seconds to avoid having to, for
   example, contact the user or location server again upon receiving a
   request retransmission.

        Use of the exponential backoff is for congestion control
        purposes. However, the back-off must cap off, since request
        retransmissions are used to trigger response
        retransmissions at the server. Without a cap, the loss of a
        single response could significantly increase transaction

   The value of the initial retransmission timer is smaller than that
   that for TCP since it is expected that network paths suitable for
   interactive communications have round-trip times smaller than 500 ms.
   For congestion control purposes, the retransmission count has to be
   bounded.  Given that most transactions are expected to consist of one
   request and a few responses, round-trip time estimation is not likely
   to be very useful. If RTT estimation is desired to more quickly
   discover a missing final response, each request retransmission needs
   to be labeled with its own Timestamp (Section 6.36), returned in the
   response. The server caches the result until it can be sure that the
   client will not retransmit the same request again.
ToP   noToC   Page 91
   Each server in a proxy chain generates its own final response to a
   CANCEL request. The server responds immediately upon receipt of the
   CANCEL request rather than waiting until it has received final
   responses from the CANCEL requests it generates.

   BYE and OPTIONS final responses are generated by redirect and user
   agent servers; REGISTER final responses are generated by registrars.
   Note that in contrast to the reliability mechanism described in
   Section 10.5, responses to these requests are not retransmitted
   periodically and not acknowledged via ACK.

10.4.2 TCP

   Clients using TCP do not need to retransmit requests.

10.5 Reliability for INVITE Requests

   Special considerations apply for the INVITE method.

        1.   After receiving an invitation, considerable time can elapse
             before the server can determine the outcome. For example,
             if the called party is "rung" or extensive searches are
             performed, delays between the request and a definitive
             response can reach several tens of seconds. If either
             caller or callee are automated servers not directly
             controlled by a human being, a call attempt could be
             unbounded in time.

        2.   If a telephony user interface is modeled or if we need to
             interface to the PSTN, the caller's user interface will
             provide "ringback", a signal that the callee is being
             alerted. (The status response 180 (Ringing) MAY be used to
             initiate ringback.) Once the callee picks up, the caller
             needs to know so that it can enable the voice path and stop
             ringback. The callee's response to the invitation could get
             lost. Unless the response is transmitted reliably, the
             caller will continue to hear ringback while the callee
             assumes that the call exists.

        3.   The client has to be able to terminate an on-going request,
             e.g., because it is no longer willing to wait for the
             connection or search to succeed. The server will have to
             wait several retransmission intervals to interpret the lack
             of request retransmissions as the end of a call. If the
             call succeeds shortly after the caller has given up, the
             callee will "pick up the phone" and not be "connected".
ToP   noToC   Page 92
10.5.1 UDP

   For UDP, A SIP client SHOULD retransmit a SIP INVITE request with an
   interval that starts at T1 seconds, and doubles after each packet
   transmission. The client ceases retransmissions if it receives a
   provisional or definitive response, or once it has sent a total of 7
   request packets.

   A server which transmits a provisional response should retransmit it
   upon reception of a duplicate request. A server which transmits a
   final response should retransmit it with an interval that starts at
   T1 seconds, and doubles for each subsequent packet. Response
   retransmissions cease when any one of the following occurs:

        1.   An ACK request for the same transaction is received;

        2.   a BYE request for the same call leg is received;

        3.   a CANCEL request for the same call leg is received and the
             final response status was equal or greater to 300;

        4.   the response has been transmitted 7 times.

   Only the user agent client generates an ACK for 2xx final responses,
   If the response contained a Contact header field, the ACK MAY be sent
   to the address listed in that Contact header field. If the response
   did not contain a Contact header, the client uses the same To header
   field and Request-URI as for the INVITE request and sends the ACK to
   the same destination as the original INVITE request. ACKs for final
   responses other than 2xx are sent to the same server that the
   original request was sent to, using the same Request-URI as the
   original request. Note, however, that the To header field in the ACK
   is copied from the response being acknowledged, not the request, and
   thus MAY additionally contain the tag parameter. Also note than
   unlike 2xx final responses, a proxy generates an ACK for non-2xx
   final responses.

   The ACK request MUST NOT be acknowledged to prevent a response-ACK
   feedback loop. Fig. 12 and 13 show the client and server state
   diagram for invitations.

        The mechanism in Sec. 10.4 would not work well for INVITE
        because of the long delays between INVITE and a final
        response. If the 200 response were to get lost, the callee
        would believe the call to exist, but the voice path would
ToP   noToC   Page 93
              *           *
  ...........>*  Initial  *<;;;;;;;;;;
  : 7 INVITE  *           *          ;
  :   sent    +===========+          ;
  :                 |                ;
  :                 |    -           ;
  :                 |  INVITE        ;
  :                 |                ;
  :                 v                ;
  :           *************          ;
  : T1*2^n <--*           *          ;
  : INVITE -->*  Calling  *--------+ ;
  :           *           *        | ;
  :           *************        | ;
  :             :   |              | ;
  :.............:   | 1xx      xxx | ;
                    |  -       ACK | ;
                    |              | ;
                    v              | ; 
              *************        | ;
              *           *        | ;
              *  Ringing  *<->1xx  | ; 
              *           *        | ;
              *************        | ;
                    |              | ;
                    |<-------------+ ; 
                    |                ;
                    v                ;
              *************          ;
      xxx  <--*           *          ;
      ACK  -->* Completed *          ;
              *           *          ;
              *************          ;
                    ; 32s (for proxy);

 event (xxx=status)

   Figure 12: State transition diagram of client for INVITE method
ToP   noToC   Page 94
   7 pkts sent  +===============+                   
+-------------->*               *
|               *   Initial     *<...............
|;;;;;;;;;;;;;;>*               *               :
|;              +===============+               :
|; CANCEL               !                       :
|;  200                 !  INVITE               :
|;                      !   1xx                 :
|;                      !                       :
|;                      v                       :
|;              *****************          BYE  :
|;    INVITE -->*               *          200  :
|;      1xx  <--* Call proceed. *..............>:
|;              *               *               :
|;;;;;;;;;;;;;;;*****************               :
|;                    !   !                     :
|:                    !   !                     :
|;         failure    !   !  picks up           :
|;         >= 300     !   !    200              :
|;            +-------+   +-------+             :
|;            v                   v             :
|;       ***********         ***********        :
|;INVITE<*         *<T1*2^n->*         *>INVITE :
|;status>* failure *>status<-* success *<status :
|;       *         *         *         *        :
|;;;;;;;;***********         ***********        :
|             ! : |            |  !  :          :
|             ! : |            |  !  :          :
+-------------!-:-+------------+  !  :          :
              ! :.................!..:.........>:
              !                   !         BYE : 
              +---------+---------+         200 :
  event                 ! ACK                   :
message sent            v                       :
                *****************               :
            V---*               *               :
           ACK  *   Confirmed   *               :
            |-->*               *               :
                *****************               . 

   Figure 13: State transition diagram of server for INVITE method
ToP   noToC   Page 95
        be dead since the caller does not know that the callee has
        picked up. Thus, the INVITE retransmission interval would
        have to be on the order of a second or two to limit the
        duration of this state confusion. Retransmitting the
        response with an exponential back-off helps ensure that the
        response is received, without placing an undue burden on
        the network.

10.5.2 TCP

   A user agent using TCP MUST NOT retransmit requests, but uses the
   same algorithm as for UDP (Section 10.5.1) to retransmit responses
   until it receives an ACK.

        It is necessary to retransmit 2xx responses as their
        reliability is assured end-to-end only. If the chain of
        proxies has a UDP link in the middle, it could lose the
        response, with no possibility of recovery. For simplicity,
        we also retransmit non-2xx responses, although that is not
        strictly necessary.

10.6 Reliability for ACK Requests

   The ACK request does not generate responses. It is only generated
   when a response to an INVITE request arrives (see Section 10.5). This
   behavior is independent of the transport protocol. Note that the ACK
   request MAY take a different path than the original INVITE request,
   and MAY even cause a new TCP connection to be opened in order to send

10.7 ICMP Handling

   Handling of ICMP messages in the case of UDP messages is
   straightforward. For requests, a host, network, port, or protocol
   unreachable error SHOULD be treated as if a 400-class response was
   received. For responses, these errors SHOULD cause the server to
   cease retransmitting the response.

   Source quench ICMP messages SHOULD be ignored. TTL exceeded errors
   SHOULD be ignored. Parameter problem errors SHOULD be treated as if a
   400-class response was received.

11 Behavior of SIP User Agents

   This section describes the rules for user agent client and servers
   for generating and processing requests and responses.
ToP   noToC   Page 96
11.1 Caller Issues Initial INVITE Request

   When a user agent client desires to initiate a call, it formulates an
   INVITE request. The To field in the request contains the address of
   the callee. The Request-URI contains the same address. The From field
   contains the address of the caller.  If the From address can appear
   in requests generated by other user agent clients for the same call,
   the caller MUST insert the tag parameter in the From field. A UAC MAY
   optionally add a Contact header containing an address where it would
   like to be contacted for transactions from the callee back to the

11.2 Callee Issues Response

   When the initial INVITE request is received at the callee, the callee
   can accept, redirect, or reject the call. In all of these cases, it
   formulates a response. The response MUST copy the To, From, Call-ID,
   CSeq and Via fields from the request. Additionally, the responding
   UAS MUST add the tag parameter to the To field in the response if the
   request contained more than one Via header field. Since a request
   from a UAC may fork and arrive at multiple hosts, the tag parameter
   serves to distinguish, at the UAC, multiple responses from different
   UAS's. The UAS MAY add a Contact header field in the response. It
   contains an address where the callee would like to be contacted for
   subsequent transactions, including the ACK for the current INVITE.
   The UAS stores the values of the To and From field, including any
   tags. These become the local and remote addresses of the call leg,

11.3 Caller Receives Response to Initial Request

   Multiple responses may arrive at the UAC for a single INVITE request,
   due to a forking proxy. Each response is distinguished by the "tag"
   parameter in the To header field, and each represents a distinct call
   leg. The caller MAY choose to acknowledge or terminate the call with
   each responding UAS. To acknowledge, it sends an ACK request, and to
   terminate it sends a BYE request.  The To header field in the ACK or
   BYE MUST be the same as the To field in the 200 response, including
   any tag. The From header field MUST be the same as the From header
   field in the 200 (OK) response, including any tag. The Request-URI of
   the ACK or BYE request MAY be set to whatever address was found in
   the Contact header field in the 200 (OK) response, if present.
   Alternately, a UAC may copy the address from the To header field into
   the Request-URI. The UAC also notes the value of the To and From
   header fields in each response. For each call leg, the To header
   field becomes the remote address, and the From header field becomes
   the local address.
ToP   noToC   Page 97
11.4 Caller or Callee Generate Subsequent Requests

   Once the call has been established, either the caller or callee MAY
   generate INVITE or BYE requests to change or terminate the call.
   Regardless of whether the caller or callee is generating the new
   request, the header fields in the request are set as follows. For the
   desired call leg, the To header field is set to the remote address,
   and the From header field is set to the local address (both including
   any tags). The Contact header field MAY be different than the Contact
   header field sent in a previous response or request. The Request-URI
   MAY be set to the value of the Contact header field received in a
   previous request or response from the remote party, or to the value
   of the remote address.

11.5 Receiving Subsequent Requests

   When a request is received subsequently, the following checks are

        1.   If the Call-ID is new, the request is for a new call,
             regardless of the values of the To and From header fields.

        2.   If the Call-ID exists, the request is for an existing call.
             If the To, From, Call-ID, and CSeq values exactly match
             (including tags) those of any requests received previously,
             the request is a retransmission.

        3.   If there was no match to the previous step, the To and From
             fields are compared against existing call leg local and
             remote addresses. If there is a match, and the CSeq in the
             request is higher than the last CSeq received on that leg,
             the request is a new transaction for an existing call leg.

12 Behavior of SIP Proxy and Redirect Servers

   This section describes behavior of SIP redirect and proxy servers in
   detail. Proxy servers can "fork" connections, i.e., a single incoming
   request spawns several outgoing (client) requests.

12.1 Redirect Server

   A redirect server does not issue any SIP requests of its own. After
   receiving a request other than CANCEL, the server gathers the list of
   alternative locations and returns a final response of class 3xx or it
   refuses the request. For well-formed CANCEL requests, it SHOULD
   return a 2xx response. This response ends the SIP transaction. The
ToP   noToC   Page 98
   redirect server maintains transaction state for the whole SIP
   transaction. It is up to the client to detect forwarding loops
   between redirect servers.

12.2 User Agent Server

   User agent servers behave similarly to redirect servers, except that
   they also accept requests and can return a response of class 2xx.

12.3 Proxy Server

   This section outlines processing rules for proxy servers. A proxy
   server can either be stateful or stateless. When stateful, a proxy
   remembers the incoming request which generated outgoing requests, and
   the outgoing requests. A stateless proxy forgets all information once
   an outgoing request is generated. A forking proxy SHOULD be stateful.
   Proxies that accept TCP connections MUST be stateful.

        Otherwise, if the proxy were to lose a request, the TCP
        client would never retransmit it.

   A stateful proxy SHOULD NOT become stateless until after it sends a
   definitive response upstream, and at least 32 seconds after it
   received a definitive response.

   A stateful proxy acts as a virtual UAS/UAC. It implements the server
   state machine when receiving requests, and the client state machine
   for generating outgoing requests, with the exception of receiving a
   2xx response to an INVITE. Instead of generating an ACK, the 2xx
   response is always forwarded upstream towards the caller.
   Furthermore, ACK's for 200 responses to INVITE's are always proxied
   downstream towards the UAS, as they would be for a stateless proxy.

   A stateless proxy does not act as a virtual UAS/UAC (as this would
   require state). Rather, a stateless proxy forwards every request it
   receives downstream, and every response it receives upstream.

12.3.1 Proxying Requests

   To prevent loops, a server MUST check if its own address is already
   contained in the Via header field of the incoming request.

   The To, From, Call-ID, and Contact tags are copied exactly from the
   original request. The proxy SHOULD change the Request-URI to indicate
   the server where it intends to send the request.
ToP   noToC   Page 99
   A proxy server always inserts a Via header field containing its own
   address into those requests that are caused by an incoming request.
   Each proxy MUST insert a "branch" parameter (Section 6.40).

12.3.2 Proxying Responses

   A proxy only processes a response if the topmost Via field matches
   one of its addresses. A response with a non-matching top Via field
   MUST be dropped.

12.3.3 Stateless Proxy: Proxying Responses

   A stateless proxy removes its own Via field, and checks the address
   in the next Via field. In the case of UDP, the response is sent to
   the address listed in the "maddr" tag if present, otherwise to the
   "received" tag if present, and finally to the address in the "sent-
   by" field. A proxy MUST remain stateful when handling requests
   received via TCP.

   A stateless proxy MUST NOT generate its own provisional responses.

12.3.4 Stateful Proxy: Receiving Requests

   When a stateful proxy receives a request, it checks the To, From
   (including tags), Call-ID and CSeq against existing request records.
   If the tuple exists, the request is a retransmission. The provisional
   or final response sent previously is retransmitted, as per the server
   state machine. If the tuple does not exist, the request corresponds
   to a new transaction, and the request should be proxied.

   A stateful proxy server MAY generate its own provisional (1xx)

12.3.5 Stateful Proxy: Receiving ACKs

   When an ACK request is received, it is either processed locally or
   proxied. To make this determination, the To, From, CSeq and Call-ID
   fields are compared against those in previous requests. If there is
   no match, the ACK request is proxied as if it were an INVITE request.
   If there is a match, and if the server had ever sent a 200 response
   upstream, the ACK is proxied.  If the server had never sent any
   responses upstream, the ACK is also proxied. If the server had sent a
   3xx, 4xx, 5xx or 6xx response, but no 2xx response, the ACK is
   processed locally if the tag in the To field of the ACK matches the
   tag sent by the proxy in the response.
ToP   noToC   Page 100
12.3.6 Stateful Proxy: Receiving Responses

   When a proxy server receives a response that has passed the Via
   checks, the proxy server checks the To (without the tag), From
   (including the tag), Call-ID and CSeq against values seen in previous
   requests. If there is no match, the response is forwarded upstream to
   the address listed in the Via field. If there is a match, the
   "branch" tag in the Via field is examined. If it matches a known
   branch identifier, the response is for the given branch, and
   processed by the virtual client for the given branch. Otherwise, the
   response is dropped.

   A stateful proxy should obey the rules in Section 12.4 to determine
   if the response should be proxied upstream. If it is to be proxied,
   the same rules for stateless proxies above are followed, with the
   following addition for TCP. If a request was received via TCP
   (indicated by the protocol in the top Via header), the proxy checks
   to see if it has a connection currently open to that address. If so,
   the response is sent on that connection.  Otherwise, a new TCP
   connection is opened to the address and port in the Via field, and
   the response is sent there. Note that this implies that a UAC or
   proxy MUST be prepared to receive responses on the incoming side of a
   TCP connection. Definitive non 200-class responses MUST be
   retransmitted by the proxy, even over a TCP connection.

12.3.7 Stateless, Non-Forking Proxy

   Proxies in this category issue at most a single unicast request for
   each incoming SIP request, that is, they do not "fork" requests.
   However, servers MAY choose to always operate in a mode that allows
   issuing of several requests, as described in Section 12.4.

   The server can forward the request and any responses. It does not
   have to maintain any state for the SIP transaction. Reliability is
   assured by the next redirect or stateful proxy server in the server

   A proxy server SHOULD cache the result of any address translations
   and the response to speed forwarding of retransmissions. After the
   cache entry has been expired, the server cannot tell whether an
   incoming request is actually a retransmission of an older request.
   The server will treat it as a new request and commence another

12.4 Forking Proxy

   The server MUST respond to the request immediately with a 100
   (Trying) response.
ToP   noToC   Page 101
   Successful responses to an INVITE request MAY contain a Contact
   header field so that the following ACK or BYE bypasses the proxy
   search mechanism. If the proxy requires future requests to be routed
   through it, it adds a Record-Route header to the request (Section

   The following C-code describes the behavior of a proxy server issuing
   several requests in response to an incoming INVITE request.  The
   function request(r, a, b) sends a SIP request of type r to address a,
   with branch id b. await_response() waits until a response is received
   and returns the response. close(a) closes the TCP connection to
   client with address a. response(r) sends a response to the client.
   ismulticast() returns 1 if the location is a multicast address and
   zero otherwise.  The variable timeleft indicates the amount of time
   left until the maximum response time has expired. The variable
   recurse indicates whether the server will recursively try addresses
   returned through a 3xx response. A server MAY decide to recursively
   try only certain addresses, e.g., those which are within the same
   domain as the proxy server. Thus, an initial multicast request can
   trigger additional unicast requests.

     /* request type */
     typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method;

     process_request(Method R, int N, address_t address[])
       struct {
         int branch;         /* branch id */
         int done;           /* has responded */
       } outgoing[];
       int done[];           /* address has responded */
       char *location[];     /* list of locations */
       int heard = 0;        /* number of sites heard from */
       int class;            /* class of status code */
       int timeleft = 120;   /* sample timeout value */
       int loc = 0;          /* number of locations */
       struct {              /* response */
         int status;         /* response: CANCEL=-1 */
         int locations;      /* number of redirect locations */
         char *location[];   /* redirect locations */
         address_t a;        /* address of respondent */
         int branch;         /* branch identifier */
       } r, best;            /* response, best response */
       int i;

       best.status = 1000;
       for (i = 0; i < N; i++) {
ToP   noToC   Page 102
         request(R, address[i], i);
         outgoing[i].done = 0;
         outgoing[i].branch = i;

       while (timeleft > 0 && heard < N) {
         r = await_response();
         class = r.status / 100;

         /* If final response, mark branch as done. */
         if (class >= 2) {
           for (i = 0; i < N; i++) {
             if (r.branch == outgoing[i].branch) {
               outgoing[i].done = 1;
         /* CANCEL: respond, fork and wait for responses */
         else if (class < 0) {
           best.status = 200;
           for (i = 0; i < N; i++) {
             if (!outgoing[i].done)
               request(CANCEL, address[i], outgoing[i].branch);
           best.status = -1;

         /* Send an ACK */

         if (class != 2) {
           if (R == INVITE) request(ACK, r.a, r.branch);

         if (class == 2) {
           if (r.status < best.status) best = r;
         else if (class == 3) {
           /* A server MAY optionally recurse.  The server MUST check
            * whether it has tried this location before and whether
            * the location is part of the Via path of the incoming
            * request.  This check is omitted here for brevity.
            * Multicast locations MUST NOT be returned to the client if
            * the server is not recursing.
ToP   noToC   Page 103
           if (recurse) {
             multicast = 0;
             N += r.locations;
             for (i = 0; i < r.locations; i++) {
               request(R, r.location[i]);
           } else if (!ismulticast(r.location)) {
             best = r;
         else if (class == 4) {
           if (best.status >= 400) best = r;
         else if (class == 5) {
           if (best.status >= 500) best = r;
         else if (class == 6) {
           best = r;

       /* We haven't heard anything useful from anybody. */
       if (best.status == 1000) {
         best.status = 404;
       if (best.status/100 != 3) loc = 0;

   Responses are processed as follows. The process completes (and state
   can be freed) when all requests have been answered by final status
   responses (for unicast) or 60 seconds have elapsed (for multicast). A
   proxy MAY send a CANCEL to all branches and return a 408 (Timeout) to
   the client after 60 seconds or more.

   1xx: The proxy MAY forward the response upstream towards the client.

   2xx: The proxy MUST forward the response upstream towards the client,
        without sending an ACK downstream. After receiving a 2xx, the
        server MAY terminate all other pending requests by sending a
        CANCEL request and closing the TCP connection, if applicable.
        (Terminating pending requests is advisable as searches consume
        resources. Also, INVITE requests could "ring" on a number of
        workstations if the callee is currently logged in more than
ToP   noToC   Page 104
   3xx: The proxy MUST send an ACK and MAY recurse on the listed Contact
        addresses. Otherwise, the lowest-numbered response is returned
        if there were no 2xx responses.

        Location lists are not merged as that would prevent
        forwarding of authenticated responses. Also, responses can
        have message bodies, so that merging is not feasible.

   4xx, 5xx: The proxy MUST send an ACK and remember the response if it
        has a lower status code than any previous 4xx and 5xx responses.
        On completion, the lowest-numbered response is returned if there
        were no 2xx or 3xx responses.

   6xx: The proxy MUST forward the response to the client and send an
        ACK. Other pending requests MAY be terminated with CANCEL as
        described for 2xx responses.

   A proxy server forwards any response for Call-IDs for which it does
   not have a pending transaction according to the response's Via
   header. User agent servers respond to BYE requests for unknown call
   legs with status code 481 (Transaction Does Not Exist); they drop ACK
   requests with unknown call legs silently.

   Special considerations apply for choosing forwarding destinations for
   ACK and BYE requests. In most cases, these requests will bypass
   proxies and reach the desired party directly, keeping proxies from
   having to make forwarding decisions.

   A proxy MAY maintain call state for a period of its choosing. If a
   proxy still has list of destinations that it forwarded the last
   INVITE to, it SHOULD direct ACK requests only to those downstream

(page 104 continued on part 5)

Next Section