was sent using TCP, use the existing TCP connection if
available.
6.40.5 Syntax
The format for a Via header field is shown in Fig. 11. The defaults
for "protocol-name" and "transport" are "SIP" and "UDP",
respectively. The "maddr" parameter, designating the multicast
address, and the "ttl" parameter, designating the time-to-live (TTL)
value, are included only if the request was sent via multicast. The
"received" parameter is added only for receiver-added Via fields
(Section 6.40.2). For reasons of privacy, a client or proxy may wish
to hide its Via information by encrypting it (see Section 6.22). The
"hidden" parameter is included if this header field was hidden by the
upstream proxy (see 6.22). Note that privacy of the proxy relies on
the cooperation of the next hop, as the next-hop proxy will, by
necessity, know the IP address and port number of the source host.
The "branch" parameter is included by every forking proxy. The token
MUST be unique for each distinct request generated when a proxy
forks. CANCEL requests MUST have the same branch value as the
corresponding forked request. When a response arrives at the proxy it
can use the branch value to figure out which branch the response
corresponds to. A proxy which generates a single request (non-
forking) MAY also insert the "branch" parameter. The identifier has
to be unique only within a set of isomorphic requests.
Via: SIP/2.0/UDP first.example.com:4000;ttl=16
;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example)
Via: SIP/2.0/UDP adk8
Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by
*( ";" via-params ) [ comment ] )
via-params = via-hidden | via-ttl | via-maddr
| via-received | via-branch
via-hidden = "hidden"
via-ttl = "ttl" "=" ttl
via-maddr = "maddr" "=" maddr
via-received = "received" "=" host
via-branch = "branch" "=" token
sent-protocol = protocol-name "/" protocol-version "/" transport
protocol-name = "SIP" | token
protocol-version = token
transport = "UDP" | "TCP" | token
sent-by = ( host [ ":" port ] ) | ( concealed-host )
concealed-host = token
ttl = 1*3DIGIT ; 0 to 255
Figure 11: Syntax of Via header field
6.41 Warning
The Warning response-header field is used to carry additional
information about the status of a response. Warning headers are sent
with responses and have the following format:
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
A response MAY carry more than one Warning header.
The "warn-text" should be in a natural language that is most likely
to be intelligible to the human user receiving the response. This
decision can be based on any available knowledge, such as the
location of the cache or user, the Accept-Language field in a
request, or the Content-Language field in a response. The default
language is i-default [31].
Any server MAY add Warning headers to a response. Proxy servers MUST
place additional Warning headers before any Authorization headers.
Within that constraint, Warning headers MUST be added after any
existing Warning headers not covered by a signature. A proxy server
MUST NOT delete any Warning header field that it received with a
response.
When multiple Warning headers are attached to a response, the user
agent SHOULD display as many of them as possible, in the order that
they appear in the response. If it is not possible to display all of
the warnings, the user agent first displays warnings that appear
early in the response.
The warn-code consists of three digits. A first digit of "3"
indicates warnings specific to SIP.
This is a list of the currently-defined "warn-code"s, each with a
recommended warn-text in English, and a description of its meaning.
Note that these warnings describe failures induced by the session
description.
Warnings 300 through 329 are reserved for indicating problems with
keywords in the session description, 330 through 339 are warnings
related to basic network services requested in the session
description, 370 through 379 are warnings related to quantitative QoS
parameters requested in the session description, and 390 through 399
are miscellaneous warnings that do not fall into one of the above
categories.
300 Incompatible network protocol: One or more network protocols
contained in the session description are not available.
301 Incompatible network address formats: One or more network address
formats contained in the session description are not available.
302 Incompatible transport protocol: One or more transport protocols
described in the session description are not available.
303 Incompatible bandwidth units: One or more bandwidth measurement
units contained in the session description were not understood.
304 Media type not available: One or more media types contained in
the session description are not available.
305 Incompatible media format: One or more media formats contained in
the session description are not available.
306 Attribute not understood: One or more of the media attributes in
the session description are not supported.
307 Session description parameter not understood: A parameter other
than those listed above was not understood.
330 Multicast not available: The site where the user is located does
not support multicast.
331 Unicast not available: The site where the user is located does
not support unicast communication (usually due to the presence
of a firewall).
370 Insufficient bandwidth: The bandwidth specified in the session
description or defined by the media exceeds that known to be
available.
399 Miscellaneous warning: The warning text can include arbitrary
information to be presented to a human user, or logged. A system
receiving this warning MUST NOT take any automated action.
1xx and 2xx have been taken by HTTP/1.1.
Additional "warn-code"s, as in the example below, can be defined
through IANA.
Examples:
Warning: 307 isi.edu "Session parameter 'foo' not understood"
Warning: 301 isi.edu "Incompatible network address type 'E.164'"
6.42 WWW-Authenticate
The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages. The field value consists of at
least one challenge that indicates the authentication scheme(s) and
parameters applicable to the Request-URI. See [H14.46] for a
definition of the syntax, and section 14 for an overview of usage.
The content of the "realm" parameter SHOULD be displayed to the user.
A user agent SHOULD cache the authorization credentials for a given
value of the destination (To header) and "realm" and attempt to re-
use these values on the next request for that destination.
In addition to the "basic" and "digest" authentication schemes
defined in the specifications cited above, SIP defines a new scheme,
PGP (RFC2015, [32]), Section 15. Other schemes, such as S/MIME, are
for further study.
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/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
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