RFC 2543
SIP: Session Initiation Protocol
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 located.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.
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.
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 location. 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.
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.
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 time.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 registrations.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.
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.
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 transaction.)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 field.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 provided. 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 lee@example.com : 485 Ambiguous SIP/2.0 Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sip:lee.foote@example.com>
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.
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.
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
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/html8.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 indicator.)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:
INVITE sip:schooler@vlsi.caltech.edu SIP/2.0
v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16
v:SIP/2.0/UDP 128.16.64.19
f:sip:mjh@isi.edu
t:sip:schooler@cs.caltech.edu
i:62729-27@128.16.64.19
c:application/sdp
CSeq: 4711 INVITE
l:187
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
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
state.)
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
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.
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.
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
indefinitely.
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).
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" connection.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 latencies. 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.
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".
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
+===========+
* *
...........>* 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)
message
Figure 12: State transition diagram of client for INVITE method
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
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
it.
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.
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 caller.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, respectively.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.
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 made: 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
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.
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) responses.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.
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 chain. 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 search.12.4 Forking Proxy
The server MUST respond to the request immediately with a 100 (Trying) response.
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 6.29). 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++) {
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) {
heard++;
for (i = 0; i < N; i++) {
if (r.branch == outgoing[i].branch) {
outgoing[i].done = 1;
break;
}
}
}
/* CANCEL: respond, fork and wait for responses */
else if (class < 0) {
best.status = 200;
response(best);
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;
break;
}
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.
*/
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;
break;
}
}
/* We haven't heard anything useful from anybody. */
if (best.status == 1000) {
best.status = 404;
}
if (best.status/100 != 3) loc = 0;
response(best);
}
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
once.)
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
servers.
(page 104 continued on part 5)
