draft-ietf-mmusic-sip-07.txt   draft-ietf-mmusic-sip-08.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft Handley/Schulzrinne/Schooler/Rosenberg Internet Draft Handley/Schulzrinne/Schooler/Rosenberg
ietf-mmusic-sip-07.txt ISI/Columbia U./Caltech/Bell Labs. ietf-mmusic-sip-08.txt ISI/Columbia U./Caltech/Bell Labs.
July 16, 1998 August 7, 1998
Expires: December 1998 Expires: February 1999
SIP: Session Initiation Protocol SIP: Session Initiation Protocol
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 5, line 21 skipping to change at page 5, line 21
participation in a session. A successful SIP invitation consists participation in a session. A successful SIP invitation consists
of two transactions: an INVITE request followed by an ACK of two transactions: an INVITE request followed by an ACK
request. request.
Invitee, invited user, called party, callee: The person or service Invitee, invited user, called party, callee: The person or service
that the calling party is trying to invite to a conference. that the calling party is trying to invite to a conference.
Isomorphic request or response: Two requests or responses are defined Isomorphic request or response: Two requests or responses are defined
to be isomorphic for the purposes of this document if they have to be isomorphic for the purposes of this document if they have
the same values for the Call-ID, To, From and CSeq header the same values for the Call-ID, To, From and CSeq header
fields. In addition, requests have to have the same Request- fields. In addition, requests have to have the same Request-URI.
URI.
Location server: See location service Location server: See location service
Location service: A location service is used by a SIP redirect or Location service: A location service is used by a SIP redirect or
proxy server to obtain information about a callee's possible proxy server to obtain information about a callee's possible
location(s). Location services are offered by location servers. location(s). Location services are offered by location servers.
Location servers may be co-located with a SIP server, but the Location servers may be co-located with a SIP server, but the
manner in which a SIP server requests location services is manner in which a SIP server requests location services is
beyond the scope of this document. beyond the scope of this document.
skipping to change at page 6, line 38 skipping to change at page 6, line 37
If SDP is used, a session is defined by the concatenation of the If SDP is used, a session is defined by the concatenation of the
user name , session id , network type , address type and address user name , session id , network type , address type and address
elements in the origin field. elements in the origin field.
(SIP) transaction: A SIP transaction occurs between a client and a (SIP) transaction: A SIP transaction occurs between a client and a
server and comprises all messages from the first request sent server and comprises all messages from the first request sent
from the client to the server up to a final (non-1xx) response from the client to the server up to a final (non-1xx) response
sent from the server to the client. A transaction is identified sent from the server to the client. A transaction is identified
by the CSeq sequence number (Section 6.16) within a single call by the CSeq sequence number (Section 6.16) within a single call
leg The ACK request has the same CSeq number as the leg The ACK request has the same CSeq number as the
corresponding INVITE request, but comprises a transaction of corresponding INVITE request, but comprises a transaction of its
its own. own.
Upstream: Responses sent in the direction from the called client to Upstream: Responses sent in the direction from the called client to
the caller. the caller.
URL-encoded: A character string encoded according to RFC 1738, URL-encoded: A character string encoded according to RFC 1738,
Section 2.2 [8]. Section 2.2 [8].
User agent client (UAC), calling user agent: A user agent client is a User agent client (UAC), calling user agent: A user agent client is a
client application that initiates the SIP request. client application that initiates the SIP request.
skipping to change at page 7, line 18 skipping to change at page 7, line 17
a server. For example, a typical multimedia conference control a server. For example, a typical multimedia conference control
application would act as a user agent client to initiate calls or to application would act as a user agent client to initiate calls or to
invite others to conferences and as a user agent server to accept invite others to conferences and as a user agent server to accept
invitations. The properties of the different SIP server types are invitations. The properties of the different SIP server types are
summarized in Table 1. summarized in Table 1.
property redirect proxy user agent registrar property redirect proxy user agent registrar
server server server server server server
__________________________________________________________________________ __________________________________________________________________________
also acts as a SIP client no yes no no also acts as a SIP client no yes no no
returns 1xx status yes yes yes rare returns 1xx status yes yes yes yes
returns 2xx status no yes yes yes returns 2xx status no yes yes yes
returns 3xx status yes yes yes yes returns 3xx status yes yes yes yes
returns 4xx status yes yes yes yes returns 4xx status yes yes yes yes
returns 5xx status yes yes yes yes returns 5xx status yes yes yes yes
returns 6xx status no yes yes no returns 6xx status no yes yes no
inserts Via header no yes no no inserts Via header no yes no no
accepts ACK yes yes yes no accepts ACK yes yes yes no
Table 1: Properties of the different SIP server types Table 1: Properties of the different SIP server types
skipping to change at page 7, line 45 skipping to change at page 7, line 44
(Section 1.4.3). The most common SIP operation is the invitation (Section 1.4.3). The most common SIP operation is the invitation
(Section 1.4.4). Instead of directly reaching the intended callee, a (Section 1.4.4). Instead of directly reaching the intended callee, a
SIP request may be redirected or may trigger a chain of new SIP SIP request may be redirected or may trigger a chain of new SIP
requests by proxies (Section 1.4.5). Users can register their requests by proxies (Section 1.4.5). Users can register their
location(s) with SIP servers (Section 4.2.6). location(s) with SIP servers (Section 4.2.6).
1.4.1 SIP Addressing 1.4.1 SIP Addressing
The "objects" addressed by SIP are users at hosts, identified by a The "objects" addressed by SIP are users at hosts, identified by a
SIP URL. The SIP URL takes the form similar to a mailto or telnet SIP URL. The SIP URL takes the form similar to a mailto or telnet
URL, i.e., user@host The user part is a user name, a civil name or a URL, i.e., user@host user part is a user name, a civil name or a
telephone number. The host part is either a domain name having a DNS telephone number. The host part is either a domain name having a DNS
SRV (RFC 2052 [9]), MX (RFC 974 [10], CNAME or A record (RFC 1035 SRV (RFC 2052 [9]), MX (RFC 974 [10], CNAME or A record (RFC 1035
[11]), or a numeric network address. [11]), or a numeric network address.
A user's SIP address can be obtained out-of-band, can be learned via A user's SIP address can be obtained out-of-band, can be learned via
existing media agents, can be included in some mailers' message existing media agents, can be included in some mailers' message
headers, or can be recorded during previous invitation interactions. headers, or can be recorded during previous invitation interactions.
In many cases, a user's SIP URL can be guessed from his email In many cases, a user's SIP URL can be guessed from his email
address. address.
skipping to change at page 8, line 34 skipping to change at page 8, line 34
If a user or service chooses to be reachable at an address that is If a user or service chooses to be reachable at an address that is
guessable from the person's name and organizational affiliation, the guessable from the person's name and organizational affiliation, the
traditional method of ensuring privacy by having an unlisted "phone" traditional method of ensuring privacy by having an unlisted "phone"
number is compromised. However, unlike traditional telephony, SIP number is compromised. However, unlike traditional telephony, SIP
offers authentication and access control mechanisms and can avail offers authentication and access control mechanisms and can avail
itself of lower-layer security mechanisms, so that client software itself of lower-layer security mechanisms, so that client software
can reject unauthorized or undesired call attempts. can reject unauthorized or undesired call attempts.
1.4.2 Locating a SIP Server 1.4.2 Locating a SIP Server
When a client wishes to send a request, the client either sends it to
locally configured SIP proxy server (as in HTTP), independent of the
Request-URI, or sends it to the IP address and port corresponding to
the Request-URI. For the latter case, the client performs the
following steps to obtain the server's IP address.
A SIP client MUST follow the following steps to resolve the host part A SIP client MUST follow the following steps to resolve the host part
of a callee address. If a client supports only TCP or UDP, but not of the Request-URI. If a client supports only TCP or UDP, but not
both, the client omits the respective address type. If the SIP both, the client omits the respective address type. If the SIP
address contains a port number, that number is to be used, otherwise, address contains a port number, that number is to be used, otherwise,
the default port number 5060 is to be used. The default port number the default port number 5060 is to be used. The default port number
is the same for UDP and TCP. In all cases, the client first attempts is the same for UDP and TCP. In all cases, the client first attempts
to contact the server using UDP, then TCP. to contact the server using UDP, then TCP.
A client SHOULD rely on ICMP "Port Unreachable" messages rather than A client SHOULD rely on ICMP "Port Unreachable" messages rather than
time-outs to determine that a server is not reachable at a particular time-outs to determine that a server is not reachable at a particular
address. (For socket-based programs: For TCP, connect() returns address. (For socket-based programs: For TCP, connect() returns
ECONNREFUSED if there is no server at the designated address; for ECONNREFUSED if there is no server at the designated address; for
skipping to change at page 9, line 38 skipping to change at page 9, line 44
given host and try to contact a SIP server at the one or given host and try to contact a SIP server at the one or
more addresses listed, again trying first UDP, then TCP. more addresses listed, again trying first UDP, then TCP.
If all of the above methods fail to locate a server, the caller MAY If all of the above methods fail to locate a server, the caller MAY
contact an SMTP server at the user's host and use the SMTP EXPN contact an SMTP server at the user's host and use the SMTP EXPN
command to obtain an alternate address and repeat the steps above. As command to obtain an alternate address and repeat the steps above. As
a last resort, a client MAY choose to deliver the session description a last resort, a client MAY choose to deliver the session description
to the callee using electronic mail. to the callee using electronic mail.
A client MAY cache the result of the reachability steps for a A client MAY cache the result of the reachability steps for a
particular address and retry that host address for the next call. If particular address and retry that host address for the next request.
the client does not find a SIP server at the cached address, it MUST If the client does not find a SIP server at the cached address, it
start the search at the beginning of the sequence. MUST start the search at the beginning of the sequence.
This sequence is modeled after that described for SMTP, This sequence is modeled after that described for SMTP,
where MX records are to be checked before A records (RFC where MX records are to be checked before A records (RFC
1123 [12]). 1123 [12]).
1.4.3 SIP Transaction 1.4.3 SIP Transaction
Once the host part has been resolved to a SIP server, the client Once the host part has been resolved to a SIP server, the client
sends one or more SIP requests to that server and receives one or sends one or more SIP requests to that server and receives one or
more responses from the server. A request (and its retransmissions) more responses from the server. A request (and its retransmissions)
together with the responses triggered by that request make up a SIP together with the responses triggered by that request make up a SIP
transaction. The ACK request following an INVITE is not part of transaction. The ACK request following an INVITE is not part of the
the transaction since it may traverse a different set of hosts. transaction since it may traverse a different set of hosts.
If TCP is used, request and responses within a single SIP transaction If TCP is used, request and responses within a single SIP transaction
are carried over the same TCP connection (see Section 10). Several are carried over the same TCP connection (see Section 10). Several
SIP requests from the same client to the same server may use the same SIP requests from the same client to the same server may use the same
TCP connection or may open a new connection for each request. TCP connection or may open a new connection for each request.
If the client sent the request via unicast UDP, the response is sent If the client sent the request via unicast UDP, the response is sent
to the address contained in the next Via header field (Section 6.40) to the address contained in the next Via header field (Section 6.40)
of the response. If the request is sent via multicast UDP, the of the response. If the request is sent via multicast UDP, the
response is directed to the same multicast address and destination response is directed to the same multicast address and destination
port. For UDP, reliability is achieved using retransmission (Section port. For UDP, reliability is achieved using retransmission (Section
10). 10).
The SIP message format and operation is independent of the transport The SIP message format and operation is independent of the transport
protocol. protocol.
1.4.4 SIP Invitation 1.4.4 SIP Invitation
A successful SIP invitation consists of two requests, INVITE A successful SIP invitation consists of two requests, INVITE followed
followed by ACK. The INVITE (Section 4.2.1) request asks the callee by ACK. The INVITE (Section 4.2.1) request asks the callee to join a
to join a particular conference or establish a two-party particular conference or establish a two-party conversation. After
conversation. After the callee has agreed to participate in the call, the callee has agreed to participate in the call, the caller confirms
the caller confirms that it has received that response by sending an that it has received that response by sending an ACK (Section 4.2.2)
ACK (Section 4.2.2) request. If the caller no longer wants to request. If the caller no longer wants to participate in the call, it
participate in the call, it sends a BYE request instead of an ACK. sends a BYE request instead of an ACK.
The INVITE request typically contains a session description, for The INVITE request typically contains a session description, for
example written in SDP (RFC 2327 [5]) format, that provides the example written in SDP (RFC 2327 [5]) format, that provides the
called party with enough information to join the session. For called party with enough information to join the session. For
multicast sessions, the session description enumerates the media multicast sessions, the session description enumerates the media
types and formats that may be distributed to that session. For a types and formats that may be distributed to that session. For a
unicast session, the session description enumerates the media types unicast session, the session description enumerates the media types
and formats that the caller is willing to receive and where it wishes and formats that the caller is willing to receive and where it wishes
the media data to be sent. In either case, if the callee wishes to the media data to be sent. In either case, if the callee wishes to
accept the call, it responds to the invitation by returning a similar accept the call, it responds to the invitation by returning a similar
skipping to change at page 11, line 11 skipping to change at page 11, line 17
messages shown in the figures have been abbreviated slightly.) In messages shown in the figures have been abbreviated slightly.) In
Fig. 1, the proxy server accepts the INVITE request (step 1), Fig. 1, the proxy server accepts the INVITE request (step 1),
contacts the location service with all or parts of the address (step contacts the location service with all or parts of the address (step
2) and obtains a more precise location (step 3). The proxy server 2) and obtains a more precise location (step 3). The proxy server
then issues a SIP INVITE request to the address(es) returned by the then issues a SIP INVITE request to the address(es) returned by the
location service (step 4). The user agent server alerts the user location service (step 4). The user agent server alerts the user
(step 5) and returns a success indication to the proxy server (step (step 5) and returns a success indication to the proxy server (step
6). The proxy server then returns the success result to the original 6). The proxy server then returns the success result to the original
caller (step 7). The receipt of this message is confirmed by the caller (step 7). The receipt of this message is confirmed by the
caller using an ACK request, which is forwarded to the callee (steps caller using an ACK request, which is forwarded to the callee (steps
8 and 9). All requests and responses have the same Call-ID. 8 and 9). Note that an ACK can also be sent directly to the callee,
bypassing the proxy. All requests and responses have the same Call-
ID.
+....... cs.columbia.edu .......+ +....... cs.columbia.edu .......+
: : : :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ( location ) : : ( location ) :
: ( service ) : : ( service ) :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ^ | : : ^ | :
: | hgs@play : : | hgs@play :
: 2| 3| : : 2| 3| :
skipping to change at page 11, line 39 skipping to change at page 12, line 4
: : : ( tune ) ( play ) : : : : ( tune ) ( play ) :
: : 8: ACK : ( )9: ACK ( ) : : : 8: ACK : ( )9: ACK ( ) :
: ========================>(~~~~~~)=========>(~~~~~~) : : ========================>(~~~~~~)=========>(~~~~~~) :
+.....................+ +...............................+ +.....................+ +...............................+
====> SIP request ====> SIP request
....> SIP response ....> SIP response
----> non-SIP protocols ----> non-SIP protocols
Figure 1: Example of SIP proxy server Figure 1: Example of SIP proxy server
The redirect server shown in Fig. 2 accepts the INVITE request (step The redirect server shown in Fig. 2 accepts the INVITE request (step
1), contacts the location service as before (steps 2 and 3) and, 1), contacts the location service as before (steps 2 and 3) and,
instead of contacting the newly found address itself, returns the instead of contacting the newly found address itself, returns the
address to the caller (step 4), which is then acknowledged via an address to the caller (step 4), which is then acknowledged via an ACK
ACK request (step 5). The caller issues a new request, with the same request (step 5). The caller issues a new request, with the same
call-ID but a higher CSeq, to the address returned by the first call-ID but a higher CSeq, to the address returned by the first
server (step 6). In the example, the call succeeds (step 7). The server (step 6). In the example, the call succeeds (step 7). The
caller and callee complete the handshake with an ACK (step 8). caller and callee complete the handshake with an ACK (step 8).
The next section discusses what happens if the location service The next section discusses what happens if the location service
returns more than one possible alternative. returns more than one possible alternative.
1.4.5 Locating a User 1.4.5 Locating a User
A callee may move between a number of different end systems over A callee may move between a number of different end systems over
skipping to change at page 12, line 39 skipping to change at page 12, line 45
successful (2xx response) or the callee has declined the call (6xx successful (2xx response) or the callee has declined the call (6xx
response). With sequential attempts, a proxy server can implement an response). With sequential attempts, a proxy server can implement an
"anycast" service. "anycast" service.
If a proxy server forwards a SIP request, it MUST add itself to the If a proxy server forwards a SIP request, it MUST add itself to the
end of the list of forwarders noted in the Via (Section 6.40) end of the list of forwarders noted in the Via (Section 6.40)
headers. The Via trace ensures that replies can take the same path headers. The Via trace ensures that replies can take the same path
back, ensuring correct operation through compliant firewalls and back, ensuring correct operation through compliant firewalls and
avoiding request loops. On the response path, each host MUST remove avoiding request loops. On the response path, each host MUST remove
its Via, so that routing internal information is hidden from the its Via, so that routing internal information is hidden from the
callee and outside networks. When a multicast request is made, first callee and outside networks. A proxy server MUST check that it does
the host making the request, then the multicast address itself are not generate a request to a host listed in the Via sent-by, via-
added to the path. A proxy server MUST check that it does not received or via-maddr parameters (Section 6.40). (Note: If a host
generate a request to a host listed in the Via list. (Note: If a has several names or network addresses, this may not always work.
host has several names or network addresses, this may not always Thus, each host also checks if it is part of the Via list.)
work. Thus, each host also checks if it is part of the Via list.)
A SIP invitation may traverse more than one SIP proxy server. If one
of these "forks" the request, i.e., issues more than one request in
response to receiving the invitation request, it is possible that a
client is reached, independently, by more than one copy of the
invitation request. Each of these copies bears the same Call-ID. The
+....... cs.columbia.edu .......+ +....... cs.columbia.edu .......+
: : : :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ( location ) : : ( location ) :
: ( service ) : : ( service ) :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ^ | : : ^ | :
: | hgs@play : : | hgs@play :
: 2| 3| : : 2| 3| :
: | | : : | | :
skipping to change at page 14, line 4 skipping to change at page 14, line 4
| : ( ) : | : ( ) :
| 8: ACK : ( ) : | 8: ACK : ( ) :
======================================================> (~~~~~~) : ======================================================> (~~~~~~) :
+...............................+ +...............................+
====> SIP request ====> SIP request
....> SIP response ....> SIP response
----> non-SIP protocols ----> non-SIP protocols
Figure 2: Example of SIP redirect server Figure 2: Example of SIP redirect server
A SIP invitation may traverse more than one SIP proxy server. If one
of these "forks" the request, i.e., issues more than one request in
response to receiving the invitation request, it is possible that a
client is reached, independently, by more than one copy of the
invitation request. Each of these copies bears the same Call-ID. The
user agent MUST return the appropriate status response. Duplicate user agent MUST return the appropriate status response. Duplicate
requests are not an error. requests are not an error.
1.4.6 Changing an Existing Session 1.4.6 Changing an Existing Session
In some circumstances, it may be necessary to change the parameters In some circumstances, it may be necessary to change the parameters
of an existing session. For example, two parties may have been of an existing session. For example, two parties may have been
conversing and then want to add a third party, switching to multicast conversing and then want to add a third party, switching to multicast
for efficiency. One of the participants invites the third party with for efficiency. One of the participants invites the third party with
the new multicast address and simultaneously sends an INVITE to the the new multicast address and simultaneously sends an INVITE to the
skipping to change at page 14, line 30 skipping to change at page 14, line 35
server know at which address(es) it may be reached. A client may also server know at which address(es) it may be reached. A client may also
use it to install call handling features at the server. use it to install call handling features at the server.
1.5 Protocol Properties 1.5 Protocol Properties
1.5.1 Minimal State 1.5.1 Minimal State
A single conference session or call may involve one or more SIP A single conference session or call may involve one or more SIP
request-response transactions. Proxy servers do not have to keep request-response transactions. Proxy servers do not have to keep
state for a particular call, however, they MAY maintain state for a state for a particular call, however, they MAY maintain state for a
single SIP transaction, as discussed in Section 11. single SIP transaction, as discussed in Section 12.
For efficiency, a server may cache the results of location service For efficiency, a server may cache the results of location service
requests. requests.
1.5.2 Lower-Layer-Protocol Neutral 1.5.2 Lower-Layer-Protocol Neutral
SIP makes minimal assumptions about the underlying transport and SIP makes minimal assumptions about the underlying transport and
network-layer protocols. The lower-layer may provide either a packet network-layer protocols. The lower-layer may provide either a packet
or a byte stream service, with reliable or unreliable service. or a byte stream service, with reliable or unreliable service.
skipping to change at page 15, line 26 skipping to change at page 15, line 31
SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This
allows easy implementation in languages such as Java, Tcl and Perl, allows easy implementation in languages such as Java, Tcl and Perl,
allows easy debugging, and most importantly, makes SIP flexible and allows easy debugging, and most importantly, makes SIP flexible and
extensible. As SIP is used for initiating multimedia conferences extensible. As SIP is used for initiating multimedia conferences
rather than delivering media data, it is believed that the additional rather than delivering media data, it is believed that the additional
overhead of using a text-based protocol is not significant. overhead of using a text-based protocol is not significant.
2 SIP Uniform Resource Locators 2 SIP Uniform Resource Locators
SIP URLs are used within SIP messages to indicate the originator ( SIP URLs are used within SIP messages to indicate the originator
From), current destination ( Request-URI) and final recipient ( To) (From), current destination (Request-URI) and final recipient (To) of
of a SIP request, and to specify redirection addresses ( Location). A a SIP request, and to specify redirection addresses (Location). A SIP
SIP URL can also be embedded in web pages or other hyperlinks to URL can also be embedded in web pages or other hyperlinks to indicate
indicate that a user or service may be called. that a user or service may be called.
Because interaction with some resources may require message headers Because interaction with some resources may require message headers
or message bodies to be specified as well as the SIP address, the SIP or message bodies to be specified as well as the SIP address, the SIP
URL scheme is defined to allow setting SIP request-header fields and URL scheme is defined to allow setting SIP request-header fields and
the SIP message-body. the SIP message-body.
A SIP URL follows the guidelines of RFC 1630 [17], as revised [18], A SIP URL follows the guidelines of RFC 1630 [17], as revised [18],
and has the syntax shown in Fig. 3. Note that reserved characters and has the syntax shown in Fig. 3. Note that reserved characters
have to be escaped. have to be escaped.
The URI character classes referenced above are described in Section The URI character classes referenced above are described in Section
C. The URI specification is currently being revised. It is C. The URI specification is currently being revised. It is
anticipated that future versions of this specification will reference anticipated that future versions of this specification will reference
the revised edition. Note that all URL reserved characters MUST be the revised edition. Note that all URL reserved characters MUST be
encoded. SIP-URL = "sip:" [ userinfo "@" ] hostport
host: The mailto: URL and RFC 822 email addresses require that
numeric host addresses ("host numbers") are enclosed in square
brackets (presumably, since host names might be numeric), while
SIP-URL = "sip:" [ userinfo ] "@" hostport
url-parameters [ headers ] url-parameters [ headers ]
userinfo = user [ ":" password ] userinfo = user [ ":" password ]
user = *( unreserved | escaped user = *( unreserved | escaped
| ";" | "&" | "=" | "+" | "$" | "," ) | "&" | "=" | "+" | "$" | "," )
password = *( unreserved | escaped password = *( unreserved | escaped
| ";" | "&" | "=" | "+" | "$" | "," ) | "&" | "=" | "+" | "$" | "," )
hostport = host [ ":" port ] hostport = host [ ":" port ]
host = hostname | IPv4address host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ] hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum toplabel = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit port = *digit
url-parameters = *( ";" url-parameter ) url-parameters = *( ";" url-parameter )
url-parameter = transport-param | user-param url-parameter = transport-param | user-param
| ttl-param | maddr-param | tag-param | other-param | ttl-param | maddr-param | tag-param | other-param
transport-param = "transport=" ( "udp" | "tcp" ) transport-param = "transport=" ( "udp" | "tcp" )
ttl-param = "ttl=" ttl ttl-param = "ttl=" ttl
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
maddr-param = "maddr=" maddr maddr-param = "maddr=" host
maddr = IPv4address ; multicast address user-param = "user=" ( "phone" $|$ "ip" )
user-param = "user=" ( "phone" )
tag-param = "tag=" UUID tag-param = "tag=" UUID
UUID = 1*( hex | "-" ) UUID = 1*( hex | "-" )
other-param = *uric other-param = *uric
headers = "?" header *( "&" header ) headers = "?" header *( "&" header )
header = hname "=" hvalue header = hname "=" hvalue
hname = *uric hname = *uric
hvalue = *uric hvalue = *uric
uric = reserved | unreserved | escaped uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | "," "$" | ","
digits = 1*DIGIT digits = 1*DIGIT
Figure 3: SIP URL syntax Figure 3: SIP URL syntax
Figure 4: SIP URL syntax; telephone subscriber
encoded.
host: The mailto: URL and RFC 822 email addresses require that
numeric host addresses ("host numbers") are enclosed in square
brackets (presumably, since host names might be numeric), while
host numbers without brackets are used for all other URLs. The host numbers without brackets are used for all other URLs. The
SIP URL requires the latter form, without brackets. SIP URL requires the latter form, without brackets.
userinfo: The SIP scheme MAY use the format " user:password" in the userinfo: The SIP scheme MAY use the format " user:password" in the
userinfo field. The use of passwords in the userinfo is NOT userinfo field. The use of passwords in the userinfo is NOT
RECOMMENDED, because the passing of authentication information RECOMMENDED, because the passing of authentication information
in clear text (such as URIs) has proven to be a security risk in in clear text (such as URIs) has proven to be a security risk in
almost every case where it has been used. almost every case where it has been used.
telephone-subscriber = global-phone-number | local-phone-number
global-phone-number = "+" 1*phonedigit [isdn-subaddress]
[post-dial]
local-phone-number = 1*(phonedigit | dtmf-digit |
pause-character) [isdn-subaddress]
[post-dial]
isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit | dtmf-digit
| pause-character)
phonedigit = DIGIT | visual-separator
visual-separator = "-" | "."
pause-character = one-second-pause | wait-for-dial-tone
one-second-pause = "p"
wait-for-dial-tone = "w"
dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D"
Figure 4: SIP URL syntax; telephone subscriber
If the host is an Internet telephony gateway, the userinfo field can If the host is an Internet telephony gateway, the userinfo field can
also encode a telephone number using the notation of telephone- also encode a telephone number using the notation of telephone-
subscriber (Fig. 4). The telephone number is a special case of a subscriber (Fig. 4). The telephone number is a special case of a
user name and cannot be distinguished by a BNF. Thus, a URL user name and cannot be distinguished by a BNF. Thus, a URL
parameter, user, is added to distinguish telephone numbers from user parameter, user, is added to distinguish telephone numbers from user
names. The phone identifier is to be used when connecting to a names. The phone identifier is to be used when connecting to a
telephony gateway. Even without this parameter, recipients of SIP telephony gateway. Even without this parameter, recipients of SIP
URLs MAY interpret the pre-@ part as a phone number if local URLs MAY interpret the pre-@ part as a phone number if local
restrictions on the name space for user name allow it. restrictions on the name space for user name allow it.
If a server handles SIP addresses for another domain, it MUST URL- If a server handles SIP addresses for another domain, it MUST URL-
encode the "@" character (%40). encode the "@" character (%40). The ";" character MUST be URL-
encoded, as otherwise it is not possible to distinguish, in one
parsing pass, the case host;parameter and user;moreuser@host
URL parameters: SIP URLs can define specific parameters of the URL parameters: SIP URLs can define specific parameters of the
request, including the transport mechanism (UDP or TCP) and the request: The transport parameter determines the the transport
use of multicast to make a request. These parameters are added mechanism (UDP or TCP). UDP is to be assumed when no explicit
after the host and are separated by semi-colons. For example, to transport parameter is included. The maddr parameter provides
the server address to be contacted for this user, overriding the
address supplied in the host field. This address is typically a
multicast address, but could also be the address of a backup
server. The ttl parameter determines the time-to-live value of
the UDP multicast packet and MUST only be used if maddr is a
multicast address and the transport protocol is UDP. The user
parameter was described above, the tag parameter is described in
its own section below. URL parameters are added after the host
component and are separated by semi-colons. For example, to
specify to call j.doe@big.com using multicast to 239.255.255.1 specify to call j.doe@big.com using multicast to 239.255.255.1
with a ttl of 15, the following URL would be used: with a ttl of 15, the following URL would be used:
sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
The transport protocol UDP is to be assumed when a multicast address The transport, maddr, and ttl parameters MUST NOT be used in the From
is given. and To header fields and the Request-URI; they are ignored if
present.
Transport parameters MUST NOT be used in the From and To header
fields and the Request-URI; they are ignored if present.
Headers: Headers of the SIP request can be defined with the "?" Headers: Headers of the SIP request can be defined with the "?"
mechanism within a SIP URL. The special hname " body" indicates mechanism within a SIP URL. The special hname " body" indicates
that the associated hvalue is the message-body of the SIP that the associated hvalue is the message-body of the SIP INVITE
INVITE request. Headers MUST NOT be used in the From and To request. Headers MUST NOT be used in the From and To header
header fields and the Request-URI; they are ignored if present. fields and the Request-URI; they are ignored if present.
Tag: The tag parameter allows several instances of a user that share Tag: The tag parameter serves as a general mechanism to distinguish
the same host and port values to be distinguished from each multiple instances of a user identified by a single SIP URL.
other, for example, where the host designates a firewall or Such distinction is needed in two cases. First, as proxies can
proxy. The tag value is a random string consisting of hex fork requests, the same request can reach multiple instances of
digits. The use of version-1 (time-based) or version-4 (random) a user (mobile and home phones, for example). As each can
UUID [19] is OPTIONAL. The tag value is designed to be respond, there needs to be a means to distinguish the responses
globally unique and cryptographically random with at least 32 from each at the caller. The situation also arises with
bits of randomness. It SHOULD NOT be included in long-lived SIP multicast requests. The tag serves to distinguish responses at
URLs, e.g., those found on web pages or user databases. A single the UAC. It MUST be placed in the To field of the response by
user maintains the same tag throughout the call identified by each instance when there is a possibility that the request was
the Call-ID. The tag parameter in To headers is ignored when forked at an intermediate proxy. This, in general, means that
matching responses to requests that did not contain a tag in the Tag MUST be inserted when the URL in the To does not refer
their To header. (See Section 6.37.) to a fully qualified hostname. The tag MUST be added by UAS,
registrars and redirect servers, but MUST NOT be inserted into
responses forwarded upstream by proxies. The Tag is added for
all responses for all methods. All subsequent transactions
between two entities MUST include the Tag parameter, as
described in Section 11.
Secondly, the tag MAY appear in the From field of a call invitation.
This is needed when it is anticipated that two instances of a user
sharing a SIP address may make call invitations with the same Call-
ID. In this case, it MUST be present.
The use of version-1 (time based) or version-4 (random) UUID [19] is
OPTIONAL. The tag value is designed to be globally unique and
cryptographically random with at least 32 bits of randomness. It
SHOULD NOT be included in long-lived SIP URLs, e.g., those found on
web pages or user databases. A single user maintains the same tag
throughout the call identified by the Call-ID. The tag parameter in
To headers is ignored when matching responses to requests that did
not contain a tag in their To header. (See Section 6.37.)
Table 2 summarizes where the components of the SIP URL can be used. Table 2 summarizes where the components of the SIP URL can be used.
Examples of SIP URLs are:
sip:j.doe@big.com
sip:j.doe:secret@big.com;transport=tcp
sip:j.doe@big.com?subject=project
sip:+1-212-555-1212:1234@gateway.com;user=phone
Request-URI To From Location external Request-URI To From Location external
user x x x x x user x x x x x
password x x x password x x x
host x x x x x host x x x x x
tag x x x x user-param x x x x x
tag-param x x x x
maddr-param x x
ttl-param x x
transport-param x x
headers x x headers x x
transport para. x x
Table 2: Use of URL elements for SIP headers, Request-URI and Table 2: Use of URL components for SIP headers, Request-URI and
references references
Examples of SIP URLs are:
sip:j.doe@big.com
sip:j.doe:secret@big.com;transport=tcp
sip:j.doe@big.com?subject=project
sip:+1-212-555-1212:1234@gateway.com;user=phone
sip:1212@gateway.com sip:1212@gateway.com
sip:alice@10.1.2.3 sip:alice@10.1.2.3
sip:alice@example.com;tag=f81d4fae-7dec-11d0-a765-00a0c91e6bf6 sip:alice@example.com;tag=f81d4fae-7dec-11d0-a765-00a0c91e6bf6
sip:alice sip:alice
Within a SIP message, URLs are used to indicate the source and Within a SIP message, URLs are used to indicate the source and
intended destination of a request, redirection addresses and the intended destination of a request, redirection addresses and the
current destination of a request. Normally all these fields will current destination of a request. Normally all these fields will
contain SIP URLs. contain SIP URLs.
skipping to change at page 20, line 19 skipping to change at page 20, line 37
size of 950 bytes, to accommodate packet headers within the size of 950 bytes, to accommodate packet headers within the
SLIP MTU without fragmentation. SLIP MTU without fragmentation.
A SIP message is either a request from a client to a server, or a A SIP message is either a request from a client to a server, or a
response from a server to a client. response from a server to a client.
SIP-message ___ Request | Response SIP-message ___ Request | Response
Both Request (section 4) and Response (section 5) messages use the Both Request (section 4) and Response (section 5) messages use the
generic-message format of RFC 822 [24] for transferring entities (the generic-message format of RFC 822 [24] for transferring entities (the
body of the message). Both types of messages consist of a start- body of the message). Both types of messages consist of a start-line,
line, one or more header fields (also known as "headers"), an empty one or more header fields (also known as "headers"), an empty line
line (i.e., a line with nothing preceding the carriage-return line- (i.e., a line with nothing preceding the carriage-return line-feed
feed ( CRLF)) indicating the end of the header fields, and an (CRLF)) indicating the end of the header fields, and an optional
optional message-body. To avoid confusion with similar-named headers message-body. To avoid confusion with similar-named headers in HTTP,
in HTTP, we refer to the header describing the message body as entity we refer to the header describing the message body as entity headers.
headers. These components are described in detail in the upcoming These components are described in detail in the upcoming sections.
sections.
generic-message = start-line generic-message = start-line
*message-header *message-header
CRLF CRLF
[ message-body ] [ message-body ]
start-line = Request-Line | Section 4.1 start-line = Request-Line | Section 4.1
Status-Line Section 5.1 Status-Line Section 5.1
message-header = *( general-header message-header = ( general-header
| request-header | request-header
| response-header | response-header
| entity-header ) | entity-header )
In the interest of robustness, any leading empty line(s) MUST be In the interest of robustness, any leading empty line(s) MUST be
ignored. In other words, if the Request or Response message begins
with a CRLF, CR, or LF, these characters should be ignored.
4 Request
The Request message format is shown below:
Request = Request-Line ; Section 4.1
*( general-header
| request-header
| entity-header )
CRLF
[ message-body ] ; Section 8
4.1 Request-Line
The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF are allowed
except in the final CRLF sequence.
Request-Line = Method SP Request-URI SP SIP-Version CRLF
4.2 Methods
general-header = Call-ID ; Section 6.12 general-header = Call-ID ; Section 6.12
| CSeq ; Section 6.16 | CSeq ; Section 6.16
| Date ; Section 6.17 | Date ; Section 6.17
| Encryption ; Section 6.18 | Encryption ; Section 6.18
| Expires ; Section 6.19 | Expires ; Section 6.19
| From ; Section 6.20 | From ; Section 6.20
| Record-Route ; Section 6.29 | Record-Route ; Section 6.29
| Timestamp ; Section 6.36 | Timestamp ; Section 6.36
| To ; Section 6.37 | To ; Section 6.37
| Via ; Section 6.40 | Via ; Section 6.40
skipping to change at page 21, line 44 skipping to change at page 22, line 44
| Location ; Section 6.22 | Location ; Section 6.22
| Proxy-Authenticate ; Section 6.26 | Proxy-Authenticate ; Section 6.26
| Retry-After ; Section 6.32 | Retry-After ; Section 6.32
| Server ; Section 6.34 | Server ; Section 6.34
| Unsupported ; Section 6.38 | Unsupported ; Section 6.38
| Warning ; Section 6.41 | Warning ; Section 6.41
| WWW-Authenticate ; Section 6.42 | WWW-Authenticate ; Section 6.42
Table 3: SIP headers Table 3: SIP headers
ignored. In other words, if the Request or Response message begins
with a CRLF, CR, or LF, these characters should be ignored.
4 Request
The Request message format is shown below:
Request = Request-Line ; Section 4.1
*( general-header
| request-header
| entity-header )
CRLF
[ message-body ] ; Section 8
4.1 Request-Line
The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF are allowed
except in the final CRLF sequence.
Request-Line = Method SP Request-URI SP SIP-Version CRLF
4.2 Methods
The methods are defined below. Methods that are not supported by a The methods are defined below. Methods that are not supported by a
proxy or redirect server are treated by that server as if they were proxy or redirect server are treated by that server as if they were
an INVITE method and forwarded accordingly. Methods that are not an OPTIONS method and forwarded accordingly. Methods that are not
supported by a user agent server cause a 501 (Not Implemented) supported by a user agent server or registrar cause a 501 (Not
response to be returned (Section 7). Implemented) response to be returned (Section 7).
Method = "ACK" | "BYE" | "CANCEL" | "INVITE" Method = "ACK" | "BYE" | "CANCEL" | "INVITE"
| "OPTIONS" | "REGISTER" | "OPTIONS" | "REGISTER"
4.2.1 INVITE 4.2.1 INVITE
The INVITE method indicates that the user or service is being The INVITE method indicates that the user or service is being invited
invited to participate in a session. The message body contains a to participate in a session. The message body contains a description
description of the session to which the callee is being invited. For of the session to which the callee is being invited. For two-party
two-party calls, the caller indicates the type of media it is able to calls, the caller indicates the type of media it is able to receive
receive as well as their parameters such as network destination. If as well as their parameters such as network destination. If the
the session description format allows this, it may also indicate session description format allows this, it may also indicate "send-
"send-only" media. A success response indicates in its message body only" media. A success response indicates in its message body which
which media the callee wishes to receive. media the callee wishes to receive.
A server MAY automatically respond to an invitation for a conference A server MAY automatically respond to an invitation for a conference
the user is already participating in, identified either by the SIP the user is already participating in, identified either by the SIP
Call-ID or a globally unique identifier within the session Call-ID or a globally unique identifier within the session
description, with a 200 (OK) response. description, with a 200 (OK) response.
If a user agent receives an INVITE request for an existing Call-ID If a user agent receives an INVITE request for an existing Call-ID
with a higher CSeq sequence number than any previous INVITE for the with a higher CSeq sequence number than any previous INVITE for the
same Call-ID, it MUST check any version identifiers in the session same Call-ID, it MUST check any version identifiers in the session
description or, if there are no version identifiers, the content of description or, if there are no version identifiers, the content of
skipping to change at page 23, line 40 skipping to change at page 24, line 7
requests.) 2xx responses are acknowledged by client user agents, all requests.) 2xx responses are acknowledged by client user agents, all
other final responses by the first proxy or client user agent to other final responses by the first proxy or client user agent to
receive the response. The Via is always initialized to the host that receive the response. The Via is always initialized to the host that
originates the ACK request, i.e., the client user agent after a 2xx originates the ACK request, i.e., the client user agent after a 2xx
response or the first proxy to receive a non-2xx final response. The response or the first proxy to receive a non-2xx final response. The
ACK request is forwarded as the corresponding INVITE request, based ACK request is forwarded as the corresponding INVITE request, based
on its Request-URI. See Section 10 for details. on its Request-URI. See Section 10 for details.
The ACK request MAY contain a message body with the final session The ACK request MAY contain a message body with the final session
description to be used by the callee. If the ACK message body is description to be used by the callee. If the ACK message body is
empty, the callee uses the session description in the INVITE empty, the callee uses the session description in the INVITE request.
request.
This method MUST be supported by SIP proxy, redirect and user agent This method MUST be supported by SIP proxy, redirect and user agent
servers as well as clients. servers as well as clients.
4.2.3 OPTIONS 4.2.3 OPTIONS
The client is being queried as to its capabilities. A server that The server is being queried as to its capabilities. A server that
believes it can contact the user, such as a user agent where the user believes it can contact the user, such as a user agent where the user
is logged in and has been recently active, MAY respond to this is logged in and has been recently active, MAY respond to this
request with a capability set. A called user agent MAY return a request with a capability set. A called user agent MAY return a
status reflecting how it would have responded to an invitation, e.g., status reflecting how it would have responded to an invitation, e.g.,
600 (Busy). 600 (Busy). Such a server SHOULD return an Allow header field
indicating the methods that it supports. Proxy and redirect servers
simply forward the request without indicating their capabilities.
This method MUST be supported by SIP proxy, redirect and user agent This method MUST be supported by SIP proxy, redirect and user agent
servers, registrars and clients. servers, registrars and clients.
4.2.4 BYE 4.2.4 BYE
The user agent client uses BYE to indicate to the server that it The user agent client uses BYE to indicate to the server that it
wishes to abort the call. A BYE request is forwarded like an INVITE wishes to abort the call. A BYE request is forwarded like an INVITE
request. A caller SHOULD issue a BYE request before aborting a call request. A caller SHOULD issue a BYE request before aborting a call
("hanging up"). Note that a BYE request may also be issued by the ("hanging up"). Note that a BYE request may also be issued by the
callee. callee.
If the INVITE request contained a Location header, the callee sends If the INVITE request contained a Location header, the callee MAY
the BYE request to that address rather than the From address. send a BYE request to that address rather than the From address.
This method MUST be supported by proxy servers and SHOULD be This method MUST be supported by proxy servers and SHOULD be
supported by redirect and user agent SIP servers. supported by redirect and user agent SIP servers.
4.2.5 CANCEL 4.2.5 CANCEL
The CANCEL request cancels a pending request with the same Call-ID, The CANCEL request cancels a pending request with the same Call-ID,
To, From and CSeq (sequence number only) header values, but does To, From and CSeq (sequence number only) header values, but does not
not affect a completed request. (A request is considered completed if affect a completed request. (A request is considered completed if the
the server has returned a final status response.) server has returned a final status response.)
A user agent client or proxy client MAY issue a CANCEL request at A user agent client or proxy client MAY issue a CANCEL request at any
any time. A proxy, in particular, MAY choose to send a CANCEL to time. A proxy, in particular, MAY choose to send a CANCEL to
destinations that have not yet returned a final response after it has destinations that have not yet returned a final response after it has
received a 2xx or 6xx response for one or more of the parallel-search received a 2xx or 6xx response for one or more of the parallel-search
requests. A proxy that receives a CANCEL request forwards the requests. A proxy that receives a CANCEL request forwards the request
request to all destinations with pending requests. The Call-ID, To to all destinations with pending requests.
and From in the CANCEL request are identical to those contained in
the request being canceled, but the Via header field is initialized The Call-ID, To, the numeric part of CSeq and From headers in the
to the proxy issuing the CANCEL request. (Thus, responses to this CANCEL request are identical to those in the original request. This
CANCEL request only reach the issuing proxy.) allows a CANCEL request to be matched with the request it cancels.
However, to allow the client to distinguish responses to the CANCEL
from those to the original request, the CSeq Method component is set
to CANCEL. The Via header field is initialized to the proxy issuing
the CANCEL request. (Thus, responses to this CANCEL request only
reach the issuing proxy.)
Once a user agent server has received a CANCEL, it MUST NOT issue a Once a user agent server has received a CANCEL, it MUST NOT issue a
2xx response for the cancelled original request. 2xx response for the cancelled original request.
A redirect server or user agent server returns 200 (OK) if the Call- A redirect or user agent server receiving a CANCEL request responds
ID exists and 481 (Invalid Call-ID) if not, but takes no further with a status of 200 (OK) if the Call-ID exists and a status of 481
action. In particular, any existing call is unaffected. (Invalid Call-ID) if not, but takes no further action. In particular,
any existing call is unaffected.
The BYE request cannot be used to cancel branches of a The BYE request cannot be used to cancel branches of a
parallel search, since several branches may, through parallel search, since several branches may, through
intermediate proxies, find the same user agent server and intermediate proxies, find the same user agent server and
then terminate the call. To terminate a call instead of then terminate the call. To terminate a call instead of
just pending searches, the UAC must use BYE instead of or just pending searches, the UAC must use BYE instead of or
in addition to CANCEL. While CANCEL can terminate any in addition to CANCEL. While CANCEL can terminate any
pending request other than ACK or CANCEL, it is typically pending request other than ACK or CANCEL, it is typically
useful only for INVITE. 200 responses to INVITE and 200 useful only for INVITE. 200 responses to INVITE and 200
responses to CANCEL are distinguished by the method in the responses to CANCEL are distinguished by the method in the
Cseq header field, so there is no ambiguity. Cseq header field, so there is no ambiguity.
This method MUST be supported by proxy servers and SHOULD be This method MUST be supported by proxy servers and SHOULD be
supported by all other SIP server types. supported by all other SIP server types.
4.2.6 REGISTER 4.2.6 REGISTER
A client uses the REGISTER method to register the address listed in A client uses the REGISTER method to register the address listed in
the To header with a SIP server. the To header with a SIP server.
A user agent SHOULD register with a local server on startup by A user agent MAY register with a local server on startup by sending a
sending a REGISTER request to the well-known "all SIP servers" REGISTER request to the well-known "all SIP servers" multicast
multicast address, 224.0.1.75, with a time-to-live value of 1. SIP address "sip.mcast.net" (224.0.1.75), with a time-to-live value of 1.
user agents on the same subnet MAY listen to that address and use it SIP user agents on the same subnet MAY listen to that address and use
to become aware of the location of other local users [16]; however, it to become aware of the location of other local users [16];
they do not respond to the request. however, they do not respond to the request. A user agent MAY also
be configured with the address of a registrar server to which it
sends a REGISTER request upon startup.
The REGISTER request-header fields are defined as follows. We define The meaning of the REGISTER request-header fields is defined as
"address-of-record" as the SIP address that the registry knows the follows. We define "address-of-record" as the SIP address that the
registrand, typically of the form "user@domain" rather than registry knows the registrand, typically of the form "user@domain"
"user@host". In third-party registration, the entity issuing the rather than "user@host". In third-party registration, the entity
request is different from the entity being registered. issuing the request is different from the entity being registered.
To: The To header field contains the address-of-record whose To: The To header field contains the address-of-record whose
registration is to be created or updated. registration is to be created or updated.
From: The From header field contains the address-of-record of the From: The From header field contains the address-of-record of the
person responsible for the registration. For first-party person responsible for the registration. For first-party
registration, it is identical to the To header field value. registration, it is identical to the To header field value.
Request-URI: The Request-URI names the destination of the Request-URI: The Request-URI names the destination of the
registration request, i.e., the domain of the registrar. The registration request, i.e., the domain of the registrar. The
user name MUST be empty. Generally, the domains in the user name MUST be empty. Generally, the domains in the Request-
Request-URI and the To header have the same value; however, it URI and the To header have the same value; however, it is
is possible to register as a "visitor", while maintaining one's possible to register as a "visitor", while maintaining one's
name. For example, a traveller sip:alice@acme.com ( To) may name. For example, a traveller sip:alice@acme.com ( To) may
register under the Request-URI sip:@atlanta.ayh.org , with the register under the Request-URI sip:@atlanta.ayh.org , with the
former as the To field and the latter as the Request-URI. The former as the To field and the latter as the Request-URI. The
request is no longer forwarded once it reached the server whose request is no longer forwarded once it reached the server whose
authoritative domain is the one listed in the Request-URI. authoritative domain is the one listed in the Request-URI.
Location: The request MUST contain a Location header field; requests Location: The request MAY contain a Location header field; future
for the Request-URI will be directed to the address(es) given. non-REGISTER requests for the URI given in the To field will be
It is RECOMMENDED that user agents include SIP URLs with both directed to the address(es) given in the Location header. It is
UDP and TCP transport parameters in their registration. If the RECOMMENDED that user agents include SIP URLs with both UDP and
TCP transport parameters in their registration. If the
registration contains a Location field whose URL includes a registration contains a Location field whose URL includes a
transport parameter, future requests will use that protocol. transport parameter, future requests will use that protocol.
Otherwise, requests use the same transport protocol as used by Otherwise, requests use the same transport protocol as used by
the registration. However, a multicast REGISTER request still the registration. However, a multicast REGISTER request still
causes future requests to be unicast unless the maddr URL causes future requests to be unicast unless the maddr URL
parameter explicitly requests otherwise. If the Location header parameter explicitly requests otherwise. If the Location header
does not contain a port number, the default SIP port number is does not contain a port number, the default SIP port number is
used for future requests. used for future requests.
We cannot require that registration and subsequent INVITE We cannot require that registration and subsequent INVITE
requests use the same transport protocol, as multicast requests use the same transport protocol, as multicast
registrations may be quite useful. registrations may be quite useful.
Registrations are additive, but all current locations must share the If the request does not contain a Location header, the registration
same action value. A proxy server ignores the q parameter, while a remains unchanged. Registrations that differ in one or more of host,
redirect server simply returns the parameter in its Location header. port, transport or maddr from an existing registration are added to
the list of registrations. If these parameters are the same as an
existing registration, the new registration replaces the old one if
it has a higher q value or, for the same value of q, if the ttl value
is higher. All current locations MUST share the same action value.
Registrations that have a different action than current registrations
for the same user are rejected with status of 409 (Conflict).
A proxy server ignores the q parameter in processing non-REGISTER
requests, while a redirect server simply returns the parameter in its
Location header.
Having the proxy server interpret the q parameter is not Having the proxy server interpret the q parameter is not
sufficient to guide proxy behavior, as it is not clear, for sufficient to guide proxy behavior, as it is not clear, for
example, how long it should wait between trying addresses. example, how long it should wait between trying addresses.
If the registration is changed while a user agent or proxy server If the registration is changed while a user agent or proxy server
processes an invitation, the new information should be used. processes an invitation, the new information should be used.
This allows a service known as "directed pick-up". This allows a service known as "directed pick-up".
A server SHOULD silently drop the registration after one hour, unless A server SHOULD silently drop the registration after one hour, unless
refreshed by the client. A client may request a lower or higher refreshed by the client. A client may request a lower or higher
refresh interval through the Expires header (Section 6.19). Based on refresh interval through the Expires header (Section 6.19). Based on
this request and its configuration, the server chooses the expiration this request and its configuration, the server chooses the expiration
interval and indicates it through the Expires header in the interval and indicates it through the Expires header in the response.
response. A single address (if host-independent) may be registered A single address (if host-independent) may be registered from several
from several different clients. different clients.
A client cancels an existing registration by sending a REGISTER A client cancels an existing registration by sending a REGISTER
request with an expiration time ( Expires) of zero seconds for a request with an expiration time ( Expires) of zero seconds for a
particular Location or the wildcard Location designated by a "*" particular Location or the wildcard Location designated by a "*" for
for all registrations. all registrations. Registrations are matched based on the user, host,
port and maddr parameters.
The server SHOULD return the current list of registrations in the 200 The server SHOULD return the current list of registrations in the 200
response as Location header fields. response as Location header fields.
It is particularly important that REGISTER requests are It is particularly important that REGISTER requests are authenticated
authenticated since they allow to redirect future requests. since they allow to redirect future requests.
Beyond its use as a simple location service, this method is Beyond its use as a simple location service, this method is
needed if there are several SIP servers on a single host. needed if there are several SIP servers on a single host.
In that case, only one of the servers can use the default In that case, only one of the servers can use the default
port number. Each server that cannot would register with a port number. Each server that cannot would register with a
server for the administrative domain. Since a client may server for the administrative domain. Since a client may
not have easy access to the host address or port number, not have easy access to the host address or port number,
using the source address and port from the request itself using the source address and port from the request itself
seems simpler. seems simpler.
Support of this method is RECOMMENDED. Support of this method is RECOMMENDED.
4.3 Request-URI 4.3 Request-URI
The Request-URI field is a SIP URL as described in Section 2 or a The Request-URI field is a SIP URL as described in Section 2 or a
general URI. It indicates the user or service to which this request general URI. It indicates the user or service to which this request
is being addressed. Unlike the To field, the Request-URI field may is being addressed. Unlike the To field, the Request-URI field may be
be re-written by proxies. re-written by proxies.
The SIP-URL MUST NOT contain the transport-param, maddr-param, When used as a Request-URI, a SIP-URL MUST NOT contain the
ttl-param, or headers elements. A server that receives a SIP-URL transport-param, maddr-param, ttl-param, or headers elements. A
with these elements removes them before further processing. server that receives a SIP-URL with these elements removes them
before further processing.
Typically, the UAC sets the Request-URI and To to the same Typically, the UAC sets the Request-URI and To to the same
SIP URL, presumed to remain unchanged over long time SIP URL, presumed to remain unchanged over long time
periods. However, if the UAC has cached a more direct path periods. However, if the UAC has cached a more direct path
to the callee, e.g., from the Location header of a to the callee, e.g., from the Location header of a response
response to a previous request, the To would still contain to a previous request, the To would still contain the
the long-term, "public" address, while the Request-URI long-term, "public" address, while the Request-URI would be
would be set to the cached address. set to the cached address.
Proxy and redirect servers may use the information in the Request-URI Proxy and redirect servers may use the information in the Request-URI
and request header fields to handle the request and possibly rewrite and request header fields to handle the request and possibly rewrite
the Request-URI. For example, a request addressed to the generic the Request-URI. For example, a request addressed to the generic
address sip:sales@acme.com might be proxied to the particular person, address sip:sales@acme.com might be proxied to the particular person,
e.g., sip:bob@ny.acme.com , with the To remaining as sales@acme.com e.g., sip:bob@ny.acme.com , with the To remaining as sales@acme.com
ny.acme.com , Bob may have designated Alice as the temporary ny.acme.com , Bob may have designated Alice as the temporary
substitute. substitute.
The host part of the Request-URI typically agrees with one of the The host part of the Request-URI typically agrees with one of the
skipping to change at page 30, line 4 skipping to change at page 30, line 33
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version (Section 4.3.1) followed by a numeric of the protocol version (Section 4.3.1) followed by a numeric
Status-Code and its associated textual phrase, with each element Status-Code and its associated textual phrase, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence. final CRLF sequence.
Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF
5.1.1 Status Codes and Reason Phrases 5.1.1 Status Codes and Reason Phrases
The Status-Code is a 3-digit integer result code that indicates the The Status-Code is a 3-digit integer result code that indicates the
outcome of the attempt to understand and satisfy the request. The outcome of the attempt to understand and satisfy the request. The
Reason-Phrase is intended to give a short textual description of the Reason-Phrase is intended to give a short textual description of the
Status-Code. The Status-Code is intended for use by automata, Status-Code. The Status-Code is intended for use by automata, whereas
whereas the Reason-Phrase is intended for the human user. The client the Reason-Phrase is intended for the human user. The client is not
is not required to examine or display the Reason-Phrase. required to examine or display the Reason-Phrase.
Status-Code = Informational Fig. 5 Status-Code = Informational Fig. 5
| Success Fig. 5 | Success Fig. 5
| Redirection Fig. 6 | Redirection Fig. 6
| Client-Error Fig. 7 | Client-Error Fig. 7
| Server-Error Fig. 8 | Server-Error Fig. 8
| Global-Failure Fig. 9 | Global-Failure Fig. 9
| extension-code | extension-code
extension-code = 3DIGIT extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF> Reason-Phrase = *<TEXT, excluding CR, LF>
skipping to change at page 32, line 4 skipping to change at page 32, line 25
Figure 5: Informational and success status codes Figure 5: Informational and success status codes
Redirection = "300" ; Multiple Choices Redirection = "300" ; Multiple Choices
| "301" ; Moved Permanently | "301" ; Moved Permanently
| "302" ; Moved Temporarily | "302" ; Moved Temporarily
| "303" ; See Other | "303" ; See Other
| "305" ; Use Proxy | "305" ; Use Proxy
| "380" ; Alternative Service | "380" ; Alternative Service
Figure 6: Redirection status codes Figure 6: Redirection status codes
6 Header Field Definitions
SIP header fields are similar to HTTP header fields in both syntax
and semantics [H4.2, H14]. In general, the ordering of the header
fields is not of importance (with the exception of Via fields, see
below). The only requirement is that header fields which are hop-by-
hop MUST appear before any header fields which are end-to-end.
Proxies MUST NOT reorder or otherwise modify header fields other than
by adding a new Via or other hop-by-hop field. Proxies MUST NOT, for
example, change how header fields are broken across lines. This
allows an authentication field to be added after the Via fields that
will not be invalidated by proxies.
Client-Error = "400" ; Bad Request Client-Error = "400" ; Bad Request
| "401" ; Unauthorized | "401" ; Unauthorized
| "402" ; Payment Required | "402" ; Payment Required
| "403" ; Forbidden | "403" ; Forbidden
| "404" ; Not Found | "404" ; Not Found
| "405" ; Method Not Allowed | "405" ; Method Not Allowed
| "406" ; Not Acceptable | "406" ; Not Acceptable
| "407" ; Proxy Authentication Required | "407" ; Proxy Authentication Required
| "408" ; Request Timeout | "408" ; Request Timeout
| "409" ; Conflict | "409" ; Conflict
skipping to change at page 32, line 38 skipping to change at page 33, line 39
Server-Error = "500" ; Internal Server Error Server-Error = "500" ; Internal Server Error
| "501" ; Not Implemented | "501" ; Not Implemented
| "502" ; Bad Gateway | "502" ; Bad Gateway
| "503" ; Service Unavailable | "503" ; Service Unavailable
| "504" ; Gateway Timeout | "504" ; Gateway Timeout
| "505" ; SIP Version not supported | "505" ; SIP Version not supported
Figure 8: Server error status codes Figure 8: Server error status codes
6 Header Field Definitions The header fields required, optional and not applicable for each
method are listed in Table 4. The table uses "o" to indicate
SIP header fields are similar to HTTP header fields in both syntax optional, "m" mandatory and "-" for not applicable. A "*" indicates
and semantics [H4.2, H14]. In general the ordering of the header that the header fields are needed only if message body is not empty:
fields is not of importance (with the exception of Via fields, see The Content-Type and Content-Length headers are required when there
below), but proxies MUST NOT reorder or otherwise modify header is a valid message body (of non-zero length) associated with the
Global-Failure | "600" ; Busy Global-Failure | "600" ; Busy
| "603" ; Decline | "603" ; Decline
| "604" ; Does not exist anywhere | "604" ; Does not exist anywhere
| "606" ; Not Acceptable | "606" ; Not Acceptable
Figure 9: Global failure status codes Figure 9: Global failure status codes
fields other than by adding a new Via or other hop-by-hop field.
Proxies MUST NOT, for example, change how header fields are broken
across lines. This allows an authentication field to be added after
the Via fields that will not be invalidated by proxies.
The header fields required, optional and not applicable for each
method are listed in Table 4. The table uses "o" to indicate
optional, "m" mandatory and "-" for not applicable. A "*" indicates
that the header fields are needed only if message body is not empty:
The Content-Type and Content-Length headers are required when there
is a valid message body (of non-zero length) associated with the
message (Section 8). message (Section 8).
The "type" column describes the request and response types for which The "type" column describes the request and response types for which
the header field may be used. A numeric value indicates the status the header field may be used. A numeric value indicates the status
code for a response, while "R" refers to any request header, "r" to code for a response, while "R" refers to any request header, "r" to
any response header. "g" and "e" designate general (Section 6.1) and any response header. "g" and "e" designate general (Section 6.1) and
entity header (Section 6.2) fields, respectively. entity header (Section 6.2) fields, respectively.
The "enc." column describes whether this message header may be The "enc." column describes whether this message header may be
encrypted end-to-end. A "n" designates fields that MUST NOT be encrypted end-to-end. A "n" designates fields that MUST NOT be
skipping to change at page 34, line 4 skipping to change at page 34, line 36
Other headers may be added as required; a server MAY ignore optional Other headers may be added as required; a server MAY ignore optional
headers that it does not understand. A compact form of these header headers that it does not understand. A compact form of these header
fields is also defined in Section 9 for use over UDP when the request fields is also defined in Section 9 for use over UDP when the request
has to fit into a single packet and size is an issue. has to fit into a single packet and size is an issue.
Table 5 in Appendix A indicates which system components should be Table 5 in Appendix A indicates which system components should be
capable of parsing which header fields. capable of parsing which header fields.
6.1 General Header Fields 6.1 General Header Fields
type enc. e-e ACK BYE CAN INV OPT REG
________________________________________________________________________________
Accept R e - - - o o o
Accept-Encoding R e - - - o o o
Accept-Language R n e - o o o o o
Allow 405 e o o o o o o
Authorization R e o o o o o o
Call-ID g n e m m m m m m
Content-Encoding e e * - - * * *
Content-Length e e m - - m m m
Content-Type e e * - - * * *
CSeq g n e m m m m m o
Date g e o o o o o o
Encryption g n e o o o o o o
Expires g e - - - o o o
From g e m m m m m m
Hide R n h o o o o o o
Location R e o - - o - m
Location 2xx e - - - o o -
Location 3xx e - o - o o o
Location 485 e - o - o o o
Max-Forwards R n e o o o o o o
Organization R c e - - - o o o
Proxy-Authenticate 407 n h o o o o o o
Proxy-Authorization R n h o o o o o o
Proxy-Require R n h o o o o o o
Priority R c e - - - o - -
Require R n e o o o o o o
Retry-After R c e - - - - - o
Retry-After 600,603 c e - - - o - -
Response-Key R c e - o o o o o
Record-Route R h o o o o o o
Record-Route 2xx h o o o o o o
Route R h - o o o o o
Server r c e o o o o o o
Subject R c e - - - o - -
Timestamp g e o o o o o o
To g n e m m m m m m
Unsupported 420 e o o o o o o
User-Agent R c e o o o o o o
Via g n e m m m m m m
Warning r e o o o o o o
WWW-Authenticate 401 c e o o o o o o
Table 4: Summary of header fields
General header fields apply to both request and response messages. General header fields apply to both request and response messages.
The general-header field names can be extended reliably only in The general-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields may be given the semantics of general experimental header fields may be given the semantics of general
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as be general-header fields. Unrecognized header fields are treated as
entity-header fields. entity-header fields.
6.2 Entity Header Fields 6.2 Entity Header Fields
The entity-header fields define meta-information about the message- The entity-header fields define meta-information about the message-
body or, if no body is present, about the resource identified by the body or, if no body is present, about the resource identified by the
request. The term "entity header" is an HTTP 1.1 term where the request. The term "entity header" is an HTTP 1.1 term where the
response body may contain a transformed version of the message body. response body may contain a transformed version of the message body.
The original message body is referred to as the "entity". We retain The original message body is referred to as the "entity". We retain
the same terminology for header fields but usually refer to the the same terminology for header fields but usually refer to the
"message body" rather then the entity as the two are the same in SIP. "message body" rather then the entity as the two are the same in SIP.
6.3 Request Header Fields 6.3 Request Header Fields
skipping to change at page 36, line 4 skipping to change at page 35, line 42
further access to the resource identified by the Request-URI. further access to the resource identified by the Request-URI.
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response- experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as be response-header fields. Unrecognized header fields are treated as
entity-header fields. entity-header fields.
6.5 End-to-end and Hop-by-hop Headers 6.5 End-to-end and Hop-by-hop Headers
End-to-end headers must be transmitted unmodified across all proxies, End-to-end headers must be transmitted unmodified across all proxies,
while hop-by-hop headers may be modified or added by proxies. while hop-by-hop headers may be modified or added by proxies.
6.6 Header Field Format 6.6 Header Field Format
Header fields ( general-header, request-header, response-header, and Header fields ( general-header, request-header, response-header, and
entity-header) follow the same generic header format as that given in entity-header) follow the same generic header format as that given in
Section 3.1 of RFC 822 [24]. Each header field consists of a name Section 3.1 of RFC 822 [24]. Each header field consists of a name
followed by a colon (":") and the field value. Field names are case- followed by a colon (":") and the field value. Field names are case-
type enc. e-e ACK BYE CAN INV OPT REG
_____________________________________________________________________________________________
Accept R e - - - o o o
Accept-Encoding R e - - - o o o
Accept-Language R n e - o o o o o
Allow 200 e - - - - m -
Allow 405 e o o o o o o
Authorization R e o o o o o o
Call-ID g n e m m m m m m
Content-Encoding e e * - - * * *
Content-Length e e m - - m m m
Content-Type e e * - - * * *
CSeq g n e m m m m m m
Date g e o o o o o o
Encryption g n e o o o o o o
Expires g e - - - o - o
From g n e m m m m m m
Hide R n h o o o o o o
Location R e o - - o o o
Location 1xx e - - - o o -
Location 2xx e - - - o o o
Location 3xx e - o - o o o
Location 485 e - o - o o o
Max-Forwards R n e o o o o o o
Organization g c h - - - o o o
Proxy-Authenticate 407 n h o o o o o o
Proxy-Authorization R n h o o o o o o
Proxy-Require R n h o o o o o o
Priority R c e - - - o - -
Require R e o o o o o o
Retry-After R c e - - - - - o
Retry-After 404,480,503,600,603 c e o o o o o o
Response-Key R c e - o o o o o
Record-Route R h o o o o o o
Record-Route 2xx h o o o o o o
Route R h - o o o o o
Server r c e o o o o o o
Subject R c e - - - o - -
Timestamp g e o o o o o o
To g n e m m m m m m
Unsupported 420 e o o o o o o
User-Agent g c e o o o o o o
Via g n e m m m m m m
Warning r e o o o o o o
WWW-Authenticate 401 c e o o o o o o
Table 4: Summary of header fields
insensitive. The field value may be preceded by any amount of leading insensitive. The field value may be preceded by any amount of leading
white space (LWS), though a single space (SP) is preferred. Header white space (LWS), though a single space (SP) is preferred. Header
fields can be extended over multiple lines by preceding each extra fields can be extended over multiple lines by preceding each extra
line with at least one SP or horizontal tab (HT). Applications SHOULD line with at least one SP or horizontal tab (HT). Applications SHOULD
follow HTTP "common form" when generating these constructs, since follow HTTP "common form" when generating these constructs, since
there might exist some implementations that fail to accept anything there might exist some implementations that fail to accept anything
beyond the common forms. beyond the common forms.
message-header = field-name ":" [ field-value ] CRLF message-header = field-name ":" [ field-value ] CRLF
field-name = token field-name = token
skipping to change at page 37, line 34 skipping to change at page 38, line 27
Example: Example:
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
6.10 Allow 6.10 Allow
See [H14.7]. The Allow entity-header field lists the set of methods See [H14.7]. The Allow entity-header field lists the set of methods
supported by the resource identified by the Request-URI. The purpose supported by the resource identified by the Request-URI. The purpose
of this field is strictly to inform the recipient of valid methods of this field is strictly to inform the recipient of valid methods
associated with the resource. An Allow header field MUST be present associated with the resource. An Allow header field MUST be present
in a 405 (Method Not Allowed) response. in a 405 (Method Not Allowed) response and SHOULD be present in an
OPTIONS response.
6.11 Authorization 6.11 Authorization
See [H14.8]. See [H14.8].
A user agent that wishes to authenticate itself with a server -- A user agent that wishes to authenticate itself with a server --
usually, but not necessarily, after receiving a 401 response -- MAY usually, but not necessarily, after receiving a 401 response -- MAY
do so by including an Authorization request-header field with the do so by including an Authorization request-header field with the
request. The Authorization field value consists of credentials request. The Authorization field value consists of credentials
containing the authentication information of the user agent for the containing the authentication information of the user agent for the
skipping to change at page 38, line 25 skipping to change at page 39, line 17
INVITE request. If the user is already a member of the conference and INVITE request. If the user is already a member of the conference and
the conference parameters contained in the session description have the conference parameters contained in the session description have
not changed, a callee user agent server MAY silently accept the call, not changed, a callee user agent server MAY silently accept the call,
regardless of the Call-ID. An invitation for an existing Call-ID or regardless of the Call-ID. An invitation for an existing Call-ID or
session may change the parameters of the conference. A client session may change the parameters of the conference. A client
application MAY decide to simply indicate to the user that the application MAY decide to simply indicate to the user that the
conference parameters have been changed and accept the invitation conference parameters have been changed and accept the invitation
automatically or it MAY require user confirmation. automatically or it MAY require user confirmation.
A user may be invited to the same conference or call using several A user may be invited to the same conference or call using several
different Call-IDs. If desired, the client may use identifiers different Call-IDs. If desired, the client may use identifiers within
within the session description to detect this duplication. For the session description to detect this duplication. For example, SDP
example, SDP contains a session id and version number in the origin ( contains a session id and version number in the origin (o) field.
o) field.
The REGISTER and OPTIONS methods use the Call-ID value to The REGISTER and OPTIONS methods use the Call-ID value to
unambiguously match requests and responses. All REGISTER requests unambiguously match requests and responses. All REGISTER requests
issued by a single client MUST use the same Call-ID. issued by a single client MUST use the same Call-ID.
The Call-ID may be any string consisting of the unreserved URI
characters that can be guaranteed to be globally unique for the
duration of the request. Call-IDs are case-sensitive and are not
URL-encoded.
Since the Call-ID is generated by and for SIP, there is no Since the Call-ID is generated by and for SIP, there is no
reason to deal with the complexity of URL-encoding and reason to deal with the complexity of URL-encoding and
case-ignoring string comparison. case-ignoring string comparison.
Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host
local-id = *uric local-id = *uric
host MUST be either a fully qualified domain name or a globally host MUST be either a fully qualified domain name or a globally
routable IP address, while the local-id is a random identifier routable IP address, while the local-id is a random identifier
unique within host. The use of a UUID as local-id is OPTIONAL. The consisting of URI characters that is unique within host. It MUST NOT
UUID is a version-4 (random) UUID [19]. be reused for a different call. Call-IDs are case-sensitive. The
use of a UUID as local-id is OPTIONAL. The UUID is a version-4
(random) UUID [19].
Using cryptographically random identifiers provides some Using cryptographically random identifiers provides some
protection against session hijacking. Call-ID, To and protection against session hijacking. Call-ID, To and From
From are needed to identify a call leg call leg matters in are needed to identify a call leg calls with third-party
calls with third-party control. control.
Example: Example:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
6.13 Content-Encoding 6.13 Content-Encoding
The Content-Encoding entity-header field is used as a modifier to The Content-Encoding entity-header field is used as a modifier to the
the media-type. When present, its value indicates what additional media-type. When present, its value indicates what additional content
content codings have been applied to the entity-body, and thus what codings have been applied to the entity-body, and thus what decoding
decoding mechanisms MUST be applied in order to obtain the media-type mechanisms MUST be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing primarily used to allow a document to be compressed without losing
the identity of its underlying media type. See [H14.12]. the identity of its underlying media type. See [H14.12].
6.14 Content-Length 6.14 Content-Length
The Content-Length entity-header field indicates the size of the The Content-Length entity-header field indicates the size of the
message-body, in decimal number of octets, sent to the recipient. message-body, in decimal number of octets, sent to the recipient.
Content-Length = "Content-Length" ":" 1*DIGIT Content-Length = "Content-Length" ":" 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
Applications MUST use this field to indicate the size of the Applications SHOULD use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the message-body to be transferred, regardless of the media type of the
entity. Any Content-Length greater than or equal to zero is a valid entity. Any Content-Length greater than or equal to zero is a valid
value. If no body is present in a message, then the Content-Length value. If no body is present in a message, then the Content-Length
header MUST be set to zero. If a server receives a message without header MUST be set to zero. If a server receives a UDP request
Content-Length, it MUST assume it to be zero. Section 8 describes how without Content-Length, it MUST assume that the request encompasses
to determine the length of the message body. the remainder of the packet. If a response does not contain a
Content-Length, the client assumes that it encompasses the remainder
of the UDP packet or the data until the TCP connection is closed, as
applicable. Section 8 describes how to determine the length of the
message body.
6.15 Content-Type 6.15 Content-Type
The Content-Type entity-header field indicates the media type of the
message-body sent to the recipient. The media-type element is
defined in [H3.7].
Content-Type = "Content-Type" ":" media-type The Content-Type entity-header field indicates the media type of the
message-body sent to the recipient. The media-type element is defined
in [H3.7].
Content-Type = ( "Content-Type" ":" media-type
Examples of this header field are Examples of this header field are
Content-Type: application/sdp Content-Type: application/sdp
Content-Type: text/html; charset=ISO-8859-4 Content-Type: text/html; charset=ISO-8859-4
6.16 CSeq 6.16 CSeq
Clients MUST add the CSeq (command sequence) general-header field to Clients MUST add the CSeq (command sequence) general-header field to
every request. A CSeq request header field contains a single decimal every request. A CSeq request header field contains a single decimal
sequence number chosen by the requesting client, unique within a sequence number chosen by the requesting client, unique within a
single value of Call-ID. The sequence number MUST be expressible as single value of Call-ID. The sequence number MUST be expressible as a
a 32-bit unsigned integer. The initial value of the sequence number 32-bit unsigned integer. The initial value of the sequence number is
is arbitrary, but MUST be less than 2**31. Consecutive requests that arbitrary, but MUST be less than 2**31. Consecutive requests that
differ in request method, headers or body, but have the same Call-ID differ in request method, headers or body, but have the same Call-ID
MUST contain strictly monotonically increasing and contiguous MUST contain strictly monotonically increasing and contiguous
sequence numbers; sequence numbers do not wrap around. sequence numbers; sequence numbers do not wrap around.
Retransmissions of the same request carry the same sequence number, Retransmissions of the same request carry the same sequence number,
but an INVITE with a different message body or different header but an INVITE with a different message body or different header
fields (a "re-invitation") acquires a new, higher sequence number. A fields (a "re-invitation") acquires a new, higher sequence number. A
server MUST echo the CSeq value from the request in its response. If server MUST echo the CSeq value from the request in its response. If
the Method value is missing, the server fills it in appropriately. the Method value is missing, the server fills it in appropriately.
The ACK and CANCEL requests MUST contain the same CSeq value as The ACK and CANCEL requests MUST contain the same CSeq value as the
the INVITE request that it refers to, while a BYE request INVITE request that it refers to, while a BYE request cancelling an
cancelling an invitation MUST have a higher sequence number. invitation MUST have a higher sequence number.
A user agent server MUST remember the highest sequence number for any A user agent server MUST remember the highest sequence number for any
INVITE request with the same Call-ID value. The server MUST respond INVITE request with the same Call-ID value. The server MUST respond
to, but ignore any INVITE request with a lower sequence number. to, but ignore any INVITE request with a lower sequence number.
All requests spawned in a parallel search have the same CSeq value All requests spawned in a parallel search have the same CSeq value as
as the request triggering the parallel search. the request triggering the parallel search.
CSeq = "CSeq" ":" 1*DIGIT Method CSeq = "CSeq" ":" 1*DIGIT Method
Strictly speaking, CSeq header fields are needed for any Strictly speaking, CSeq header fields are needed for any
SIP request that can be cancelled by a BYE or CANCEL SIP request that can be cancelled by a BYE or CANCEL
request or where a client can issue several requests for request or where a client can issue several requests for
the same Call-ID in close succession. Without a sequence the same Call-ID in close succession. Without a sequence
number, the response to an INVITE could be mistaken for number, the response to an INVITE could be mistaken for the
the response to the cancellation ( BYE or CANCEL). Also, response to the cancellation (BYE or CANCEL). Also, if the
if the network duplicates packets or if an ACK is delayed network duplicates packets or if an ACK is delayed until
until the server has sent an additional response, the the server has sent an additional response, the client
client could interpret an old response as the response to a could interpret an old response as the response to a re-
re-invitation issued shortly thereafter. Using CSeq also invitation issued shortly thereafter. Using CSeq also makes
makes it easy for the server to distinguish different it easy for the server to distinguish different versions of
versions of an invitation, without comparing the message an invitation, without comparing the message body.
body.
The Method value allows the client to distinguish the response to an The Method value allows the client to distinguish the response to an
INVITE request from that of a CANCEL response. CANCEL requests can INVITE request from that of a CANCEL response. CANCEL requests can be
be generated by proxies; if they were to increase the sequence generated by proxies; if they were to increase the sequence number,
number, it might conflict with a later request issued by the user it might conflict with a later request issued by the user agent for
agent for the same call. the same call.
With a length of 32 bits, a server could generate, within a single With a length of 32 bits, a server could generate, within a single
call, one request a second for about 136 years before needing to wrap call, one request a second for about 136 years before needing to wrap
around. The initial value of the sequence number is chosen so that around. The initial value of the sequence number is chosen so that
subsequent requests within the same call will not wrap around. A subsequent requests within the same call will not wrap around. A
non-zero initial value allows to use a time-based initial sequence non-zero initial value allows to use a time-based initial sequence
number, which protects against ambiguities when clients are re- number, which protects against ambiguities when clients are re-
invited to the same call after rebooting. A client could, for invited to the same call after rebooting. A client could, for
example, choose the 31 most significant bits of a 32-bit second clock example, choose the 31 most significant bits of a 32-bit second clock
as an initial sequence number. as an initial sequence number.
skipping to change at page 42, line 9 skipping to change at page 42, line 45
General header field. See [H14.19]. General header field. See [H14.19].
The Date header field can be used by simple end systems The Date header field can be used by simple end systems
without a battery-backed clock to acquire a notion of without a battery-backed clock to acquire a notion of
current time. current time.
6.18 Encryption 6.18 Encryption
The Encryption general-header field specifies that the content has The Encryption general-header field specifies that the content has
been encrypted. Section 12 describes the overall SIP security been encrypted. Section 13 describes the overall SIP security
architecture and algorithms. This header field is intended for end- architecture and algorithms. This header field is intended for end-
to-end encryption of requests and responses. Requests are encrypted to-end encryption of requests and responses. Requests are encrypted
with a public key belonging to the entity named in the To header with a public key belonging to the entity named in the To header
field. Responses are encrypted with the public key conveyed in the field. Responses are encrypted with the public key conveyed in the
Response-Key header field. Response-Key header field.
SIP chose not to adopt HTTP's Content-Transfer-Encoding SIP chose not to adopt HTTP's Content-Transfer-Encoding
header because the encrypted body may contain additional header because the encrypted body may contain additional
SIP header fields as well as the body of the message. SIP header fields as well as the body of the message.
skipping to change at page 42, line 43 skipping to change at page 43, line 35
listed in the From message header, only that the sender listed in the From message header, only that the sender
used the recipients public key. However, proxies will not used the recipients public key. However, proxies will not
be able to modify the request or response. be able to modify the request or response.
Encryption = "Encryption" ":" encryption-scheme 1*SP Encryption = "Encryption" ":" encryption-scheme 1*SP
#encryption-params #encryption-params
encryption-scheme = token encryption-scheme = token
encryption-params = token "=" ( token | quoted-string ) encryption-params = token "=" ( token | quoted-string )
The token indicates the form of encryption used; it is The token indicates the form of encryption used; it is
described in section 12. described in section 13.
The following example for a message encrypted with ASCII-armored PGP The following example for a message encrypted with ASCII-armored PGP
was generated by applying "pgp -ea" to the payload to be encrypted. was generated by applying "pgp -ea" to the payload to be encrypted.
INVITE sip:watson@boston.bell-telephone.com SIP/2.0 INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
From: <sip:a.g.bell@bell-telephone.com> From: <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com> To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com Call-ID: 187602141351@worcester.bell-telephone.com
Content-Length: 885 Content-Length: 885
skipping to change at page 43, line 40 skipping to change at page 44, line 31
"hiding" header fields will reach the same destination as an "hiding" header fields will reach the same destination as an
otherwise identical un-encrypted request. otherwise identical un-encrypted request.
6.19 Expires 6.19 Expires
The Expires entity-header field gives the date and time after which The Expires entity-header field gives the date and time after which
the message content expires. the message content expires.
This header field is currently defined only for the REGISTER and This header field is currently defined only for the REGISTER and
INVITE methods. For REGISTER, it is a request and response-header INVITE methods. For REGISTER, it is a request and response-header
field and allows the client to indicate how long the registration is field. In a REGISTER request, the client indicates how long it wishes
to be valid; the server uses it to indicate when the client has to the registration to be valid. In the response, the server indicates
re-register the addresses contained in the request. The server's the earliest expiration time of all registrations. The server MAY
choice overrides that of the client. The server MAY choose a shorter choose a shorter time interval than that requested by the client, but
time interval than that requested by the client, but SHOULD NOT SHOULD NOT choose a longer one.
choose a longer one.
For INVITE, it is a request and response-header field. In a request, For INVITE, it is a request and response-header field. In a request,
the callee can limit the validity of an invitation. For example, if a the callee can limit the validity of an invitation. For example, if a
client wants to limit how long a search should take at most or when a client wants to limit how long a search should take at most or when a
conference invitation is time-limited. A user interface may take this conference invitation is time-limited. A user interface may take this
as a hint to leave the invitation window on the screen even if the as a hint to leave the invitation window on the screen even if the
user is not currently at the workstation. This also limits the user is not currently at the workstation. This also limits the
duration of a search. If the request expires before the search duration of a search. If the request expires before the search
completes, the proxy returns a 408 (Request Timeout) status. In a 302 completes, the proxy returns a 408 (Request Timeout) status. In a 302
(Moved Temporarily) response, a server can advise the client of the (Moved Temporarily) response, a server can advise the client of the
skipping to change at page 44, line 26 skipping to change at page 45, line 17
Expires = "Expires" ":" ( HTTP-date | delta-seconds ) Expires = "Expires" ":" ( HTTP-date | delta-seconds )
Two examples of its use are Two examples of its use are
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
Expires: 5 Expires: 5
6.20 From 6.20 From
Requests and responses MUST contain a From general-header field, Requests and responses MUST contain a From general-header field,
indicating the initiator of the request. The server copies the To and indicating the initiator of the request. The From field MAY contain
From header fields from the request to the response. The optional the Tag parameter. The server copies the To and From header fields
display-name is meant to be rendered by a human-user interface. from the request to the response and MUST add the tag parameter to
the To field in the response if the URL in the To field is not a
fully qualified hostname . The optional display-name is meant to be
rendered by a human-user interface.
The SIP-URL MUST NOT contain the transport-param, maddr-param, The SIP-URL MUST NOT contain the transport-param, maddr-param, ttl-
ttl-param, or headers elements. A server that receives a SIP-URL param, or headers elements. A server that receives a SIP-URL with
with these elements removes them before further processing. these elements removes them before further processing.
From = ( "From" | "f" ) ":" ( name-addr | addr-spec ) From = ( "From" | "f" ) ":" ( name-addr | addr-spec )
name-addr = [ display-name ] "<" addr-spec ">" name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI addr-spec = SIP-URL | URI
display-name = *token | quoted-string display-name = *token | quoted-string
Examples: Examples:
From: A. G. Bell <sip:agb@bell-telephone.com> From: A. G. Bell <sip:agb@bell-telephone.com>
From: sip:+12125551212@server.phone2net.com From: sip:+12125551212@server.phone2net.com
From: Anonymous <sip:c8oqz84zk7z@privacy.org> From: Anonymous <sip:c8oqz84zk7z@privacy.org>
Call-ID, To and From are needed to identify a call leg Call-ID, To and From are needed to identify a call leg
matters in calls with third-party control. The format is matters in calls with third-party control. The format is
similar to the equivalent RFC 822 [24] header, but with a similar to the equivalent RFC 822 [24] header, but with a
URI instead of just an email address. URI instead of just an email address.
6.21 Hide 6.21 Hide
The Hide request header field indicates that the path comprised of The Hide request header field indicates that the path comprised of
the Via header fields (Section 6.40) should be hidden from the Via header fields (Section 6.40) should be hidden from subsequent
subsequent proxies and user agents. It can take two forms: Hide: proxies and user agents. It can take two forms: Hide: route and
route and Hide: hop. Hide header fields are typically added by the Hide: hop. Hide header fields are typically added by the client user
client user agent, but MAY be added by any proxy along the path. agent, but MAY be added by any proxy along the path.
If a request contains the " Hide: route" header field, all following If a request contains the " Hide: route" header field, all following
proxies SHOULD hide their previous hop. If a request contains the " proxies SHOULD hide their previous hop. If a request contains the
Hide: hop" header field, only the next proxy SHOULD hide the previous "Hide: hop" header field, only the next proxy SHOULD hide the
hop and then remove the Hide option unless it also wants to remain previous hop and then remove the Hide option unless it also wants to
anonymous. remain anonymous.
A server hides the previous hop by encrypting the host and port A server hides the previous hop by encrypting the host and port parts
parts of the top-most Via header with an algorithm of its choice. of the top-most Via header with an algorithm of its choice. Servers
Servers SHOULD add additional "salt" to the host and port SHOULD add additional "salt" to the host and port information prior
information prior to encryption to prevent malicious downstream to encryption to prevent malicious downstream proxies from guessing
proxies from guessing earlier parts of the path based on seeing earlier parts of the path based on seeing identical encrypted Via
identical encrypted Via headers. Hidden Via fields are marked with headers. Hidden Via fields are marked with the hidden Via option, as
the hidden Via option, as described in Section 6.40. described in Section 6.40.
A server that is capable of hiding Via headers MUST attempt to A server that is capable of hiding Via headers MUST attempt to
decrypt all Via headers marked as "hidden" to perform loop decrypt all Via headers marked as "hidden" to perform loop detection.
detection. Servers that are not capable of hiding can ignore hidden Servers that are not capable of hiding can ignore hidden Via fields
Via fields in their loop detection algorithm. in their loop detection algorithm.
If hidden headers were not marked, a proxy would have to If hidden headers were not marked, a proxy would have to
decrypt all headers to detect loops, just in case one was decrypt all headers to detect loops, just in case one was
encrypted, as the Hide: Hop option may have been removed encrypted, as the Hide: Hop option may have been removed
along the way. along the way.
A host MUST NOT add such a " Hide: hop" header field unless it can A host MUST NOT add such a " Hide: hop" header field unless it can
guarantee it will only send a request for this destination to the guarantee it will only send a request for this destination to the
same next hop. The reason for this is that it is possible that the same next hop. The reason for this is that it is possible that the
request will loop back through this same hop from a downstream proxy. request will loop back through this same hop from a downstream proxy.
skipping to change at page 46, line 18 skipping to change at page 47, line 12
Hiding the route of a SIP request may be of limited value if the Hiding the route of a SIP request may be of limited value if the
request results in data packets being exchanged directly between the request results in data packets being exchanged directly between the
calling and called user agent. calling and called user agent.
The use of Hide header fields is discouraged unless path privacy is The use of Hide header fields is discouraged unless path privacy is
truly needed; Hide fields impose extra processing costs and truly needed; Hide fields impose extra processing costs and
restrictions for proxies and can cause requests to generate 482 (Loop restrictions for proxies and can cause requests to generate 482 (Loop
Detected) responses that could otherwise be avoided. Detected) responses that could otherwise be avoided.
The encryption of Via header fields is described in more detail in The encryption of Via header fields is described in more detail in
Section 12. Section 13.
The Hide header field has the following syntax: The Hide header field has the following syntax:
Hide = "Hide" ":" ( "route" | "hop" ) Hide = "Hide" ":" ( "route" | "hop" )
6.22 Location 6.22 Location
The Location general-header field can appear in requests, 2xx The Location general-header field can appear in requests, 1xx, 2xx
responses and 3xx responses. responses and 3xx responses.
REGISTER requests: REGISTER requests MUST contain a Location header REGISTER requests: REGISTER requests MAY contain a Location header
field indicating at which locations the user may be reachable. field indicating at which locations the user may be reachable.
The REGISTER request defines a wildcard Location field, "*", The REGISTER request defines a wildcard Location field, "*",
which is only used with Expires: 0 to remove all registrations which MUST only be used with Expires: 0 to remove all
for a particular user. registrations for a particular user.
INVITE and ACK requests: INVITE and ACK requests SHOULD contain INVITE and ACK requests: INVITE and ACK requests SHOULD contain
Location headers indicating from which location the request is Location headers indicating from which location the request is
originating. If the SIP address does not refer to the user agent originating.
server, the SIP URL MUST contain a tag parameter uniquely
identifying the user agent. (The same person may be logged on at
several locations within the same domain served by the proxy.)
This allows the callee to send a BYE directly to the This allows the callee to send a BYE directly to the caller
caller instead of through a series of proxies. The Via instead of through a series of proxies. The Via header is
header is not sufficient since the desired address may be not sufficient since the desired address may be that of a
that of a proxy. proxy.
INVITE 2xx responses: A user agent server sending a definitive, INVITE 2xx responses: A user agent server sending a definitive,
positive response (2xx) MAY insert a Location response header positive response (2xx) MAY insert a Location response header
indicating the SIP address under which it is reachable most indicating the SIP address under which it is reachable most
directly for future SIP requests, such as ACK. This may be the directly for future SIP requests, such as ACK, within the same
address of the server itself or that of a proxy, e.g., if the Call-ID. This may be the address of the server itself or that of
host is behind a firewall. If the SIP address does not refer to a proxy, e.g., if the host is behind a firewall. The value of
the user agent server, the SIP URL MUST contain a tag parameter this Location header is copied into the Request-URI of
uniquely identifying the user agent. (The same person may be subsequent requests for this call.
logged on at several locations within the same domain served by
the proxy.) The value of this Location header is copied into
the Request-URI of subsequent requests for this call.
REGISTER 2xx responses: Similarly, a REGISTER response SHOULD return The Location value MUST NOT be cached across calls, as it
all locations at which the user is currently reachable. may not represent the most desirable location for a
particular destination address.
3xx responses: The Location response-header field can be used with a INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY
3xx response codes to indicate one or more addresses to try. It insert a Location response header. It has the same semantics in
can appear in responses to BYE, INVITE and OPTIONS methods. a 1xx response as a 2xx INVITE response.
The Location header field contains URIs giving the new
locations or user names to try, or may simply specify additional REGISTER 2xx responses: Similarly, a REGISTER response MAY return all
transport parameters. A 301 (Moved Permanently) or 302 (Moved locations at which the user is currently reachable.
Temporarily) response SHOULD contain a Location field
3xx and 485 responses: The Location response-header field can be used
with a 3xx or 485 response codes to indicate one or more
alternate addresses to try. It can appear in responses to BYE,
INVITE and OPTIONS methods. The Location header field contains
URIs giving the new locations or user names to try, or may
simply specify additional transport parameters. A 300 (Multiple
Choices), 301 (Moved Permanently), 302 (Moved Temporarily) or
485 (Ambiguous) response SHOULD contain a Location field
containing URIs of new addressed to be tried. A 301 or 302 containing URIs of new addressed to be tried. A 301 or 302
response may also give the same location and username that was response may also give the same location and username that was
being tried but specify additional transport parameters such as being tried but specify additional transport parameters such as
a multicast address to try or a change of SIP transport from UDP a different server or multicast address to try or a change of
to TCP or vice versa. SIP transport from UDP to TCP or vice versa. The client copies
the host, user and tag elements of the Location URI into the
Request-URI of the redirected request and directs the request to
the address specified in the maddr and port parameter, using the
transport protocol given in the transport parameter. If maddr is
a multicast address, the value of ttl is used as the time-to-
live value.
Note that the Location header may also refer to a different entity Note that the Location header may also refer to a different entity
than the one originally called. For example, a SIP call connected to than the one originally called. For example, a SIP call connected to
GSTN gateway may need to deliver a special information announcement GSTN gateway may need to deliver a special information announcement
such as "The number you have dialed has been changed." such as "The number you have dialed has been changed."
A Location response header may contain any suitable URI indicating A Location response header may contain any suitable URI indicating
where the called party may be reached, not limited to SIP URLs. For where the called party may be reached, not limited to SIP URLs. For
example, it may contain a phone or fax example, it may contain a phone or fax
skipping to change at page 48, line 10 skipping to change at page 49, line 13
action: The action is only used when registering with the REGISTER action: The action is only used when registering with the REGISTER
request. It indicates whether the client wishes that the server request. It indicates whether the client wishes that the server
proxies or redirects future requests intended for the client. proxies or redirects future requests intended for the client.
The action taken if this parameter is not specified depends on The action taken if this parameter is not specified depends on
server configuration. In its response, the registrar SHOULD server configuration. In its response, the registrar SHOULD
indicate the mode used. This parameter is ignored for other indicate the mode used. This parameter is ignored for other
requests. requests.
Location = ( "Location" | "m" ) ":" Location = ( "Location" | "m" ) ":"
("*" | (1# (( SIP-URL | URI ) ("*" | (1# (( SIP-URL | URI )
[ LWS *( ";" location-params ) ] )) [ LWS *( ";" location-params ) ] [ comment ] ))
location-params = "q" "=" qvalue location-params = "q" "=" qvalue
| "action" "=" "proxy" | "redirect" | "action" "=" "proxy" | "redirect"
| extension-attribute | extension-attribute
extension-attribute = extension-name [ "=" extension-value ] extension-attribute = extension-name [ "=" extension-value ]
Example: Example:
Location: sip:watson@worcester.bell-telephone.com;tag=123 Location: sip:watson@worcester.bell-telephone.com ;q=0.7,
;q=0.7,
mailto:watson@bell-telephone.com ;q=0.1 mailto:watson@bell-telephone.com ;q=0.1
6.23 Max-Forwards 6.23 Max-Forwards
The Max-Forwards request-header field may be used with any SIP The Max-Forwards request-header field may be used with any SIP method
method to limit the number of proxies or gateways that can forward to limit the number of proxies or gateways that can forward the
the request to the next inbound server. This can also be useful when request to the next inbound server. This can also be useful when the
the client is attempting to trace a request chain which appears to be client is attempting to trace a request chain which appears to be
failing or looping in mid-chain. [H14.31] failing or looping in mid-chain. [H14.31]
Max-Forwards = "Max-Forwards" ":" 1*DIGIT Max-Forwards = "Max-Forwards" ":" 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message may be forwarded. number of times this request message may be forwarded.
Each proxy or gateway recipient of a request containing a Max- Each proxy or gateway recipient of a request containing a Max-
Forwards header field MUST check and update its value prior to Forwards header field MUST check and update its value prior to
forwarding the request. If the received value is zero (0), the forwarding the request. If the received value is zero (0), the
skipping to change at page 49, line 17 skipping to change at page 50, line 19
If the received Max-Forwards value is greater than zero, then the If the received Max-Forwards value is greater than zero, then the
forwarded message MUST contain an updated Max-Forwards field with a forwarded message MUST contain an updated Max-Forwards field with a
value decremented by one (1). value decremented by one (1).
Example: Example:
Max-Forwards: 6 Max-Forwards: 6
6.24 Organization 6.24 Organization
The Organization request-header field conveys the name of the The Organization general-header field conveys the name of the
organization to which the callee belongs. It may also be inserted by organization to which the entity issuing the request or response
proxies at the boundary of an organization and may be used by client belongs. It may also be inserted by proxies at the boundary of an
software to filter calls. organization and may be used by client software to filter calls.
Organization = "Organization" ":" *text Organization = "Organization" ":" *text
6.25 Priority 6.25 Priority
The Priority request header signals the urgency of the call to the The Priority request header signals the urgency of the call to the
callee. callee.
Priority = "Priority" ":" priority-value Priority = "Priority" ":" priority-value
priority-value = "emergency" | "urgent" | "normal" priority-value = "emergency" | "urgent" | "normal"
skipping to change at page 49, line 40 skipping to change at page 51, line 4
priority-value = "emergency" | "urgent" | "normal" priority-value = "emergency" | "urgent" | "normal"
| "non-urgent" | "non-urgent"
The value of "emergency" should only be used when life, limb or The value of "emergency" should only be used when life, limb or
property are in imminent danger. property are in imminent danger.
Examples: Examples:
Subject: A tornado is heading our way! Subject: A tornado is heading our way!
Priority: emergency Priority: emergency
Subject: Weekend plans Subject: Weekend plans
Priority: non-urgent Priority: non-urgent
These are the values of RFC 2076 [26], with the addition of These are the values of RFC 2076 [26], with the addition of
"emergency". "emergency".
6.26 Proxy-Authenticate 6.26 Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as The Proxy-Authenticate response-header field MUST be included as part
part of a 407 (Proxy Authentication Required) response. The field of a 407 (Proxy Authentication Required) response. The field value
value consists of a challenge that indicates the authentication consists of a challenge that indicates the authentication scheme and
scheme and parameters applicable to the proxy for this Request-URI. parameters applicable to the proxy for this Request-URI. See [H14.33]
See [H14.33] for further details. for further details.
A client SHOULD cache the credentials used for a particular proxy A client SHOULD cache the credentials used for a particular proxy
server and realm for the next request to that server. Credentials server and realm for the next request to that server. Credentials
are, in general, valid for a specific value of the Request-URI at a are, in general, valid for a specific value of the Request-URI at a
particular proxy server. If a client contacts a proxy server that has particular proxy server. If a client contacts a proxy server that has
required authentication in the past, but the client does not have required authentication in the past, but the client does not have
credentials for the particular Request-URI, it MAY attempt to use credentials for the particular Request-URI, it MAY attempt to use the
the most-recently used credential. The server responds with 401 most-recently used credential. The server responds with 401
(Unauthorized) if the client guessed wrong. (Unauthorized) if the client guessed wrong.
This suggested caching behavior is motivated by proxies This suggested caching behavior is motivated by proxies
restricting phone calls to authenticated users. It seems restricting phone calls to authenticated users. It seems
likely that in most cases, all destinations require the likely that in most cases, all destinations require the
same password. Note that end-to-end authentication is same password. Note that end-to-end authentication is
likely to be destination-specific. likely to be destination-specific.
6.27 Proxy-Authorization 6.27 Proxy-Authorization
The Proxy-Authorization request-header field allows the client to The Proxy-Authorization request-header field allows the client to
identify itself (or its user) to a proxy which requires identify itself (or its user) to a proxy which requires
authentication. The Proxy-Authorization field value consists of authentication. The Proxy-Authorization field value consists of
credentials containing the authentication information of the user credentials containing the authentication information of the user
agent for the proxy and/or realm of the resource being requested. See agent for the proxy and/or realm of the resource being requested. See
[H14.34] for further details. [H14.34] for further details.
6.28 Proxy-Require 6.28 Proxy-Require
The Proxy-Require header is used to indicate proxy-sensitive The Proxy-Require header is used to indicate proxy-sensitive features
features that MUST be supported by the proxy. Any Proxy-Require that MUST be supported by the proxy. Any Proxy-Require header
header features that are not supported by the proxy MUST be features that are not supported by the proxy MUST be negatively
negatively acknowledged by the proxy to the client if not supported. acknowledged by the proxy to the client if not supported. Servers
Servers treat this field identically to the Require field. treat this field identically to the Require field.
See Section 6.30 for more details on the mechanics of this message See Section 6.30 for more details on the mechanics of this message
and a usage example. and a usage example.
6.29 Record-Route 6.29 Record-Route
The Record-Route request and response header field is added to an The Record-Route request and response header field is added to an
INVITE request by any proxy that insists on being in the path of INVITE request by any proxy that insists on being in the path of
subsequent ACK and BYE requests for the same call. It contains a subsequent ACK and BYE requests for the same call. It contains a
globally reachable Request-URI that identifies the proxy server. globally reachable Request-URI that identifies the proxy server. Each
Each proxy server adds its Request-URI to the beginning of the list. proxy server adds its Request-URI to the beginning of the list.
The server copies the Record-Route header unchanged into the The server copies the Record-Route header unchanged into the
response. ( Record-Route is only relevant for 2xx responses.) response. ( Record-Route is only relevant for 2xx responses.)
The calling user agent client copies the Record-Route header into a The calling user agent client copies the Record-Route header into a
Route header of subsequent requests, reversing the order of requests, Route header of subsequent requests, reversing the order of requests,
so that the first entry is closest to the caller. If the response so that the first entry is closest to the caller. If the response
contained a Location header field, the calling user agent adds its contained a Location header field, the calling user agent adds its
content as the last Route header. Unless this would cause a loop, content as the last Route header. Unless this would cause a loop, any
any client MUST send any subsequent requests for this Call-ID to the client MUST send any subsequent requests for this Call-ID to the
first Request-URI in the Route request header and remove that entry. first Request-URI in the Route request header and remove that entry.
Some proxies, such as those controlling firewalls or in an Some proxies, such as those controlling firewalls or in an
automatic call distribution (ACD) system, need to maintain automatic call distribution (ACD) system, need to maintain
call state and thus need to receive any BYE and ACK call state and thus need to receive any BYE and ACK packets
packets for the call. for the call.
The Record-Route header field has the following syntax: The Record-Route header field has the following syntax:
Record-Route = "Record-Route" ":" 1# request-uri Record-Route = "Record-Route" ":" 1# SIP-URL
Example for a request that has traversed the hosts ieee.org and Example for a request that has traversed the hosts ieee.org and
bell-telephone.com , in that order: bell-telephone.com , in that order:
Record-Route: sip:a.g.bell@bell-telephone.com, sip:a.bell@ieee.org Record-Route: sip:a.g.bell@bell-telephone.com, sip:a.bell@ieee.org
6.30 Require 6.30 Require
The Require request header is used by clients to tell user agent The Require request header is used by clients to tell user agent
servers about options that the client expects the server to support servers about options that the client expects the server to support
skipping to change at page 52, line 38 skipping to change at page 54, line 4
6.31 Response-Key 6.31 Response-Key
The Response-Key request header field can be used by a client to The Response-Key request header field can be used by a client to
request the key that the called user agent SHOULD use to encrypt the request the key that the called user agent SHOULD use to encrypt the
response with. The syntax is: response with. The syntax is:
Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param
key-scheme = token key-scheme = token
key-param = token "=" ( token | quoted-string ) key-param = token "=" ( token | quoted-string )
The key-scheme gives the type of encryption to be used for the The key-scheme gives the type of encryption to be used for the
response. Section 12 describes security schemes. response. Section 13 describes security schemes.
If the client insists that the server return an encrypted response, If the client insists that the server return an encrypted response,
it includes a it includes a
Require: org.ietf.sip.encrypt-response Require: org.ietf.sip.encrypt-response
header field in its request. If the client cannot encrypt for header field in its request. If the client cannot encrypt for
whatever reason, it MUST follow normal Require header field whatever reason, it MUST follow normal Require header field
procedures and return a 420 (Bad Extension) response. If this Require procedures and return a 420 (Bad Extension) response. If this Require
header is not present, a client SHOULD still encrypt, but MAY return header is not present, a client SHOULD still encrypt, but MAY return
an unencrypted response if unable to. an unencrypted response if unable to.
6.32 Retry-After 6.32 Retry-After
The Retry-After response header field can be used with a 503 The Retry-After response header field can be used with a 503 (Service
(Service Unavailable) response to indicate how long the service is Unavailable) response to indicate how long the service is expected to
expected to be unavailable to the requesting client and with a 404 be unavailable to the requesting client and with a 404 (Not Found),
(Not Found), 600 (Busy), or 603 (Decline) response to indicate when 600 (Busy), or 603 (Decline) response to indicate when the called
the called party may be available again. The value of this field can party may be available again. The value of this field can be either
be either an HTTP-date or an integer number of seconds (in decimal) an HTTP-date or an integer number of seconds (in decimal) after the
after the time of the response. time of the response.
A REGISTER request may include this header field when deleting A REGISTER request may include this header field when deleting
registrations with Location: *; Expires: 0. The Retry-After value registrations with Location: *; Expires: 0. The Retry-After value
then indicates when the user might again be reachable. The registrar then indicates when the user might again be reachable. The registrar
MAY then include this information in responses to future calls. MAY then include this information in responses to future calls.
An optional comment can be used to indicate additional information An optional comment can be used to indicate additional information
about the time of callback. An optional duration parameter indicates about the time of callback. An optional duration parameter indicates
how long the called party will be reachable starting at the initial how long the called party will be reachable starting at the initial
time of availability. If no duration parameter is given, the service time of availability. If no duration parameter is given, the service
skipping to change at page 55, line 15 skipping to change at page 56, line 18
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ] delay = *(DIGIT) [ "." *(DIGIT) ]
6.37 To 6.37 To
The To general-header field specifies recipient of the request, with The To general-header field specifies recipient of the request, with
the same SIP URL syntax as the From field. the same SIP URL syntax as the From field.
To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) To = ( "To" | "t" ) ":" ( name-addr | addr-spec )
The UAS copies the To header into its response, but SHOULD add a The UAS copies the To header into its response, and MUST add a tag
tag parameter if not already present. It MAY forego adding the tag parameter if the URL is not a full qualified hostname.
parameter if there is no chance that another UAS responds to the same
request.
A SIP server returns a 400 (Bad Request) response if it receives a A SIP server returns a 400 (Bad Request) response if it receives a
request with a To header field containing a URI with a scheme it request with a To header field containing a URI with a scheme it does
does not recognize. not recognize.
Example: Example:
To: The Operator <sip:operator@cs.columbia.edu> To: The Operator <sip:operator@cs.columbia.edu>
To: sip:+12125551212@server.phone2net.com To: sip:+12125551212@server.phone2net.com
Call-ID, To and From are needed to identify a call leg Call-ID, To and From are needed to identify a call leg
matters in calls with third-party control. The tag is matters in calls with third-party control. The tag is added
added to the To header in the response to allow forking of to the To header in the response to allow forking of future
future requests for the same call by proxies, while requests for the same call by proxies, while addressing
addressing only one of the possibly several responding user only one of the possibly several responding user agent
agent servers. It also allows several instances of the servers. It also allows several instances of the callee to
callee to send requests that can be distinguished. send requests that can be distinguished.
6.38 Unsupported 6.38 Unsupported
The Unsupported response header lists the features not supported by The Unsupported response header lists the features not supported by
the server. See Section 6.30 for a usage example and motivation. the server. See Section 6.30 for a usage example and motivation.
6.39 User-Agent 6.39 User-Agent
The User-Agent request-header field contains information about the The User-Agent general-header field contains information about the
client user agent originating the request. See [H14.42]. client user agent originating the request. See [H14.42].
6.40 Via 6.40 Via
The Via field indicates the path taken by the request so far. This The Via field indicates the path taken by the request so far. This
prevents request looping and ensures replies take the same path as prevents request looping and ensures replies take the same path as
the requests, which assists in firewall traversal and other unusual the requests, which assists in firewall traversal and other unusual
routing situations. routing situations.
6.40.1 Requests 6.40.1 Requests
The client originating the request MUST insert into the request a Via The client originating the request MUST insert into the request a Via
field containing its host name or network address and, if not the field containing its host name or network address and, if not the
default port number, the port number at which it wishes to receive default port number, the port number at which it wishes to receive
responses. (Note that this port number may differ from the UDP source responses. (Note that this port number may differ from the UDP source
port number of the request.) A fully-qualified domain name is port number of the request.) A fully-qualified domain name is
RECOMMENDED. Each subsequent proxy server that sends the request RECOMMENDED. Each subsequent proxy server that sends the request
onwards MUST add its own additional Via field before any existing onwards MUST add its own additional Via field before any existing Via
Via fields. A proxy that receives a redirection (3xx) response and fields. A proxy that receives a redirection (3xx) response and then
then searches recursively, MUST use the same Via headers as on the searches recursively, MUST use the same Via headers as on the
original request. original request.
A proxy SHOULD check the top-most Via header to ensure that it A proxy SHOULD check the top-most Via header to ensure that it
contains the sender's correct network address, as seen from that contains the sender's correct network address, as seen from that
proxy. If the sender's address is incorrect, the proxy should add an proxy. If the sender's address is incorrect, the proxy should add an
additional received attribute, as described 6.40.2. additional received attribute, as described 6.40.2.
A host behind a network address translator (NAT) or A host behind a network address translator (NAT) or
firewall may not be able to insert a network address into firewall may not be able to insert a network address into
the Via header that can be reached by the next hop beyond the Via header that can be reached by the next hop beyond
the NAT. Hosts behind NATs or NAPTs should insert the local the NAT. Hosts behind NATs or NAPTs should insert the local
port number of the outgoing socket, rather than the port port number of the outgoing socket, rather than the port
number for incoming requests, as NAPTs assume that number for incoming requests, as NAPTs assume that
responses return with reversed source and destination responses return with reversed source and destination
ports. ports.
Additionally, if the message goes to a multicast address, an extra A proxy sending a request to a multicast address MUST add the maddr
Via field is added by the sender before all the other Via fields parameter to its Via header field, and SHOULD add the ttl parameter.
giving the multicast address and TTL. If a server receives a request which contained an maddr parameter in
the topmost Via field, it should SHOULD send the response to the
multicast address listed in the maddr parameter.
If a proxy server receives a request which contains its own address, If a proxy server receives a request which contains its own address,
it MUST respond with a 482 (Loop Detected) status code. it MUST respond with a 482 (Loop Detected) status code.
This prevents a malfunctioning proxy server from causing This prevents a malfunctioning proxy server from causing
loops. Also, it cannot be guaranteed that a proxy server loops. Also, it cannot be guaranteed that a proxy server
can always detect that the address returned by a location can always detect that the address returned by a location
service refers to a host listed in the Via list, as a service refers to a host listed in the Via list, as a
single host may have aliases or several network interfaces. single host may have aliases or several network interfaces.
skipping to change at page 57, line 16 skipping to change at page 58, line 22
Normally, every host that sends or forwards a SIP message adds a Via Normally, every host that sends or forwards a SIP message adds a Via
field indicating the path traversed. However, it is possible that field indicating the path traversed. However, it is possible that
Network Address Translators (NAT) may change the source address of Network Address Translators (NAT) may change the source address of
the request (e.g., from net-10 to a globally routable address), in the request (e.g., from net-10 to a globally routable address), in
which case the Via field cannot be relied on to route replies. To which case the Via field cannot be relied on to route replies. To
prevent this, a proxy SHOULD check the top-most Via header to ensure prevent this, a proxy SHOULD check the top-most Via header to ensure
that it contains the sender's correct network address, as seen from that it contains the sender's correct network address, as seen from
that proxy. If the sender's address is incorrect, the proxy should that proxy. If the sender's address is incorrect, the proxy should
add a received tag to the Via field inserted by the previous hop. add a received tag to the Via field inserted by the previous hop.
Such a modified Via field is known as a receiver-tagged Via field. Such a modified Via field is known as a receiver-tagged Via field. An
An example is: example is:
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060 Via: SIP/2.0/UDP erlang.bell-telephone.com:5060
Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3 Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3
In this example, the message originated from 10.0.0.1 and traversed a In this example, the message originated from 10.0.0.1 and traversed a
NAT with the external address border.ieee.org (199.172.136.3) to NAT with the external address border.ieee.org (199.172.136.3) to
reach erlang.bell-telephone.com and tagged the previous hop's Via reach erlang.bell-telephone.com and tagged the previous hop's Via
field with the address that it actually came from. field with the address that it actually came from.
6.40.3 Responses 6.40.3 Responses
In the return path, Via fields are processed by a proxy or client In the return path, Via fields are processed by a proxy or client
according to the following rules: according to the following rules:
1. The first Via field should indicate the proxy or client 1. The first Via field should indicate the proxy or client
processing this message. If it does not, discard the processing this response. If it does not, discard the
message. Otherwise, remove this Via field. message. Otherwise, remove this Via field.
2. If the second Via field is a receiver-tagged field 2. If the second Via field contains a maddr parameter, the
(Section 6.40.2), send the message to the address in the response is sent to the address listed there, using the
received tag. Otherwise, if the Via header contains a port indicated in sent-by, or 5060 if none is present. The
maddr multicast address, send the response to that response SHOULD be sent using the TTL indicated in the ttl
multicast address, using the value of the ttl parameter if parameter, or with a TTL of 1 if none is present.
given. Otherwise, send the message to the address
indicated in the sent-by parameter.
3. If there is no second Via field, this response is destined 3. Otherwise, if the second Via field is a receiver-tagged
field (Section 6.40.2), send the message to the address in
the received tag, using the port present in sent-by, or
port 5060 if none is present.
4. Otherwise, send the message to the address indicated by
sent-by in the second Via field.
5. If there is no second Via field, this response is destined
for this client. for this client.
A user agent server or redirect server should send a response by
pretending to insert the received tag into the topmost Via header in
the request, and treating this header as the second Via in the above
procedure.
These rules ensure that a client only has to check the first Via These rules ensure that a client only has to check the first Via
field in a response to see if it needs processing. field in a response to see if it needs processing.
A user agent server or redirect server returns the response to the
network address where the request came from. (Since these servers do
not forward the request, they do not add a Via header field or
received tag.)
6.40.4 Syntax 6.40.4 Syntax
The format for a Via header is shown in Fig. 10. The format for a Via header is shown in Fig. 10.
Via = ( "Via" $|$ "v") ":" 1#( sent-protocol sent-by Via = ( "Via" $|$ "v") ":" 1#( sent-protocol sent-by
*( ";" via-params ) [ comment ] ) *( ";" via-params ) [ comment ] )
via-params = via-hidden | via-ttl | via-maddr via-params = via-hidden | via-ttl | via-maddr
| via-received | via-branch | via-received | via-branch
via-hidden = "hidden" via-hidden = "hidden"
via-ttl = "ttl" "=" ttl via-ttl = "ttl" "=" ttl
skipping to change at page 58, line 34 skipping to change at page 59, line 45
[ "/" transport ] [ "/" transport ]
protocol-name = "SIP" $|$ token protocol-name = "SIP" $|$ token
protocol-version = token protocol-version = token
transport = "UDP" $|$ "TCP" $|$ token transport = "UDP" $|$ "TCP" $|$ token
sent-by = ( host [ ":" port ] ) $|$ ( concealed-host ) sent-by = ( host [ ":" port ] ) $|$ ( concealed-host )
concealed-host = token concealed-host = token
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
Figure 10: Syntax of Via header field Figure 10: Syntax of Via header field
The defaults for " protocol-name" and " transport" are "SIP" and The defaults for "protocol-name" and "transport" are "SIP" and "UDP",
"UDP", respectively. The " maddr" parameter, designating the respectively. The "maddr" parameter, designating the multicast
multicast address, and the " ttl" parameter, designating the time- address, and the "ttl" parameter, designating the time-to-live (TTL)
to-live (TTL) value, are included only if the request was sent via value, are included only if the request was sent via multicast. The
multicast. The " received" parameter is added only for receiver-added "received" parameter is added only for receiver-added Via fields
Via fields (Section 6.40.2). For reasons of privacy, a client or (Section 6.40.2). For reasons of privacy, a client or proxy may wish
proxy may wish to hide its Via information by encrypting it (see to hide its Via information by encrypting it (see Section 6.21). The
Section 6.21). The " hidden" parameter is included if this header was "hidden" parameter is included if this header was hidden by the
hidden by the upstream proxy (see 6.21). upstream proxy (see 6.21). Note that privacy of the proxy relies on
the cooperation of the next hop, as the next-hop proxy will, by
The " branch" parameter is included by every forking proxy. The necessity, know the IP address and port number of the source host.
token uniquely identifies a branch of a particular search. The
identifier has to be unique only within a set of isomorphic requests.
Note that privacy of the proxy relies on the cooperation of the next The "branch" parameter is included by every forking proxy. The token
hop, as the next-hop proxy will, by necessity, know the IP address MUST be unique for each distinct request generated when a proxy
and port number of the source host. forks. 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 Via: SIP/2.0/UDP first.example.com:4000;ttl=16
;maddr=224.2.0.1 (Example) ;maddr=224.2.0.1 (Example)
Via: SIP/2.0/UDP adk8 Via: SIP/2.0/UDP adk8
6.41 Warning 6.41 Warning
The Warning response-header field is used to carry additional The Warning response-header field is used to carry additional
information about the status of a response. Warning headers are sent information about the status of a response. Warning headers are sent
with responses and have the following format: with responses and have the following format:
skipping to change at page 59, line 44 skipping to change at page 61, line 16
Any server may add Warning headers to a response. Proxy servers MUST Any server may add Warning headers to a response. Proxy servers MUST
place additional Warning headers before any Authorization headers. place additional Warning headers before any Authorization headers.
Within that constraint, Warning headers MUST be added after any Within that constraint, Warning headers MUST be added after any
existing Warning headers not covered by a signature. A proxy server existing Warning headers not covered by a signature. A proxy server
MUST NOT delete any Warning header that it received with a response. MUST NOT delete any Warning header that it received with a response.
When multiple Warning headers are attached to a response, the user When multiple Warning headers are attached to a response, the user
agent SHOULD display as many of them as possible, in the order that 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 they appear in the response. If it is not possible to display all of
the warnings, the user agent first displays warnings that appear the warnings, the user agent first displays warnings that appear
early in the response. Systems that generate multiple Warning early in the response. Systems that generate multiple Warning headers
headers should order them with this user agent behavior in mind. should order them with this user agent behavior in mind.
The warn-code consists of three digits. The first digit indicates the The warn-code consists of three digits. The first digit indicates the
significance of the warning, with 3xx indicating a warning that did significance of the warning, with 3xx indicating a warning that did
not cause the request to fail and 4xx indicating a fatal error not cause the request to fail and 4xx indicating a fatal error
condition that contributed to the failure of the request. condition that contributed to the failure of the request.
This is a list of the currently-defined warn-codes, each with a This is a list of the currently-defined warn-codes, each with a
recommended warn-text in English, and a description of its meaning. recommended warn-text in English, and a description of its meaning.
Additional warn-codes may be defined through IANA. Note that these Additional warn-codes may be defined through IANA. Note that these
warnings describe failures induced by the session description. warnings describe failures induced by the session description.
skipping to change at page 61, line 19 skipping to change at page 62, line 34
Warning: 309 isi.edu "Session parameter 'foo' not understood" Warning: 309 isi.edu "Session parameter 'foo' not understood"
Warning: 404 isi.edu "Incompatible network address type 'E.164'" Warning: 404 isi.edu "Incompatible network address type 'E.164'"
6.42 WWW-Authenticate 6.42 WWW-Authenticate
The WWW-Authenticate response-header field MUST be included in 401 The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages. The field value consists of at (Unauthorized) response messages. The field value consists of at
least one challenge that indicates the authentication scheme(s) and least one challenge that indicates the authentication scheme(s) and
parameters applicable to the Request-URI. See [H14.46] and [27]. parameters applicable to the Request-URI. See [H14.46] and [27].
The content of the realm parameter SHOULD be displayed to the user. The content of the realm parameter SHOULD be displayed to the user. A
A user agent SHOULD cache the authorization credentials for a given user agent SHOULD cache the authorization credentials for a given
value of the destination ( To header) and realm and attempt to re-use value of the destination ( To header) and realm and attempt to re-use
these values on the next request for that destination. these values on the next request for that destination.
In addition to the "basic" and "digest" authentication schemes In addition to the "basic" and "digest" authentication schemes
defined in the specifications cited above, SIP defines a new scheme, defined in the specifications cited above, SIP defines a new scheme,
PGP (RFC 2015, [28]), Section 13. Other schemes, such as S-MIME, are PGP (RFC 2015, [28]), Section 14. Other schemes, such as S-MIME, are
for further study. for further study.
7 Status Code Definitions 7 Status Code Definitions
The response codes are consistent with, and extend, HTTP/1.1 response The response codes are consistent with, and extend, HTTP/1.1 response
codes. Not all HTTP/1.1 response codes are appropriate, and only codes. Not all HTTP/1.1 response codes are appropriate, and only
those that are appropriate are given here. Other HTTP/1.1 response 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 should not be used. Response codes not defined by HTTP/1.1 have
codes x80 upwards to avoid clashes with future HTTP response codes. codes x80 upwards to avoid clashes with future HTTP response codes.
Also, SIP defines a new class, 6xx. The default behavior for unknown Also, SIP defines a new class, 6xx. The default behavior for unknown
skipping to change at page 63, line 39 skipping to change at page 65, line 6
own specific location, and the user (or user agent) can select a own specific location, and the user (or user agent) can select a
preferred communication end point and redirect its request to that preferred communication end point and redirect its request to that
location. location.
The response SHOULD include an entity containing a list of resource The response SHOULD include an entity containing a list of resource
characteristics and location(s) from which the user or user agent can characteristics and location(s) from which the user or user agent can
choose the one most appropriate, if allowed by the Accept request choose the one most appropriate, if allowed by the Accept request
header. The entity format is specified by the media type given in the header. The entity format is specified by the media type given in the
Content-Type header field. The choices SHOULD also be listed as Content-Type header field. The choices SHOULD also be listed as
Location fields (Section 6.22). Unlike HTTP, the SIP response may Location fields (Section 6.22). Unlike HTTP, the SIP response may
contain several Location fields or a list of addresses in a contain several Location fields or a list of addresses in a Location
Location field. User agents MAY use the Location field value for field. User agents MAY use the Location field value for automatic
automatic redirection or MAY ask the user to confirm a choice. redirection or MAY ask the user to confirm a choice. However, this
However, this specification does not define any standard for such specification does not define any standard for such automatic
automatic selection. selection.
This header is appropriate if the callee can be reached at This header is appropriate if the callee can be reached at
several different locations and the server cannot or several different locations and the server cannot or
prefers not to proxy the request. prefers not to proxy the request.
7.3.2 301 Moved Permanently 7.3.2 301 Moved Permanently
The user can no longer be found at the address in the Request-URI and 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 the requesting client should retry at the new address given by the
Location header field (Section 6.22). The caller SHOULD update any Location header field (Section 6.22). The caller SHOULD update any
skipping to change at page 64, line 49 skipping to change at page 66, line 17
Reserved for future use. Reserved for future use.
7.4.4 403 Forbidden 7.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. The server understood the request, but is refusing to fulfill it.
Authorization will not help, and the request should not be repeated. Authorization will not help, and the request should not be repeated.
7.4.5 404 Not Found 7.4.5 404 Not Found
The server has definitive information that the user does not exist at The server has definitive information that the user does not exist at
the domain specified in the Request-URI. This status is also the domain specified in the Request-URI. This status is also returned
returned if the domain in the Request-URI does not match any of the if the domain in the Request-URI does not match any of the domains
domains handled by the recipient of the request. handled by the recipient of the request.
7.4.6 405 Method Not Allowed 7.4.6 405 Method Not Allowed
The method specified in the Request-Line is not allowed for the The method specified in the Request-Line is not allowed for the
address identified by the Request-URI. The response MUST include an address identified by the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the indicated Allow header containing a list of valid methods for the indicated
address. address.
7.4.7 406 Not Acceptable 7.4.7 406 Not Acceptable
skipping to change at page 65, line 26 skipping to change at page 66, line 42
according to the accept headers sent in the request. according to the accept headers sent in the request.
7.4.8 407 Proxy Authentication Required 7.4.8 407 Proxy Authentication Required
This code is similar to 401 (Unauthorized), but indicates that the This code is similar to 401 (Unauthorized), but indicates that the
client MUST first authenticate itself with the proxy. The proxy MUST client MUST first authenticate itself with the proxy. The proxy MUST
return a Proxy-Authenticate header field (section 6.26) containing a return a Proxy-Authenticate header field (section 6.26) containing a
challenge applicable to the proxy for the requested resource. The challenge applicable to the proxy for the requested resource. The
client MAY repeat the request with a suitable Proxy-Authorization client MAY repeat the request with a suitable Proxy-Authorization
header field (section 6.27). SIP access authentication is explained header field (section 6.27). SIP access authentication is explained
in section 12.2 and [H11]. in section 13.2 and [H11].
This status code should be used for applications where access to the This status code should be used for applications where access to the
communication channel (e.g., a telephony gateway) rather than the communication channel (e.g., a telephony gateway) rather than the
callee herself requires authentication. callee herself requires authentication.
7.4.9 408 Request Timeout 7.4.9 408 Request Timeout
The server could not produce a response, e.g., a user location, The server could not produce a response, e.g., a user location,
within the time indicated in the Expires request-header field. The within the time indicated in the Expires request-header field. The
client MAY repeat the request without modifications at any later client MAY repeat the request without modifications at any later
time. time.
7.4.10 414 Request-URI Too Long 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 is the action
parameter in a REGISTER request conflicts with existing
registrations.
7.4.11 414 Request-URI Too Long
The server is refusing to service the request because the Request-URI The server is refusing to service the request because the Request-URI
is longer than the server is willing to interpret. is longer than the server is willing to interpret.
7.4.11 415 Unsupported Media Type 7.4.12 415 Unsupported Media Type
The server is refusing to service the request because the message The server is refusing to service the request because the message
body of the request is in a format not supported by the requested body of the request is in a format not supported by the requested
resource for the requested method. resource for the requested method.
7.4.12 420 Bad Extension 7.4.13 420 Bad Extension
The server did not understand the protocol extension specified in a The server did not understand the protocol extension specified in a
Require (Section 6.30) header field. Require (Section 6.30) header field.
7.4.13 480 Temporarily Unavailable 7.4.14 480 Temporarily Unavailable
The callee's end system was contacted successfully but the callee is 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 currently unavailable (e.g., not logged in or logged in in such a
manner as to preclude communication with the callee). The response manner as to preclude communication with the callee). The response
may indicate a better time to call in the Retry-After header. The may indicate a better time to call in the Retry-After header. The
user may also be available elsewhere (unbeknownst to this host), user may also be available elsewhere (unbeknownst to this host),
thus, this response does not terminate any searches. The reason thus, this response does not terminate any searches. The reason
phrase SHOULD indicate a more precise cause as to why the callee is phrase SHOULD indicate a more precise cause as to why the callee is
unavailable. This value SHOULD be setable by the user agent. unavailable. This value SHOULD be setable by the user agent.
7.4.14 481 Invalid Call-ID 7.4.15 481 Invalid Call-ID
The server received a BYE or CANCEL request with a Call-ID (Section The server received a BYE or CANCEL request with a Call-ID (Section
6.12) value it does not recognize. (A server simply discards an ACK 6.12) value it does not recognize. (A server simply discards an ACK
with an invalid Call-ID.) with an invalid Call-ID.)
7.4.15 482 Loop Detected 7.4.16 482 Loop Detected
The server received a request with a Via (Section 6.40) path The server received a request with a Via (Section 6.40) path
containing itself. containing itself.
7.4.16 483 Too Many Hops 7.4.17 483 Too Many Hops
The server received a request that contains more Via entries (hops) The server received a request that contains more Via entries (hops)
(Section 6.40) than allowed by the Max-Forwards (Section 6.23) (Section 6.40) than allowed by the Max-Forwards (Section 6.23) header
header field. field.
7.4.17 484 Address Incomplete 7.4.18 484 Address Incomplete
The server received a request with a To (Section 6.37) address or The server received a request with a To (Section 6.37) address or
Request-URI that was incomplete. Additional information should be Request-URI that was incomplete. Additional information should be
provided. provided.
This status code allows overlapped dialing. With overlapped This status code allows overlapped dialing. With overlapped
dialing, the client does not know the length of the dialing dialing, the client does not know the length of the dialing
string. It sends strings of increasing lengths, prompting string. It sends strings of increasing lengths, prompting
the user for more input, until it no longer receives a 484 the user for more input, until it no longer receives a 484
status response. status response.
7.4.18 485 Ambiguous 7.4.19 485 Ambiguous
The callee address provided in the request was ambiguous. The The callee address provided in the request was ambiguous. The
response MAY contain a listing of possible unambiguous addresses in response MAY contain a listing of possible unambiguous addresses in
Location headers. Location headers.
Revealing alternatives may infringe on privacy concerns of the user Revealing alternatives may infringe on privacy concerns of the user
or the organization. It MUST be possible to configure a server to or the organization. It MUST be possible to configure a server to
respond with status 404 (Not Found) or to suppress the listing of respond with status 404 (Not Found) or to suppress the listing of
possible choices if the request address was ambiguous. possible choices if the request address was ambiguous.
skipping to change at page 69, line 32 skipping to change at page 71, line 8
negotiation will not frequently be needed, and when a new user is negotiation will not frequently be needed, and when a new user is
being invited to join an already existing conference, negotiation may being invited to join an already existing conference, negotiation may
not be possible. It is up to the invitation initiator to decide not be possible. It is up to the invitation initiator to decide
whether or not to act on a 606 (Not Acceptable) response. whether or not to act on a 606 (Not Acceptable) response.
8 SIP Message Body 8 SIP Message Body
8.1 Body Inclusion 8.1 Body Inclusion
For a request message, the presence of a body is signaled by the For a request message, the presence of a body is signaled by the
inclusion of a Content-Length header. Only ACK, INVITE, OPTIONS inclusion of a Content-Length header. Only ACK, INVITE, OPTIONS and
and REGISTER requests may contain message bodies. For ACK, INVITE REGISTER requests may contain message bodies. For ACK, INVITE and
and OPTIONS, the message body is always a session description. The OPTIONS, the message body is always a session description. The use of
use of message bodies for REGISTER requests is for further study. message bodies for REGISTER requests is for further study.
For response messages, whether or not a body is included is dependent For response messages, whether or not a body is included is dependent
on both the request method and the response message's response code. on both the request method and the response message's response code.
All responses MAY include a body, although it may be of zero length. All responses MAY include a body, although it may be of zero length.
Message bodies for 1xx responses contain advisory information about Message bodies for 1xx responses contain advisory information about
the progress of the request. 2xx responses contain session the progress of the request. 2xx responses contain session
descriptions. For responses with status 300 or greater, the messaage descriptions. In 3xx respones, 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 body MAY contain additional, human-readable information about the
reasons for failure. It is RECOMMENDED that information in 1xx and reasons for failure. It is RECOMMENDED that information in 1xx and
300 and greater responses be of type text/plain or text/html 300 and greater responses be of type text/plain or text/html
8.2 Message Body Type 8.2 Message Body Type
The Internet media type of the message body MUST be given by the The Internet media type of the message body MUST be given by the
Content-Type header field, If the body has undergone any encoding Content-Type header field, If the body has undergone any encoding
(such as compression) then this MUST be indicated by the Content- (such as compression) then this MUST be indicated by the Content-
Encoding header field, otherwise Content-Encoding MUST be omitted. If Encoding header field, otherwise Content-Encoding MUST be omitted. If
applicable, the character set of the message body is indicated as applicable, the character set of the message body is indicated as
part of the Content-Type header-field value. part of the Content-Type header-field value.
8.3 Message Body Length 8.3 Message Body Length
The body length in bytes MUST be given by the Content-Length header The body length in bytes SHOULD be given by the Content-Length header
field. If no body is present in a message, then the Content-Length field. Section 6.22 describes the behavior in detail.
header MUST set to zero. If a server receives a message without
Content-Length, it MUST assume it to be zero.
The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. 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 (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 to transfer it as a series of chunks, each with its own size
indicator.) indicator.)
9 Compact Form 9 Compact Form
When SIP is carried over UDP with authentication and a complex When SIP is carried over UDP with authentication and a complex
session description, it may be possible that the size of a request or session description, it may be possible that the size of a request or
skipping to change at page 70, line 39 skipping to change at page 72, line 16
c Content-Type c Content-Type
e Content-Encoding e Content-Encoding
f From f From
i Call-ID i Call-ID
l Content-Length l Content-Length
m Location from "moved" m Location from "moved"
s Subject s Subject
t To t To
v Via v Via
Thus, the header in section 14.2 could also be written: Thus, the header in section 15.2 could also be written:
INVITE sip:schooler@vlsi.caltech.edu SIP/2.0 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 131.215.131.131;maddr=239.128.16.254;ttl=16
v:SIP/2.0/UDP 128.16.64.19 v:SIP/2.0/UDP 128.16.64.19
f:sip:mjh@isi.edu f:sip:mjh@isi.edu
t:sip:schooler@cs.caltech.edu t:sip:schooler@cs.caltech.edu
i:62729-27@128.16.64.19 i:62729-27@128.16.64.19
c:application/sdp c:application/sdp
CSeq: 4711 INVITE CSeq: 4711 INVITE
l:187 l:187
skipping to change at page 71, line 20 skipping to change at page 72, line 42
e=mbone@somewhere.com e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127 c=IN IP4 224.2.0.1/127
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
Mixing short field names and long field names is allowed, but not Mixing short field names and long field names is allowed, but not
recommended. Servers MUST accept both short and long field names for recommended. Servers MUST accept both short and long field names for
requests. Proxies MUST NOT translate a request between short and long requests. Proxies MUST NOT translate a request between short and long
forms if authentication fields are present. forms if authentication fields are present.
10 SIP Transport 10 Behavior of SIP Clients and Servers
10.1 General Remarks 10.1 General Remarks
SIP is defined so it can use either UDP (unicast or multicast) or TCP SIP is defined so it can use either UDP (unicast or multicast) or TCP
as a transport protocol; it provides its own reliability mechanism. as a transport protocol; it provides its own reliability mechanism.
10.1.1 Requests 10.1.1 Requests
Servers ignore isomorphic requests, but retransmit the appropriate Servers ignore isomorphic requests, but retransmit the appropriate
response. (SIP requests are said to be idempotent , i.e., receiving response. (SIP requests are said to be idempotent , i.e., receiving
more than one copy of a request does not change the server state.) more than one copy of a request does not change the server state.)
After receiving a CANCEL request from an upstream client, a stateful After receiving a CANCEL request from an upstream client, a stateful
proxy server SHOULD send a CANCEL on all branches where it has not proxy server MAY send a CANCEL on all branches where it has not yet
yet received a final response. received a final response.
If the To header user and host information does not match an address
supported by the server, the server returns a 404 (Not Found) error
response. Otherwise, it searches for the Call-ID value.
If the Call-ID was found, it compares the tag value of To with the When a user agent receives a request, it checks the Call-ID against
user's tag and rejects the request if the two do not match. If the those of in-progress calls. If the Call-ID was found, it compares the
From header, including any tag value, matches the value for an tag value of To with the user's tag and rejects the request if the
existing call leg, the server compares the CSeq header value. If less two do not match. If the From header, including any tag value,
than or equal to the current sequence number, the request is a matches the value for an existing call leg, the server compares the
retransmission. Otherwise, it is a new request. If the From header CSeq header value. If less than or equal to the current sequence
does not match an existing call leg, a new call leg is created. 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 If the Call-ID was not found, a new call leg is created, with entries
entries for the To, From and Call-ID headers. In this case, the for the To, From and Call-ID headers. In this case, the To header
To header should not have contained a tag. The server returns a should not have contained a tag. The server returns a response
response containing the same To value, but with a unique tag added. containing the same To value, but with a unique tag added. The tag
The tag MAY be omitted if the To refers to a fully qualified host MAY be omitted if the To refers to a fully qualified host name.
name.
10.1.2 Responses 10.1.2 Responses
A server MAY issue one or more provisional responses at any time A server MAY issue one or more provisional responses at any time
before sending a final response. If a stateful proxy, user agent before sending a final response. If a stateful proxy, user agent
server, redirect server or registrar cannot respond to a request with server, redirect server or registrar cannot respond to a request with
a final response within 200 ms, it MUST issue a provisional (1xx) a final response within 200 ms, it MUST issue a provisional (1xx)
response as soon as possible. Stateless proxies MUST NOT issue response as soon as possible. Stateless proxies MUST NOT issue
provisional responses on their own. provisional responses on their own.
skipping to change at page 72, line 37 skipping to change at page 74, line 9
proxy actively opens a TCP connection to that address. Thus, proxies proxy actively opens a TCP connection to that address. Thus, proxies
have to be prepared to receive responses on the incoming side of have to be prepared to receive responses on the incoming side of
passive TCP connections, even though most responses will arrive on passive TCP connections, even though most responses will arrive on
the incoming side of an active connection. (An active connection is a the incoming side of an active connection. (An active connection is a
TCP connection initiated by the proxy, a passive connection is one TCP connection initiated by the proxy, a passive connection is one
accepted by the proxy, but initiated by another entity.) accepted by the proxy, but initiated by another entity.)
100 responses are not forwarded, other 1xx responses MAY be 100 responses are not forwarded, other 1xx responses MAY be
forwarded, possibly after the server eliminates responses with status forwarded, possibly after the server eliminates responses with status
codes that had already been sent earlier. 2xx responses are forwarded codes that had already been sent earlier. 2xx responses are forwarded
according to the Via header. Once a stateful proxy has received a according to the Via header. Once a stateful proxy has received a 2xx
2xx response, it MUST NOT forward non-2xx final responses. Responses response, it MUST NOT forward non-2xx final responses. Responses
with status 300 and higher are retransmitted by each stateful proxy with status 300 and higher are retransmitted by each stateful proxy
until the next upstream proxy sends an ACK (see below for timing until the next upstream proxy sends an ACK (see below for timing
details) or CANCEL. details) or CANCEL.
A stateful proxy can remove state for a call attempt and close any A stateful proxy can remove state for a call attempt and close any
connections 20 seconds after receiving the first final response. connections 20 seconds after receiving the first final response.
The 20 second window is given by the maximum retransmission The 20 second window is given by the maximum retransmission
duration of 200 responses (10 times T4), in case the ACK duration of 200 responses (10 times T4), in case the ACK is
is lost somewhere on the way to the called user agent or lost somewhere on the way to the called user agent or the
the next stateful proxy. next stateful proxy.
10.2 Source Addresses, Destination Addresses and Connections 10.2 Source Addresses, Destination Addresses and Connections
10.2.1 Unicast UDP 10.2.1 Unicast UDP
UDP packets MUST have a source address that is valid as a destination Responses are returned to the address listed in the Via header field
for requests and responses. Responses are returned to the address (Section 6.40), not the source address of the request.
listed in the Via header field (Section 6.40), not the source
address of the request.
10.2.2 Multicast UDP 10.2.2 Multicast UDP
Requests may be multicast; multicast requests likely feature a host- Requests may be multicast; multicast requests likely feature a host-
independent Request-URI. Multicast requests SHOULD have a time-to- independent Request-URI. Multicast requests SHOULD have a time-to-
live value of no greater than one, i.e., be restricted to the local live value of no greater than one, i.e., be restricted to the local
network. network.
A client receiving a multicast query does not have to check whether 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 the host part of the Request-URI matches its own host or domain name.
name. If the request was received via multicast, the response is also If the request was received via multicast, the response is also
returned via multicast. Responses to multicast requests are multicast returned via multicast. Responses to multicast requests are multicast
with the same TTL as the request, where the TTL is derived from the with the same TTL as the request, where the TTL is derived from the
ttl parameter in the Via header (Section 6.40). ttl parameter in the Via header (Section 6.40).
To avoid response implosion, servers MUST NOT answer multicast To avoid response implosion, servers MUST NOT answer multicast
requests with a status code other than 2xx or 6xx. Servers only requests with a status code other than 2xx or 6xx. Servers only
return 6xx responses if the To represents a single individual rather return 6xx responses if the To represents a single individual rather
than a group of people. The server delays its response by a random than a group of people. The server delays its response by a random
interval between zero and one second. Servers SHOULD suppress interval between zero and one second. Servers MAY suppress responses
responses if they hear a lower-numbered or 6xx response from another if they hear a lower-numbered or 6xx response from another group
group member prior to sending. Servers do not respond to CANCEL member prior to sending. Servers do not respond to CANCEL requests
requests received via multicast to avoid request implosion. 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 10.3 TCP
A single TCP connection can serve one or more SIP transactions. A A single TCP connection can serve one or more SIP transactions. A
transaction contains zero or more provisional responses followed by transaction contains zero or more provisional responses followed by
one or more final responses. (Typically, transactions contain exactly one or more final responses. (Typically, transactions contain exactly
one final response, but there are exceptional circumstances, where, one final response, but there are exceptional circumstances, where,
for example, multiple 200 responses may be generated.) for example, multiple 200 responses may be generated.)
The client MAY close the connection at any time, but SHOULD keep the The client MAY close the connection at any time, but SHOULD keep the
skipping to change at page 74, line 14 skipping to change at page 75, line 50
desires it may re-use the connection for further SIP requests or for 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 requests from the same family of protocols (such as HTTP or stream
control commands). control commands).
If a client closes a connection or the connection is reset (e.g., If a client closes a connection or the connection is reset (e.g.,
because the client has crashed and rebooted), the server treats this because the client has crashed and rebooted), the server treats this
as equivalent to having received a CANCEL request. as equivalent to having received a CANCEL request.
If a server needs to return a response to a client and no longer has 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 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 address listed in the Via header. Thus, a proxy or user agent MUST be
be prepared to receive both requests and responses on a "passive" prepared to receive both requests and responses on a "passive"
connection. connection.
10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER Requests 10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER Requests
10.4.1 UDP 10.4.1 UDP
A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or
REGISTER request periodically with timer T1 until it receives a REGISTER request periodically with timer T1 until it receives a
response, or until it has reached a set limit on the number of response, or until it has reached a set limit on the number of
retransmissions. If the response is provisional, the client continues retransmissions. If the response is provisional, the client continues
to retransmit the request, albeit less frequently, using timer T2. to retransmit the request, albeit less frequently, using timer T2.
The default values of timer T1 and T2 are 1 and 5 seconds, The default values of timer T1 and T2 are 1 and 5 seconds,
respectively. The default retransmit limit is 20 times. After the respectively. The default retransmit limit is 20 times. After the
server sends a final response, it cannot be sure the client has server sends a final response, it cannot be sure the client has
received the response, and thus SHOULD cache the results for at least received the response, and thus SHOULD cache the results for at least
100 seconds to avoid having to, for example, contact the user or 100 seconds to avoid having to, for example, contact the user or
location server again upon receiving a retransmission. location server again upon receiving a retransmission.
Each server in a proxy chain generates its own final response to a Each server in a proxy chain generates its own final response to a
CANCEL request; BYE and OPTIONS final responses are generated by CANCEL request. The server responds immediately upon receipt of the
redirect and user agent servers; REGISTER final responses are CANCEL request rather than not waiting until it has received final
generated by registrars. Note that responses to these commands are responses from the CANCEL requests it generates.
not acknowledged via ACK.
BYE and OPTIONS final responses are generated by redirect and user
agent servers; REGISTER final responses are generated by registrars.
Note that responses to these commands are not acknowledged via ACK.
The value of the initial retransmission timer is smaller The value of the initial retransmission timer is smaller
than that that for TCP since it is expected that network than that that for TCP since it is expected that network
paths suitable for interactive communications have round- paths suitable for interactive communications have round-
trip times smaller than 1 second. To avoid flooding the trip times smaller than 1 second. To avoid flooding the
network with packets every second even if the destination network with packets every second even if the destination
network is unreachable, the retransmission count has to be network is unreachable, the retransmission count has to be
bounded. Given that most transactions should consist of one bounded. Given that most transactions should consist of one
request and a few responses, round-trip time estimation is request and a few responses, round-trip time estimation is
not likely to be very useful. If RTT estimation is desired not likely to be very useful. If RTT estimation is desired
skipping to change at page 75, line 13 skipping to change at page 77, line 4
request retransmission needs to be labeled with its own request retransmission needs to be labeled with its own
Timestamp (Section 6.36), returned in the response. The Timestamp (Section 6.36), returned in the response. The
server caches the result until it can be sure that the server caches the result until it can be sure that the
client will not retransmit the same request again. client will not retransmit the same request again.
10.4.2 TCP 10.4.2 TCP
Clients using TCP do not need to retransmit requests. Clients using TCP do not need to retransmit requests.
10.5 Reliability for ACK Requests 10.5 Reliability for ACK Requests
The ACK request does not generate responses. It is only retransmitted
The ACK request does not generate responses. It is only when a response to an INVITE request arrives. This behavior is
retransmitted when a response to an INVITE request arrives. This independent of the transport protocol. Note that the ACK request MAY
behavior is independent of the transport protocol. take a different path than the original INVITE request, and even may
cause a new TCP connection to be opened in order to send it.
10.6 Reliability for INVITE Requests 10.6 Reliability for INVITE Requests
Special considerations apply for the INVITE method. Special considerations apply for the INVITE method.
1. After receiving an invitation, considerable time may elapse 1. After receiving an invitation, considerable time may elapse
before the server can determine the outcome. For example, before the server can determine the outcome. For example,
the called party may be "rung" or extensive searches may be the called party may be "rung" or extensive searches may be
performed, so delays between the request and a definitive performed, so delays between the request and a definitive
response can reach several tens of seconds. If either response can reach several tens of seconds. If either
skipping to change at page 76, line 4 skipping to change at page 77, line 43
3. The client has to be able to terminate an on-going request, 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 e.g., because it is no longer willing to wait for the
connection or search to succeed. The server will have to connection or search to succeed. The server will have to
wait several round-trip times to interpret the lack of wait several round-trip times to interpret the lack of
request retransmissions as the end of a call. If the call request retransmissions as the end of a call. If the call
succeeds shortly after the caller has given up, the callee succeeds shortly after the caller has given up, the callee
will "pick up the phone" and not be "connected". will "pick up the phone" and not be "connected".
10.6.1 UDP 10.6.1 UDP
For UDP, A SIP client SHOULD retransmits a SIP INVITE request
For UDP, A SIP client SHOULD retransmit a SIP INVITE request
periodically with timer T1 until it receives a response. If the periodically with timer T1 until it receives a response. If the
client receives no response, it ceases retransmission after 20 client receives no response, it ceases retransmission after 20
attempts. If the response is provisional, the client continues to attempts. If the response is provisional, the client continues to
retransmit the request, albeit less frequently, using timer T3. The retransmit the request, albeit less frequently, using timer T3. The
default values of timer T1 and T3 are 1 and 30 seconds, respectively. default values of timer T1 and T3 are 1 and 30 seconds, respectively.
The value of T3 was chosen so that for most normal phone The value of T3 was chosen so that for most normal phone
calls, only one INVITE request will be issued. Typically, calls, only one INVITE request will be issued. Typically, a
a phone switches to an answering machine or voice mail phone switches to an answering machine or voice mail after
after about 20--22 seconds. The number of retransmissions about 20--22 seconds. The number of retransmissions after
after receiving a provisional response is unlimited to receiving a provisional response is unlimited to allow call
allow call queueing. Clients may limit the number of queueing. Clients may limit the number of invitations sent
invitations sent for each call attempt. for each call attempt.
For 2xx final responses, only the user agent client generates an For 2xx final responses, only the user agent client generates an ACK.
ACK. If the response contained a Location header, the ACK is sent If the response contained a Location header, the ACK MAY be sent to
to the address listed in that Location header field. If the response the address listed in that Location header field. If the response
did not contain a Location header, the client uses the same To did not contain a Location header, the client uses the same To header
header field and Request-URI as for the INVITE request and sends the field and Request-URI as for the INVITE request and sends the ACK to
ACK to the same destination as the original INVITE request. ACKs the same destination as the original INVITE request. ACKs for final
for final responses other than 2xx are sent to the source of the responses other than 2xx are sent to the same server that the
response by each client. original request was sent to, using the same Request-URI as the
original request. Note, however, that the To 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 server retransmits the final response at intervals of T4 (default The server retransmits the final response at intervals of T4 (default
value of T4 = 2 seconds) until it receives an ACK request for the value of T4 = 2 seconds) until it receives an ACK request for the
same Call-ID and CSeq from the same From source or until it has same Call-ID and CSeq from the same From source or until it has
retransmitted the final response 10 times. The ACK request MUST NOT retransmitted the final response 10 times. The ACK request MUST NOT
be acknowledged to prevent a response- ACK feedback loop. be acknowledged to prevent a response- ACK feedback loop.
Fig. 11 and 12 show the client and server state diagram for Fig. 11 and 12 show the client and server state diagram for
invitations. invitations.
skipping to change at page 77, line 5 skipping to change at page 78, line 48
response. If the 200 response were to get lost, the callee response. If the 200 response were to get lost, the callee
would believe the call to exist, but the voice path would would believe the call to exist, but the voice path would
be dead since the caller does not know that the callee has be dead since the caller does not know that the callee has
picked up. Thus, the INVITE retransmission interval would picked up. Thus, the INVITE retransmission interval would
have to be on the order of a second or two to limit the have to be on the order of a second or two to limit the
duration of this state confusion. Retransmitting the duration of this state confusion. Retransmitting the
response a fixed number of times increases the probability response a fixed number of times increases the probability
of success, but at the cost of significantly higher of success, but at the cost of significantly higher
processing and network load. processing and network load.
10.6.2 TCP
+===========+ +===========+
| Initial | | Initial |
+===========+ +===========+
| |
| |
| - | -
| ------ | ------
| INVITE | INVITE
+------v v +------v v
T1 +-----------+ T1 +-----------+
skipping to change at page 77, line 46 skipping to change at page 79, line 45
--- | Completed |<-------+ --- | Completed |<-------+
ACK +-----------+ ACK +-----------+
+------| +------|
event event
------- -------
message message
Figure 11: State transition diagram of client for INVITE method Figure 11: State transition diagram of client for INVITE method
10.6.2 TCP
A client using TCP MUST NOT retransmit requests, but uses the same A client using TCP MUST NOT retransmit requests, but uses the same
algorithm as for UDP (Section 10.6.1) to retransmit responses until algorithm as for UDP (Section 10.6.1) to retransmit responses until
it receives an ACK. (An implementation can simply set T1 and T3 to
infinity and otherwise maintain the same state diagram.)
+===========+ +===========+
| Initial |<-------------+ | Initial |<-------------+
+===========+ | +===========+ |
| | | |
| | | |
| INVITE | | INVITE |
| ------ | | ------ |
| 1xx | | 1xx |
+------v v | +------v v |
INVITE +-----------+ | INVITE +-----------+ |
skipping to change at page 78, line 46 skipping to change at page 80, line 46
- +-----------+ | - +-----------+ |
+------| | | +------| | |
+-----------------+ +-----------------+
event event
------- -------
message message
Figure 12: State transition diagram of server for INVITE method Figure 12: State transition diagram of server for INVITE method
it receives an ACK. (An implementation can simply set T1 and T3 to
infinity and otherwise maintain the same state diagram.)
It is necessary to retransmit 2xx responses as their It is necessary to retransmit 2xx responses as their
reliability is assured end-to-end only. If the chain of reliability is assured end-to-end only. If the chain of
proxies has a UDP link in the middle, it could lose the proxies has a UDP link in the middle, it could lose the
response, with no possibility of recovery. For simplicity, response, with no possibility of recovery. For simplicity,
we also retransmit non-2xx responses, although that is not we also retransmit non-2xx responses, although that is not
strictly necessary. strictly necessary.
11 Behavior of SIP Servers 11 Behavior of SIP User Agents
This section describes behavior of a SIP server in detail. Servers This section describes the rules for user agent client and servers
can operate in proxy or redirect mode. Proxy servers can "fork" for generating and processing requests and responses.
connections, i.e., a single incoming request spawns several outgoing
(client) requests.
A proxy server always inserts a Via header field containing its own 11.1 Caller Issues Initial INVITE Request
address into those requests that are caused by an incoming request.
Each proxy MUST insert a " branch" parameter (Section 6.40). To
prevent loops, a server MUST check if its own address is already
contained in the Via header of the incoming request.
A proxy server MAY convert a version-x SIP request or response to a When a user agent client desires to initiate a call, it formulates an
version-y request or response, where x may be larger, smaller or INVITE request. The To field in the request contains the address of
equal to y. 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 should insert the tag parameter in the From field. A UAC
MAY optionally add a Location header containing an address where it
would like to be contacted for transactions from the callee back to
the caller.
This rule allows a proxy to serve as a go-between between 11.2 Callee Issues Response
two servers that have no version of the protocol in common.
11.1 Redirect Server When the initial INVITE request is received at the callee, the callee
may 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
To field in the request was not the fully-qualified hostname of the
UAS. 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 Location header 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 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 field in the 200
response, including any tag. The Request-URI of the ACK or BYE
request MAY be set to whatever address was found in the Location
field in the 200 response, if present. Alternately, a UAC may copy
the address from the To field into the Request-URI. The UAC also
notes the value of the To and From field 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 either INVITE or BYE requests to change or terminate the
call. Regardless of whether the caller or callee is generating the
new request, the 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 Location header field MAY be different than the
Location header field sent in a previous response or request. The
Request-URI MAY be set to the value of the Location 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 A redirect server does not issue any SIP requests of its own. After
receiving a request, the server gathers the list of alternative receiving a request, the server gathers the list of alternative
locations and returns a final response of class 3xx or it refuses the locations and returns a final response of class 3xx or it refuses the
request. For CANCEL requests, it may also return a 2xx response. request. For CANCEL requests, it SHOULD also return a 2xx response.
This response ends the SIP transaction. The redirect server maintains This response ends the SIP transaction. The redirect server maintains
transaction state for the whole SIP transaction. It is up to the transaction state for the whole SIP transaction. It is up to the
client to detect forwarding loops between redirect servers. client to detect forwarding loops between redirect servers.
11.2 User Agent Server 12.2 User Agent Server
User agent servers behave similarly to redirect servers, except that User agent servers behave similarly to redirect servers, except that
they may also accept requests and return a response of class 2xx. they may also accept requests and return a response of class 2xx.
11.3 Stateless Proxy: Proxy Servers Issuing Single Unicast Requests 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.
A stateful proxy MAY become stateless at any time, but SHOULD remain
stateful until it sends a definitive response upstream.
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 of the incoming request.
The To, From, Call-ID, and Location 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. If the field indicates TCP as the transport
protocol, 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. 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. Note that this implies that a UAC
or proxy must be prepared to receive responses on the incoming side
of a TCP connection.
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 must either be 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, as it is acknowledging the response generated by
the proxy.
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.
12.3.7 Stateless, Non-Forking Proxy
Proxies in this category issue at most a single unicast request for Proxies in this category issue at most a single unicast request for
each incoming SIP request, that is, they do not "fork" requests. each incoming SIP request, that is, they do not "fork" requests.
However, servers may choose to always operate in a mode that allows However, servers may choose to always operate in a mode that allows
issuing of several requests, as described in Section 11.4. issuing of several requests, as described in Section 12.4.
The server can forward the request and any responses. It does not The server can forward the request and any responses. It does not
have to maintain any state for the SIP transaction. Reliability is have to maintain any state for the SIP transaction. Reliability is
assured by the next redirect or stateful proxy server in the server assured by the next redirect or stateful proxy server in the server
chain. chain.
A proxy server SHOULD cache the result of any address translations A proxy server SHOULD cache the result of any address translations
and the response to speed forwarding of retransmissions. After the and the response to speed forwarding of retransmissions. After the
cache entry has been expired, the server cannot tell whether an cache entry has been expired, the server cannot tell whether an
incoming request is actually a retransmission of an older request. incoming request is actually a retransmission of an older request.
The server will treat it as a new request and commence another The server will treat it as a new request and commence another
search. search.
11.4 Proxy Server Issuing Several Requests 12.4 Forking Proxy
The server MUST respond to the request immediately with a 100 The server MUST respond to the request immediately with a 100
(Trying) response. (Trying) response.
All outgoing requests carry the same Call-ID, To, From and CSeq
headers as the request received. Each of the requests has a different
(host-dependent) Request-URI.
Successful responses to an INVITE request SHOULD contain a Location Successful responses to an INVITE request SHOULD contain a Location
header so that the following ACK or BYE bypasses the proxy search header so that the following ACK or BYE bypasses the proxy search
mechanism. If the proxy requires future requests to be routed through mechanism. If the proxy requires future requests to be routed through
it, it adds a Record-Route header to the request (Section 6.29). it, it adds a Record-Route header to the request (Section 6.29).
The following pseudo-code describes the behavior of a proxy server The following pseudo-code describes the behavior of a proxy server
issuing several requests in response to an incoming INVITE request. issuing several requests in response to an incoming INVITE request.
The function request(r, a, b) sends a SIP request of type r to 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 address a, with branch id b. await_response() waits until a response
is received and returns the response. close(a) closes the TCP is received and returns the response. close(a) closes the TCP
skipping to change at page 81, line 15 skipping to change at page 86, line 31
int branch; /* branch id */ int branch; /* branch id */
int done; /* has responded */ int done; /* has responded */
} outgoing[]; } outgoing[];
int done[]; /* address has responded */ int done[]; /* address has responded */
char *location[]; /* list of locations */ char *location[]; /* list of locations */
int heard = 0; /* number of sites heard from */ int heard = 0; /* number of sites heard from */
int class; /* class of status code */ int class; /* class of status code */
int timeleft = 120; /* sample timeout value */ int timeleft = 120; /* sample timeout value */
int loc = 0; /* number of locations */ int loc = 0; /* number of locations */
struct { /* response */ struct { /* response */
int status; /* response: BYE=-2; CANCEL=-1 */ int status; /* response: CANCEL=-1 */
int locations; /* number of redirect locations */ int locations; /* number of redirect locations */
char *location[]; /* redirect locations */ char *location[]; /* redirect locations */
address_t a; /* address of respondent */ address_t a; /* address of respondent */
int branch; /* branch identifier */ int branch; /* branch identifier */
} r, best; /* response, best response */ } r, best; /* response, best response */
int i; int i;
best.status = 1000; best.status = 1000;
for (i = 0; i < N; i++) { for (i = 0; i < N; i++) {
request(R, address[i], i); request(R, address[i], i);
outgoing[i].done = 0; outgoing[i].done = 0;
outgoing[i].branch = i; outgoing[i].branch = i;
} }
while (timeleft > 0 && heard < N) { while (timeleft > 0 && heard < N) {
r = await_response(); r = await_response();
class = r.status / 100; class = r.status / 100;
if (r.status < 0) {
break;
}
/* If final response, mark branch as done. */ /* If final response, mark branch as done. */
if (class >= 2) { if (class >= 2) {
heard++; heard++;
for (i = 0; i < N; i++) { for (i = 0; i < N; i++) {
if (r.branch == outgoing[i].branch) { if (r.branch == outgoing[i].branch) {
outgoing[i].done = 1; outgoing[i].done = 1;
break; break;
} }
} }
} }
/* CANCEL: respond, fork and wait for responses */
else if (class < 0) {
best.status = 200;
response(best);
for (i = 0; i < N; i++) {
request(CANCEL, address[i], outgoing[i].branch);
}
best.status = -1;
}
if (class == 2) { if (class == 2) {
best = r; if (r.status < best) best = r;
break; break;
} }
else if (class == 3) { else if (class == 3) {
/* A server may optionally recurse. The server MUST check /* A server may optionally recurse. The server MUST check
* whether it has tried this location before and whether the * whether it has tried this location before and whether the
* location is part of the Via path of the incoming request. * location is part of the Via path of the incoming request.
* This check is omitted here for brevity. Multicast locations * This check is omitted here for brevity. Multicast locations
* MUST NOT be returned to the client if the server is not * MUST NOT be returned to the client if the server is not
* recursing. * recursing.
*/ */
if (recurse) { if (recurse) {
multicast = 0; multicast = 0;
N += r.locations; N += r.locations;
for (i = 0; i < r.locations; i++) { for (i = 0; i < r.locations; i++) {
request(R, r.location[i]); request(R, r.location[i]);
} }
} else if (!ismulticast(r.location)) { } else if (!ismulticast(r.location)) {
best = r; best = r;
} }
if (R == INVITE} request(ACK, r.a, r.branch); if (R == INVITE) request(ACK, r.a, r.branch);
} }
else if (class == 4) { else if (class == 4) {
if (R == INVITE} request(ACK, r.a, r.branch); if (R == INVITE) request(ACK, r.a, r.branch);
if (best.status >= 400) best = r; if (best.status >= 400) best = r;
} }
else if (class == 5) { else if (class == 5) {
if (R == INVITE} request(ACK, r.a, r.branch); if (R == INVITE) request(ACK, r.a, r.branch);
if (best.status >= 500) best = r; if (best.status >= 500) best = r;
} }
else if (class == 6) { else if (class == 6) {
if (R == INVITE} request(ACK, r.a, r.branch); if (R == INVITE) request(ACK, r.a, r.branch);
best = r; best = r;
break; break;
} }
} }
/* CANCEL */
if (r.status == -1) {
best.status = 200;
response(best);
}
/* BYE */
else if (r.status == -2) {
for (i = 0; i < N; i++) {
request(BYE, address[i], i);
}
}
/* INVITE */
else {
/* We haven't heard anything useful from anybody. */ /* We haven't heard anything useful from anybody. */
if (best.status == 1000) { if (best.status == 1000) {
best.status = 404; best.status = 404;
} }
if (best.status/100 != 3) loc = 0; if (best.status/100 != 3) loc = 0;
response(best); response(best);
} }
/*
* If complete or CANCELed, close the other pending transactions by
* sending CANCEL.
*/
if (r.status > 0 || r.status == -1) {
for (i = 0; i < N; i++) {
if (!outgoing[i].done) {
request(CANCEL, address[i], outgoing[i].branch);
if (tcp) close(a);
}
}
}
}
Responses are processed as follows. The process completes (and state Responses are processed as follows. The process completes (and state
can be freed) when all requests have been answered by final status can be freed) when all requests have been answered by final status
responses (for unicast) or 60 seconds have elapsed (for multicast). A responses (for unicast) or 60 seconds have elapsed (for multicast). A
proxy MAY send a CANCEL to all branches and return a 408 (Timeout) proxy MAY send a CANCEL to all branches and return a 408 (Timeout) to
to the client after 60 seconds or more. the client after 60 seconds or more.
1xx: The proxy MAY forward the response upstream towards the client. 1xx: The proxy MAY forward the response upstream towards the client.
2xx: The proxy MUST 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 without sending an ACK downstream. After receiving a 2xx, the
server SHOULD terminate all other pending requests by sending a server MAY terminate all other pending requests by sending a
CANCEL request and closing the TCP connection, if applicable. CANCEL request and closing the TCP connection, if applicable.
(Terminating pending requests is advisable as searches consume (Terminating pending requests is advisable as searches consume
resources. Also, INVITE requests may "ring" on a number of resources. Also, INVITE requests may "ring" on a number of
workstations if the callee is currently logged in more than workstations if the callee is currently logged in more than
once.) once.)
3xx: The proxy MUST send an ACK and MAY recurse on the listed 3xx: The proxy MUST send an ACK and MAY recurse on the listed
Location addresses. Otherwise, the lowest-numbered response is Location addresses. Otherwise, the lowest-numbered response is
returned if there were no 2xx responses. returned if there were no 2xx responses.
Location lists are not merged as that would prevent Location lists are not merged as that would prevent
forwarding of authenticated responses. Also, some responses forwarding of authenticated responses. Also, some responses
may have message bodies, so that merging is not feasible. may have message bodies, so that merging is not feasible.
4xx, 5xx: The proxy MUST send an ACK and remember the response if it 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. has a lower status code than any previous 4xx and 5xx responses.
On completion, the lowest-numbered response is returned if there On completion, the lowest-numbered response is returned if there
were no 2xx or 3xx responses. were no 2xx or 3xx responses.
6xx: The proxy MUST forward the response to the client and send an 6xx: The proxy MUST forward the response to the client and send an
ACK. Other pending requests SHOULD be terminated with CANCEL as ACK. Other pending requests MAY be terminated with CANCEL as
described for 2xx responses. described for 2xx responses.
When operating in this mode, a proxy server MUST ignore any responses A proxy server forwards any response for Call-IDs for which it does
received for Call-IDs for which it does not have a pending not have a pending transaction according to the response's Via
transaction. (If server were to forward responses not belonging to a header. User agent servers respond to BYE requests with an unknown
current transaction using the Via field, the requesting client would Call-ID with status code 481 (Invalid Call-ID). ACK requests are
get confused if it has just issued another request using the same silently dropped.
Call-ID.)
If a proxy server receives a BYE request for a pending search, the
proxy MUST terminate all pending requests by sending a BYE request.
Special considerations apply for choosing forwarding destinations for Special considerations apply for choosing forwarding destinations for
ACK and BYE requests. In most cases, these requests will bypass ACK and BYE requests. In most cases, these requests will bypass
proxies and reach the desired party directly, keeping proxies from proxies and reach the desired party directly, keeping proxies from
having to make forwarding decisions. having to make forwarding decisions.
User agent clients respond to ACK and BYE requests with unknown
Call-ID with status code 481 (Invalid Call-ID).
A proxy MAY maintain call state for a period of its choosing. If a 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 proxy still has list of destinations that it forwarded the last
INVITE to, it SHOULD direct ACK requests only to those downstream INVITE to, it SHOULD direct ACK requests only to those downstream
servers. It SHOULD direct BYE to only those servers that had servers.
previously responded with 2xx or have not yet responded to the last
INVITE. If the proxy has no call state for a particular Call-ID and
To destination, it forks the request as it would for an INVITE
request.
12 Security Considerations 13 Security Considerations
12.1 Confidentiality and Privacy: Encryption 13.1 Confidentiality and Privacy: Encryption
12.1.1 End-to-End Encryption 13.1.1 End-to-End Encryption
SIP requests and responses can contain sensitive information about SIP requests and responses can contain sensitive information about
the communication patterns and communication content of individuals the communication patterns and communication content of individuals
and thus should be protected against eavesdropping. The SIP message and thus should be protected against eavesdropping. The SIP message
body may also contain encryption keys for the session itself. body may also contain encryption keys for the session itself.
SIP supports three complementary forms of encryption to protect SIP supports three complementary forms of encryption to protect
privacy: privacy:
o End-to-end encryption of the SIP message body and certain o End-to-end encryption of the SIP message body and certain
skipping to change at page 85, line 26 skipping to change at page 90, line 10
because header fields such as To and Via need to be visible to because header fields such as To and Via need to be visible to
proxies so that the SIP request can be routed correctly. Hop-by-hop proxies so that the SIP request can be routed correctly. Hop-by-hop
encryption encrypts the entire SIP request or response on the wire encryption encrypts the entire SIP request or response on the wire
(the request may already have been end-to-end encrypted) so that (the request may already have been end-to-end encrypted) so that
packet sniffers or other eavesdroppers cannot see who is calling packet sniffers or other eavesdroppers cannot see who is calling
whom. Note that proxies can still see who is calling whom, and this whom. Note that proxies can still see who is calling whom, and this
information may also be deducible by performing a network traffic information may also be deducible by performing a network traffic
analysis, so this provides a very limited but still worthwhile degree analysis, so this provides a very limited but still worthwhile degree
of protection. of protection.
SIP Via fields are used to route a response back along the path SIP Via fields are used to route a response back along the path taken
taken by the request and to prevent infinite request loops. However, by the request and to prevent infinite request loops. However, the
the information given by them may also provide useful information to information given by them may also provide useful information to an
an attacker. Section 6.21 describes how a sender can request that Via attacker. Section 6.21 describes how a sender can request that Via
fields be encrypted by cooperating proxies without compromising the fields be encrypted by cooperating proxies without compromising the
purpose of the Via field. purpose of the Via field.
End-to-end encryption relies on keys shared by the two user agents End-to-end encryption relies on keys shared by the two user agents
involved in the request. Typically, the message is sent encrypted involved in the request. Typically, the message is sent encrypted
with the public key of the recipient, so that only that recipient can with the public key of the recipient, so that only that recipient can
read the message. SIP does not limit the security mechanisms that may read the message. SIP does not limit the security mechanisms that may
be used, but all implementations SHOULD support PGP-based encryption. be used, but all implementations SHOULD support PGP-based encryption.
A SIP request (or response) is end-to-end encrypted by splitting the A SIP request (or response) is end-to-end encrypted by splitting the
message to be sent into a part to be encrypted and a short header message to be sent into a part to be encrypted and a short header
that will remain in the clear. Some parts of the SIP message, namely that will remain in the clear. Some parts of the SIP message, namely
the request line, the response line and certain header fields marked the request line, the response line and certain header fields marked
with "n" in the "enc." column in Table 4 need to be read and returned with "n" in the "enc." column in Table 4 need to be read and returned
by proxies and thus MUST NOT be encrypted end-to-end. Possibly by proxies and thus MUST NOT be encrypted end-to-end. Possibly
sensitive information that needs to be made available as plaintext sensitive information that needs to be made available as plaintext
include destination address ( To) and the forwarding path ( Via) of include destination address (To) and the forwarding path (Via) of the
the call. The Authorization header MUST remain in the clear if it call. The Authorization header MUST remain in the clear if it
contains a digital signature as the signature is generated after contains a digital signature as the signature is generated after
encryption, but MAY be encrypted if it contains "basic" or "digest" encryption, but MAY be encrypted if it contains "basic" or "digest"
authentication. The From header field SHOULD normally remain in the authentication. The From header field SHOULD normally remain in the
clear, but MAY be encrypted if required, in which case some proxies clear, but MAY be encrypted if required, in which case some proxies
MAY return a 401 (Unauthorized) status if they require a From field. MAY return a 401 (Unauthorized) status if they require a From field.
Other header fields MAY be encrypted or MAY travel in the clear as Other header fields MAY be encrypted or MAY travel in the clear as
desired by the sender. The Subject, Allow, Call-ID, and Content- desired by the sender. The Subject, Allow, Call-ID, and Content-Type
Type header fields will typically be encrypted. The Accept, header fields will typically be encrypted. The Accept, Accept-
Accept-Language, Date, Expires, Priority, Require, Cseq, and Language, Date, Expires, Priority, Require, Cseq, and Timestamp
Timestamp header fields will remain in the clear. header fields will remain in the clear.
All fields that will remain in the clear MUST precede those that will All fields that will remain in the clear MUST precede those that will
be encrypted. The message is encrypted starting with the first be encrypted. The message is encrypted starting with the first
character of the first header field that will be encrypted and character of the first header field that will be encrypted and
continuing through to the end of the message body. If no header continuing through to the end of the message body. If no header
fields are to be encrypted, encrypting starts with the second CRLF fields are to be encrypted, encrypting starts with the second CRLF
pair after the last header field, as shown below. Carriage return and pair after the last header field, as shown below. Carriage return and
line feed characters have been made visible as "$", and the encrypted line feed characters have been made visible as "$", and the encrypted
part of the message is outlined. part of the message is outlined.
skipping to change at page 87, line 28 skipping to change at page 92, line 11
Content-Length: 107$ Content-Length: 107$
$ $
************************************************* *************************************************
* $ * * $ *
* v=0$ * * v=0$ *
* o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ *
* c=IN IP4 135.180.144.94$ * * c=IN IP4 135.180.144.94$ *
* m=audio 3456 RTP/AVP 0 3 4 5$ * * m=audio 3456 RTP/AVP 0 3 4 5$ *
************************************************* *************************************************
12.1.2 Privacy of SIP Responses 13.1.2 Privacy of SIP Responses
SIP requests may be sent securely using end-to-end encryption and SIP requests may be sent securely using end-to-end encryption and
authentication to a called user agent that sends an insecure authentication to a called user agent that sends an insecure
response. This is allowed by the SIP security model, but is not a response. This is allowed by the SIP security model, but is not a
good idea. However, unless the correct behaviour is explicit, it good idea. However, unless the correct behaviour is explicit, it
would not always be possible for the called user agent to infer what would not always be possible for the called user agent to infer what
a reasonable behaviour was. Thus when end-to-end encryption is used a reasonable behaviour was. Thus when end-to-end encryption is used
by the request originator, the encryption key to be used for the by the request originator, the encryption key to be used for the
response SHOULD be specified in the request. If this were not done, response SHOULD be specified in the request. If this were not done,
it might be possible for the called user agent to incorrectly infer it might be possible for the called user agent to incorrectly infer
skipping to change at page 88, line 5 skipping to change at page 92, line 33
guessing becoming an acceptable strategy, we specify that a called guessing becoming an acceptable strategy, we specify that a called
user agent receiving a request that does not specify a key to be used user agent receiving a request that does not specify a key to be used
for the response SHOULD send that response unencrypted. for the response SHOULD send that response unencrypted.
Any SIP header fields that were encrypted in a request should also be Any SIP header fields that were encrypted in a request should also be
encrypted in an encrypted response. Location response fields MAY be encrypted in an encrypted response. Location response fields MAY be
encrypted if the information they contain is sensitive, or MAY be encrypted if the information they contain is sensitive, or MAY be
left in the clear to permit proxies more scope for localized left in the clear to permit proxies more scope for localized
searches. searches.
12.1.3 Encryption by Proxies 13.1.3 Encryption by Proxies
Normally, proxies are not allowed to alter end-to-end header fields Normally, proxies are not allowed to alter end-to-end header fields
and message bodies. Proxies MAY, however, encrypt an unsigned request and message bodies. Proxies MAY, however, encrypt an unsigned request
or response with the key of the call recipient. or response with the key of the call recipient.
Proxies may need to encrypt a SIP request if the end system Proxies may need to encrypt a SIP request if the end system
cannot perform encryption or to enforce organizational cannot perform encryption or to enforce organizational
security policies. security policies.
12.1.4 Hop-by-Hop Encryption 13.1.4 Hop-by-Hop Encryption
It is RECOMMENDED that SIP requests and responses are also protected It is RECOMMENDED that SIP requests and responses are also protected
by security mechanisms at the transport and network layer. by security mechanisms at the transport and network layer.
12.1.5 Via field encryption 13.1.5 Via field encryption
When Via fields are to be hidden, a proxy that receives a request When Via fields are to be hidden, a proxy that receives a request
containing an appropriate " Hide: hop" header field (as specified in containing an appropriate " Hide: hop" header field (as specified in
section 6.21) SHOULD encrypt the header field. As only the proxy that section 6.21) SHOULD encrypt the header field. As only the proxy that
encrypts the field will decrypt it, the algorithm chosen is entirely encrypts the field will decrypt it, the algorithm chosen is entirely
up to the proxy implementor. Two methods satisfy these requirements: up to the proxy implementor. Two methods satisfy these requirements:
o The server keeps a cache of Via fields and the associated To o The server keeps a cache of Via fields and the associated To
field, and replaces the Via field with an index into the field, and replaces the Via field with an index into the
cache. On the reverse path, take the Via field from the cache cache. On the reverse path, take the Via field from the cache
rather than the message. rather than the message.
skipping to change at page 89, line 8 skipping to change at page 93, line 38
timestamp and an appropriate checksum in any such message with timestamp and an appropriate checksum in any such message with
the same secret key. The checksum is needed to detect whether the same secret key. The checksum is needed to detect whether
successful decoding has occurred, and the timestamp is successful decoding has occurred, and the timestamp is
required to prevent possible response attacks and to ensure required to prevent possible response attacks and to ensure
that no two requests from the same previous hop have the same that no two requests from the same previous hop have the same
encrypted Via field. encrypted Via field.
The latter is the preferred solution, although proxy developers may The latter is the preferred solution, although proxy developers may
devise other methods that might also satisfy the requirements. devise other methods that might also satisfy the requirements.
12.2 Message Integrity and Access Control: Authentication 13.2 Message Integrity and Access Control: Authentication
An active attacker may be able to modify and replay SIP requests and An active attacker may be able to modify and replay SIP requests and
responses unless protective measures are taken. In practice, the same responses unless protective measures are taken. The same
cryptographic measures that are used to ensure the authenticity of cryptographic measures that are used to ensure the authenticity of
the SIP message also serve to authenticate the originator of the the SIP message also serve to authenticate the originator of the
message. message. However, the "basic" and "digest" authentication mechanism
offer authentication only, without message integrity.
Transport-layer or network-layer authentication may be used for hop- Transport-layer or network-layer authentication may be used for hop-
by-hop authentication. SIP also extends the HTTP WWW-Authenticate by-hop authentication. SIP also extends the HTTP WWW-Authenticate
(Section 6.42) and Authorization (Section 6.11) header and their (Section 6.42) and Authorization (Section 6.11) header and their
Proxy- counterparts to include cryptographically strong signatures. Proxy counterparts to include cryptographically strong signatures.
SIP also supports the HTTP "basic" authentication scheme SIP also supports the HTTP "basic" and "digest" schemes and other
HTTP authentication schemes to be defined that offer a rudimentary
that offers a very rudimentary mechanism of ascertaining the identity mechanism of ascertaining the identity of the caller.
of the caller.
Since SIP requests are often sent to parties with which no Since SIP requests are often sent to parties with which no
prior communication relationship has existed, we do not prior communication relationship has existed, we do not
specify authentication based on shared secrets. specify authentication based on shared secrets.
SIP requests may be authenticated using the Authorization header SIP requests may be authenticated using the Authorization header
field to include a digital signature of certain header fields, the field to include a digital signature of certain header fields, the
request method and version number and the payload, none of which are request method and version number and the payload, none of which are
modified between client and called user agent. The Authorization modified between client and called user agent. The Authorization
header field may be used in requests to end-to-end authenticate the header field may be used in requests to authenticate the request
request originator to proxies and the called user agent, and in originator end-to-end to proxies and the called user agent, and in
responses to authenticate the called user agent or proxies returning responses to authenticate the called user agent or proxies returning
their own failure codes. It does not provide hop-by-hop their own failure codes. It does not provide hop-by-hop
authentication, which may be provided if required using the IPSEC authentication, which may be provided if required using the IPSEC
Authentication Header. Authentication Header.
SIP does not dictate which digital signature scheme is used for SIP does not dictate which digital signature scheme is used for
authentication, but does define how to provide authentication using authentication, but does define how to provide authentication using
PGP in Section 13. PGP in Section 14. As indicated above, SIP may also use "basic" and
"digest" authentication and other authentication mechanisms defined
for HTTP. Note that "basic" authentication has severe security
limitations. The following does not apply to these schemes.
To sign a SIP request, the order of the SIP header fields is To cryptographically sign a SIP request, the order of the SIP header
important. Via header fields MUST precede all other SIP header fields is important. When an Authorization header field is present,
fields as these are modified in transit. When an Authorization it indicates that all header fields following the Authorization
header field is present, it indicates that all the header fields header field have been included in the signature. Therefore, hop-by-
following the Authorization header field have been included in the hop header fields which MUST or SHOULD be modified by proxies MUST
signature. To sign a request, a client removes all of the SIP header precede the Authorization header as they will generally be modified
from before where the Authorization field will be added. It then or added-to by proxy servers. Hop-by-hop header fields which MAY be
prepends the request method (in upper case) followed by the SIP modified by a proxy MAY appear before or after the Authorization
version number field (in upper case) directly to the start of the header. When the appear before, the MAY be modified by a proxy. When
message with no whitespace, CR or LF characters inserted. This they appear after, they MUST NOT be modified by a proxy. To sign a
extended message is what is signed. request, a client constructs a message from the request method (in
upper case) followed, without LWS, by the SIP version number,
followed, again without LWS, by the request headers to be signed and
the message body. The message thus constructed is then signed.
For example, if the SIP request is to be: For example, if the SIP request is to be:
INVITE sip:watson@boston.bell-telephone.com SIP/2.0 INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
Authorization: PGP version=5.0, signature=... Authorization: PGP version=5.0, signature=...
From: A. Bell <sip:a.g.bell@bell-telephone.com> From: A. Bell <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com> To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here. Subject: Mr. Watson, come here.
skipping to change at page 91, line 7 skipping to change at page 95, line 40
before the digital signature is generated. On receipt, the digital before the digital signature is generated. On receipt, the digital
signature is checked before decryption. signature is checked before decryption.
A client MAY require that a server sign its response by including a A client MAY require that a server sign its response by including a
Require: org.ietf.sip.signed-response request header field. The Require: org.ietf.sip.signed-response request header field. The
client indicates the desired authentication method via the WWW- client indicates the desired authentication method via the WWW-
Authenticate header. Authenticate header.
The correct behaviour in handling unauthenticated responses to a The correct behaviour in handling unauthenticated responses to a
request that requires authenticated responses is described in section request that requires authenticated responses is described in section
12.2.1. 13.2.1.
12.2.1 Trusting responses 13.2.1 Trusting responses
It may be possible for an eavesdropper to listen to requests and to It may be possible for an eavesdropper to listen to requests and to
inject unauthenticated responses that would terminate, redirect or inject unauthenticated responses that would terminate, redirect or
otherwise interfere with a call. (Even encrypted requests contain otherwise interfere with a call. (Even encrypted requests contain
enough information to fake a response.) enough information to fake a response.)
Client should be particularly careful with 3xx redirection responses. Client should be particularly careful with 3xx redirection responses.
Thus a client receiving, for example, a 301 (Moved Permanently) which Thus a client receiving, for example, a 301 (Moved Permanently) which
was not authenticated when the public key of the called user agent is was not authenticated when the public key of the called user agent is
known to the client, and authentication was requested in the request known to the client, and authentication was requested in the request
SHOULD be treated as suspicious. The correct behaviour in such a case SHOULD be treated as suspicious. The correct behaviour in such a case
would be for the called-user to form a dated response containing the would be for the called-user to form a dated response containing the
Location field to be used, to sign it, and give this signed stub Location field to be used, to sign it, and give this signed stub
response to the proxy that will provide the redirection. Thus the response to the proxy that will provide the redirection. Thus the
response can be authenticated correctly. There may be circumstances response can be authenticated correctly. There may be circumstances
where such unauthenticated responses are unavoidable, but a client where such unauthenticated responses are unavoidable, but a client
skipping to change at page 92, line 6 skipping to change at page 96, line 43
called user agent, and so there is no simple way to detect these called user agent, and so there is no simple way to detect these
rogue responses. This problem is best prevented by using hop-by-hop rogue responses. This problem is best prevented by using hop-by-hop
encryption of the SIP request, which removes any additional problems encryption of the SIP request, which removes any additional problems
that UDP might have over TCP. that UDP might have over TCP.
These attacks are prevented by having the client require response These attacks are prevented by having the client require response
authentication and dropping unauthenticated responses. A server user authentication and dropping unauthenticated responses. A server user
agent that cannot perform response authentication responds using the agent that cannot perform response authentication responds using the
normal Require response of 420 (Bad Extension). normal Require response of 420 (Bad Extension).
12.3 Callee Privacy 13.3 Callee Privacy
User location and SIP-initiated calls may violate a callee's privacy. User location and SIP-initiated calls may violate a callee's privacy.
An implementation SHOULD be able to restrict, on a per-user basis, An implementation SHOULD be able to restrict, on a per-user basis,
what kind of location and availability information is given out to what kind of location and availability information is given out to
certain classes of callers. certain classes of callers.
12.4 Known Security Problems 13.4 Known Security Problems
With either TCP or UDP, a denial of service attack exists by a rogue With either TCP or UDP, a denial of service attack exists by a rogue
proxy sending 6xx responses. Although a client SHOULD choose to proxy sending 6xx responses. Although a client SHOULD choose to
ignore such responses if it requested authentication, a proxy cannot ignore such responses if it requested authentication, a proxy cannot
do so. It is obliged to forward the 6xx response back to the client. do so. It is obliged to forward the 6xx response back to the client.
The client can then ignore the response, but if it repeats the The client can then ignore the response, but if it repeats the
request it will probably reach the same rogue proxy again, and the request it will probably reach the same rogue proxy again, and the
process will repeat. process will repeat.
13 SIP Security Using PGP 14 SIP Security Using PGP
13.1 PGP Authentication Scheme 14.1 PGP Authentication Scheme
The "pgp" authentication scheme is based on the model that the client The "pgp" authentication scheme is based on the model that the client
must authenticate itself with a request signed with the client's must authenticate itself with a request signed with the client's
private key. The server can then ascertain the origin of the request private key. The server can then ascertain the origin of the request
if it has access to the public key, preferably signed by a trusted if it has access to the public key, preferably signed by a trusted
third party. third party.
13.1.1 The WWW-Authenticate Response Header 14.1.1 The WWW-Authenticate Response Header
WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge
pgp-challenge = 1# ( realm | pgp-version | pgp-algorithm ) pgp-challenge = * (";" pgp-params )
pgp-params = realm | pgp-version | pgp-algorithm
realm = "realm" "=" realm-value realm = "realm" "=" realm-value
realm-value = quoted-string realm-value = quoted-string
pgp-version = "version" "=" digit *( "." digit ) *letter pgp-version = "version" "=" digit *( "." digit ) *letter
pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token ) pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token )
The meanings of the values of the parameters used above are as The meanings of the values of the parameters used above are as
follows: follows:
realm: A string to be displayed to users so they know which identity realm: A string to be displayed to users so they know which identity
to use. This string should contain at least the name of the host to use. This string should contain at least the name of the host
skipping to change at page 93, line 16 skipping to change at page 98, line 7
pgp-algorithm: A string indicating the PGP message integrity check pgp-algorithm: A string indicating the PGP message integrity check
(MIC) to be used to produce the signature. If this not present (MIC) to be used to produce the signature. If this not present
it is assumed to be "md5". The currently defined values are it is assumed to be "md5". The currently defined values are
"md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm. "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.
pgp-version: The version of PGP that the client MUST use. Common pgp-version: The version of PGP that the client MUST use. Common
values are "2.6.2" and "5.0". The default is 5.0. values are "2.6.2" and "5.0". The default is 5.0.
Example: Example:
WWW-Authenticate: pgp version="5.0", WWW-Authenticate: pgp ;version="5.0"
realm="Your Startrek identity, please", algorithm="md5" ;realm="Your Startrek identity, please" ;algorithm="md5"
13.1.2 The Authorization Request Header 14.1.2 The Authorization Request Header
The client is expected to retry the request, passing an Authorization The client is expected to retry the request, passing an Authorization
header line, which is defined as follows. header line, which is defined as follows.
Authorization ___ "Authorization" ":" "pgp" pgp-response Authorization ___ "Authorization" ":" "pgp" *( ";" pgp-response )
pgp-response ___ 1# (realm | pgp-version | pgp-signature | signed-by) pgp-response ___ realm | pgp-version | pgp-signature | signed-by
pgp-signature ___ "signature" "=" quoted-string pgp-signature ___ "signature" "=" quoted-string
signed-by ___ "signed-by" "=" URI signed-by ___ "signed-by" "=" URI
The signature MUST correspond to the From header of the request The signature MUST correspond to the From header of the request
unless the signed-by parameter is provided. unless the signed-by parameter is provided.
pgp-signature: The PGP ASCII-armored signature, as it appears between pgp-signature: The PGP ASCII-armored signature, as it appears between
the "BEGIN PGP MESSAGE" and "END PGP MESSAGE" delimiters, the "BEGIN PGP MESSAGE" and "END PGP MESSAGE" delimiters,
without the version indication. The signature is included without the version indication. The signature is included
without any linebreaks. without any linebreaks.
skipping to change at page 94, line 27 skipping to change at page 99, line 18
signed-by: If and only if the request was not signed by the entity signed-by: If and only if the request was not signed by the entity
listed in the From header, the signed-by header indicates the listed in the From header, the signed-by header indicates the
name of the signing entity, expressed as a URI. name of the signing entity, expressed as a URI.
Receivers of signed SIP messages SHOULD discard any end-to-end header Receivers of signed SIP messages SHOULD discard any end-to-end header
fields above the Authorization header, as they may have been fields above the Authorization header, as they may have been
maliciously added en route by a proxy. maliciously added en route by a proxy.
Example: Example:
Authorization: pgp version="5.0", Authorization: pgp version="5.0"
realm="Your Startrek identity, please", ;realm="Your Startrek identity, please"
signature="iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL/Wt3dk6TWK81/b0gcNDf ;signature="iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL/Wt3dk6TWK81/b0gcNDf
VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt
SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC+KLFX SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC+KLFX
=aIrx" =aIrx"
13.2 PGP Encryption Scheme 14.2 PGP Encryption Scheme
The PGP encryption scheme uses the following syntax: The PGP encryption scheme uses the following syntax:
Encryption ___ "Encryption" ":" "pgp" pgp-eparams Encryption ___ "Encryption" ":" "pgp" pgp-eparams
pgp-eparams ___ 1# ( pgp-version | pgp-encoding ) pgp-eparams ___ 1# ( pgp-version | pgp-encoding )
pgp-encoding ___ "encoding" "=" "ascii" | token pgp-encoding ___ "encoding" "=" "ascii" | token
encoding: Describes the encoding or "armor" used by PGP. The value encoding: Describes the encoding or "armor" used by PGP. The value
"ascii" refers to the standard PGP ASCII armor, without the "ascii" refers to the standard PGP ASCII armor, without the
lines containing "BEGIN PGP MESSAGE" and "END PGP MESSAGE" and lines containing "BEGIN PGP MESSAGE" and "END PGP MESSAGE" and
without the version identifier. By default, the encrypted part without the version identifier. By default, the encrypted part
is included as binary. is included as binary.
Example: Example:
Encryption: pgp version="2.6.2", encoding="ascii" Encryption: pgp version="2.6.2", encoding="ascii"
13.3 Response-Key Header Field for PGP 14.3 Response-Key Header Field for PGP
Response-Key ___ "Response-Key" ":" "pgp" pgp-eparams Response-Key ___ "Response-Key" ":" "pgp" pgp-eparams
pgp-eparams ___ 1# ( pgp-version | pgp-encoding | pgp-key) pgp-eparams ___ 1# ( pgp-version | pgp-encoding | pgp-key)
pgp-key ___ "key" "=" quoted-string pgp-key ___ "key" "=" quoted-string
If ASCII encoding has been requested via the encoding parameter, the If ASCII encoding has been requested via the encoding parameter, the
key parameter contains the user's public key as extracted with the key parameter contains the user's public key as extracted with the
"pgp -kxa user ". "pgp -kxa user ".
Example: Example:
Response-Key: pgp version="2.6.2", encoding="ascii", Response-Key: pgp version="2.6.2", encoding="ascii",
key="mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG+ItYK5tCF8HNJM60sU4rLaV+eUnkMk key="mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG+ItYK5tCF8HNJM60sU4rLaV+eUnkMk
mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx
sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu
bmVAY3MuY29sdW1iaWEuZWR1Pg== bmVAY3MuY29sdW1iaWEuZWR1Pg==
=+y19" =+y19"
14 Examples 15 Examples
14.1 Registration In the following examples, we often omit the message body and the
corresponding Content-Length and Content-Type headers for brevity.
15.1 Registration
A user at host saturn.bell-tel.com registers on start-up, via A user at host saturn.bell-tel.com registers on start-up, via
multicast, with the local SIP server named sip.bell-tel.com the multicast, with the local SIP server named sip.bell-tel.com the
example, the user agent on saturn expects to receive SIP requests on example, the user agent on saturn expects to receive SIP requests on
UDP port 3890. UDP port 3890.
C->S: REGISTER sip:@sip.bell-tel.com SIP/2.0 C->S: REGISTER sip:sip.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP 128.16.64.19 Via: SIP/2.0/UDP 128.16.64.19
From: sip:watson@bell-tel.com From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com To: sip:watson@bell-tel.com
Call-ID: 4236500900@saturn.bell-tel.com
CSeq: 1 REGISTER
Location: sip:saturn.bell-tel.com:3890;transport=udp Location: sip:saturn.bell-tel.com:3890;transport=udp
Call-ID: 123@saturn.bell-tel.com
Expires: 7200 Expires: 7200
CSeq: 1 REGISTER
The registration expires after two hours. Any future invitations for The registration expires after two hours. Any future invitations for
watson@bell-tel.com arriving at sip.bell-tel.com will now be watson@bell-tel.com arriving at sip.bell-tel.com will now be
redirected to watson@saturn.bell-tel.com , UDP port 3890. redirected to watson@saturn.bell-tel.com , UDP port 3890.
If Watson wants to be reached elsewhere, say, an on-line service he If Watson wants to be reached elsewhere, say, an on-line service he
uses while traveling, he updates his reservation after first uses while traveling, he updates his reservation after first
cancelling any existing locations: cancelling any existing locations:
C->S: REGISTER sip:@bell-tel.com SIP/2.0 C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP 128.16.64.19 Via: SIP/2.0/UDP 128.16.64.19
From: sip:watson@bell-tel.com From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com To: sip:watson@bell-tel.com
Call-ID: 1234@saturn.bell-tel.com Call-ID: 1345441868@saturn.bell-tel.com
Expire: 0 CSeq: 1 REGISTER
Location: * Location: *
Expires: 0
C->S: REGISTER sip:@bell-tel.com SIP/2.0 C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP 128.16.64.19 Via: SIP/2.0/UDP 128.16.64.19
From: sip:watson@bell-tel.com From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com To: sip:watson@bell-tel.com
Call-ID: 1235@saturn.bell-tel.com Call-ID: 81791800@saturn.bell-tel.com
CSeq: 1 REGISTER
Location: sip:tawatson@example.com Location: sip:tawatson@example.com
Now, the server will forward any request for Watson to the server at Now, the server will forward any request for Watson to the server at
example.com , using the Request-URI tawatson@example.com example.com , using the Request-URI tawatson@example.com
It is possible to use third-party registration. Here, the secretary It is possible to use third-party registration. Here, the secretary
jon.diligent registers his boss: jon.diligent registers his boss:
C->S: REGISTER sip:@bell-tel.com SIP/2.0 C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP 128.16.64.19 Via: SIP/2.0/UDP 128.16.64.19
From: sip:jon.diligent@bell-tel.com From: sip:jon.diligent@bell-tel.com
To: sip:watson@bell-tel.com To: sip:watson@bell-tel.com
Call-ID: 1212759220@saturn.bell-tel.com
CSeq: 1 REGISTER
Location: sip:tawatson@example.com Location: sip:tawatson@example.com
Call-ID: 1236@saturn.bell-tel.com
The request could be send to either the registrar at bell-tel.com or The request could be send to either the registrar at bell-tel.com or
the server at example.com example.com would proxy the request to the the server at example.com example.com would proxy the request to the
address indicated in the Request-URI. Then, Max-Forwards header address indicated in the Request-URI. Then, Max-Forwards header could
could be used to restrict the registration to that server. be used to restrict the registration to that server.
15.2 Invitation to a Multicast Conference
14.2 Invitation to Multicast Conference
The first example invites schooler@vlsi.cs.caltech.edu to a multicast The first example invites schooler@vlsi.cs.caltech.edu to a multicast
session. All examples use the Session Description Protocol (SDP) (RFC session. All examples use the Session Description Protocol (SDP) (RFC
2327 [5]) as the session description format. 2327 [5]) as the session description format.
14.2.1 Request 15.2.1 Request
C->S: INVITE sip:schooler@vlsi.cs.caltech.edu SIP/2.0 C->S: INVITE sip:schooler@vlsi.cs.caltech.edu SIP/2.0
Via: SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
Via: SIP/2.0/UDP 128.16.64.19 ;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu> From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> To: Eve Schooler <sip:schooler@caltech.edu>
Call-ID: 2963313058@oregon.isi.edu
CSeq: 1 INVITE
Subject: SIP will be discussed, too Subject: SIP will be discussed, too
Call-ID: 42100bb8-1dd2-11b2-8d70-c91e31477491@oregon.isi.edu
Content-Type: application/sdp Content-Type: application/sdp
CSeq: 4711 INVITE
Content-Length: 187 Content-Length: 187
v=0 v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5 o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio s=Mbone Audio
i=Discussion of Mbone Engineering Issues i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127 c=IN IP4 224.2.0.1/127
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
skipping to change at page 97, line 47 skipping to change at page 102, line 47
mjh@isi.edu from the host 128.16.64.19 schooler@caltech.edu is being mjh@isi.edu from the host 128.16.64.19 schooler@caltech.edu is being
invited; the message is currently being routed to invited; the message is currently being routed to
schooler@vlsi.cs.caltech.edu schooler@vlsi.cs.caltech.edu
In this case, the session description is using the Session In this case, the session description is using the Session
Description Protocol (SDP), as stated in the Content-Type header. Description Protocol (SDP), as stated in the Content-Type header.
The header is terminated by an empty line and is followed by a The header is terminated by an empty line and is followed by a
message body containing the session description. message body containing the session description.
14.2.2 Response 15.2.2 Response
The called user agent, directly or indirectly through proxy servers, The called user agent, directly or indirectly through proxy servers,
indicates that it is alerting ("ringing") the called party: indicates that it is alerting ("ringing") the called party:
S->C: SIP/2.0 180 Ringing S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348; Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16 ;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu Via: SIP/2.0/UDP north.east.isi.edu
To: Eve Schooler <sip:schooler@caltech.edu>
From: Mark Handley <sip:mjh@isi.edu> From: Mark Handley <sip:mjh@isi.edu>
Call-ID: 42100bb8-1dd2-11b2-8d70-c91e31477491@north.east.isi.edu To: Eve Schooler <sip:schooler@caltech.edu;tag=9883472>
Location: sip:es@jove.cs.caltech.edu Call-ID: 2963313058@oregon.isi.edu
CSeq: 4711 INVITE CSeq: 1 INVITE
A sample response to the invitation is given below. The first line of A sample response to the invitation is given below. The first line of
the response states the SIP version number, that it is a 200 (OK) the response states the SIP version number, that it is a 200 (OK)
response, which means the request was successful. The Via headers response, which means the request was successful. The Via headers are
are taken from the request, and entries are removed hop by hop as the taken from the request, and entries are removed hop by hop as the
response retraces the path of the request. A new authentication field response retraces the path of the request. A new authentication field
MAY be added by the invited user's agent if required. The Call-ID is MAY be added by the invited user's agent if required. The Call-ID is
taken directly from the original request, along with the remaining taken directly from the original request, along with the remaining
fields of the request message. The original sense of From field is fields of the request message. The original sense of From field is
preserved (i.e., it is the session initiator). preserved (i.e., it is the session initiator).
In addition, the Location header gives details of the host where the In addition, the Location header gives details of the host where the
user was located, or alternatively the relevant proxy contact point user was located, or alternatively the relevant proxy contact point
which should be reachable from the caller's host. which should be reachable from the caller's host.
S->C: SIP/2.0 200 OK S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
maddr=239.128.16.254 16;ttl=16 ;maddr=239.128.16.254 16;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu Via: SIP/2.0/UDP north.east.isi.edu
From: sip:mjh@isi.edu From: Mark Handley <sip:mjh@isi.edu>
To: sip:schooler@cs.caltech.edu To: Eve Schooler <sip:schooler@caltech.edu;tag=9883472>
Call-ID: 42100bb8-1dd2-11b2-8d70-c91e31477491@oregon.isi.edu Call-ID: 2963313058@oregon.isi.edu
CSeq: 1 INVITE
Location: sip:es@jove.cs.caltech.edu Location: sip:es@jove.cs.caltech.edu
CSeq: 4711 INVITE
The caller confirms the invitation by sending a request to the The caller confirms the invitation by sending a request to the
location named in the Location header: location named in the Location header:
C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0 C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0
From: sip:mjh@isi.edu Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
To: sip:schooler@cs.caltech.edu ;maddr=239.128.16.254;ttl=16
Call-ID: 42100bb8-1dd2-11b2-8d70-c91e31477491@oregon.isi.edu From: Mark Handley <sip:mjh@isi.edu>
CSeq: 4711 ACK To: Eve Schooler <sip:schooler@caltech.edu;tag=9883472>
Call-ID: 2963313058@oregon.isi.edu
CSeq: 1 ACK
14.3 Two-party Call 15.3 Two-party Call
For two-party Internet phone calls, the response must contain a For two-party Internet phone calls, the response must contain a
description of where to send the data. In the example below, Bell description of where to send the data. In the example below, Bell
calls Watson. Bell indicates that he can receive RTP audio codings 0 calls Watson. Bell indicates that he can receive RTP audio codings 0
(PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4). (PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4).
C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0 C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com>
Call-ID: 2d978243-b270-33dc-a261-d1fe3e2aa05a@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Subject: Mr. Watson, come here. Subject: Mr. Watson, come here.
CSeq: 17 INVITE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
v=0 v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5 o=bell 53655765 2353687637 IN IP4 128.3.4.5
s=Mr. Watson, come here.
c=IN IP4 135.180.144.94 c=IN IP4 135.180.144.94
m=audio 3456 RTP/AVP 0 3 4 5 m=audio 3456 RTP/AVP 0 3 4 5
S->C: SIP/2.0 100 Trying S->C: SIP/2.0 100 Trying
Via: SIP/2.0/UDP 169.130.12.5
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com;tag=37462311>
Call-ID: 2d978243-b270-33dc-a261-d1fe3e2aa05a@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
S->C: SIP/2.0 180 Ringing S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 169.130.12.5
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com;tag=37462311>
Call-ID: 2d978243-b270-33dc-a261-d1fe3e2aa05a@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
S->C: SIP/2.0 182 Queued, 2 callers ahead S->C: SIP/2.0 182 Queued, 2 callers ahead
Via: SIP/2.0/UDP 169.130.12.5
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com;tag=37462311>
Call-ID: 2d978243-b270-33dc-a261-d1fe3e2aa05a@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
S->C: SIP/2.0 182 Queued, 1 caller ahead S->C: SIP/2.0 182 Queued, 1 caller ahead
Via: SIP/2.0/UDP 169.130.12.5
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com;tag=37462311>
Call-ID: 2d978243-b270-33dc-a261-d1fe3e2aa05a@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
S->C: SIP/2.0 200 OK S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP 169.130.12.5
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: sip:watson@bell-tel.com To: sip:watson@bell-tel.com;tag=37462311
Call-ID: 2d978243-b270-33dc-a261-d1fe3e2aa05a@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 17 INVITE CSeq: 1 INVITE
Location: sip:watson@boston.bell-tel.com Location: sip:watson@boston.bell-tel.com
Content-Length: ... Content-Length: ...
v=0 v=0
o=watson 4858949 4858949 IN IP4 192.1.2.3 o=watson 4858949 4858949 IN IP4 192.1.2.3
s=I'm on my way
c=IN IP4 135.180.161.25 c=IN IP4 135.180.161.25
m=audio 5004 RTP/AVP 0 3 m=audio 5004 RTP/AVP 0 3
The example illustrates the use of informational status responses. The example illustrates the use of informational status responses.
Here, the reception of the call is confirmed immediately (100), then, Here, the reception of the call is confirmed immediately (100), then,
possibly after some database mapping delay, the call rings (180) and possibly after some database mapping delay, the call rings (180) and
is then queued, with periodic status updates. is then queued, with periodic status updates.
Watson can only receive PCMU and GSM. Note that Watson's list of Watson can only receive PCMU and GSM. Note that Watson's list of
codecs may or may not be a subset of the one offered by Bell, as each codecs may or may not be a subset of the one offered by Bell, as each
party indicates the data types it is willing to receive. Watson will party indicates the data types it is willing to receive. Watson will
send audio data to port 3456 at 135.180.144.94, Bell will send to send audio data to port 3456 at 135.180.144.94, Bell will send to
port 5004 at 135.180.161.25. port 5004 at 135.180.161.25.
By default, the media session is one RTP session. Watson will receive By default, the media session is one RTP session. Watson will receive
RTCP packets on port 5005, while Bell will receive them on port 3457. RTCP packets on port 5005, while Bell will receive them on port 3457.
Since the two sides have agree on the set of media, Watson confirms Since the two sides have agreed on the set of media, Watson confirms
the call without enclosing another session description: the call without enclosing another session description:
C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0 C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com;tag=37462311>
Call-ID: 2d978243-b270-33dc-a261-d1fe3e2aa05a@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 17 ACK CSeq: 1 ACK
Content-Length: 0
14.4 Terminating a Call 15.4 Terminating a Call
To terminate a call, caller or callee can send a BYE request: To terminate a call, caller or callee can send a BYE request:
C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0 C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. A. Watson <sip:watson@bell-tel.com> To: T. A. Watson <sip:watson@bell-tel.com;tag=37462311>
Call-ID: 1985853074@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 18 BYE CSeq: 2 BYE
If the callee wants to abort the call, it simply reverses the To and If the callee wants to abort the call, it simply reverses the To and
From fields. Note that it is unlikely that an BYE from the callee From fields. Note that it is unlikely that an BYE from the callee
will traverse the same proxies as the original INVITE. will traverse the same proxies as the original INVITE.
14.5 Forking Proxy 15.5 Forking Proxy
In this example, Bell ( a.g.bell@bell-tel.com ) (C), currently seated In this example, Bell ( a.g.bell@bell-tel.com ) (C), currently seated
at host c.bell-tel.com wants to call Watson ( t.watson@ieee.org ). At at host c.bell-tel.com wants to call Watson ( t.watson@ieee.org ). At
the time of the call, Watson is logged in at two workstations, the time of the call, Watson is logged in at two workstations,
watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has
registered with the IEEE proxy server (P) called proxy.ieee.org registered with the IEEE proxy server (P) called sip.ieee.org
registration for the home machine of Watson, at watson@h.bell-tel.com registration for the home machine of Watson, at watson@h.bell-tel.com
(H), as well as a permanent registration at watson@acm.org (A). For (H), as well as a permanent registration at watson@acm.org (A). For
brevity, the examples omit the session description. brevity, the examples omit the session description.
Watson's user agent sends the invitation to the SIP server for the Watson's user agent sends the invitation to the SIP server for the
ieee.org domain: ieee.org domain:
C->P: INVITE sip:watson@ieee.org SIP/2.0 C->P: INVITE sip:watson@ieee.org SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@kton.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 INVITE CSeq: 1 INVITE
Via: SIP/2.0/UDP c.bell-tel.com
The SIP server tries the four addresses in parallel. It sends the The SIP server at ieee.org tries the four addresses in parallel. It
following message to the home machine: sends the following message to the home machine:
P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0 P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP proxy.ieee.org ;branch=1 Via: SIP/2.0/UDP sip.ieee.org ;branch=1
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@kton.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 INVITE CSeq: 1 INVITE
This request immediately yields a 404 (Not Found) response, since This request immediately yields a 404 (Not Found) response, since
Watson is not currently logged in at home: Watson is not currently logged in at home:
H->P: SIP/2.0 404 Not Found H->P: SIP/2.0 404 Not Found
Via: SIP/2.0/UDP proxy.ieee.org ;branch=1 Via: SIP/2.0/UDP sip.ieee.org ;branch=1
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org;tag=87454273>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 INVITE CSeq: 1 INVITE
The proxy ACKs the response so that host H can stop retransmitting The proxy ACKs the response so that host H can stop retransmitting
it: it:
P->H: ACK sip:watson@h.bell-tel.com SIP/2.0 P->H: ACK sip:watson@h.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP proxy.ieee.org ;branch=1 Via: SIP/2.0/UDP sip.ieee.org ;branch=1
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org;tag=37462311>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 ACK CSeq: 1 ACK
Also, P attempts to reach Watson through the ACM server: Also, P attempts to reach Watson through the ACM server:
P->A: INVITE sip:watson@acm.org SIP/2.0 P->A: INVITE sip:watson@acm.org SIP/2.0
Via: SIP/2.0/UDP proxy.ieee.org ;branch=2 Via: SIP/2.0/UDP sip.ieee.org ;branch=2
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 INVITE CSeq: 1 INVITE
In parallel, the next attempt proceeds, with an INVITE to X and Y: In parallel, the next attempt proceeds, with an INVITE to X and Y:
P->X: INVITE sip:watson@x.bell-tel.com SIP/2.0 P->X: INVITE sip:watson@x.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP proxy.ieee.org ;branch=3 Via: SIP/2.0/UDP sip.ieee.org ;branch=3
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 INVITE CSeq: 1 INVITE
P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0 P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP proxy.ieee.org ;branch=4 Via: SIP/2.0/UDP sip.ieee.org ;branch=4
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 INVITE CSeq: 1 INVITE
As it happens, both Watson at X and a colleague in the other lab at As it happens, both Watson at X and a colleague in the other lab at
host Y hear the phones ringing and pick up. Both X and Y return 200s host Y hear the phones ringing and pick up. Both X and Y return 200s
via the proxy to Bell. The tag URI parameter is not strictly via the proxy to Bell.
necessary here, since the Location header is unambiguous.
X->P: SIP/2.0 200 OK X->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.ieee.org ;branch=3 Via: SIP/2.0/UDP sip.ieee.org ;branch=3
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
Location: sip:t.watson@x.bell-tel.com;tag=1620
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org;tag=192137601>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 INVITE CSeq: 1 INVITE
Location: sip:t.watson@x.bell-tel.com
Y->P: SIP/2.0 200 OK Y->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.ieee.org ;branch=4 Via: SIP/2.0/UDP sip.ieee.org ;branch=4
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
Location: sip:t.watson@y.bell-tel.com;tag=2016 Location: sip:t.watson@y.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org;tag=35253448>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 INVITE CSeq: 1 INVITE
Both responses are forwarded to Bell, using the Via information. At Both responses are forwarded to Bell, using the Via information. At
this point, the ACM server is still searching its database. P can now this point, the ACM server is still searching its database. P can now
cancel this attempt: cancel this attempt:
P->A: CANCEL sip:watson@acm.org SIP/2.0 P->A: CANCEL sip:watson@acm.org SIP/2.0
Via: SIP/2.0/UDP proxy.ieee.org ;branch=2 Via: SIP/2.0/UDP sip.ieee.org ;branch=2
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 CANCEL CSeq: 1 CANCEL
The ACM server gladly stops its neural-network database search and The ACM server gladly stops its neural-network database search and
responds with a 200. The 200 will not travel any further, since P is responds with a 200. The 200 will not travel any further, since P is
the last Via stop. the last Via stop.
A->P: SIP/2.0 200 OK A->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.ieee.org ;branch=3 Via: SIP/2.0/UDP sip.ieee.org ;branch=2
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@kton.bell-tel.com
CSeq: 19 CANCEL CSeq: 1 CANCEL
Bell gets the two 200 responses from X and Y in short order. Bell's Bell gets the two 200 responses from X and Y in short order. Bell's
reaction now depends on his software. He can either send an ACK to reaction now depends on his software. He can either send an ACK to
both if human intelligence is needed to determine who he wants to both if human intelligence is needed to determine who he wants to
talk to or he can automatically reject one of the two calls. Here, he talk to or he can automatically reject one of the two calls. Here, he
acknowledges both, separately and directly to the final destination: acknowledges both, separately and directly to the final destination:
C->X: ACK sip:watson@x.bell-tel.com SIP/2.0 C->X: ACK sip:watson@x.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org;tag=192137601>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 19 ACK CSeq: 1 ACK
C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0 C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org;tag=35253448>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 19 ACK CSeq: 1 ACK
After a brief discussion between the three, it becomes clear that After a brief discussion between the three, it becomes clear that
Watson is at X, thus Bell sends a BYE to Y, which is replied to: Watson is at X, thus Bell sends a BYE to Y, which is replied to:
C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0 C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org;tag=35253448>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 20 BYE CSeq: 2 BYE
Y->C: SIP/2.0 200 OK Y->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP c.bell-tel.com Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> To: T. Watson <sip:t.watson@ieee.org;tag=35253448>
Call-ID: 88323b2a-0a09-3888-88b4-2f93ee7808ea@c.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 20 BYE CSeq: 2 BYE
14.6 Redirects 15.6 Redirects
Replies with status codes 301 (Moved Permanently) or 302 (Moved Replies with status codes 301 (Moved Permanently) or 302 (Moved
Temporarily) specify another location using the Location field: Temporarily) specify another location using the Location field.
Continuing our earlier example, the server at ieee.org decides to
redirect rather than proxy the request:
S->C: SIP/2.0 302 Moved temporarily S->C: SIP/2.0 302 Moved temporarily
Via: SIP/2.0/UDP csvax.cs.caltech.edu ;branch=8348 Via: SIP/2.0/UDP sip.ieee.org
Via: SIP/2.0/UDP 128.16.64.19 From: A. Bell <sip:a.g.bell@bell-tel.com>
From: sip:mjh@isi.edu To: T. Watson <sip:t.watson@ieee.org;tag=72538263>
To: sip:schooler@cs.caltech.edu Call-ID: 31415@kton.bell-tel.com
Call-ID: 46842902-e7b0-3583-ae6a-bee550833c34@oregon.isi.edu CSeq: 1 INVITE
Location: sip:@239.128.16.254;ttl=16;transport=udp Location: sip:watson@h.bell-tel.com,
CSeq: 19 INVITE sip:watson@acm.org, sip:watson@x.bell-tel.com,
Content-Length: 0 sip:watson@y.bell-tel.com
CSeq: 1 INVITE
As another example, assume Alice wants to delegate her calls to Bob
while she is on vacation until July 29th. Any calls meant for her
will reach Bob with Alice's To field, indicating to him what role he
is to play. In the example below, Charlie calls Alice.
In this example, the proxy located at csvax.cs.caltech.edu is being S->C: SIP/2.0 302 Moved temporarily
advised to contact the multicast group 239.128.16.254 with a ttl of From: sip:charlie@caller.com
16 and UDP transport. In normal situations, a server would not To: sip:alice@anywhere.com;tag=2332462
suggest a redirect to a local multicast group unless, as in the above Call-ID: 27182@caller.com
situation, it knows that the previous proxy or client is within the Location: sip:bob@anywhere.com
scope of the local group. If the request is redirected to a multicast Expires: Wed, 29 Jul 1998 9:00:00 GMT
group, a proxy server SHOULD query the multicast address itself CSeq: 1 INVITE
rather than sending the redirect back towards the client as multicast
may be scoped; this allows a proxy within the appropriate scope
regions to make the query.
14.7 Alternative Services Charlie then sends the following request to the SIP server of the
anywhere.com domain.
An example of a 350 (Alternative Service) response is: C->S: INVITE sip:bob@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: sip:alice@anywhere.com
Call-ID: 27182@caller.com
CSeq: 2 INVITE
S->C: SIP/2.0 350 Alternative Service In the third redirection example, we assume that all requests are
directed through a local firewall at caller.com firewall happens to
be overloaded and thus redirects the call from Charlie to a secondary
server.
S->C: SIP/2.0 302 Moved temporarily
From: sip:charlie@caller.com
To: sip:alice@anywhere.com;tag=273462236
Call-ID: 27182@caller.com
CSeq: 2 INVITE
Location: sip:alice@anywhere.com:5080 ;maddr=secondary.caller.com
Charlie directs the invitation to the secondary server at port 5080,
but maintains the same Request-URI as before.
C->S: INVITE sip:alice@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: sip:alice@anywhere.com
Call-ID: 27182@caller.com
CSeq: 3 INVITE
15.7 Alternative Services
An example of a 380 (Alternative Service) response is:
S->C: SIP/2.0 380 Alternative Service
Via: SIP/2.0/UDP 131.215.131.131 Via: SIP/2.0/UDP 131.215.131.131
Via: SIP/2.0/UDP 128.16.64.19 Via: SIP/2.0/UDP 128.16.64.19
From: sip:mjh@isi.edu From: sip:mjh@isi.edu
To: sip:schooler@cs.caltech.edu To: sip:schooler@cs.caltech.edu;tag=11223647
Call-ID: 46842902-e7b0-3583-ae6a-bee550833c34oregon.isi.edu Call-ID: 14142@oregon.isi.edu
CSeq: 1 INVITE
Location: sip:recorder@131.215.131.131 Location: sip:recorder@131.215.131.131
CSeq: 19 INVITE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 146 Content-Length: 146
v=0 v=0
o=mm-server 2523535 0 IN IP4 131.215.131.131 o=mm-server 2523535 0 IN IP4 131.215.131.131
s=Answering Machine s=Answering Machine
i=Leave an audio message i=Leave an audio message
c=IN IP4 131.215.131.131 c=IN IP4 131.215.131.131
t=0 0 t=0 0
m=audio 12345 RTP/AVP 0 m=audio 12345 RTP/AVP 0
skipping to change at page 106, line 37 skipping to change at page 112, line 45
invitation request to the answering machine at 131.215.131.131 with invitation request to the answering machine at 131.215.131.131 with
the session description provided (modified as appropriate for a the session description provided (modified as appropriate for a
unicast session to contain the appropriate local address and port for unicast session to contain the appropriate local address and port for
the invitation initiator). This request SHOULD contain a different the invitation initiator). This request SHOULD contain a different
Call-ID from the one in the original request. An example would be: Call-ID from the one in the original request. An example would be:
C->S: INVITE sip:recorder@131.215.131.131 SIP/2.0 C->S: INVITE sip:recorder@131.215.131.131 SIP/2.0
Via: SIP/2.0/UDP 128.16.64.19 Via: SIP/2.0/UDP 128.16.64.19
From: sip:mjh@isi.edu From: sip:mjh@isi.edu
To: sip:schooler@cs.caltech.edu To: sip:schooler@cs.caltech.edu
Call-ID: 9469f230-70e0-3216-8482-fe1a2a150386@128.16.64.19 Call-ID: 1732@oregon.isi.edu
CSeq: 20 INVITE CSeq: 1 INVITE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 146 Content-Length: 146
v=0 v=0
o=mm-server 2523535 0 IN IP4 131.215.131.131 o=mm-server 2523535 0 IN IP4 131.215.131.131
s=Answering Machine s=Answering Machine
i=Leave an audio message i=Leave an audio message
c=IN IP4 128.16.64.19 c=IN IP4 128.16.64.19
t=0 0 t=0 0
m=audio 26472 RTP/AVP 0 m=audio 26472 RTP/AVP 0
skipping to change at page 107, line 4 skipping to change at page 113, line 15
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 146 Content-Length: 146
v=0 v=0
o=mm-server 2523535 0 IN IP4 131.215.131.131 o=mm-server 2523535 0 IN IP4 131.215.131.131
s=Answering Machine s=Answering Machine
i=Leave an audio message i=Leave an audio message
c=IN IP4 128.16.64.19 c=IN IP4 128.16.64.19
t=0 0 t=0 0
m=audio 26472 RTP/AVP 0 m=audio 26472 RTP/AVP 0
Invitation initiators MAY choose to treat a 350 (Alternative Service) Invitation initiators MAY choose to treat a 350 (Alternative Service)
response as a failure if they wish to do so. response as a failure if they wish to do so.
14.8 Negotiation 15.8 Negotiation
An example of a 606 (Not Acceptable) response is: An example of a 606 (Not Acceptable) response is:
S->C: SIP/2.0 606 Not Acceptable S->C: SIP/2.0 606 Not Acceptable
From: sip:mjh@isi.edu From: sip:mjh@isi.edu
To: sip:schooler@cs.caltech.edu To: sip:schooler@cs.caltech.edu;tag=7434264
Call-ID: 9469f230-70e0-3216-8482-fe1a2a150386@128.16.64.19 Call-ID: 14142@oregon.isi.edu
CSeq: 1 INVITE
Location: sip:mjh@131.215.131.131 Location: sip:mjh@131.215.131.131
Warning: 606.1 Insufficient bandwidth (only have ISDN), Warning: 606.1 Insufficient bandwidth (only have ISDN),
606.3 Incompatible format, 606.3 Incompatible format,
606.4 Multicast not available 606.4 Multicast not available
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 50 Content-Length: 50
v=0 v=0
s=Lets talk s=Lets talk
b=CT:128 b=CT:128
skipping to change at page 107, line 38 skipping to change at page 114, line 8
In this example, the original request specified 256 kb/s total In this example, the original request specified 256 kb/s total
bandwidth, and the response states that only 128 kb/s is available. bandwidth, and the response states that only 128 kb/s is available.
The original request specified GSM audio, H.261 video, and WB The original request specified GSM audio, H.261 video, and WB
whiteboard. The audio coding and whiteboard are not available, but whiteboard. The audio coding and whiteboard are not available, but
the response states that DVI, PCM or LPC audio could be supported in the response states that DVI, PCM or LPC audio could be supported in
order of preference. The response also states that multicast is not order of preference. The response also states that multicast is not
available. In such a case, it might be appropriate to set up a available. In such a case, it might be appropriate to set up a
transcoding gateway and re-invite the user. transcoding gateway and re-invite the user.
14.9 OPTIONS Request 15.9 OPTIONS Request
A caller Alice can use an OPTIONS request to find out the A caller Alice can use an OPTIONS request to find out the
capabilities of a potential callee Bob, without "ringing" the capabilities of a potential callee Bob, without "ringing" the
designated address. Bob returns a description indicating that he is designated address. Bob returns a description indicating that he is
capable of receiving audio and video, with a list of supported capable of receiving audio and video, with a list of supported
encodings. encodings.
C->S: OPTIONS sip:bob@example.com SIP/2.0 C->S: OPTIONS sip:bob@example.com SIP/2.0
From: Alice <sip:alice@anywhere.org> From: Alice <sip:alice@anywhere.org>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: 45869@host.anywhere.org Call-ID: 6378@host.anywhere.org
CSeq: 1 OPTIONS
Accept: application/sdp Accept: application/sdp
S->C: SIP/2.0 200 OK S->C: SIP/2.0 200 OK
From: Alice <sip:alice@anywhere.org> From: Alice <sip:alice@anywhere.org>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com;tag=376364382>
Call-ID: 45869@host.anywhere.org Call-ID: 6378@host.anywhere.org
Content-Length: 81 Content-Length: 81
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
m=audio 0 RTP/AVP 0 1 3 99 m=audio 0 RTP/AVP 0 1 3 99
m=video 0 RTP/AVP 29 30 m=video 0 RTP/AVP 29 30
a=rtpmap:99 SX7300/8000 a=rtpmap:99 SX7300/8000
A Minimal Implementation A Minimal Implementation
A.1 Client A.1 Client
All clients MUST be able to generate the INVITE and ACK requests. All clients MUST be able to generate the INVITE and ACK requests.
Clients MUST generate and parse the Call-ID, Content-Length, Clients MUST generate and parse the Call-ID, Content-Length,
Content-Type, CSeq, From and To headers. Clients MUST also parse Content-Type, CSeq, From and To headers. Clients MUST also parse the
the Require header. A minimal implementation MUST understand SDP (RFC Require header. A minimal implementation MUST understand SDP (RFC
2327, [5]). It MUST be able to recognize the status code classes 1 2327, [5]). It MUST be able to recognize the status code classes 1
through 6 and act accordingly. through 6 and act accordingly.
The following capability sets build on top of the minimal The following capability sets build on top of the minimal
implementation described in the previous paragraph: implementation described in the previous paragraph:
Basic: A basic implementation adds support for the BYE method to Basic: A basic implementation adds support for the BYE method to
allow the interruption of a pending call attempt. It includes a allow the interruption of a pending call attempt. It includes a
User-Agent header in its requests and indicate its preferred User-Agent header in its requests and indicate its preferred
language in the Accept-Language header. language in the Accept-Language header.
skipping to change at page 109, line 35 skipping to change at page 116, line 4
Table 5 lists the headers that different implementations support. UAC Table 5 lists the headers that different implementations support. UAC
refers to a user-agent client (calling user agent), UAS to a user- refers to a user-agent client (calling user agent), UAS to a user-
agent server (called user-agent). agent server (called user-agent).
B Usage of SDP B Usage of SDP
By default, the nth media session in a unicast INVITE request will By default, the nth media session in a unicast INVITE request will
become a single RTP session with the nth media session in the become a single RTP session with the nth media session in the
response. Thus, the callee should be careful to order media response. Thus, the callee should be careful to order media
descriptions appropriately.
It is assumed that if caller or callee include a particular media
type, they want to both send and receive media data. If the callee
does not want to send a particular media type, it should mark the
media entry as recvonly receive a particular media type, it may mark
it as sendonly wants to neither receive nor send a particular media
type, it should set the port to zero. (RTCP ports are not needed in
this case.)
The caller should include all media types that it is willing to send
so that the receiver can provide matching media descriptions.
The callee should set the port to zero if callee and caller only want
to receive a media type.
type UAC proxy UAS type UAC proxy UAS
__________________________________________________ __________________________________________________
Accept R - o o Accept R - o o
Accept-Language R - b b Accept-Language R - b b
Allow 405 o - - Allow 405 o - -
Authorization R a o a Authorization R a o a
Call-ID g m m m Call-ID g m m m
Content-Length g m m m Content-Length g m m m
Content-Type g m - m Content-Type g m - m
CSeq g o m m CSeq g m m m
Encryption g e - e Encryption g e - e
Expires g - o o Expires g - o o
From R m o m From g m o m
Location R - - - Location R - - -
Location r r r - Location r r r -
Max-Forwards R - b - Max-Forwards R - b -
Proxy-Authenticate 407 a - - Proxy-Authenticate 407 a - -
Proxy-Authorization R - a - Proxy-Authorization R - a -
Proxy-Require R - m - Proxy-Require R - m -
Require R m - m Require R m - m
Response-Key R - - e Response-Key R - - e
Timestamp g o o m Timestamp g o o m
To g m m m To g m m m
Unsupported r b b - Unsupported r b b -
Via g - m m Via g m m m
WWW-Authenticate 401 a - - WWW-Authenticate 401 a - -
Table 5: This table indicates which systems should be able to parse Table 5: This table indicates which systems should be able to parse
which response header fields. Type is as in Table 4. "-" indicates which header fields. Type is as in Table 4. "-" indicates the field
the field is not meaningful to this system (although it might be is not meaningful to this system (although it might be generated by
generated by it). "m" indicates the field MUST be understood. "b" it). "m" indicates the field MUST be understood. "b" indicates the
indicates the field SHOULD be understood by a Basic implementation. field SHOULD be understood by a Basic implementation. "r" indicates
"r" indicates the field SHOULD be understood if the system claims to the field SHOULD be understood if the system claims to understand
understand redirection. "a" indicates the field SHOULD be understood redirection. "a" indicates the field SHOULD be understood if the
if the system claims to support authentication. "e" indicates the system claims to support authentication. "e" indicates the field
field SHOULD be understood if the system claims to support SHOULD be understood if the system claims to support encryption. "o"
encryption. "o" indicates support of the field is purely optional. indicates support of the field is purely optional. Headers whose
Headers whose support is optional for all implementations are not support is optional for all implementations are not shown.
shown.
descriptions appropriately.
It is assumed that if caller or callee include a particular media
type, they want to both send and receive media data. If the callee
does not want to send a particular media type, it should mark the
media entry as recvonly receive a particular media type, it may mark
it as sendonly wants to neither receive nor send a particular media
type, it should set the port to zero. (RTCP ports are not needed in
this case.)
The caller should include all media types that it is willing to send
so that the receiver can provide matching media descriptions.
The callee should set the port to zero if callee and caller only want
to receive a media type.
C Summary of Augmented BNF C Summary of Augmented BNF
In this specification we use the Augmented Backus-Naur Form notation In this specification we use the Augmented Backus-Naur Form notation
described in RFC 2234 [21]. For quick reference, the following is a described in RFC 2234 [21]. For quick reference, the following is a
brief summary of the main features of this ABNF. brief summary of the main features of this ABNF.
"abc" "abc"
The case-insensitive string of characters "abc" (or "Abc", The case-insensitive string of characters "abc" (or "Abc",
"aBC", etc.); "aBC", etc.);
skipping to change at page 111, line 46 skipping to change at page 118, line 11
2#4term 2#4term
a comma separated list of term containing 2 to 4 items. a comma separated list of term containing 2 to 4 items.
Common Tokens Common Tokens
Certain tokens are used frequently in the BNF of this document, and Certain tokens are used frequently in the BNF of this document, and
not defined elsewhere. Their meaning is well understood but we not defined elsewhere. Their meaning is well understood but we
include it here for completeness. include it here for completeness.
CR = %d13 ; carriage return character CR = %d13 ; US-ASCII CR, carriage return character
LF = %d10 ; line feed character LF = %d10 ; US-ASCII LF, line feed character
CRLF = CR LF ; typically the end of a line CRLF = CR LF ; typically the end of a line
SP = %d32 ; space character SP = %d32 ; US-ASCII SP, space character
TAB = %d09 ; tab character HT = %d09 ; US-ASCII HT, horizontal tab character
LWS = *( SP | TAB) ; linear whitespace LWS = [CRLF] 1*( SP | HT ) ; linear whitespace
DIGIT = "0" .. "9" ; a single decimal digit DIGIT = "0" .. "9" ; a single decimal digit
CHAR = <any US-ASCII character (octets 0 - 127)>
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
OCTET = <any 8-bit sequence of data>
TEXT = <any OCTET except CTLs, but including LWS>
unreserved = alphanum | mark unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" mark = "-" | "_" | "." | "!" | "~" | "*" | "'"
| "(" | ")" | "(" | ")"
separators = "(" | ")" | "<" | ">" | "@" |
"," | ";" | ":" | "/" | <"> |
"/" | "[" | "]" | "?" | "=" |
"" | "" | SP | HT
escaped = "%" hex hex escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f" "a" | "b" | "c" | "d" | "e" | "f"
alphanum = alpha | digit alphanum = alpha | digit
alpha = lowalpha | upalpha alpha = lowalpha | upalpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9" "8" | "9"
token = 1*<any CHAR except CTL's or separators>
comment = "(" *(ctext | quoted-pair | comment) ")"
ctext = <any TEXT excluding "(" and ")">
D IANA Considerations D IANA Considerations
Section 4.4 describes a name space and mechanism for registering SIP Section 4.4 describes a name space and mechanism for registering SIP
options. options.
Section 6.41 describes the name space for registering SIP warn-codes. Section 6.41 describes the name space for registering SIP warn-codes.
E Changes in Version -07 E Changes in Version -08
Since version -06, the following changes have been made.
o Removed references to Internet Drafts.
o Expanded URI definition to be independent of I-Ds.
o Clarified redirect behavior for BYE.
o Call-ID mandatory for all requests to allow to match requests Since version -07, the following changes have been made.
with responses.
o Clarified that INVITE retransmit limit only applies if there o Allow maddr to contain host names, not just IP multicast
has been no provisional response. Otherwise, call queueing is addresses. This is useful to allow multicast addresses of the
not possible. form mcast.net as well as for redirecting requests to a
different server without changing the Request-URI. Added note
to that effect to description of 302.
o Removed open issues list. o Added references to symbolic name sip.mcast.net
o Removed REGISTER as special case of reliability mechanism. o REGISTER requests without Location are quite useful to obtain
the current lists of registrations.
o Split out large syntax diagrams into figures to avoid empty o Added "comment" to Location header to allow responses like
space. Location: alice@example.com (Alice) solution conforming to the
format of From and To is, unfortunately, not backward
compatible with HTTP.
o Abstract rewritten to reflect current protocol functionality. o Allow Content-Length to be optional, in line with HTTP. This
does not seem to complicate matters, but makes the processing
of cgi-style output much easier, since the server doesn't have
to store the output to compute the Content-Length.
o Reorganized "SIP Transport" chapter to more clearly reflect o Fixed table 4: CSeq is now mandatory for all requests.
behavior for UDP and TCP.
o Modified syntax for Via to include multicast address as a o Since To, From, and Call-ID are used as a callleg identifier
parameter. even in proxies, encryption of From needs to be disallowed.
o "Ambiguous" status code moved from 381 to 485, to give o Organization is now a general header; no reason not to allow