draft-ietf-mmusic-sip-09.txt   draft-ietf-mmusic-sip-10.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-09.txt ISI/Columbia U./Caltech/Bell Labs. ietf-mmusic-sip-10.txt ISI/Columbia U./Caltech/Bell Labs.
September 18, 1998 November 12, 1998
Expires: February 1999 Expires: May 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 1, line 44 skipping to change at page 1, line 44
layer control (signaling) protocol for creating, layer control (signaling) protocol for creating,
modifying and terminating sessions with one or more modifying and terminating sessions with one or more
participants. These sessions include Internet multimedia participants. These sessions include Internet multimedia
conferences, Internet telephone calls and multimedia conferences, Internet telephone calls and multimedia
distribution. Members in a session can communicate via distribution. Members in a session can communicate via
multicast or via a mesh of unicast relations, or a multicast or via a mesh of unicast relations, or a
combination of these. combination of these.
SIP invitations used to create sessions carry session SIP invitations used to create sessions carry session
descriptions which allow participants to agree on a set descriptions which allow participants to agree on a set
of compatible media types. It supports user mobility by of compatible media types. SIP supports user mobility by
proxying and redirecting requests to the user's current proxying and redirecting requests to the user's current
location. Users can register their current location. SIP location. Users can register their current location. SIP
is not tied to any particular conference control is not tied to any particular conference control
protocol. SIP is designed to be independent of the protocol. SIP is designed to be independent of the
lower-layer transport protocol and can be extended with lower-layer transport protocol and can be extended with
additional capabilities. additional capabilities.
This document is a product of the Multi-party Multimedia This document is a product of the Multi-party Multimedia
Session Control (MMUSIC) working group of the Internet Session Control (MMUSIC) working group of the Internet
Engineering Task Force. Comments are solicited and Engineering Task Force. Comments are solicited and
skipping to change at page 2, line 35 skipping to change at page 2, line 35
added to an existing session. added to an existing session.
SIP can be used to initiate sessions as well as invite members to SIP can be used to initiate sessions as well as invite members to
sessions that have been advertised and established by other means. sessions that have been advertised and established by other means.
Sessions can be advertised using multicast protocols such as SAP, Sessions can be advertised using multicast protocols such as SAP,
electronic mail, news groups, web pages or directories (LDAP), among electronic mail, news groups, web pages or directories (LDAP), among
others. others.
SIP transparently supports name mapping and redirection services, SIP transparently supports name mapping and redirection services,
allowing the implementation of ISDN and Intelligent Network telephony allowing the implementation of ISDN and Intelligent Network telephony
subscriber services. These facilities also enable personal mobility subscriber services. These facilities also enable personal mobility.
services, this is defined as: "Personal mobility is the ability of In the parlance of telecommunications intelligent network services,
end users to originate and receive calls and access subscribed this is defined as: "Personal mobility is the ability of end users to
telecommunication services on any terminal in any location, and the originate and receive calls and access subscribed telecommunication
ability of the network to identify end users as they move. Personal services on any terminal in any location, and the ability of the
mobility is based on the use of a unique personal identity (i.e., network to identify end users as they move. Personal mobility is
mobility complements terminal mobility, i.e., the ability to maintain based on the use of a unique personal identity (i.e., personal
communications when moving a single end system from one subnet to number)." [1]. Personal mobility complements terminal mobility, i.e.,
another. the ability to maintain communications when moving a single end
system from one subnet to another.
SIP supports five facets of establishing and terminating multimedia SIP supports five facets of establishing and terminating multimedia
communications: communications:
User location: determination of the end system to be used for User location: determination of the end system to be used for
communication; communication;
User capabilities: determination of the media and media parameters to User capabilities: determination of the media and media parameters to
be used; be used;
User availability: determination of the willingness of the called User availability: determination of the willingness of the called
party to engage in communications; party to engage in communications;
Call setup: "ringing", establishment of call parameters at both Call setup: "ringing", establishment of call parameters at both
called and calling party; called and calling party;
Call handling: including transfer and termination of calls. Call handling: including transfer and termination of calls.
skipping to change at page 3, line 16 skipping to change at page 3, line 17
User availability: determination of the willingness of the called User availability: determination of the willingness of the called
party to engage in communications; party to engage in communications;
Call setup: "ringing", establishment of call parameters at both Call setup: "ringing", establishment of call parameters at both
called and calling party; called and calling party;
Call handling: including transfer and termination of calls. Call handling: including transfer and termination of calls.
SIP can also initiate multi-party calls using a multipoint control SIP can also initiate multi-party calls using a multipoint control
unit (MCU) or fully-meshed interconnection instead of multicast. unit (MCU) or fully-meshed interconnection instead of multicast.
Internet telephony gateways that connect PSTN parties can also use Internet telephony gateways that connect Public Switched Telephone
SIP to set up calls between them. Network (PSTN) parties can also use SIP to set up calls between them.
SIP is designed as part of the overall IETF multimedia data and SIP is designed as part of the overall IETF multimedia data and
control architecture currently incorporating protocols such as RSVP control architecture currently incorporating protocols such as RSVP
(RFC 2205 [2]) for reserving network resources, the real-time (RFC 2205 [2]) for reserving network resources, the real-time
transport protocol (RTP) (RFC 1889 [3]) for transporting real-time transport protocol (RTP) (RFC 1889 [3]) for transporting real-time
data and providing QOS feedback, the real-time streaming protocol data and providing QOS feedback, the real-time streaming protocol
(RTSP) (RFC 2326 [4]) for controlling delivery of streaming media, (RTSP) (RFC 2326 [4]) for controlling delivery of streaming media,
the session announcement protocol (SAP) for advertising multimedia the session announcement protocol (SAP) [5] for advertising
sessions via multicast and the session description protocol (SDP) multimedia sessions via multicast and the session description
(RFC 2327 [5]) for describing multimedia sessions. However, the protocol (SDP) (RFC 2327 [6]) for describing multimedia sessions.
functionality and operation of SIP does not depend on any of these However, the functionality and operation of SIP does not depend on
protocols. any of these protocols.
SIP can also be used in conjunction with other call setup and SIP can also be used in conjunction with other call setup and
signaling protocols. In that mode, an end system uses SIP exchanges signaling protocols. In that mode, an end system uses SIP exchanges
to determine the appropriate end system address and protocol from a to determine the appropriate end system address and protocol from a
given address that is protocol-independent. For example, SIP could be given address that is protocol-independent. For example, SIP could be
used to determine that the party can be reached via H.323, obtain the used to determine that the party can be reached via H.323 [7], obtain
H.245 gateway and user address and then use H.225.0 to establish the the H.245 [8] gateway and user address and then use H.225.0 [9] to
call. establish the call.
In another example, SIP might be used to determine that the callee is In another example, SIP might be used to determine that the callee is
reachable via the public switched telephone network (PSTN) and reachable via the PSTN and indicate the phone number to be called,
indicate the phone number to be called, possibly suggesting an possibly suggesting an Internet-to-PSTN gateway to be used.
Internet-to-PSTN gateway to be used.
SIP does not offer conference control services such as floor control SIP does not offer conference control services such as floor control
or voting and does not prescribe how a conference is to be managed, or voting and does not prescribe how a conference is to be managed,
but SIP can be used to introduce conference control protocols. SIP but SIP can be used to introduce conference control protocols. SIP
does not allocate multicast addresses. does not allocate multicast addresses.
SIP can invite users to sessions with and without resource SIP can invite users to sessions with and without resource
reservation. SIP does not reserve resources, but can convey to the reservation. SIP does not reserve resources, but can convey to the
invited system the information necessary to do this. invited system the information necessary to do this.
1.2 Terminology 1.2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [6] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [10]
indicate requirement levels for compliant SIP implementations. and indicate requirement levels for compliant SIP implementations.
1.3 Definitions 1.3 Definitions
This specification uses a number of terms to refer to the roles This specification uses a number of terms to refer to the roles
played by participants in SIP communications. The definitions of played by participants in SIP communications. The definitions of
client, server and proxy are similar to those used by the Hypertext client, server and proxy are similar to those used by the Hypertext
Transport Protocol (HTTP) (RFC 2068 [7]). The terms URI and URL are Transport Protocol (HTTP) (RFC 2068 [11]). The terms and generic
defined in [8]. The following terms have special significance for syntax of URI and URL are defined in RFC 2396 [12]. The following
SIP. terms have special significance for SIP.
Call: A call consists of all participants in a conference invited by Call: A call consists of all participants in a conference invited by
a common source. A SIP call is identified by a globally unique a common source. A SIP call is identified by a globally unique
call-id (Section 6.12). Thus, if a user is, for example, invited call-id (Section 6.12). Thus, if a user is, for example, invited
to the same multicast session by several people, each of these to the same multicast session by several people, each of these
invitations will be a unique call. A point-to-point Internet invitations will be a unique call. A point-to-point Internet
telephony conversation maps into a single SIP call. In a MCU- telephony conversation maps into a single SIP call. In a
based call-in conference, each participant uses a separate call multiparty conference unit (MCU) based call-in conference, each
to invite himself to the MCU. participant uses a separate call to invite himself to the MCU.
Call leg: A call leg is identified by the combination of Call-ID, To Call leg: A call leg is identified by the combination of Call-ID, To
and From. and From.
Client: An application program that establishes connections for the Client: An application program that sends SIP requests. Clients may
purpose of sending requests. Clients may or may not interact or may not interact directly with a human user. User agents and
directly with a human user. User agents and proxies contain proxies contain clients (and servers).
clients (and servers).
Conference: A multimedia session (see below), identified by a common Conference: A multimedia session (see below), identified by a common
session description. A conference can have zero or more members session description. A conference can have zero or more members
and includes the cases of a multicast conference, a full-mesh and includes the cases of a multicast conference, a full-mesh
conference and a two-party "telephone call", as well as conference and a two-party "telephone call", as well as
combinations of these. Any number of calls can be used to combinations of these. Any number of calls can be used to
create a conference. create a conference.
Downstream: Requests sent in the direction from the caller to the Downstream: Requests sent in the direction from the caller to the
callee. callee (i.e., user agent client to user agent server).
Final response: A response that terminates a SIP transaction, as Final response: A response that terminates a SIP transaction, as
opposed to a provisional response that does not. All 2xx, 3xx, opposed to a provisional response that does not. All 2xx, 3xx,
4xx, 5xx and 6xx responses are final. 4xx, 5xx and 6xx responses are final.
Initiator, calling party, caller: The party initiating a conference Initiator, calling party, caller: The party initiating a conference
invitation. Note that the calling party does not have to be the invitation. Note that the calling party does not have to be the
same as the one creating the conference. same as the one creating the conference.
Invitation: A request sent to a user (or service) requesting Invitation: A request sent to a user (or service) requesting
skipping to change at page 6, line 18 skipping to change at page 6, line 18
Ringback: Ringback is the signaling tone produced by the calling Ringback: Ringback is the signaling tone produced by the calling
client's application indicating that a called party is being client's application indicating that a called party is being
alerted (ringing). alerted (ringing).
Server: A server is an application program that accepts requests in Server: A server is an application program that accepts requests in
order to service requests and sends back responses to those order to service requests and sends back responses to those
requests. Servers are either proxy, redirect or user agent requests. Servers are either proxy, redirect or user agent
servers or registrars. servers or registrars.
Session: "A multimedia session is a set of multimedia senders and Session: From the SDP specification: "A multimedia session is a set
receivers and the data streams flowing from senders to of multimedia senders and receivers and the data streams flowing
receivers. A multimedia conference is an example of a multimedia from senders to receivers. A multimedia conference is an example
session." (RFC 2327 [5]) (A session as defined for SDP can of a multimedia session." (RFC 2327 [6]) (A session as defined
comprise one or more RTP sessions.) As defined, a callee can be for SDP can comprise one or more RTP sessions.) As defined, a
invited several times, by different calls, to the same session. callee can be invited several times, by different calls, to the
If SDP is used, a session is defined by the concatenation of the same session. If SDP is used, a session is defined by the
user name , session id , network type , address type and address concatenation of the user name , session id , network type ,
elements in the origin field. address type and address 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.17) within a single call by the CSeq sequence number (Section 6.17) 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 its corresponding INVITE request, but comprises a transaction of its
own. own.
Upstream: Responses sent in the direction from the called client to Upstream: Responses sent in the direction from the user agent server
the caller. to the user agent client.
URL-encoded: A character string encoded according to RFC 1738, URL-encoded: A character string encoded according to RFC 1738,
Section 2.2 [9]. Section 2.2 [13].
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.
User agent server (UAS), called user agent: A user agent server is a User agent server (UAS), called user agent: A user agent server is a
server application that contacts the user when a SIP request is server application that contacts the user when a SIP request is
received and that returns a response on behalf of the user. The received and that returns a response on behalf of the user. The
response accepts, rejects or redirects the request. response accepts, rejects or redirects the request.
An application program MAY be capable of acting both as a client and An application program MAY be capable of acting both as a client and
skipping to change at page 7, line 24 skipping to change at page 7, line 24
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
1.4 Summary of SIP Operation 1.4 Overview of SIP Operation
This section explains the basic protocol functionality and operation. This section explains the basic protocol functionality and operation.
Callers and callees are identified by SIP addresses, described in Callers and callees are identified by SIP addresses, described in
Section 1.4.1. When making a SIP call, a caller first locates the Section 1.4.1. When making a SIP call, a caller first locates the
appropriate server (Section 1.4.2) and then sends a SIP request appropriate server (Section 1.4.2) and then sends a SIP request
(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 a form similar to a mailto or telnet URL,
URL, i.e., user@host user part is a user name, a civil name or a i.e., user@host user part is a user name, a civil name or a telephone
telephone number. The host part is either a domain name having a DNS number. The host part is either a domain name having a DNS SRV (RFC
SRV (RFC 2052 [10]), MX (RFC 974 [11], CNAME or A record (RFC 1035 2052 [14]), CNAME or A record (RFC 1035 [15]), or a numeric network
[12]), or a numeric network address. 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.
Examples of SIP URLs include: Examples of SIP URLs include:
sip:mjh@metro.isi.edu sip:mjh@metro.isi.edu
sip:watson@bell-telephone.com sip:watson@bell-telephone.com
sip:root@193.175.132.42 sip:root@193.175.132.42
sip:info@ietf.org sip:info@ietf.org
A SIP URL address can designate an individual (possibly located at A SIP URL address can designate an individual (possibly located at
one of several end systems), the first available person from a group one of several end systems), the first available person from a group
of individuals or a whole group. The form of the address, e.g., of individuals or a whole group. The form of the address, for
sip:sales@example.com , is not sufficient, in general, to determine example, sip:sales@example.com , is not sufficient, in general, to
the intent of the caller. determine the intent of the caller.
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
skipping to change at page 8, line 48 skipping to change at page 8, line 48
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
UDP, the socket needs to be bound to the destination address using UDP, the socket needs to be bound to the destination address using
connect() rather than sendto() or similar so that a second write() connect() rather than sendto() or similar so that a second write()
fails with ECONNREFUSED. ) fails with ECONNREFUSED. ) If it finds the server is not reachable
at a particular address, it SHOULD behave as if it received a 400-
class error response to that request.
If the SIP address contains a numeric IP address, the client contacts If the SIP address contains a numeric IP address, the client contacts
the SIP server at that address. Otherwise, the client follows the the SIP server at that address. Otherwise, the client follows the
steps below. steps below.
1. If there is a SRV DNS resource record (RFC 2052 [10]) of 1. If there is a SRV DNS resource record (RFC 2052 [14]) of
type sip.udp or type sip.tcp, order all such records by type sip.udp or type sip.tcp, order all such records by
their priority value and attempt to contact the servers in their priority value and attempt to contact the servers in
that order. If a port number is explicitly specified in the that order. If a port number is explicitly specified in the
SIP URL, it overrides the port number in the SRV record. It SIP URL, it overrides the port number in the SRV record. It
is RECOMMENDED that DNS zone files give higher weight to is RECOMMENDED that DNS zone files give higher weight to
servers running UDP than those running TCP. If a server servers running UDP than those running TCP. If a server
responds, skip the remaining steps below. responds, skip the remaining steps below.
2. If there is a DNS MX record (RFC 974 [11]), contact the 2. Check if there is a DNS CNAME or A record for the given
hosts listed in their order of preference at the port host and try to contact a SIP server at the one or more
number listed in the URL or the default SIP port number if addresses listed, again trying first UDP, then TCP. If a
none. For each host listed, first try to contact the SIP server responds, skip the remaining step.
server using UDP, then TCP. If a server responds, skip the
remaining steps.
3. Finally, check if there is a DNS CNAME or A record for the
given host and try to contact a SIP server at the one or
more addresses listed, again trying first UDP, then TCP. If
a server responds, skip the remaining step.
4. If all of the above methods fail to locate a server, the 3. If all of the above methods fail to locate a server, the
caller MAY contact an SMTP server at the user's host and caller MAY contact an SMTP server at the user's host and
use the SMTP EXPN command to obtain an alternate address use the SMTP EXPN command to obtain an alternate address
and repeat the steps above. As a last resort, a client MAY and repeat the steps above. As a last resort, a client MAY
choose to deliver the session description to the callee choose to deliver the session description to the callee
using electronic mail. using electronic mail, encapsulating it as a MIME [16]
attachment. This allows mail readers with automated
processing of attachments to start the appropriate tool.
Alternatively, the human user can examine the session
description and take whatever actions they like.
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 request. particular address and retry that host address for the next request.
If the client does not find a SIP server at the cached address, it It SHOULD honor DNS TTL's and expire the cache entry at the
MUST start the search at the beginning of the sequence. appropriate time. If the client does not find a SIP server at the
cached address, it MUST start the search at the beginning of the
sequence.
This sequence is modeled after that described for SMTP, An organization MAY use sip. domain as the name CNAME or A name of
where MX records are to be checked before A records (RFC its SIP server, according to RFC 2219 [17]. A client MAY attempt to
1123 [13]). contact a server with the name sip. domain when given the address
user@domain.
This suggestion allows a reasonably smooth transition until
the widespread deployment of DNS SRV records.
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 the transaction. All responses to a request contain the same values in
the Call-ID, CSeq, To, and From fields (with the possible addition of
a tag in the To field 6.37). This allows responses to be matched with
requests. The ACK request following an INVITE is not part of 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
skipping to change at page 10, line 32 skipping to change at page 10, line 38
A successful SIP invitation consists of two requests, INVITE followed A successful SIP invitation consists of two requests, INVITE followed
by ACK. The INVITE (Section 4.2.1) request asks the callee to join a by ACK. The INVITE (Section 4.2.1) request asks the callee to join a
particular conference or establish a two-party conversation. After particular conference or establish a two-party conversation. After
the callee has agreed to participate in the call, the caller confirms the callee has agreed to participate in the call, the caller confirms
that it has received that response by sending an ACK (Section 4.2.2) that it has received that response by sending an ACK (Section 4.2.2)
request. If the caller no longer wants to participate in the call, it request. If the caller no longer wants to 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 [6]) 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 are allowed to be distributed to that session. types and formats that are allowed to be distributed to that session.
For a unicast session, the session description enumerates the media For a unicast session, the session description enumerates the media
types and formats that the caller is willing to receive and where it types 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 the media data to be sent. In either case, if the callee
wishes to accept the call, it responds to the invitation by returning wishes to accept the call, it responds to the invitation by returning
a similar description listing the media it wishes to receive. For a a similar description listing the media it wishes to receive. For a
multicast session, the callee SHOULD only return a session multicast session, the callee SHOULD only return a session
description if it is unable to receive the media indicated in the description if it is unable to receive the media indicated in the
skipping to change at page 11, line 13 skipping to change at page 11, line 19
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). Note that an ACK can also be sent directly to the callee, 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- bypassing the proxy. All requests and responses have the same Call-
ID. ID.
The transport, maddr, and ttl 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 "?"
mechanism within a SIP URL. The special hname "body" indicates
that the associated hvalue is the message-body of the SIP INVITE
request. Headers MUST NOT be used in the From and To header
fields and the Request-URI; they are ignored if present.
Method: The method of the SIP request can be specified with the
method parameter. This parameter MUST NOT be used in the From
and To header fields and the Request-URI; they are ignored if
present.
Table 2 summarizes where the components of the SIP URL can be used
and what default values they assume if not present.
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:alice@10.1.2.3
sip:alice@example.com
sip:alice
sip:alice@registrar.com;method=REGISTER
Within a SIP message, URLs are used to indicate the source and
intended destination of a request, redirection addresses and the
current destination of a request. Normally all these fields will
contain SIP URLs.
SIP URLs are case-insensitive, so that for example the two URLs
sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All
URL parameters are included when comparing SIP URLs for equality.
SIP header fields MAY contain non-SIP URLs. As an example, if a call
from a telephone is relayed to the Internet via SIP, the SIP From
header field might contain a phone URL.
3 SIP Message Overview
SIP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 2279 [22]). Lines are terminated by CRLF, but
receivers MUST also interpret CR and LF by themselves as line
terminators.
Except for the above difference in character sets, much of the
message syntax is identical to HTTP/1.1; rather than repeating it
here we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1
specification (RFC 2068 [11]). In addition, we describe SIP in both
prose and an augmented Backus-Naur form (BNF) [H2.1] described in
detail in RFC 2234 [23].
Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP
transactions can be carried in a single TCP connection or UDP
datagram. UDP datagrams, including all headers, SHOULD NOT be larger
than the path maximum transmission unit (MTU) if the MTU is known, or
1400 bytes if the MTU is unknown.
The 1400 bytes accommodates lower-layer packet headers
within the "typical" MTU of around 1500 bytes. Recent
studies [24] indicate that an MTU of 1500 bytes is a
reasonable assumption. The next lower common MTU values are
1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191
[25]). Thus, another reasonable value would be a message
size of 950 bytes, to accommodate packet headers within the
SLIP MTU without fragmentation.
A SIP message is either a request from a client to a server, or a
response from a server to a client.
+....... cs.columbia.edu .......+ +....... cs.columbia.edu .......+
: : : :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ( location ) : : ( location ) :
: ( service ) : : ( service ) :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ^ | : : ^ | :
: | hgs@play : : | hgs@lab :
: 2| 3| : : 2| 3| :
: | | : : | | :
: henning | : : henning | :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | : +.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | | 4: INVITE 5: ring : : : henning@cs.col: | \/ 4: INVITE 5: ring :
: cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) : : cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) :
: <........................( )<.........( ) : : <........................( )<.........( ) :
: : 7: 200 OK : ( )6: 200 OK ( ) : : : 7: 200 OK : ( )6: 200 OK ( ) :
: : : ( tune ) ( play ) : : : : ( work ) ( lab ) :
: : 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 ACK address to the caller (step 4), which is then acknowledged via an 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).
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@lab : ( work ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( lab ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+
====> SIP request
....> SIP response
^
| non-SIP protocols
|
Figure 2: Example of SIP redirect server
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
A callee may move between a number of different end systems over A callee may move between a number of different end systems over
time. These locations can be dynamically registered with the SIP time. These locations can be dynamically registered with the SIP
server (Sections 1.4.7, 4.2.6). A location server MAY also use one or server (Sections 1.4.7, 4.2.6). A location server MAY also use one or
more other protocols, such as finger (RFC 1288 [14]), rwhois (RFC more other protocols, such as finger (RFC 1288 [18]), rwhois (RFC
2167 [15]), LDAP (RFC 1777 [16]), multicast-based protocols [17] or 2167 [19]), LDAP (RFC 1777 [20]), multicast-based protocols [21] or
operating-system dependent mechanisms to actively determine the end operating-system dependent mechanisms to actively determine the end
system where a user might be reachable. A location server MAY return system where a user might be reachable. A location server MAY return
several locations because the user is logged in at several hosts several locations because the user is logged in at several hosts
simultaneously or because the location server has (temporarily) simultaneously or because the location server has (temporarily)
inaccurate information. The SIP server combines the results to yield inaccurate information. The SIP server combines the results to yield
a list of a zero or more locations. It is recommended that each a list of a zero or more locations. It is RECOMMENDED that each
location server sorts results according to the likelihood of success. location server sorts results according to the likelihood of success.
The action taken on receiving a list of locations varies with the The action taken on receiving a list of locations varies with the
type of SIP server. A SIP redirect server returns the list to the type of SIP server. A SIP redirect server returns the list to the
client as Contact headers (Section 6.13). A SIP proxy server can client as Contact headers (Section 6.13). A SIP proxy server can
sequentially or in parallel try the addresses until the call is sequentially or in parallel try the addresses until the call is
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.
skipping to change at page 12, line 50 skipping to change at page 15, line 43
not generate a request to a host listed in the Via sent-by, via- not generate a request to a host listed in the Via sent-by, via-
received or via-maddr parameters (Section 6.40). (Note: If a host has received or via-maddr parameters (Section 6.40). (Note: If a host has
several names or network addresses, this does not always work. Thus, several names or network addresses, this does not always work. Thus,
each host also checks if it is part of the Via list.) 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 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 of these "forks" the request, i.e., issues more than one request in
response to receiving the invitation request, it is possible that a response to receiving the invitation request, it is possible that a
client is reached, independently, by more than one copy of the client is reached, independently, by more than one copy of the
invitation request. Each of these copies bears the same Call-ID. 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 same status response returned in the first
+....... cs.columbia.edu .......+ response. Duplicate requests are not an error.
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@play :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | | :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@play : ( tune ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@play.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( play ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+
====> SIP request
....> SIP response
----> non-SIP protocols
Figure 2: Example of SIP redirect server
requests are not an error.
1.4.6 Changing an Existing Session 1.4.6 Changing an Existing Session
In some circumstances, it is desirable to change the parameters of an In some circumstances, it is desirable to change the parameters of an
existing session. For example, two parties may have been conversing existing session. For example, two parties may have been conversing
and then want to add a third party, switching to multicast for and then want to add a third party, switching to multicast for
efficiency. One of the participants invites the third party with the efficiency. One of the participants invites the third party with the
new multicast address and simultaneously sends an INVITE to the new multicast address and simultaneously sends an INVITE to the
second party, with the new multicast session description, but with second party, with the new multicast session description, but with
the old call identifier. the old call identifier.
1.4.7 Registration Services
The REGISTER request allows a client to let a proxy or redirect The REGISTER request allows a client to let a proxy or redirect
server know at which address(es) it can be reached. A client MAY also server know at which address(es) it can 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 involves one or more SIP A single conference session or call involves one or more SIP
request-response transactions. Proxy servers do not have to keep request-response transactions. Proxy servers do not have to keep
skipping to change at page 15, line 21 skipping to change at page 17, line 5
1.5.3 Text-Based 1.5.3 Text-Based
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
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) of (From), current destination (Request-URI) and final recipient (To) of
a SIP request, and to specify redirection addresses (Contact). A SIP a SIP request, and to specify redirection addresses (Contact). A SIP
URL can also be embedded in web pages or other hyperlinks to indicate URL can also be embedded in web pages or other hyperlinks to indicate
that a particular user or service can be called via SIP. When used that a particular user or service can be called via SIP. When used as
as a hyperlink, the SIP URL indicates the use of the INVITE method. a hyperlink, the SIP URL indicates the use of the INVITE method.
The SIP URL scheme is defined to allow setting SIP request-header The SIP URL scheme is defined to allow setting SIP request-header
fields and the SIP message-body. fields and the SIP message-body.
This corresponds to the use of mailto: URLs. It makes it This corresponds to the use of mailto: URLs. It makes it
possible, for example, to specify the subject, urgency or possible, for example, to specify the subject, urgency or
media types of calls initiated through a web page or as media types of calls initiated through a web page or as
part of an email message. part of an email message.
A SIP URL follows the guidelines of RFC 2396 [18] and has the syntax A SIP URL follows the guidelines of RFC 2396 [12] and has the syntax
shown in Fig. 3. Note that reserved characters have to be escaped. shown in Fig. 3. The syntax is described using Augmented Backus-Naur
Form (See Section C). Note that reserved characters have to be
The URI character classes referenced above are described in Section escaped and that the "set of characters reserved within any given URI
C. component is defined by that component. In general, a character is
reserved if the semantics of the URI changes if the character is
userinfo: The SIP scheme MAY use the format "user:password" in the replaced with its escaped US-ASCII encoding" [12].
userinfo field. The use of passwords in the userinfo is NOT
RECOMMENDED, because the passing of authentication information
in clear text (such as URIs) has proven to be a security risk in
almost every case where it has been used.
SIP-URL = "sip:" [ userinfo "@" ] hostport 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 | method-param url-parameter = transport-param | user-param
| ttl-param | maddr-param | other-param | ttl-param | maddr-param | tag-param | other-param
transport-param = "transport=" ( "udp" | "tcp" ) transport-param = "transport=" ( "udp" | "tcp" )
user-param = "user=" ( "phone" | "ip" )
method-param = "method=" Method
ttl-param = "ttl=" ttl ttl-param = "ttl=" ttl
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
maddr-param = "maddr=" host maddr-param = "maddr=" host
other-param = *uric user-param = "user=" ( "phone" )
headers = "?" header *( "&" header ) tag-param = "tag=" UUID
header = hname "=" hvalue UUID = 1*( hex | "-" )
other-param = ( token $|$ ( token "=" ( token $|$ quoted-string )))
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
If the host is an Internet telephony gateway, the user field MAY also
encode a telephone number using the notation of telephone-subscriber
(Fig. 4). The telephone number is a special case of a user name and
cannot be distinguished by a BNF. Thus, a URL parameter, user, is
added to distinguish telephone numbers from user names. The phone
identifier is to be used when connecting to a telephony gateway. Even
without this parameter, recipients of SIP URLs MAY interpret the
pre-@ part as a phone number if local restrictions on the name space
for user name allow it.
telephone-subscriber = global-phone-number | local-phone-number telephone-subscriber = global-phone-number | local-phone-number
global-phone-number = "+" 1*phonedigit [isdn-subaddress] global-phone-number = "+" 1*phonedigit [isdn-subaddress]
[post-dial] [post-dial]
local-phone-number = 1*(phonedigit | dtmf-digit | local-phone-number = 1*(phonedigit | dtmf-digit |
pause-character) [isdn-subaddress] pause-character) [isdn-subaddress]
[post-dial] [post-dial]
isdn-subaddress = ";isub=" 1*phonedigit isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit | dtmf-digit post-dial = ";postd=" 1*(phonedigit | dtmf-digit
| pause-character) | pause-character)
phonedigit = DIGIT | visual-separator phonedigit = DIGIT | visual-separator
visual-separator = "-" | "." visual-separator = "-" | "."
pause-character = one-second-pause | wait-for-dial-tone pause-character = one-second-pause | wait-for-dial-tone
one-second-pause = "p" one-second-pause = "p"
wait-for-dial-tone = "w" wait-for-dial-tone = "w"
dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D"
Figure 4: SIP URL syntax; telephone subscriber Figure 4: SIP URL syntax; telephone subscriber
If a server handles SIP addresses for another domain, it MUST URL- The URI character classes referenced above are described in Appendix
encode the "@" character (%40). The ";" character MUST be URL- C.
encoded, as otherwise it is not possible to distinguish, in one
parsing pass, the case host;parameter and user;moreuser@host
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
SIP URL requires the latter form, without brackets.
port: If missing, the port number is assumed to be the SIP default user: If the host is an Internet telephony gateway, the user field
port, 5060. MAY also encode a telephone number using the notation of
telephone-subscriber (Fig. 4). The telephone number is a special
case of a user name and cannot be distinguished by a BNF. Thus,
a URL parameter, user, is added to distinguish telephone numbers
from user names. The phone identifier is to be used when
connecting to a telephony gateway. Even without this parameter,
recipients of SIP URLs MAY interpret the pre-@ part as a phone
number if local restrictions on the name space for user name
allow it.
URL parameters: SIP URLs can define specific parameters of the If a server handles SIP addresses for another domain, it MUST
request. URL parameters are added after the host component and URL-encode the "@" character (%40). The ";" character MUST be
are separated by semi-colons. The transport parameter determines URL-encoded, as otherwise it is not possible to distinguish, in
the the transport mechanism (UDP or TCP). UDP is to be assumed one parsing pass, the case host;parameter and user;moreuser@host
when no explicit transport parameter is included. The maddr the userinfo field. The use of passwords in the userinfo is
parameter provides the server address to be contacted for this NOT RECOMMENDED, because the passing of authentication
user, overriding the address supplied in the host field. This information in clear text (such as URIs) has proven to be a
address is typically a multicast address, but could also be the security risk in almost every case where it has been used.
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. For example, to
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:
sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 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 SIP URL
requires the latter form, without brackets.
The transport, maddr, and ttl parameters MUST NOT be used in the From port: If missing, the port number is assumed to be the SIP
and To header fields and the Request-URI; they are ignored if default port, 5060.
present.
Headers: Headers of the SIP request can be defined with the "?" URL parameters: SIP URLs can define specific parameters of
mechanism within a SIP URL. The special hname "body" indicates the request. URL parameters are added after the host
that the associated hvalue is the message-body of the SIP INVITE component and are separated by semi-colons. The
request. Headers MUST NOT be used in the From and To header transport parameter determines the the transport
fields and the Request-URI; they are ignored if present. mechanism (UDP or TCP). UDP is to be assumed when no
explicit 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. For example, to 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:
Method: The method of the SIP request can be specified with the sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
method parameter. This parameter MUST NOT be used in the From
and To header fields and the Request-URI; they are ignored if
present.
Table 2 summarizes where the components of the SIP URL can be used SIP-message = Request | Response
and what default values they assume if not present.
default Request-URI To From Contact external Both Request (section 4) and Response (section 5) messages use the
generic-message format of RFC 822 [26] for transferring entities (the
body of the message). Both types of messages consist of a start-line,
one or more header fields (also known as "headers"), an empty line
(i.e., a line with nothing preceding the carriage-return line-feed
(CRLF)) indicating the end of the header fields, and an optional
message-body. To avoid confusion with similar-named headers in HTTP,
we refer to the headers describing the message body as entity
headers. These components are described in detail in the upcoming
default Req.-URI To From Contact external
user -- x x x x x user -- x x x x x
password -- x x x x password -- x x x x
host mandatory x x x x x host mandatory x x x x x
port 5060 x x x x x port 5060 x x x x x
user-param ip x x x x x user-param ip x x x x x
method INVITE x x method INVITE x x
maddr-param -- x x maddr-param -- x x
ttl-param 1 x x ttl-param 1 x x
transport-param -- x x transp.-param -- x x
headers -- x x headers -- x x
Table 2: Use and default values of URL components for SIP headers, Table 2: Use and default values of URL components for SIP headers,
Request-URI and references Request-URI and 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:alice@10.1.2.3
sip:alice@example.com;tag=f81d4fae-7dec-11d0-a765-00a0c91e6bf6
sip:alice
sip:alice@registrar.com;method=REGISTER
Within a SIP message, URLs are used to indicate the source and
intended destination of a request, redirection addresses and the
current destination of a request. Normally all these fields will
contain SIP URLs.
SIP URLs are case-insensitive, so that for example the two URLs
sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All
URL parameters are included when comparing SIP URLs for equality.
SIP header fields MAY contain non-SIP URLs. As an example, if a call
from a telephone is relayed to the Internet via SIP, the SIP From
header field might contain a phone URL.
3 SIP Message Overview
SIP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 2279 [20]). Lines are terminated by CRLF, but
receivers MUST also interpret CR and LF by themselves as line
terminators.
Except for the above difference in character sets, much of the
message syntax is identical to HTTP/1.1; rather than repeating it
here we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1
specification (RFC 2068 [7]). In addition, we describe SIP in both
prose and an augmented Backus-Naur form (BNF) [H2.1] described in
detail in RFC 2234 [21].
Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP
transactions can be carried in a single TCP connection or UDP
datagram. UDP datagrams, including all headers, SHOULD NOT be larger
than the path maximum transmission unit (MTU) if the MTU is known, or
1400 bytes if the MTU is unknown.
The 1400 bytes accommodates lower-layer packet headers
within the "typical" MTU of around 1500 bytes. Recent
studies [22] indicate that an MTU of 1500 bytes is a
reasonable assumption. The next lower common MTU values are
1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191
[23]). Thus, another reasonable value would be a message
size of 950 bytes, to accommodate packet headers within the
SLIP MTU without fragmentation.
A SIP message is either a request from a client to a server, or a
response from a server to a client.
SIP-message ___ Request | Response
Both Request (section 4) and Response (section 5) messages use the
generic-message format of RFC 822 [24] for transferring entities (the
body of the message). Both types of messages consist of a start-line,
one or more header fields (also known as "headers"), an empty line
(i.e., a line with nothing preceding the carriage-return line-feed
(CRLF)) indicating the end of the header fields, and an optional
message-body. To avoid confusion with similar-named headers in HTTP,
we refer to the headers describing the message body as entity
headers. 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 In the interest of robustness, any leading empty line(s) MUST be
other words, if the Request or Response message begins with a CRLF, ignored. In other words, if the Request or Response message begins
CR, or LF, these characters MUST be ignored. with a CRLF, CR, or LF, these characters MUST be ignored.
4 Request 4 Request
general-header = Call-ID ; Section 6.12
The Request message format is shown below:
general-header = Accept ; Section 6.7
| Accept-Encoding ; Section 6.8
| Accept-Language ; Section 6.9
| Call-ID ; Section 6.12
| Contact ; Section 6.13 | Contact ; Section 6.13
| CSeq ; Section 6.17 | CSeq ; Section 6.17
| Date ; Section 6.18 | Date ; Section 6.18
| Encryption ; Section 6.19 | Encryption ; Section 6.19
| Expires ; Section 6.20 | Expires ; Section 6.20
| From ; Section 6.21 | From ; Section 6.21
| 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
entity-header = Content-Encoding ; Section 6.14 entity-header = Content-Encoding ; Section 6.14
| Content-Length ; Section 6.15 | Content-Length ; Section 6.15
| Content-Type ; Section 6.16 | Content-Type ; Section 6.16
request-header = Accept ; Section 6.7 request-header = Authorization ; Section 6.11
| Accept-Encoding ; Section 6.8
| Accept-Language ; Section 6.9
| Authorization ; Section 6.11
| Contact ; Section 6.13 | Contact ; Section 6.13
| Hide ; Section 6.22 | Hide ; Section 6.22
| Max-Forwards ; Section 6.23 | Max-Forwards ; Section 6.23
| Organization ; Section 6.24 | Organization ; Section 6.24
| Priority ; Section 6.25 | Priority ; Section 6.25
| Proxy-Authorization ; Section 6.27 | Proxy-Authorization ; Section 6.27
| Proxy-Require ; Section 6.28 | Proxy-Require ; Section 6.28
| Route ; Section 6.33 | Route ; Section 6.33
| Require ; Section 6.30 | Require ; Section 6.30
| Response-Key ; Section 6.31 | Response-Key ; Section 6.31
skipping to change at page 21, line 44 skipping to change at page 21, line 45
response-header = Allow ; Section 6.10 response-header = Allow ; Section 6.10
| 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
The Request message format is shown below:
Request = Request-Line ; Section 4.1 Request = Request-Line ; Section 4.1
*( general-header *( general-header
| request-header | request-header
| entity-header ) | entity-header )
CRLF CRLF
[ message-body ] ; Section 8 [ message-body ] ; Section 8
4.1 Request-Line 4.1 Request-Line
The Request-Line begins with a method token, followed by the The Request-Line begins with a method token, followed by the
skipping to change at page 22, line 27 skipping to change at page 22, line 23
Request-Line = Method SP Request-URI SP SIP-Version CRLF Request-Line = Method SP Request-URI SP SIP-Version CRLF
4.2 Methods 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 OPTIONS method and forwarded accordingly. Methods that are not an OPTIONS method and forwarded accordingly. Methods that are not
supported by a user agent server or registrar cause a 501 (Not supported by a user agent server or registrar cause a 501 (Not
Implemented) response to be returned (Section 7). Implemented) response to be returned (Section 7).
Method = "ACK" | "BYE" | "CANCEL" | "INVITE" Method = "INVITE" | "ACK" | "OPTIONS" | "BYE"
| "OPTIONS" | "REGISTER" | "CANCEL" | "REGISTER"
4.2.1 INVITE 4.2.1 INVITE
The INVITE method indicates that the user or service is being invited The INVITE method indicates that the user or service is being invited
to participate in a session. The message body contains a description to participate in a session. The message body contains a description
of the session to which the callee is being invited. For two-party of the session to which the callee is being invited. For two-party
calls, the caller indicates the type of media it is able to receive calls, the caller indicates the type of media it is able to receive
as well as their parameters such as network destination. A success and possibly the media it is willing to send as well as their
response indicates in its message body which media the callee wishes parameters such as network destination. A success response MUST
to receive. indicate in its message body which media the callee wishes to receive
and MAY indicate the media the callee is going to send.
Not all session description formats have the ability to
indicate sending media.
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 leg
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
the session description to see if it has changed. It MUST also the session description to see if it has changed. It MUST also
inspect any other header fields for changes and act accordingly. If inspect any other header fields for changes. If there is a change,
the session description has changed, the user agent server MUST the user agent MUST update any internal state or information
adjust the session parameters accordingly, possibly after asking the generated as a result of that header. If the session description has
user for confirmation. (Versioning of the session description can be changed, the user agent server MUST adjust the session parameters
used to accommodate the capabilities of new arrivals to a conference, accordingly, possibly after asking the user for confirmation.
add or delete media or change from a unicast to a multicast (Versioning of the session description can be used to accommodate the
conference.) capabilities of new arrivals to a conference, add or delete media or
change from a unicast to a multicast conference.)
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.2 ACK 4.2.2 ACK
The ACK request confirms that the client has received a final The ACK request confirms that the client has received a final
response to an INVITE request. (ACK is used only with INVITE response to an INVITE request. (ACK is used only with INVITE
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
skipping to change at page 24, line 33 skipping to change at page 24, line 34
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 release the call. A BYE request is forwarded like an INVITE wishes to release the call. A BYE request is forwarded like an INVITE
request and MAY be issued by either caller or callee. A party to a request and MAY be issued by either caller or callee. A party to a
call SHOULD issue a BYE request before releasing a call ("hanging call SHOULD issue a BYE request before releasing a call ("hanging
up"). A party receiving a BYE request MUST cease transmitting media up"). A party receiving a BYE request MUST cease transmitting media
streams specifically directed at the party issuing the BYE request. streams specifically directed at the party issuing the BYE request.
If the INVITE request contained a Contact header, the callee MAY send If the INVITE request contained a Contact header, the callee SHOULD
a 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 field values, but To, From and CSeq (sequence number only) header field values, but
does not affect a completed request. (A request is considered does not affect a completed request. (A request is considered
completed if the server has returned a final status response.) completed if the server has returned a final status response.)
skipping to change at page 25, line 43 skipping to change at page 25, line 44
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 field with a SIP server. the To header field with a SIP server.
A user agent MAY register with a local server on startup by sending a A user agent MAY register with a local server on startup by sending a
REGISTER request to the well-known "all SIP servers" multicast REGISTER request to the well-known "all SIP servers" multicast
address "sip.mcast.net" (224.0.1.75), with a time-to-live value of 1. address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped
SIP user agents on the same subnet MAY listen to that address and use to ensure it is not forwarded beyond the boundaries of the
it to become aware of the location of other local users [17]; administrative system. This MAY be done with either TTL or
however, they do not respond to the request. A user agent MAY also administrative scopes[27], depending on what is implemented in the
be configured with the address of a registrar server to which it network. However, use of administrative scoping is RECOMMENDED. SIP
sends a REGISTER request upon startup. user agents MAY listen to that address and use it to become aware of
the location of other local users [21]; 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.
Requests are processed in the order received. Clients SHOULD avoid
sending a new registration (as opposed to a retransmission) until
they have received the response from the server for the previous one.
Clients may register from different locations, by necessity
using different Call-ID values. Thus, the CSeq value cannot
be used to enforce ordering. Since registrations are
additive, ordering is less of a problem than if each
REGISTER request completely replaced all earlier ones.
The meaning of the REGISTER request-header fields is defined as The meaning of the REGISTER request-header fields is defined as
follows. We define "address-of-record" as the SIP address that the follows. We define "address-of-record" as the SIP address that the
registry knows the registrand, typically of the form "user@domain" registry knows the registrand, typically of the form "user@domain"
rather than "user@host". In third-party registration, the entity rather than "user@host". In third-party registration, the entity
issuing the 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 Request- user name MUST be empty. Generally, the domains in the Request-
URI and the To header field have the same value; however, it is URI and the To header field have the same value; however, it 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) might name. For example, a traveller sip:alice@acme.com (To) might
register under the Request-URI sip:@atlanta.ayh.org , with the register under the Request-URI sip:atlanta.hiayh.org , with the
former as the To header field and the latter as the Request-URI. former as the To header field and the latter as the Request-URI.
The request is no longer forwarded once it reached the server The request is no longer forwarded once it reached the server
whose authoritative domain is the one listed in the Request-URI. whose authoritative domain is the one listed in the Request-URI.
Call-ID: All registrations from a client SHOULD use the same Call-ID
header value, at least within the same reboot cycle.
Cseq: Registrations with the same Call-ID MUST have increasing CSeq
header values. However, the server does not reject out-of-order
requests.
Contact: The request MAY contain a Contact header field; future non- Contact: The request MAY contain a Contact header field; future non-
REGISTER requests for the URI given in the To header field will REGISTER requests for the URI given in the To header field
be directed to the address(es) given in the Contact header. SHOULD be directed to the address(es) given in the Contact
header.
If the request does not contain a Contact header, the registration If the request does not contain a Contact header, the registration
remains unchanged. Registrations using SIP URIs that differ in one or remains unchanged.
more of host, port, transport-param or maddr-param from an existing
registration are added to the list of registrations. Other URI types This is useful to obtain the current list of registrations
are compared according to the standard URI equivalency rules for the in the response. Registrations using SIP URIs that differ
URI schema. If the URIs are equivalent to that of an existing in one or more of host, port, transport-param or maddr-
registration, the new registration replaces the old one if it has a param (see Figure 3) from an existing registration are
higher q value or, for the same value of q, if the ttl value is added to the list of registrations. Other URI types are
higher. All current registrations MUST share the same action value. compared according to the standard URI equivalency rules
Registrations that have a different action than current registrations for the URI schema. If the URIs are equivalent to that of
for the same user are rejected with status of 409 (Conflict). 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 registrations
MUST share the same action value. Registrations that have
a different action than current registrations for the same
user MUST be rejected with status of 409 (Conflict).
A proxy server ignores the q parameter when processing non-REGISTER A proxy server ignores the q parameter when processing non-REGISTER
requests, while a redirect server simply returns that parameter in requests, while a redirect server simply returns that parameter in
its Contact response header field. its Contact response header field.
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 is supposed to wait between trying example, how long it is supposed to wait between trying
addresses. 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". In the
telephone network, directed pickup permits a user at a
remote station who hears his own phone ringing to pick up
at that station, dial an access code, and be connected to
the calling user as if he had answered his own phone.
A server SHOULD silently drop the registration after one hour, unless A server MAY choose any duration for the registration lifetime.
refreshed by the client. A client MAY request a lower or higher Registrations not refreshed after this amount of time SHOULD be
refresh interval through the Expires header (Section 6.20). Based on silently discarded. Responses to a registration SHOULD include an
this request and its configuration, the server chooses the expiration Expires header (Section 6.20), indicating the time at which the
interval and indicates it through the Expires header field in the server will drop the registration. If none is present, one hour is
response. A single address (if host-independent) MAY be registered assumed. Clients MAY request a registration lifetime by indicating
from several different clients. the time in an Expires header in the request. A server SHOULD NOT use
a higher lifetime than the one requested, but MAY use a lower one. A
single address (if host-independent) MAY be registered from several
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 Contact or the wildcard Contact designated by a "*" for particular Contact or the wildcard Contact designated by a "*" for
all registrations. Registrations are matched based on the user, host, all registrations. Registrations are matched based on the user, host,
port and maddr parameters. 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 Contact header fields. response as Contact header fields.
It is particularly important that REGISTER requests are authenticated It is particularly important that REGISTER requests are authenticated
since they allow to redirect future requests. since they allow to redirect future requests (see Section 13.2).
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 registers with a port number.
server for the administrative domain. Since clients do not
always have easy access to the host address or port number,
using the source address and port from the request itself
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 is a SIP URL as described in Section 2 or a general The Request-URI is a SIP URL as described in Section 2 or a general
URI. It indicates the user or service to which this request is being URI. It indicates the user or service to which this request is being
addressed. Unlike the To field, the Request-URI MAY be re-written by addressed. Unlike the To field, the Request-URI MAY be re-written by
proxies. proxies.
skipping to change at page 28, line 18 skipping to change at page 29, line 4
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 Contact header field of a to the callee, e.g., from the Contact header field of a
response to a previous request, the To would still contain response to a previous request, the To would still contain
the long-term, "public" address, while the Request-URI the long-term, "public" address, while the Request-URI
would be set to the cached address. would be 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 is proxied to the particular person, e.g., address sip:sales@acme.com is proxied to the particular person, e.g.,
sip:bob@ny.acme.com , with the To remaining as sales@acme.com sip:bob@ny.acme.com , with the To field remaining as
ny.acme.com , Bob then designates Alice as the temporary substitute. sip:sales@acme.com ny.acme.com , Bob then designates Alice as the
temporary 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
host names of the server. If it does not, the server SHOULD proxy the host names of the receiving server. If it does not, the server SHOULD
request to the address indicated or return a 404 (Not Found) response proxy the request to the address indicated or return a 404 (Not
if it is unwilling or unable to do so. For example, the Request-URI Found) response if it is unwilling or unable to do so. For example,
and server host name can disagree in the case of a firewall proxy the Request-URI and server host name can disagree in the case of a
that handles outgoing calls. This mode of operation similar to that firewall proxy that handles outgoing calls. This mode of operation
of HTTP proxies. similar to that of HTTP proxies.
If a SIP server receives a request with a URI indicating a scheme If a SIP server receives a request with a URI indicating a scheme
other than SIP which that server does not understand, the server MUST other than SIP which that server does not understand, the server MUST
return a 400 (Bad Request) response. It MUST do this even if the To return a 400 (Bad Request) response. It MUST do this even if the To
header field contains a scheme it does understand. header field contains a scheme it does understand. This is because
proxies are responsible for processing the Request-URI; the To field
is of end to end significance.
4.3.1 SIP Version 4.3.1 SIP Version
Both request and response messages include the version of SIP in use, Both request and response messages include the version of SIP in use,
and basically follow [H3.1], with HTTP replaced by SIP. To be and basically follow [H3.1], with HTTP replaced by SIP. To be
conditionally compliant with this specification, applications sending compliant with this specification, applications sending SIP messages
SIP messages MUST include a SIP-Version of "SIP/2.0". MUST include a SIP-Version of "SIP/2.0".
4.4 Option Tags 4.4 Option Tags
Option tags are unique identifiers used to designate new options in Option tags are unique identifiers used to designate new options in
SIP. These tags are used in Require (Section 6.30) and Unsupported SIP. These tags are used in Require (Section 6.30) and Unsupported
(Section 6.38) fields. (Section 6.38) fields.
Syntax: Syntax:
option-tag ___ 1*uric option-tag = token
The creator of a new SIP option MUST either prefix the option with a
reverse domain name or register the new option with the Internet See Section C for a definition of token. The creator of a new SIP
Assigned Numbers Authority (IANA). For example, option MUST either prefix the option with their reverse domain name
"com.foo.mynewfeature" is an apt name for a feature whose inventor or register the new option with the Internet Assigned Numbers
can be reached at "foo.com". Options registered with IANA have the Authority (IANA). For example, "com.foo.mynewfeature" is an apt name
prefix "org.ietf.sip.", options described in RFCs have the prefix for a feature whose inventor can be reached at "foo.com". Individual
organizations are then responsible for ensuring that option names
don't collide. Options registered with IANA have the prefix
"org.ietf.sip.", options described in RFCs have the prefix
"org.ietf.rfc.N", where N is the RFC number. Option tags are case- "org.ietf.rfc.N", where N is the RFC number. Option tags are case-
insensitive. insensitive.
4.4.1 Registering New Option Tags with IANA 4.4.1 Registering New Option Tags with IANA
When registering a new SIP option, the following information MUST be When registering a new SIP option, the following information MUST be
provided: provided:
o Name and description of option. The name MAY be of any length, o Name and description of option. The name MAY be of any length,
but SHOULD be no more than twenty characters long. The name but SHOULD be no more than twenty characters long. The name
MUST NOT contain any spaces, control characters or periods. MUST consist of alphanum (See Figure 3 characters only.
o Indication of who has change control over the option (for o Indication of who has change control over the option (for
example, IETF, ISO, ITU-T, other international standardization example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of bodies, a consortium or a particular company or group of
companies); companies);
o A reference to a further description, if available, for o A reference to a further description, if available, for
example (in order of preference) an RFC, a published paper, a example (in order of preference) an RFC, a published paper, a
patent filing, a technical report, documented source code or a patent filing, a technical report, documented source code or a
computer manual; computer manual;
o For proprietary options, contact information (postal and email o Contact information (postal and email address);
address);
Borrowed from RTSP and the RTP AVP. Borrowed from RTSP and the RTP AVP.
5 Response 5 Response
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with a SIP response message. The response message format is responds with a SIP response message. The response message format is
shown below: shown below:
Response = Status-Line ; Section 5.1 Response = Status-Line ; Section 5.1
skipping to change at page 31, line 11 skipping to change at page 32, line 4
request; request;
2xx: Success -- the action was successfully received, understood, and 2xx: Success -- the action was successfully received, understood, and
accepted; accepted;
3xx: Redirection -- further action needs to be taken in order to 3xx: Redirection -- further action needs to be taken in order to
complete the request; complete the request;
4xx: Client Error -- the request contains bad syntax or cannot be 4xx: Client Error -- the request contains bad syntax or cannot be
fulfilled at this server; fulfilled at this server;
5xx: Server Error -- the server failed to fulfill an apparently valid 5xx: Server Error -- the server failed to fulfill an apparently valid
request; request;
6xx: Global Failure -- the request is invalid at any server. 6xx: Global Failure -- the request cannot be fulfilled at any server.
Figures 5 through 9 present the individual values of the numeric Figures 5 through 9 present the individual values of the numeric
response codes, and an example set of corresponding reason phrases response codes, and an example set of corresponding reason phrases
for SIP/2.0. These reason phrases are only recommended; they may be for SIP/2.0. These reason phrases are only recommended; they may be
replaced by local equivalents without affecting the protocol. Note replaced by local equivalents without affecting the protocol. Note
that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response
codes in the range starting at x80 to avoid conflicts with newly codes in the range starting at x80 to avoid conflicts with newly
defined HTTP response codes, and adds a new class, 6xx, of response defined HTTP response codes, and adds a new class, 6xx, of response
codes. codes.
skipping to change at page 31, line 41 skipping to change at page 32, line 33
x00 response code of that class, with the exception that an x00 response code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if a client unrecognized response MUST NOT be cached. For example, if a client
receives an unrecognized response code of 431, it can safely assume receives an unrecognized response code of 431, it can safely assume
that there was something wrong with its request and treat the that there was something wrong with its request and treat the
response as if it had received a 400 (Bad Request) response code. In response as if it had received a 400 (Bad Request) response code. In
such cases, user agents SHOULD present to the user the message body such cases, user agents SHOULD present to the user the message body
returned with the response, since that message body is likely to returned with the response, since that message body is likely to
include human-readable information which will explain the unusual include human-readable information which will explain the unusual
status. status.
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-
Informational = "100" ; Trying Informational = "100" ; Trying
| "180" ; Ringing | "180" ; Ringing
| "181" ; Call Is Being Forwarded | "181" ; Call Is Being Forwarded
| "182" ; Queued | "182" ; Queued
Success = "200" ; OK Success = "200" ; OK
Figure 5: Informational and success status codes Figure 5: Informational and success status codes
6 Header Field Definitions
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
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 header
fields that will not be invalidated by proxies.
The header fields required, optional and not applicable for each
method are listed in Table 4 and Table 5. 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 header fields are
required when there is a valid message body (of non-zero length)
associated with the message (Section 8).
The "where" column describes the request and response types with
which the header field can be used. "R" refers to header fields that
can be used in requests (that is, request and general header fields).
"r" designates a response or general-header field as applicable to
all responses, while a list of numeric values indicates the status
codes with which the header field can be used. "g" and "e" designate
general (Section 6.1) and entity header (Section 6.2) fields,
respectively. If a header field is marked "c", it is copied from the
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 33, line 30 skipping to change at page 33, line 39
| "480" ; Temporarily not available | "480" ; Temporarily not available
| "481" ; Call Leg/Transaction Does Not Exist | "481" ; Call Leg/Transaction Does Not Exist
| "482" ; Loop Detected | "482" ; Loop Detected
| "483" ; Too Many Hops | "483" ; Too Many Hops
| "484" ; Address Incomplete | "484" ; Address Incomplete
| "485" ; Ambiguous | "485" ; Ambiguous
| "486" ; Busy Here | "486" ; Busy Here
Figure 7: Client error status codes Figure 7: Client error status codes
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.
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
request to the response.
The "enc." column describes whether this message header field MAY be
encrypted end-to-end. A "n" designates fields that MUST NOT be
encrypted, while "c" designates fields that SHOULD be encrypted if
Global-Failure | "600" ; Busy Everywhere Global-Failure | "600" ; Busy Everywhere
| "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
Proxies MUST NOT reorder or otherwise modify header fields other than
by adding a new Via header field, adding another hop-by-hop header
field or fixing up the Via header fields with "received" parameters
as described in Section 6.40.1. Proxies MUST NOT, for example,
change how header fields are broken across lines. This allows an
authentication field to be added after the Via header fields that
will not be invalidated by proxies.
The header fields required, optional and not applicable for each
method are listed in Table 4 and Table 5. 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 header fields are
required when there is a valid message body (of non-zero length)
associated with the message (Section 8).
The "where" column describes the request and response types with
which the header field can be used. "R" refers to header fields that
can be used in requests (that is, request and general header fields).
"r" designates a response or general-header field as applicable to
all responses, while a list of numeric values indicates the status
codes with which the header field can be used. "g" and "e" designate
general (Section 6.1) and entity header (Section 6.2) fields,
respectively. If a header field is marked "c", it is copied from the
request to the response.
The "enc." column describes whether this message header field MAY be
encrypted end-to-end. A "n" designates fields that MUST NOT be
encrypted, while "c" designates fields that SHOULD be encrypted if
encryption is used. encryption is used.
The "e-e" column has a value of "e" for end-to-end and a value of "h" The "e-e" column has a value of "e" for end-to-end and a value of "h"
for hop-by-hop header fields. for hop-by-hop header fields.
where enc. e-e ACK BYE CAN INV OPT REG where enc. e-e ACK BYE CAN INV OPT REG
____________________________________________________________________________ __________________________________________________________________________
Accept R e - - - o o o Accept R e - - - o o o
Accept 415 e - - - o o o
Accept-Encoding R e - - - o o o Accept-Encoding R e - - - o o o
Accept-Language R n e - o o o o o Accept-Encoding 415 e - - - o o o
Accept-Language R e - o o o o o
Accept-Language 415 e - o o o o o
Allow 200 e - - - - m - Allow 200 e - - - - m -
Allow 405 e o o o o o o Allow 405 e o o o o o o
Authorization R e o o o o o o Authorization R e o o o o o o
Call-ID gc n e m m m m m m Call-ID gc n e m m m m m m
Contact R e o - - o o o Contact R e o - - o o o
Contact 1xx e - - - o o - Contact 1xx e - - - o o -
Contact 2xx e - - - o o o Contact 2xx e - - - o o o
Contact 3xx e - o - o o o Contact 3xx e - o - o o o
Contact 485 e - o - o o o Contact 485 e - o - o o o
Content-Encoding e e * - - * * * Content-Encoding e e o - - o o o
Content-Length e e o - - o o o Content-Length e e o - - o o o
Content-Type e e * - - * * * Content-Type e e * - - * * *
CSeq gc n e m m m m m m CSeq gc n e m m m m m m
Date g e o o o o o o Date g e o o o o o o
Encryption g n e o o o o o o Encryption g n e o o o o o o
Expires g e - - - o - o Expires g e - - - o - o
From gc n e m m m m m m From gc n e m m m m m m
Hide R n h o o o o o o Hide R n h o o o o o o
Max-Forwards R n e o o o o o o Max-Forwards R n e o o o o o o
Organization g c h - - - o o o Organization g c h - - - o o o
Table 4: Summary of header fields, A--O Table 4: Summary of header fields, A--O
Other header fields can be added as required; a server MUST ignore
optional header fields 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 has to fit into a single packet and size is an
where enc. e-e ACK BYE CAN INV OPT REG where enc. e-e ACK BYE CAN INV OPT REG
_____________________________________________________________________________________ ________________________________________________________________________
Proxy-Authenticate 407 n h o o o 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-Authorization R n h o o o o o o
Proxy-Require 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 - - Priority R c e - - - o - -
Require R e o o o o o o Require R e o o o o o o
Retry-After R c e - - - - - o Retry-After R c e - - - - - o
Retry-After 404,480,486 c e o o o o o o Retry-After 404,480,486 c e o o o o o o
503 c e o o o o o o 503 c e o o o o o o
600,603 c e o o o o o o 600,603 c e o o o o o o
Response-Key R c e - o o o o o Response-Key R c e - o o o o o
skipping to change at page 35, line 32 skipping to change at page 36, line 32
To gc(1) n e m m m m m m To gc(1) n e m m m m m m
Unsupported 420 e o o o o o o Unsupported 420 e o o o o o o
User-Agent g c e o o o o o o User-Agent g c e o o o o o o
Via gc(2) n e m m m m m m Via gc(2) n e m m m m m m
Warning r e o o o o o o Warning r e o o o o o o
WWW-Authenticate 401 c e o o o o o o WWW-Authenticate 401 c e o o o o o o
Table 5: Summary of header fields, P--Z; (1): copied with possible Table 5: Summary of header fields, P--Z; (1): copied with possible
addition of tag; (2): UAS removes first Via header field addition of tag; (2): UAS removes first Via header field
Other header fields can be added as required; a server MAY ignore
optional header fields 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 has to fit into a single packet and size is an
issue. issue.
Table 6 in Appendix A lists those header fields that different client Table 6 in Appendix A lists those header fields that different client
and server types MUST be able to parse. and server types MUST be able to parse.
6.1 General Header Fields 6.1 General 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
body or, if no body is present, about the resource identified by the message-body or, if no body is present, about the resource identified
request. The term "entity header" is an HTTP 1.1 term where the by the request. The term "entity header" is an HTTP 1.1 term where
response body can contain a transformed version of the message body. the response body can contain a transformed version of the message
The original message body is referred to as the "entity". We retain body. The original message body is referred to as the "entity". We
the same terminology for header fields but usually refer to the retain the same terminology for header fields but usually refer to
"message body" rather then the entity as the two are the same in SIP. the "message body" rather then the entity as the two are the same in
SIP.
6.3 Request Header Fields 6.3 Request Header Fields
The request-header fields allow the client to pass additional The "request-header" fields allow the client to pass additional
information about the request, and about the client itself, to the information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics server. These fields act as request modifiers, with semantics
equivalent to the parameters of a programming language method equivalent to the parameters of a programming language method
invocation. invocation.
The request-header field names can be extended reliably only in The "request-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 request- experimental header fields MAY be given the semantics of "request-
header fields if all parties in the communication recognize them to header" fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as be request-header fields. Unrecognized header fields are treated as
entity-header fields. "entity-header" fields.
6.4 Response Header Fields 6.4 Response Header Fields
The response-header fields allow the server to pass additional The "response-header" fields allow the server to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and about Line. These header fields give information about the server and about
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
entity-header fields. as "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",
entity-header) follow the same generic header format as that given in and "entity-header") follow the same generic header format as that
Section 3.1 of RFC 822 [24]. Each header field consists of a name given in Section 3.1 of RFC 822 [26]. Each header field consists of a
followed by a colon (":") and the field value. Field names are case- name followed by a colon (":") and the field value. Field names are
insensitive. The field value MAY be preceded by any amount of leading case-insensitive. The field value MAY be preceded by any amount of
white space (LWS), though a single space (SP) is preferred. Header leading white space (LWS), though a single space (SP) is preferred.
fields can be extended over multiple lines by preceding each extra Header fields can be extended over multiple lines by preceding each
line with at least one SP or horizontal tab (HT). Applications SHOULD extra line with at least one SP or horizontal tab (HT). Applications
follow HTTP "common form" when generating these constructs, since MUST follow HTTP "common form" when generating these constructs,
there might exist some implementations that fail to accept anything since there might exist some implementations that fail to accept
beyond the common forms. anything beyond the common forms.
message-header = field-name ":" [ field-value ] CRLF message-header = field-name ":" [ field-value ] CRLF
field-name = token field-name = token
field-value = *( field-content | LWS ) field-value = *( field-content | LWS )
field-content = < the OCTETs making up the field-value field-content = < the OCTETs making up the field-value
and consisting of either *TEXT and consisting of either *TEXT
or combinations of token, or combinations of token,
tspecials, and quoted-string> tspecials, and quoted-string>
The relative order of header fields with different field names is not The relative order of header fields with different field names is not
skipping to change at page 38, line 27 skipping to change at page 39, line 23
MAY use this field to help select the destination for the call, for MAY use this field to help select the destination for the call, for
example, a human operator conversant in a language spoken by the example, a human operator conversant in a language spoken by the
caller. caller.
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 The Allow entity-header field lists the set of methods supported by
supported by the resource identified by the Request-URI. The purpose the resource identified by the Request-URI. The purpose of this field
of this field is strictly to inform the recipient of valid methods is strictly to inform the recipient of valid methods associated with
associated with the resource. An Allow header field MUST be present the resource. An Allow header field MUST be present in a 405 (Method
in a 405 (Method Not Allowed) response and SHOULD be present in an Not Allowed) response and SHOULD be present in an OPTIONS response.
OPTIONS response.
Allow = "Allow" ":" 1#Method
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 39, line 32 skipping to change at page 40, line 33
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.
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 = 1*uric
host MUST be either a fully qualified domain name or a globally "host" SHOULD be either a fully qualified domain name or a globally
routable IP address, while the local-id is a random identifier routable IP address. If this is the case, the "local-id" SHOULD be an
consisting of URI characters that is unique within host. It MUST NOT identifier consisting of URI characters that is unique within "host".
be reused for a different call. Call-IDs are case-sensitive. The use Use of cryptographically random identifiers [28] is RECOMMENDED. If,
of a UUID as local-id is OPTIONAL. The UUID is a version-4 (random) however, host is not an FQDN or globally routable IP address (such as
UUID [19]. a net 10 address), the local-id MUST be globally unique, as opposed
to unique within host. These rules guarantee overall global
uniqueness of the Call-ID. The value for Call-ID MUST NOT be reused
for a different call. Call-IDs are case-sensitive.
Using cryptographically random identifiers provides some Using cryptographically random identifiers provides some
protection against session hijacking. Call-ID, To and From protection against session hijacking. Call-ID, To and From
are needed to identify a call leg call leg matters in calls are needed to identify a call leg between call and call leg
with third-party control. matters in calls with third-party control.
Example: For systems which have tight bandwidth constraints, many of the
mandatory SIP headers have a compact form, as discussed in Section 9.
These are alternate names for the headers which occupy less space in
the message. In the case of Call-ID, the compact form is i.
For example, both of the following are valid:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
or
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
6.13 Contact 6.13 Contact
The Contact general-header field can appear in requests, 1xx, 2xx The Contact general-header field can appear in requests, 1xx, 2xx,
responses and 3xx responses. and 3xx responses.
INVITE and ACK requests: INVITE and ACK requests MAY contain Contact INVITE and ACK requests: INVITE and ACK requests MAY contain Contact
headers indicating from which location the request is headers indicating from which location the request is
originating. originating.
This allows the callee to send a BYE directly to the caller This allows the callee to send a BYE directly to the caller
instead of through a series of proxies. The Via header is instead of through a series of proxies. The Via header is
not sufficient since the desired address may be that of a not sufficient since the desired address may be that of a
proxy. proxy.
skipping to change at page 40, line 36 skipping to change at page 41, line 47
the server itself or that of a proxy, e.g., if the host is the server itself or that of a proxy, e.g., if the host is
behind a firewall. The value of this Contact header is copied behind a firewall. The value of this Contact header is copied
into the Request-URI of subsequent requests for this call. into the Request-URI of subsequent requests for this call.
The Contact value SHOULD NOT be cached across calls, as it The Contact value SHOULD NOT be cached across calls, as it
may not represent the most desirable location for a may not represent the most desirable location for a
particular destination address. particular destination address.
INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY
insert a Contact response header. It has the same semantics in a insert a Contact response header. It has the same semantics in a
1xx response as a 2xx INVITE response. Note that CANCEL 1xx response as a 2xx INVITE response. Note that CANCEL requests
requests MUST NOT be sent to that address, but rather follow the MUST NOT be sent to that address, but rather follow the same
same path as the original request. path as the original request.
REGISTER requests: REGISTER requests MAY contain a Contact header REGISTER requests: REGISTER requests MAY contain a Contact header
field indicating at which locations the user is reachable. The field indicating at which locations the user is reachable. The
REGISTER request defines a wildcard Contact field, "*", which REGISTER request defines a wildcard Contact field, "*", which
MUST only be used with Expires: 0 to remove all registrations MUST only be used with Expires: 0 to remove all registrations
for a particular user. An optional expires parameter indicates for a particular user. An optional "expires" parameter indicates
the desired expiration time of the registration. If a Contact the desired expiration time of the registration. If a Contact
entry does not have an expires parameter, the Expires header entry does not have an "expires" parameter, the Expires header
field is used as the default value. If neither of these field is used as the default value. If neither of these
mechanisms is used, SIP URIs are assumed to expire after one mechanisms is used, SIP URIs are assumed to expire after one
hour. Other URI schemes have no expiration times. hour. Other URI schemes have no expiration times.
REGISTER 2xx responses: A REGISTER response MAY return all locations REGISTER 2xx responses: A REGISTER response MAY return all locations
at which the user is currently reachable. An optional expires at which the user is currently reachable. An optional "expires"
parameter indicates the expiration time of the registration. If parameter indicates the expiration time of the registration. If
a Contact entry does not have an expires parameter, the value of a Contact entry does not have an "expires" parameter, the value
the Expires header field indicates the expiration time. If of the Expires header field indicates the expiration time. If
neither mechanism is used, the expiration time specified in the neither mechanism is used, the expiration time specified in the
request, explicitly or by default, is used. request, explicitly or by default, is used.
3xx and 485 responses: The Contact response-header field can be used 3xx and 485 responses: The Contact response-header field can be used
with a 3xx or 485 (Ambiguous) response codes to indicate one or with a 3xx or 485 (Ambiguous) response codes to indicate one or
more alternate addresses to try. It can appear in responses to more alternate addresses to try. It can appear in responses to
BYE, INVITE and OPTIONS methods. The Contact header field BYE, INVITE and OPTIONS methods. The Contact header field
contains URIs giving the new locations or user names to try, or contains URIs giving the new locations or user names to try, or
may simply specify additional transport parameters. A 300 may simply specify additional transport parameters. A 300
(Multiple Choices), 301 (Moved Permanently), 302 (Moved (Multiple Choices), 301 (Moved Permanently), 302 (Moved
Temporarily) or 485 (Ambiguous) response SHOULD contain a Temporarily) or 485 (Ambiguous) response SHOULD contain a
Contact field containing URIs of new addresses to be tried. A Contact field containing URIs of new addresses to be tried. A
301 or 302 response may also give the same location and username 301 or 302 response may also give the same location and username
that was being tried but specify additional transport parameters that was being tried but specify additional transport parameters
such as a different server or multicast address to try or a such as a different server or multicast address to try or a
change of SIP transport from UDP to TCP or vice versa. The change of SIP transport from UDP to TCP or vice versa. The
client copies the user, password, host, port and user-param client copies the "user", "password", "host", "port" and "user-
elements of the Contact URI into the Request-URI of the param" elements of the Contact URI into the Request-URI of the
redirected request and directs the request to the address redirected request and directs the request to the address
specified by the maddr and port parameters, using the transport specified by the "maddr" and "port" parameters, using the
protocol given in the transport parameter. If maddr is a transport protocol given in the "transport" parameter. If
multicast address, the value of ttl is used as the time-to-live "maddr" is a multicast address, the value of "ttl" is used as
value. the time-to-live value.
Note that the Contact header field MAY also refer to a different Note that the Contact header field MAY also refer to a different
entity than the one originally called. For example, a SIP call entity than the one originally called. For example, a SIP call
connected to GSTN gateway may need to deliver a special information connected to GSTN gateway may need to deliver a special information
announcement such as "The number you have dialed has been changed." announcement such as "The number you have dialed has been changed."
A Contact response header field can contain any suitable URI A Contact response header field can contain any suitable URI
indicating where the called party can be reached, not limited to SIP indicating where the called party can be reached, not limited to SIP
URLs. For example, it can contain a phone or fax, URLs. For example, it can contain a phone or fax,
mailto: (RFC 2368, [25]) or irc: URL. mailto: (RFC 2368, [29]) or irc: URL.
The following parameters are defined. Additional parameters may be The following parameters are defined. Additional parameters may be
defined in other specifications. defined in other specifications.
q: The qvalue indicates the relative preference among the locations q: The "qvalue" indicates the relative preference among the locations
given. qvalue values are decimal numbers from 0.0 to 1.0, with given. "qvalue" values are decimal numbers from 0.0 to 1.0, with
higher values indicating higher preference. higher values indicating higher preference.
action: The action parameter is only used when registering with the action: The "action" parameter is used only when registering with the
REGISTER request. It indicates whether the client wishes that REGISTER request. It indicates whether the client wishes that
the server proxy or redirect future requests intended for the the server proxy or redirect future requests intended for the
client. If this parameter is not specified the action taken client. If this parameter is not specified the action taken
depends on server configuration. In its response, the registrar depends on server configuration. In its response, the registrar
SHOULD indicate the mode used. This parameter is ignored for SHOULD indicate the mode used. This parameter is ignored for
other requests. other requests.
expires: The expires parameter indicates how long the URI is valid. expires: The "expires" parameter indicates how long the URI is valid.
The parameter is either a number indicating seconds or a quoted The parameter is either a number indicating seconds or a quoted
string containing an HTTP-date. If this parameter is not string containing an HTTP-date. If this parameter is not
provided, the value of the Expires header field determines how provided, the value of the Expires header field determines how
long the URI is valid. long the URI is valid.
Contact = ( "Contact" | "m" ) ":" ("*" | (1# ( address-spec Contact = ( "Contact" | "m" ) ":" ("*" | (1# ( name-addr | addr-spec
[ *( ";" contact-params ) ] [ comment ] )) [ *( ";" contact-params ) ] [ comment ] ))
name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI
display-name = *token | quoted-string
contact-params = "q" "=" qvalue contact-params = "q" "=" qvalue
| "action" "=" "proxy" | "redirect" | "action" "=" "proxy" | "redirect"
| "expires" "=" delta-seconds | <"> HTTP-date <"> | "expires" "=" delta-seconds | <"> HTTP-date <">
| extension-attribute | extension-attribute
extension-attribute = extension-name [ "=" & extension-value ] extension-attribute = extension-name [ "=" extension-value ]
Even if the "display-name" is empty, the "name-addr" form MUST be
used if the "addr-spec" contains a comma, semicolon or question mark.
The Contact header field fulfills functionality similar to The Contact header field fulfills functionality similar to
the Location header field in HTTP. However, the HTTP header the Location header field in HTTP. However, the HTTP header
only allows one address, unquoted. Since URIs can contain only allows one address, unquoted. Since URIs can contain
commas and semicolons as reserved characters, they can be commas and semicolons as reserved characters, they can be
mistaken for header or parameter delimiters, respectively. mistaken for header or parameter delimiters, respectively.
The current syntax corresponds to that for the To and From The current syntax corresponds to that for the To and From
header, which also allows the use of display names. header, which also allows the use of display names.
Example: Example:
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com> Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600, ;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1 "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
6.14 Content-Encoding 6.14 Content-Encoding
The Content-Encoding entity-header field is used as a modifier to the The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content "media-type". When present, its value indicates what additional
codings have been applied to the entity-body, and thus what decoding content codings have been applied to the entity-body, and thus what
mechanisms MUST be applied in order to obtain the media-type decoding 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].
Content-Encoding = ( "Content-Encoding" | "e" ) ":" 1#content-coding
6.15 Content-Length 6.15 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" | "l" ) ":" 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
Applications SHOULD 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 field MUST be set to zero. If a server receives a UDP request header field MUST be set to zero. If a server receives a UDP request
without Content-Length, it MUST assume that the request encompasses without Content-Length, it MUST assume that the request encompasses
the remainder of the packet. If a response does not contain a the remainder of the packet. If a server receives a UDP request with
Content-Length, the client assumes that it encompasses the remainder a Content-Length, but the value is larger than the size of the body
of the UDP packet or the data until the TCP connection is closed, as sent in the request, the client SHOULD generate a 400 class response.
applicable. Section 8 describes how to determine the length of the If there is additional data in the UDP packet after the last byte of
message body. the body has been read, the server MUST treat the remaining data as a
separate message. This allows several messages to be placed in a
single UDP packet.
If a response does not contain a Content-Length, the client assumes
that it encompasses the remainder of the UDP packet or the data until
the TCP connection is closed, as applicable. Section 8 describes how
to determine the length of the message body.
6.16 Content-Type 6.16 Content-Type
The Content-Type entity-header field indicates the media type of the The Content-Type entity-header field indicates the media type of the
message-body sent to the recipient. The media-type element is defined message-body sent to the recipient. The "media-type" element is
in [H3.7]. defined in [H3.7].
Content-Type = ( "Content-Type" ":" media-type Content-Type = ( "Content-Type" | "c" ) ":" 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.17 CSeq 6.17 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 header field in a request contains the request every request. A CSeq header field in a request contains the request
skipping to change at page 44, line 20 skipping to change at page 46, line 6
client, unique within a single value of Call-ID. The sequence number client, unique within a single value of Call-ID. The sequence number
MUST be expressible as a 32-bit unsigned integer. The initial value MUST be expressible as a 32-bit unsigned integer. The initial value
of the sequence number is arbitrary, but MUST be less than 2**31. of the sequence number is arbitrary, but MUST be less than 2**31.
Consecutive requests that differ in request method, headers or body, Consecutive requests that differ in request method, headers or body,
but have the same Call-ID MUST contain strictly monotonically but have the same Call-ID MUST contain strictly monotonically
increasing and contiguous sequence numbers; sequence numbers do not increasing and contiguous sequence numbers; sequence numbers do not
wrap around. Retransmissions of the same request carry the same wrap around. Retransmissions of the same request carry the same
sequence number, but an INVITE with a different message body or sequence number, but an INVITE with a different message body or
different header fields (a "re-invitation") acquires a new, higher different header fields (a "re-invitation") acquires a new, higher
sequence number. A server MUST echo the CSeq value from the request sequence number. A server MUST echo the CSeq value from the request
in its response. If the Method value is missing, the server fills it in its response. If the Method value is missing in the received CSeq
in appropriately. header field, the server fills it in appropriately.
The ACK and CANCEL requests MUST contain the same CSeq value as the The ACK and CANCEL requests MUST contain the same CSeq value as the
INVITE request that it refers to, while a BYE request cancelling an INVITE request that it refers to, while a BYE request cancelling an
invitation MUST have a higher sequence number. invitation MUST have a higher sequence number. A BYE request with a
CSeq that is not higher should cause a 400 response to be generated.
A user agent server MUST remember the highest sequence number for any 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, and then discard, any INVITE request with a lower sequence
number.
All requests spawned in a parallel search have the same CSeq value as All requests spawned in a parallel search have the same CSeq value 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
skipping to change at page 46, line 9 skipping to change at page 47, line 42
been encrypted. Section 13 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 field because the encrypted body may contain header field because the encrypted body may contain
additional SIP header fields as well as the body of the additional SIP header fields as well as the body of the
message. message. See section 13.1.1
For any encrypted message, at least the message body and possibly For any encrypted message, at least the message body and possibly
other message header fields are encrypted. An application receiving a other message header fields are encrypted. An application receiving a
request or response containing an Encryption header field decrypts request or response containing an Encryption header field decrypts
the body and then concatenates the plaintext to the request line and the body and then concatenates the plaintext to the request line and
headers of the original message. Message headers in the decrypted headers of the original message. Message headers in the decrypted
part completely replace those with the same field name in the part completely replace those with the same field name in the
plaintext part. (Note: If only the body of the message is to be plaintext part. (Note: If only the body of the message is to be
encrypted, the body has to be prefixed with CRLF to allow proper encrypted, the body has to be prefixed with CRLF to allow proper
concatenation.) Note that the request method and Request-URI cannot concatenation.) Note that the request method and Request-URI cannot
be encrypted. be encrypted.
Encryption only provides privacy; the recipient has no Encryption only provides privacy; the recipient has no
guarantee that the request or response came from the party guarantee that the request or response came from the party
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 recipient's 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 13. 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.
Since proxies can base their forwarding decision on any combination
of SIP header fields, there is no guarantee that an encrypted request
"hiding" header fields will reach the same destination as an
otherwise identical un-encrypted request.
6.20 Expires
The Expires entity-header field gives the date and time after which
the message content expires.
This header field is currently defined only for the REGISTER and
INVITE methods. For REGISTER, it is a request and response-header
field. In a REGISTER request, the client indicates how long it wishes
the registration to be valid. In the response, the server indicates
the earliest expiration time of all registrations. The server MAY
choose a shorter time interval than that requested by the client, but
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
Encryption: PGP version=2.6.2,encoding=ascii Encryption: PGP version=2.6.2,encoding=ascii
hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red
h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs
ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR
RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA
zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu
X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6 X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6
IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/ IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/
GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E
WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed
wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO
skipping to change at page 47, line 19 skipping to change at page 49, line 27
X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6 X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6
IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/ IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/
GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E
WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed
wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO
z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+ z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+
6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2 6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2
z8X9N4MhMyXEVuC9rt8/AUhmVQ== z8X9N4MhMyXEVuC9rt8/AUhmVQ==
=bOW+ =bOW+
Since proxies can base their forwarding decision on any combination
of SIP header fields, there is no guarantee that an encrypted request
"hiding" header fields will reach the same destination as an
otherwise identical un-encrypted request.
6.20 Expires
The Expires entity-header field gives the date and time after which
the message content expires.
This header field is currently defined only for the REGISTER and
INVITE methods. For REGISTER, it is a request and response-header
field. In a REGISTER request, the client indicates how long it wishes
the registration to be valid. In the response, the server indicates
the earliest expiration time of all registrations. The server MAY
choose a shorter time interval than that requested by the client, but
SHOULD NOT choose a longer one. SHOULD NOT choose a longer one.
For INVITE requests, it is a request and response-header field. In a For INVITE requests, it is a request and response-header field. In a
request, the callee can limit the validity of an invitation, for request, the caller can limit the validity of an invitation, for
example, if a client wants to limit the time duration of a search or example, if a client wants to limit the time duration of a search or
a conference invitation. A user interface MAY take this as a hint to a conference invitation. A user interface MAY take this as a hint to
leave the invitation window on the screen even if the user is not leave the invitation window on the screen even if the user is not
currently at the workstation. This also limits the duration of a currently at the workstation. This also limits the duration of a
search. If the request expires before the search completes, the proxy search. If the request expires before the search completes, the proxy
returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily) returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily)
response, a server can advise the client of the maximal duration of response, a server can advise the client of the maximal duration of
the redirection. the redirection.
The value of this field can be either an HTTP-date or an integer The value of this field can be either an HTTP-date or an integer
skipping to change at page 48, line 10 skipping to change at page 50, line 4
the redirection. the redirection.
The value of this field can be either an HTTP-date or an integer The value of this field can be either an HTTP-date or an integer
number of seconds (in decimal), measured from the receipt of the number of seconds (in decimal), measured from the receipt of the
request. The latter approach is preferable for short durations, as it request. The latter approach is preferable for short durations, as it
does not depend on clients and servers sharing a synchronized clock. does not depend on clients and servers sharing a synchronized clock.
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.21 From 6.21 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 From field MAY contain indicating the initiator of the request. The From field MAY contain
the tag parameter. The server copies the From header field from the the "tag" parameter. The server copies the From header field from the
request to the response. The optional display-name is meant to be request to the response. The optional "display-name" is meant to be
rendered by a human-user interface. rendered by a human-user interface. A system SHOULD use the display
name "Anonymous" if the identity of the client is to remain hidden.
The SIP-URL MUST NOT contain the transport-param, maddr-param, ttl- The SIP-URL MUST NOT contain the "transport-param", "maddr-param",
param, or headers elements. A server that receives a SIP-URL with "ttl-param", or "headers" elements. A server that receives a SIP-URL
these elements removes them before further processing. with these elements removes them before further processing.
Even if the display-name is empty, the name-addr form MUST be used if Even if the "display-name" is empty, the "name-addr" form MUST be
the addr-spec contains a comma or semicolon. used if the "addr-spec" contains a comma, question mark, or
semicolon.
From = ( "From" | "f" ) ":" ( name-addr | addr-spec ) From = ( "From" | "f" ) ":" ( name-addr | addr-spec )
*( ";" addr-params ) *( ";" addr-params )
name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI
display-name = *token | quoted-string
addr-params = tag-param addr-params = tag-param
tag-param = "tag=" UUID tag-param = "tag=" UUID
UUID = 1*( hex | "-" ) UUID = 1*( hex | "-" )
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>
The tag MAY appear in the From field of a request. It MUST be present
when it is possible that two instances of a user sharing a SIP
address can make call invitations with the same Call-ID.
The use of version-1 (time based) or version-4 (random) UUID [19] is The "tag" MAY appear in the From field of a request. It MUST be
OPTIONAL. The tag value is designed to be globally unique and present when it is possible that two instances of a user sharing a
cryptographically random with at least 32 bits of randomness. A SIP address can make call invitations with the same Call-ID.
single user maintains the same tag throughout the call identified by
the Call-ID. The "tag" value MUST be globally unique and cryptographically random
with at least 32 bits of randomness. A single user maintains the same
tag throughout the call identified by the Call-ID.
Call-ID, To and From are needed to identify a call leg leg Call-ID, To and From are needed to identify a call leg leg
matters in calls with multiple responses to a forked matters in calls with multiple responses to a forked
request. The format is similar to the equivalent RFC 822 request. The format is similar to the equivalent RFC 822
[24] header, but with a URI instead of just an email [26] header, but with a URI instead of just an email
address. address.
6.22 Hide 6.22 Hide
A client uses the Hide request header field to indicate that it wants A client uses the Hide request header field to indicate that it wants
the path comprised of the Via header fields (Section 6.40) to be the path comprised of the Via header fields (Section 6.40) to be
hidden from subsequent proxies and user agents. It can take two hidden from subsequent proxies and user agents. It can take two
forms: Hide: route and Hide: hop. Hide header fields are typically forms: Hide: route and Hide: hop. Hide header fields are typically
added by the client user agent, but MAY be added by any proxy along added by the client user agent, but MAY be added by any proxy along
the path. 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 "Hide: hop" header field, only the next proxy SHOULD hide the
previous hop and then remove the Hide option unless it also wants to previous hop and then remove the Hide option unless it also wants to
remain anonymous. remain anonymous.
A server hides the previous hop by encrypting the host and port parts A server hides the previous hop by encrypting the "host" and "port"
of the top-most Via header field with an algorithm of its choice. parts of the top-most Via header field with an algorithm of its
Servers SHOULD add additional "salt" to the host and port information choice. Servers SHOULD add additional "salt" to the "host" and "port"
prior to encryption to prevent malicious downstream proxies from information prior to encryption to prevent malicious downstream
guessing earlier parts of the path based on seeing identical proxies from guessing earlier parts of the path based on seeing
encrypted Via headers. Hidden Via fields are marked with the hidden identical encrypted Via headers. Hidden Via fields are marked with
Via option, as described in Section 6.40. the "hidden" Via option, as 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 detection. decrypt all Via headers marked as "hidden" to perform loop detection.
Servers that are not capable of hiding can ignore hidden Via fields Servers that are not capable of hiding can ignore hidden 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.
skipping to change at page 51, line 37 skipping to change at page 53, line 27
6.25 Priority 6.25 Priority
The Priority request-header field indicates the urgency of the The Priority request-header field indicates the urgency of the
request as perceived by the client. request as perceived by the client.
Priority = "Priority" ":" priority-value Priority = "Priority" ":" priority-value
priority-value = "emergency" | "urgent" | "normal" priority-value = "emergency" | "urgent" | "normal"
| "non-urgent" | "non-urgent"
The value of "emergency" MUST only be used when life, limb or It is RECOMMENDED that the value of "emergency" only be used when
property are in imminent danger. life, limb or 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 [30], with the addition of
"emergency". "emergency".
6.26 Proxy-Authenticate 6.26 Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as part The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response. The field value of a 407 (Proxy Authentication Required) response. The field value
consists of a challenge that indicates the authentication scheme and consists of a challenge that indicates the authentication scheme and
parameters applicable to the proxy for this Request-URI. See [H14.33] parameters applicable to the proxy for this Request-URI. See [H14.33]
for further details. for further details.
skipping to change at page 53, line 44 skipping to change at page 55, line 32
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 packets call state and thus need to receive any BYE and ACK 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# name-addr Record-Route = "Record-Route" ":" 1# name-addr
Proxy servers SHOULD use the maddr URL parameter containing their Proxy servers SHOULD use the "maddr" URL parameter containing their
address to ensure that subsequent requests are guaranteed to reach address to ensure that subsequent requests are guaranteed to reach
exactly the same server. exactly the same server.
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 field is used by clients to tell user The Require request-header field is used by clients to tell user
agent servers about options that the client expects the server to agent servers about options that the client expects the server to
support in order to properly process the request. If a server does support in order to properly process the request. If a server does
not understand the option, it MUST respond by returning status code not understand the option, it MUST respond by returning status code
420 (Bad Extension) and list those options it does not understand in 420 (Bad Extension) and list those options it does not understand in
the Unsupported header. the Unsupported header.
skipping to change at page 55, line 14 skipping to change at page 57, 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 13 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 server 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 field is not present, a client SHOULD still encrypt, but MAY header field is not present, a server SHOULD still encrypt if it can.
return an unencrypted response if unable to.
6.32 Retry-After 6.32 Retry-After
The Retry-After general-header field can be used with a 503 (Service The Retry-After general-header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client and with a 404 (Not Found), be unavailable to the requesting client and with a 404 (Not Found),
600 (Busy), or 603 (Decline) response to indicate when the called 600 (Busy), or 603 (Decline) response to indicate when the called
party anticipates being available again. The value of this field can party anticipates being available again. The value of this field can
be either an HTTP-date or an integer number of seconds (in decimal) be either an HTTP-date or an integer number of seconds (in decimal)
after the time of the response. after the 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 Contact: * ;expires: 0. The Retry-After value then registrations with Contact: * ;expires: 0. The Retry-After value then
indicates when the user might again be reachable. The registrar MAY indicates when the user might again be reachable. The registrar MAY
then include this information in responses to future calls. 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
how long the called party will be reachable starting at the initial indicates how long the called party will be reachable starting at the
time of availability. If no duration parameter is given, the service initial time of availability. If no duration parameter is given, the
is assumed to be available indefinitely. service is assumed to be available indefinitely.
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
[ comment ] [ ";duration" "=" delta-seconds ] [ comment ] [ ";duration" "=" delta-seconds ]
Examples of its use are Examples of its use are
Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting) Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting)
Retry-After: Mon, 1 Jan 9999 00:00:00 GMT Retry-After: Mon, 1 Jan 9999 00:00:00 GMT
(Dear John: Don't call me back, ever) (Dear John: Don't call me back, ever)
Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600 Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600
skipping to change at page 56, line 28 skipping to change at page 58, line 16
6.33 Route 6.33 Route
The Route request-header field determines the route taken by a The Route request-header field determines the route taken by a
request. Each host removes the first entry and then proxies the request. Each host removes the first entry and then proxies the
request to the host listed in that entry, also using it as the request to the host listed in that entry, also using it as the
Request-URI. The operation is further described in Section 6.29. Request-URI. The operation is further described in Section 6.29.
The Route header field has the following syntax: The Route header field has the following syntax:
Route = "Route" ":" 1# addr-spec Route = "Route" ":" 1# name-addr
6.34 Server 6.34 Server
The Server response-header field contains information about the The Server response-header field contains information about the
software used by the user agent server to handle the request. See software used by the user agent server to handle the request. See
[H14.39]. [H14.39].
6.35 Subject 6.35 Subject
This is intended to provide a summary, or to indicate the nature, of This is intended to provide a summary, or to indicate the nature, of
skipping to change at page 57, line 27 skipping to change at page 59, line 16
that it can adjust the timeout value for retransmissions. that it can adjust the timeout value for retransmissions.
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 ) addr-params To = ( "To" | "t" ) ":" ( name-addr | addr-spec )
*( ";" addr-params )
Requests and responses MUST contain a To general-header field, Requests and responses MUST contain a To general-header field,
indicating the desired recipient of the request. The optional indicating the desired recipient of the request. The optional
display-name is meant to be rendered by a human-user interface. The "display-name" is meant to be rendered by a human-user interface.
UAS or redirect server copies the To header field into its response, The UAS or redirect server copies the To header field into its
and MUST add a tag parameter if the URL in the To header field is not response, and MUST add a "tag" parameter if the request contained
a full qualified hostname. more than one Via header field.
The SIP-URL MUST NOT contain the transport-param, maddr-param, ttl- If there was more than one Via header field, the request
param, or headers elements. A server that receives a SIP-URL with was handled by at least one proxy server. Since the
these elements removes them before further processing. receiver cannot know whether any of the proxy servers
forked the request, it is safest to assume that they might
have.
The tag parameter serves as a general mechanism to distinguish The SIP-URL MUST NOT contain the "transport-param", "maddr-param",
"ttl-param", or "headers" elements. A server that receives a SIP-URL
with these elements removes them before further processing.
The "tag" parameter serves as a general mechanism to distinguish
multiple instances of a user identified by a single SIP URL. As multiple instances of a user identified by a single SIP URL. As
proxies can fork requests, the same request can reach multiple proxies can fork requests, the same request can reach multiple
instances of a user (mobile and home phones, for example). As each instances of a user (mobile and home phones, for example). As each
can respond, there needs to be a means to distinguish the responses can respond, there needs to be a means to distinguish the responses
from each at the caller. The situation also arises with multicast from each at the caller. The situation also arises with multicast
requests. The tag in the To header field serves to distinguish requests. The tag in the To header field serves to distinguish
responses at the UAC. It MUST be placed in the To field of the responses at the UAC. It MUST be placed in the To field of the
response by each instance when there is a possibility that the response by each instance when there is a possibility that the
request was forked at an intermediate proxy. This, in general, means request was forked at an intermediate proxy. This, in general, means
that the tag MUST be inserted when the URL in the To does not refer that the "tag" MUST be inserted when the URL in the To does not refer
to a fully qualified hostname. The tag MUST be added by UAS, to a fully qualified hostname. The "tag" MUST be added by UAS,
registrars and redirect servers, but MUST NOT be inserted into registrars and redirect servers, but MUST NOT be inserted into
responses forwarded upstream by proxies. The tag is added for all responses forwarded upstream by proxies. The "tag" is added for all
definitive responses for all methods, and MAY be added for definitive responses for all methods, and MAY be added for
informational responses from a UAS or redirect server. All subsequent informational responses from a UAS or redirect server. All subsequent
transactions between two entities MUST include the tag parameter, as transactions between two entities MUST include the "tag" parameter,
described in Section 11. as described in Section 11.
The use of version-1 (time based) or version-4 (random) UUID [19] is See Section 6.21 for details of the "tag" parameter.
OPTIONAL. The tag value is designed to be globally unique and
cryptographically random with at least 32 bits of randomness. A
single user maintains the same tag throughout the call identified by
the Call-ID.
The tag parameter in To headers is ignored when matching responses to The "tag" parameter in To headers is ignored when matching responses
requests that did not contain a tag in their To header. to requests that did not contain a "tag" in their To header.
A SIP server returns a 400 (Bad Request) response if it receives a A SIP server returns a 400 (Bad Request) response if it receives a
request with a To header field containing a URI with a scheme it does request with a To header field containing a URI with a scheme it does
not recognize. not recognize.
Example: The following are examples of valid To headers:
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447 To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
To: sip:+12125551212@server.phone2net.com To: sip:+12125551212@server.phone2net.com
Call-ID, To and From are needed to identify a call leg leg Call-ID, To and From are needed to identify a call leg.
matters in calls with multiple responses from a forked The distinction between call and call leg matters in calls
request. The tag is added to the To header field in the with multiple responses from a forked request. The "tag" is
response to allow forking of future requests for the same added to the To header field in the response to allow
call by proxies, while addressing only one of the possibly forking of future requests for the same call by proxies,
several responding user agent servers. It also allows while addressing only one of the possibly several
several instances of the callee to send requests that can responding user agent servers. It also allows several
be distinguished. instances of the callee to send requests that can be
distinguished.
6.38 Unsupported 6.38 Unsupported
The Unsupported response-header field lists the features not The Unsupported response-header field lists the features not
supported by the server. See Section 6.30 for a usage example and supported by the server. See Section 6.30 for a usage example and
motivation. motivation.
6.39 User-Agent 6.39 User-Agent
The User-Agent general-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
skipping to change at page 59, line 36 skipping to change at page 61, line 28
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 Via onwards MUST add its own additional Via field before any existing Via
fields. A proxy that receives a redirection (3xx) response and then fields. A proxy that receives a redirection (3xx) response and 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 field to ensure that it A proxy SHOULD check the top-most Via header field to ensure that it
contains the sender's correct network address, as seen from that contains the sender's correct network address, as seen from that
proxy. If the sender's address is incorrect, the proxy MUST add an proxy. If the sender's address is incorrect, the proxy MUST 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 MUST insert the local the NAT. Hosts behind NATs or NAPTs MUST 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.
A proxy sending a request to a multicast address MUST add the maddr A proxy sending a request to a multicast address MUST add the "maddr"
parameter to its Via header field, and SHOULD add the ttl parameter. parameter to its Via header field, and SHOULD add the "ttl"
If a server receives a request which contained an maddr parameter in parameter. If a server receives a request which contained an "maddr"
the topmost Via field, it SHOULD send the response to the multicast parameter in the topmost Via field, it SHOULD send the response to
address listed in the maddr parameter. 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. in the Via header value, it MUST respond with a 482 (Loop Detected)
status code.
A proxy server MUST NOT forward a request to a multicast group which
already appears in any of the Via headers.
This prevents a malfunctioning proxy server from causing 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.
6.40.2 Receiver-tagged Via Fields 6.40.2 Receiver-tagged Via Header Fields
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) changes the source address of the Network Address Translators (NAT) changes the source address and port
request (e.g., from net-10 to a globally routable address), in which of the request (e.g., from net-10 to a globally routable address), in
case the Via field cannot be relied on to route replies. To prevent which case the Via header field cannot be relied on to route replies.
this, a proxy SHOULD check the top-most Via header field to ensure To prevent this, a proxy SHOULD check the top-most Via header field
that it contains the sender's correct network address, as seen from to ensure that it contains the sender's correct network address, as
that proxy. If the sender's address is incorrect, the proxy MUST add seen from that proxy. If the sender's address is incorrect, the proxy
a received tag to the Via field inserted by the previous hop. Such a MUST add a "received" parameter to the Via header field inserted by
modified Via field is known as a receiver-tagged Via field. An the previous hop. Such a modified Via header field is known as a
example is: receiver-tagged Via header field. An 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 added a parameter to the previous
field with the address that it actually came from. hop's Via header field, containing the address that the packet
actually came from. (Note that the NAT border.ieee.org is not a SIP
server.)
6.40.3 Responses 6.40.3 Responses
In the return path, Via fields are processed by a proxy or client Via header fields in responses are processed by a proxy or UAC
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 header field should indicate the proxy or
processing this response. If it does not, discard the client processing this response. If it does not, discard
message. Otherwise, remove this Via field. the message. Otherwise, remove this Via field.
2. If the second Via field contains a maddr parameter, the 2. If there is no second Via header field, this response is
response is sent to the address listed there, using the destined for this client. Otherwise, the processing depends
port indicated in sent-by, or 5060 if none is present. The on whether the Via field contains a "maddr" parameter or is
response SHOULD be sent using the TTL indicated in the ttl a receiver-tagged field:
parameter, or with a TTL of 1 if none is present.
3. Otherwise, if the second Via field is a receiver-tagged - If the second Via header field contains a "maddr"
field (Section 6.40.2), send the message to the address in parameter, send the response to the multicast address
the received tag, using the port present in sent-by, or listed there, using the port indicated in "sent-by", or
port 5060 if none is present. port 5060 if none is present. The response SHOULD be sent
using the TTL indicated in the "ttl" parameter, or with a
TTL of 1 if that parameter is not present. For
robustness, responses MUST be sent to the address
indicated in the "maddr" parameter even if it is not a
multicast address.
4. Otherwise, send the message to the address indicated by - If the second Via header field does not contain a "maddr"
sent-by in the second Via field. parameter and is a receiver-tagged field (Section
6.40.2), send the message to the address in the
"received" parameter, using the port indicated in the
"sent-by" value, or using port 5060 if none is present.
5. If there is no second Via field, this response is destined - If neither of the previous cases apply, send the message
for this client. to the address indicated by the "sent-by" value in the
second Via header field.
A user agent server or redirect server sends a response by pretending 6.40.4 User Agent and Redirect Servers
to insert the received tag into the topmost Via header field in the
request, and treating this header field as the second Via in the
above procedure.
These rules ensure that a client only has to check the first Via A UAS or redirect server sends a response based on one of the
field in a response to see if it needs processing. following rules:
6.40.4 Syntax o If the first Via header field in the request contains a
"maddr" parameter, send the response to the multicast address
listed there, using the port indicated in "sent-by", or port
5060 if none is present. The response SHOULD be sent using the
TTL indicated in the "ttl" parameter, or with a TTL of 1 if
that parameter is not present. For robustness, responses MUST
be sent to the address indicated in the "maddr" parameter even
if it is not a multicast address.
The format for a Via header field is shown in Fig. 10. o If the address in the "sent-by" value of the first Via field
differs from the source address of the packet, send the
response to the actual packet source address, similar to the
treatment for receiver-tagged Via header fields (Section
6.40.2).
The defaults for "protocol-name" and "transport" are "SIP" and "UDP", o If neither of these conditions is true, send the response to
the address contained in the "sent-by" value. If the request
was sent using TCP, use the existing TCP connection if
available.
6.40.5 Syntax
The format for a Via header field is shown in Fig. 10. The defaults
for "protocol-name" and "transport" are "SIP" and "UDP",
respectively. The "maddr" parameter, designating the multicast respectively. The "maddr" parameter, designating the multicast
address, and the "ttl" parameter, designating the time-to-live (TTL) address, and the "ttl" parameter, designating the time-to-live (TTL)
value, are included only if the request was sent via multicast. The value, are included only if the request was sent via multicast. The
"received" parameter is added only for receiver-added Via fields "received" parameter is added only for receiver-added Via fields
(Section 6.40.2). For reasons of privacy, a client or proxy may wish (Section 6.40.2). For reasons of privacy, a client or proxy may wish
to hide its Via information by encrypting it (see Section 6.22). The to hide its Via information by encrypting it (see Section 6.22). The
"hidden" parameter is included if this header field was hidden by the "hidden" parameter is included if this header field was hidden by the
upstream proxy (see 6.22). Note that privacy of the proxy relies on upstream proxy (see 6.22). Note that privacy of the proxy relies on
the cooperation of the next hop, as the next-hop proxy will, by the cooperation of the next hop, as the next-hop proxy will, by
necessity, know the IP address and port number of the source host. necessity, know the IP address and port number of the source host.
The "branch" parameter is included by every forking proxy. The token
MUST be unique for each distinct request generated when a proxy
forks. 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 = ( "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
via-maddr = "maddr" "=" maddr via-maddr = "maddr" "=" maddr
via-received = "received" "=" host via-received = "received" "=" host
via-branch = "branch" "=" token via-branch = "branch" "=" token
sent-protocol = protocol-name "/" protocol-version "/" transport sent-protocol = protocol-name "/" protocol-version "/" 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 "branch" parameter is included by every forking proxy. The token
MUST be unique for each distinct request generated when a proxy
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:
Warning = "Warning" ":" 1#warning-value Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding ; the name or pseudonym of the server adding
; the Warning header, for use in debugging ; the Warning header, for use in debugging
warn-text = quoted-string warn-text = quoted-string
A response MAY carry more than one Warning header. A response MAY carry more than one Warning header.
The warn-text should be in a natural language that is most likely to The "warn-text" should be in a natural language that is most likely
be intelligible to the human user receiving the response. This to be intelligible to the human user receiving the response. This
decision can be based on any available knowledge, such as the decision can be based on any available knowledge, such as the
location of the cache or user, the Accept-Language field in a location of the cache or user, the Accept-Language field in a
request, or the Content-Language field in a response. The default request, or the Content-Language field in a response. The default
language is English. language is English.
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 field that it received with a MUST NOT delete any Warning header field that it received with a
skipping to change at page 63, line 26 skipping to change at page 65, line 44
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. early in the response.
The warn-code consists of three digits. A first digit of "3" The warn-code consists of three digits. A first digit of "3"
indicates warnings specific to SIP. indicates warnings specific to SIP.
This is a list of the currently-defined warn-codes, each with a This is a list of the currently-defined "warn-code"s, each with a
recommended warn-text in English, and a description of its meaning. recommended warn-text in English, and a description of its meaning.
Note that these warnings describe failures induced by the session Note that these warnings describe failures induced by the session
description. description.
Warnings 300 through 329 are reserved for indicating problems with Warnings 300 through 329 are reserved for indicating problems with
keywords in the session description, 330 through 339 are warnings keywords in the session description, 330 through 339 are warnings
related to basic network services requested in the session related to basic network services requested in the session
description, 370 through 379 are warnings related to quantitative QoS description, 370 through 379 are warnings related to quantitative QoS
parameters requested in the session description, and 390 through 399 parameters requested in the session description, and 390 through 399
are miscellaneous warnings that do not fall into one of the above are miscellaneous warnings that do not fall into one of the above
skipping to change at page 64, line 32 skipping to change at page 67, line 5
370 Insufficient bandwidth: The bandwidth specified in the session 370 Insufficient bandwidth: The bandwidth specified in the session
description or defined by the media exceeds that known to be description or defined by the media exceeds that known to be
available. available.
399 Miscellaneous warning: The warning text can include arbitrary 399 Miscellaneous warning: The warning text can include arbitrary
information to be presented to a human user, or logged. A system information to be presented to a human user, or logged. A system
receiving this warning MUST NOT take any automated action. receiving this warning MUST NOT take any automated action.
1xx and 2xx have been taken by HTTP/1.1. 1xx and 2xx have been taken by HTTP/1.1.
Additional warn-codes, as in the example below, can be defined Additional "warn-code"s, as in the example below, can be defined
through IANA. through IANA.
Examples: Examples:
Warning: 307 isi.edu "Session parameter 'foo' not understood" Warning: 307 isi.edu "Session parameter 'foo' not understood"
Warning: 301 isi.edu "Incompatible network address type 'E.164'" Warning: 301 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 [31].
The content of the realm parameter SHOULD be displayed to the user. A The content of the "realm" parameter SHOULD be displayed to the user.
user agent SHOULD cache the authorization credentials for a given A 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-
these values on the next request for that destination. use 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 14. Other schemes, such as S-MIME, are PGP (RFC 2015, [32]), 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 67, line 48 skipping to change at page 70, line 20
The requesting client SHOULD retry the request at the new address(es) The requesting client SHOULD retry the request at the new address(es)
given by the Contact header field (Section 6.13). The duration of the given by the Contact header field (Section 6.13). The duration of the
redirection can be indicated through an Expires (Section 6.20) redirection can be indicated through an Expires (Section 6.20)
header. header.
7.3.4 380 Alternative Service 7.3.4 380 Alternative Service
The call was not successful, but alternative services are possible. The call was not successful, but alternative services are possible.
The alternative services are described in the message body of the The alternative services are described in the message body of the
response. response. Formats for such bodies are not defined here, and may be
the subject of future standardization.
7.4 Request Failure 4xx 7.4 Request Failure 4xx
4xx responses are definite failure responses from a particular 4xx responses are definite failure responses from a particular
server. The client SHOULD NOT retry the same request without server. The client SHOULD NOT retry the same request without
modification (e.g., adding appropriate authorization). However, the modification (e.g., adding appropriate authorization). However, the
same request to a different server might be successful. same request to a different server might be successful.
7.4.1 400 Bad Request 7.4.1 400 Bad Request
The request could not be understood due to malformed syntax. The request could not be understood due to malformed syntax.
7.4.2 401 Unauthorized 7.4.2 401 Unauthorized
skipping to change at page 68, line 24 skipping to change at page 70, line 45
The request requires user authentication. The request requires user authentication.
7.4.3 402 Payment Required 7.4.3 402 Payment Required
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 returned the domain specified in the Request-URI. This status is also returned
if the domain in the Request-URI does not match any of the domains if the domain in the Request-URI does not match any of the 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
skipping to change at page 69, line 22 skipping to change at page 71, line 43
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 409 Conflict 7.4.10 409 Conflict
The request could not be completed due to a conflict with the current The request could not be completed due to a conflict with the current
state of the resource. This response is returned is the action state of the resource. This response is returned if the action
parameter in a REGISTER request conflicts with existing parameter in a REGISTER request conflicts with existing
registrations. registrations.
7.4.11 410 Gone 7.4.11 410 Gone
The requested resource is no longer available at the server and no The requested resource is no longer available at the server and no
forwarding address is known. This condition is expected to be forwarding address is known. This condition is expected to be
considered permanent. If the server does not know, or has no facility considered permanent. If the server does not know, or has no facility
to determine, whether or not the condition is permanent, the status to determine, whether or not the condition is permanent, the status
code 404 (Not Found) SHOULD be used instead. code 404 (Not Found) SHOULD be used instead.
skipping to change at page 70, line 16 skipping to change at page 72, line 36
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.15 415 Unsupported Media Type 7.4.15 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.
The server SHOULD return a list of acceptable formats using the
Accept, Accept-Encoding and Accept-Language header fields.
7.4.16 420 Bad Extension 7.4.16 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.17 480 Temporarily Unavailable 7.4.17 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
skipping to change at page 72, line 17 skipping to change at page 74, line 39
7.5 Server Failure 5xx 7.5 Server Failure 5xx
5xx responses are failure responses given when a server itself has 5xx responses are failure responses given when a server itself has
erred. They are not definitive failures, and MUST NOT terminate a erred. They are not definitive failures, and MUST NOT terminate a
search if other possible locations remain untried. search if other possible locations remain untried.
7.5.1 500 Server Internal Error 7.5.1 500 Server Internal Error
The server encountered an unexpected condition that prevented it from The server encountered an unexpected condition that prevented it from
fulfilling the request. fulfilling the request. The client MAY display the specific error
condition, and MAY retry the request after several seconds.
7.5.2 501 Not Implemented 7.5.2 501 Not Implemented
The server does not support the functionality required to fulfill the The server does not support the functionality required to fulfill the
request. This is the appropriate response when the server does not request. This is the appropriate response when the server does not
recognize the request method and is not capable of supporting it for recognize the request method and is not capable of supporting it for
any user. any user.
7.5.3 502 Bad Gateway 7.5.3 502 Bad Gateway
skipping to change at page 73, line 4 skipping to change at page 75, line 31
server has to use it when becoming overloaded. Some servers MAY wish server has to use it when becoming overloaded. Some servers MAY wish
to simply refuse the connection. to simply refuse the connection.
7.5.5 504 Gateway Timeout 7.5.5 504 Gateway Timeout
The server, while acting as a gateway, did not receive a timely The server, while acting as a gateway, did not receive a timely
response from the server (e.g., a location server) it accessed in response from the server (e.g., a location server) it accessed in
attempting to complete the request. attempting to complete the request.
7.5.6 505 Version Not Supported 7.5.6 505 Version Not Supported
The server does not support, or refuses to support, the SIP protocol The server does not support, or refuses to support, the SIP protocol
version that was used in the request message. The server is version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request indicating that it is unable or unwilling to complete the request
using the same major version as the client, other than with this using the same major version as the client, other than with this
error message. The response SHOULD contain an entity describing why error message. The response MAY contain an entity describing why
that version is not supported and what other protocols are supported that version is not supported and what other protocols are supported
by that server. by that server. The format for such an entity is not defined here and
may be the subject of future standardization.
7.6 Global Failures 6xx 7.6 Global Failures 6xx
6xx responses indicate that a server has definitive information about 6xx responses indicate that a server has definitive information about
a particular user, not just the particular instance indicated in the a particular user, not just the particular instance indicated in the
Request-URI. All further searches for this user are doomed to failure Request-URI. All further searches for this user are doomed to failure
and pending searches SHOULD be terminated. and pending searches SHOULD be terminated.
7.6.1 600 Busy Everywhere 7.6.1 600 Busy Everywhere
skipping to change at page 74, line 35 skipping to change at page 77, line 15
respones, the message body MAY contain the description of alternative respones, the message body MAY contain the description of alternative
destinations or services, as described in Section 7.3. For responses destinations or services, as described in Section 7.3. For responses
with status 400 or greater, the message body MAY contain additional, with status 400 or greater, the message body MAY contain additional,
human-readable information about the reasons for failure. It is human-readable information about the reasons for failure. It is
RECOMMENDED that information in 1xx and 300 and greater responses be RECOMMENDED that information in 1xx and 300 and greater responses be
of type text/plain or text/html 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 SHOULD be given by the Content-Length header The body length in bytes SHOULD be given by the Content-Length header
field. Section 6.15 describes the behavior in detail. field. Section 6.15 describes the behavior in detail.
skipping to change at page 75, line 4 skipping to change at page 77, line 32
The body length in bytes SHOULD be given by the Content-Length header The body length in bytes SHOULD be given by the Content-Length header
field. Section 6.15 describes the behavior in detail. field. Section 6.15 describes the behavior in detail.
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
response is larger than the MTU. To reduce this problem, a more response is larger than the MTU. To address this problem, a more
compact form of SIP is also defined by using alternative names for compact form of SIP is also defined by using abbreviations for the
common header fields. These short forms are NOT abbreviations, they common header fields listed below:
are field names. No other header field abbreviations are allowed.
short field name long field name note short field name long field name note
c Content-Type c Content-Type
e Content-Encoding e Content-Encoding
f From f From
i Call-ID i Call-ID
m Contact from "moved" m Contact from "moved"
l Content-Length l Content-Length
s Subject s Subject
t To t To
v Via v Via
Thus, the message in section 15.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
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
Mixing short field names and long field names is allowed, but not Clients MAY mix short field names and long field names within the
recommended. Servers MUST accept both short and long field names for same request. Servers MUST accept both short and long field names for
requests. Proxies MUST NOT translate a request between short and long requests. Proxies MAY change header fields between their long and
forms. short forms, but this MUST NOT be done to fields following an
Authorization header.
10 Behavior of SIP Clients and Servers 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 discard isomorphic requests, but first retransmit the
response. (SIP requests are said to be idempotent , i.e., receiving appropriate response. (SIP requests are said to be idempotent , i.e.,
more than one copy of a request does not change the server state.) receiving more than one copy of a request does not change the server
state.)
After receiving a CANCEL request from an upstream client, a stateful After receiving a CANCEL request from an upstream client, a stateful
proxy server MAY send a CANCEL on all branches where it has not yet proxy server MAY send a CANCEL on all branches where it has not yet
received a final response. received a final response.
When a user agent receives a request, it checks the Call-ID against When a user agent receives a request, it checks the Call-ID against
those of in-progress calls. If the Call-ID was found, it compares the those of in-progress calls. If the Call-ID was found, it compares the
tag value of To with the user's tag and rejects the request if the tag value of To with the user's tag and rejects the request if the
two do not match. If the From header, including any tag value, two do not match. If the From header, including any tag value,
matches the value for an existing call leg, the server compares the matches the value for an existing call leg, the server compares the
skipping to change at page 77, line 4 skipping to change at page 79, line 36
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.
Responses are mapped to requests by the matching To, From, Call-ID, Responses are mapped to requests by the matching To, From, Call-ID,
CSeq headers and the branch parameter of the first Via header. CSeq headers and the branch parameter of the first Via header.
Responses terminate request retransmissions even if they have Via Responses terminate request retransmissions even if they have Via
headers that cause them to be delivered to an upstream client. headers that cause them to be delivered to an upstream client.
A stateful proxy may receive a response that it does not have state A stateful proxy may receive a response that it does not have state
for, that is, where it has no a record of an isomorphic request. If for, that is, where it has no a record of an associated request. If
the Via header field indicates that the upstream server used TCP, the the Via header field indicates that the upstream server used TCP, the
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 SHOULD NOT be 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 2xx according to the Via header. Once a stateful proxy has received a 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 SHOULD maintain state for at least 32 seconds after
connections 20 seconds after receiving the first final response. the receipt of the first definitive non-200 response, in order to
handle retransmissions of the response.
The 20 second window is given by the maximum retransmission The 32 second window is given by the maximum retransmission
duration of 200 responses (10 times T4), in case the ACK is duration of 200-class responses using the default timers,
lost somewhere on the way to the called user agent or the in case the ACK is lost somewhere on the way to the called
next stateful proxy. user agent or the 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
Responses are returned to the address listed in the Via header field Responses are returned to the address listed in the Via header field
(Section 6.40), not the source address of the request. (Section 6.40), not the source address of the request.
Recall that responses are not generated by the next-hop
stateless server, but generated by either a proxy server or
the user agent server. Thus, the stateless proxy can only
use the Via header field to forward the response.
10.2.2 Multicast UDP 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. This request SHOULD be scoped to ensure it
live value of no greater than one, i.e., be restricted to the local is not forwarded beyond the boundaries of the administrative system.
network. This MAY be done with either TTL or administrative scopes[27],
depending on what is implemented in the network. However, use of
administrative scoping is RECOMMENDED.
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 name. the host part of the Request-URI matches its own host or domain name.
If the request was received via multicast, the response is also 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. The server delays
return 6xx responses if the To represents a single individual rather its response by a random interval uniformly distributed between zero
than a group of people. The server delays its response by a random and one second. Servers MAY suppress responses if they hear a
interval between zero and one second. Servers MAY suppress responses lower-numbered or 6xx response from another group member prior to
if they hear a lower-numbered or 6xx response from another group sending. Servers do not respond to CANCEL requests received via
member prior to sending. Servers do not respond to CANCEL requests multicast to avoid request implosion. A proxy or UAC SHOULD send a
received via multicast to avoid request implosion. A proxy or UAC CANCEL on receiving the first 2xx or 6xx response to a multicast
SHOULD send a CANCEL on receiving the first 2xx or 6xx response to a request.
multicast request.
Server response suppression is a MAY since it requires a Server response suppression is a MAY since it requires a
server to violate some basic message processing rules. Lets server to violate some basic message processing rules. Lets
say A sends a multicast request, and it is received by B,C, 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 and D. B sends a 200 response. The topmost Via field in the
response will contain the address of A. C will also receive response will contain the address of A. C will also receive
this response, and could use it to suppress its own this response, and could use it to suppress its own
response. However, C would normally not examine this response. However, C would normally not examine this
response, as the topmost Via is not its own. Normally, a response, as the topmost Via is not its own. Normally, a
response received with an incorrect topmost Via MUST be response received with an incorrect topmost Via MUST be
skipping to change at page 78, line 40 skipping to change at page 81, line 29
the use of CANCEL here is a SHOULD 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 can be generated.) for example, multiple 200 responses can be generated.)
The client MAY close the connection at any time, but SHOULD keep the The client SHOULD keep the connection open at least until the first
connection open at least until the first final response arrives. The final response arrives. If the client closes or resets the TCP
server SHOULD NOT close the TCP connection until it has sent its connection prior to receiving the first final response, the server
treats this action as equivalent to a CANCEL request.
This behavior makes it less likely that malfunctioning
clients cause a proxy server to keep connection state
indefinitely.
The server SHOULD NOT close the TCP connection until it has sent its
final response, at which point it MAY close the TCP connection if it final response, at which point it MAY close the TCP connection if it
wishes to. However, normally it is the client's responsibility to wishes to. However, normally it is the client's responsibility to
close the connection. close the connection.
If the server leaves the connection open, and if the client so If the server leaves the connection open, and if the client so
desires it MAY re-use the connection for further SIP requests or for 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.,
because the client has crashed and rebooted), the server treats this
as equivalent to having received a CANCEL request for all pending
transactions.
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 be address listed in the Via header. Thus, a proxy or user agent MUST 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 with an exponential backoff, starting at a T1 second
response, or until it has reached a set limit on the number of interval, doubling the interval for each packet, and capping off at a
retransmissions. If the response is provisional, the client continues T2 second interval. This means that after the first packet is sent,
to retransmit the request, albeit less frequently, using timer T2. the second is sent T1 seconds later, the next 2*T1 seconds after
The default values of timer T1 and T2 are 1 and 5 seconds, that, the next 4*T1 seconds after that, and so on, until the interval
respectively. The default retransmit limit is 20 times. After the hits T2. Subsequent retransmissions are spaced by T2 seconds. If the
server sends a final response, it cannot be sure the client has client receives a provisional response, it continues to retransmit
received the response, and thus SHOULD cache the results for at least the request, but with an interval of T2 seconds. Retransmissions
100 seconds to avoid having to, for example, contact the user or cease when the client has sent a total of eleven packets, or receives
location server again upon receiving a retransmission. a definitive response. Default values for T1 and T2 are 500ms and 4s,
respectively. Clients MAY use larger values, but SHOULD NOT use
smaller ones. After the server sends a final response, it cannot be
sure the client has received the response, and thus SHOULD cache the
results for at least 10*T2 seconds to avoid having to, for example,
contact the user or location server again upon receiving a
retransmission.
Use of the exponential backoff is for congestion control
purposes. However, the back-off must cap off, since request
retransmissions are used to trigger response
retransmissions at the server. Without a cap, the loss of a
single response could significantly increase transaction
latencies.
The value of the initial retransmission timer is smaller than that
that for TCP since it is expected that network paths suitable for
interactive communications have round-trip times smaller than 500ms.
For congestion control purposes, the retransmission count has to be
bounded. Given that most transactions are expected to consist of one
request and a few responses, round-trip time estimation is not likely
to be very useful. If RTT estimation is desired to more quickly
discover a missing final response, each request retransmission needs
to be labeled with its own Timestamp (Section 6.36), returned in the
response. The server caches the result until it can be sure that the
client will not retransmit the same request again.
Each server in a proxy chain generates its own final response to a Each server in a proxy chain generates its own final response to a
CANCEL request. The server responds immediately upon receipt of the CANCEL request. The server responds immediately upon receipt of the
CANCEL request rather than not waiting until it has received final CANCEL request rather than waiting until it has received final
responses from the CANCEL requests it generates. responses from the CANCEL requests it generates.
BYE and OPTIONS final responses are generated by redirect and user BYE and OPTIONS final responses are generated by redirect and user
agent servers; REGISTER final responses are generated by registrars. agent servers; REGISTER final responses are generated by registrars.
Note that in contrast to the reliability mechanism described in Note that in contrast to the reliability mechanism described in
Section 10.5, responses to these requests are not retransmitted and Section 10.5, responses to these requests are not retransmitted
not acknowledged via ACK. periodically and not acknowledged via ACK.
The value of the initial retransmission timer is smaller
than that that for TCP since it is expected that network
paths suitable for interactive communications have round-
trip times smaller than 1 second. To avoid flooding the
network with packets every second even if the destination
network is unreachable, the retransmission count has to be
bounded. Given that most transactions are expected to
consist of one request and a few responses, round-trip time
estimation is not likely to be very useful. If RTT
estimation is desired to more quickly discover a missing
final response, each request retransmission needs to be
labeled with its own Timestamp (Section 6.36), returned in
the response. The server caches the result until it can be
sure that the client will not retransmit the same request
again.
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 INVITE Requests 10.5 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 can elapse 1. After receiving an invitation, considerable time can elapse
skipping to change at page 80, line 41 skipping to change at page 83, line 42
initiate ringback.) Once the callee picks up, the caller initiate ringback.) Once the callee picks up, the caller
needs to know so that it can enable the voice path and stop needs to know so that it can enable the voice path and stop
ringback. The callee's response to the invitation could get ringback. The callee's response to the invitation could get
lost. Unless the response is transmitted reliably, the lost. Unless the response is transmitted reliably, the
caller will continue to hear ringback while the callee caller will continue to hear ringback while the callee
assumes that the call exists. assumes that the call exists.
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 retransmission intervals to interpret the lack
request retransmissions as the end of a call. If the call of request retransmissions as the end of a call. If the
succeeds shortly after the caller has given up, the callee call succeeds shortly after the caller has given up, the
will "pick up the phone" and not be "connected". callee will "pick up the phone" and not be "connected".
10.5.1 UDP 10.5.1 UDP
For UDP, A SIP client SHOULD retransmit a SIP INVITE request For UDP, A SIP client SHOULD retransmit a SIP INVITE request with an
periodically with timer T1 until it receives a response. If the interval that starts at T1 seconds, and doubles after each packet
client receives no response, it ceases retransmission after 20 transmission. The client ceases retransmissions if it receives a
attempts. If the response is provisional, the client continues to provisional or definitive response, or once it has sent a total of 7
retransmit the request, albeit less frequently, using timer T3. The request packets.
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 A server which transmits a provisional response should retransmit it
calls, only one INVITE request will be issued. Typically, a upon reception of a duplicate request. A server which transmits a
phone switches to an answering machine or voice mail after final response should retransmit it with an interval that starts at
about 20--22 seconds. The number of retransmissions after T1 seconds, and doubles for each subsequent packet. Retransmissions
receiving a provisional response is unlimited to allow call cease when any one of the following occurs:
queueing. Clients MAY limit the number of invitations sent
for each call attempt. 1. An ACK request for the same transaction is received;
2. a BYE request for the same call leg is received;
3. a CANCEL request for the same call leg is received and the
final response status was equal or greater to 300;
4. the response has been transmitted 7 times.
Only the user agent client generates an ACK for 2xx final responses, Only the user agent client generates an ACK for 2xx final responses,
If the response contained a Contact header field, the ACK MAY be sent If the response contained a Contact header field, the ACK MAY be sent
to the address listed in that Contact header field. If the response to the address listed in that Contact header field. If the response
did not contain a Contact header, the client uses the same To header did not contain a Contact header, the client uses the same To header
field and Request-URI as for the INVITE request and sends the ACK to field and Request-URI as for the INVITE request and sends the ACK to
the same destination as the original INVITE request. ACKs for final the same destination as the original INVITE request. ACKs for final
responses other than 2xx are sent to the same server that the responses other than 2xx are sent to the same server that the
original request was sent to, using the same Request-URI as the original request was sent to, using the same Request-URI as the
original request. Note, however, that the To header field in the ACK original request. Note, however, that the To header field in the ACK
is copied from the response being acknowledged, not the request, and is copied from the response being acknowledged, not the request, and
thus MAY additionally contain the tag parameter. Also note than thus MAY additionally contain the tag parameter. Also note than
unlike 2xx final responses, a proxy generates an ACK for non-2xx unlike 2xx final responses, a proxy generates an ACK for non-2xx
final responses. final responses.
The server retransmits the final response at intervals of T4 (default
value of T4 = 2 seconds) until one of the following conditions is
true:
1. An ACK request for the same transaction is received;
2. a BYE request for the same call leg is received;
3. a CANCEL request for the same call leg is received and the
final response status was equal or greater to 300;
4. the response has been retransmitted 10 times.
The ACK request MUST NOT be acknowledged to prevent a response-ACK The ACK request MUST NOT be acknowledged to prevent a response-ACK
feedback loop. Fig. 11 and 12 show the client and server state feedback loop. Fig. 11 and 12 show the client and server state
diagram for invitations. diagram for invitations.
The mechanism in Sec. 10.4 would not work well for INVITE The mechanism in Sec. 10.4 would not work well for INVITE
because of the long delays between INVITE and a final because of the long delays between INVITE and a final
response. If the 200 response were to get lost, the callee
would believe the call to exist, but the voice path would
be dead since the caller does not know that the callee has
picked up. Thus, the INVITE retransmission interval would
have to be on the order of a second or two to limit the
duration of this state confusion. Retransmitting the
response with an exponential back-off helps ensure that the
response is received, without placing an undue burden on
+===========+ +===========+
* * * *
...........>* Initial *<;;;;;;;;;; ...........>* Initial *<;;;;;;;;;;
: 20*T1 * * ; : 7 pkts * * ;
: +===========+ ; : sent +===========+ ;
: | ; : | ;
: | - ; : | - ;
: | INVITE ; : | INVITE ;
: | ; : | ;
: v ; : v ;
: ************* ; : ************* ;
: T1 <--* * ; : timer <--* * ;
: INVITE -->* Calling *--------+ ; : INVITE -->* Calling *--------+ ;
: * * | ; : * * | ;
: ************* | ; : ************* | ;
: : | | ; : : | | ;
:.............: | 1xx xxx | ; :.............: | 1xx xxx | ;
| - ACK | ; | - ACK | ;
| | ; | | ;
v | ; v | ;
************* | ; ************* | ;
T3 <--* * | ; * * | ;
INVITE -->* Ringing *<->1xx | ; * Ringing *<->1xx | ;
* * | ; * * | ;
************* | ; ************* | ;
| | ; | | ;
|<-------------+ ; |<-------------+ ;
| ; | ;
v ; v ;
************* ; ************* ;
xxx <--* * ; xxx <--* * ;
ACK -->* Completed * ; ACK -->* Completed * ;
* * ; * * ;
************* ; ************* ;
; 10*T4 ; ; 32s ;
;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;
event (xxx=status) event (xxx=status)
message message
Figure 11: State transition diagram of client for INVITE method Figure 11: State transition diagram of client for INVITE method
response. If the 200 response were to get lost, the callee the network.
would believe the call to exist, but the voice path would
be dead since the caller does not know that the callee has 10.5.2 TCP
10*T4 +===============+ 7 pkts sent +===============+
+-------------->* * +-------------->* *
| * Initial *<............... | * Initial *<...............
|;;;;;;;;;;;;;;>* * |;;;;;;;;;;;;;;>* *
|; +===============+ : |; +===============+ :
|; CANCEL ! : |; CANCEL ! :
|; 200 ! : |; 200 ! :
|; ! INVITE : |; ! INVITE :
|; ! 1xx : |; ! 1xx :
|; ! : |; ! :
|; v : |; v :
skipping to change at page 83, line 27 skipping to change at page 86, line 27
|; 1xx <--* Call proceed. *..............>: |; 1xx <--* Call proceed. *..............>:
|; * * : |; * * :
|;;;;;;;;;;;;;;;***************** : |;;;;;;;;;;;;;;;***************** :
|; ! ! : |; ! ! :
|: ! ! : |: ! ! :
|; failure ! ! picks up : |; failure ! ! picks up :
|; >= 300 ! ! 200 : |; >= 300 ! ! 200 :
|; +-------+ +-------+ : |; +-------+ +-------+ :
|; v v : |; v v :
|; *********** *********** : |; *********** *********** :
|;INVITE<* *< T4 ->* *>INVITE : |;INVITE<* *< timer->* *>INVITE :
|;status>* failure *>status<-* success *<status : |;status>* failure *>status<-* success *<status :
|; * * * * : |; * * * * :
|;;;;;;;;*********** *********** : |;;;;;;;;*********** *********** :
| ! : | | ! : : | ! : | | ! : :
| ! : | | ! : : | ! : | | ! : :
+-------------!-:-+------------+ ! : : +-------------!-:-+------------+ ! : :
! :.................!..:.........>: ! :.................!..:.........>:
! ! BYE : ! ! BYE :
+---------+---------+ 200 : +---------+---------+ 200 :
! ACK : ! ACK :
skipping to change at page 84, line 4 skipping to change at page 87, line 4
V---* * : V---* * :
ACK * Confirmed * : ACK * Confirmed * :
|-->* * : |-->* * :
***************** . ***************** .
: : : :
:......................>: :......................>:
event event
message sent message sent
Figure 12: State transition diagram of server for INVITE method Figure 12: State transition diagram of server for INVITE method
picked up. Thus, the INVITE retransmission interval would
have to be on the order of a second or two to limit the
duration of this state confusion. Retransmitting the
response a fixed number of times increases the probability
of success, but at the cost of significantly higher
processing and network load.
10.5.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.5.1) to retransmit responses until algorithm as for UDP (Section 10.5.1) to retransmit responses until
it receives an ACK. (An implementation can simply set T1 and T3 to it receives an ACK.
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.
10.6 Reliability for ACK Requests 10.6 Reliability for ACK Requests
The ACK request does not generate responses. It is only generated The ACK request does not generate responses. It is only generated
when a response to an INVITE request arrives (see Section 10.5). This when a response to an INVITE request arrives (see Section 10.5). This
behavior is independent of the transport protocol. Note that the ACK behavior is independent of the transport protocol. Note that the ACK
request MAY take a different path than the original INVITE request, request MAY take a different path than the original INVITE request,
and MAY even cause a new TCP connection to be opened in order to send and MAY even cause a new TCP connection to be opened in order to send
it. it.
10.7 ICMP Handling
Handling of ICMP messages in the case of UDP messages is
straightforward. For requests, a host, network, port, or protocol
unreachable error SHOULD be treated as if a 400-class response was
received. For responses, these errors SHOULD cause the server to
cease retransmitting the response.
Source quench ICMP messages SHOULD be ignored. TTL exceeded errors
SHOULD be ignored. Parameter problem errors SHOULD be treated as if a
400-class response was received.
11 Behavior of SIP User Agents 11 Behavior of SIP User Agents
This section describes the rules for user agent client and servers This section describes the rules for user agent client and servers
for generating and processing requests and responses. for generating and processing requests and responses.
11.1 Caller Issues Initial INVITE Request 11.1 Caller Issues Initial INVITE Request
When a user agent client desires to initiate a call, it formulates an When a user agent client desires to initiate a call, it formulates an
INVITE request. The To field in the request contains the address of INVITE request. The To field in the request contains the address of
the callee. The Request-URI contains the same address. The From field the callee. The Request-URI contains the same address. The From field
skipping to change at page 86, line 34 skipping to change at page 89, line 36
12 Behavior of SIP Proxy and Redirect Servers 12 Behavior of SIP Proxy and Redirect Servers
This section describes behavior of SIP redirect and proxy servers in This section describes behavior of SIP redirect and proxy servers in
detail. Proxy servers can "fork" connections, i.e., a single incoming detail. Proxy servers can "fork" connections, i.e., a single incoming
request spawns several outgoing (client) requests. request spawns several outgoing (client) requests.
12.1 Redirect Server 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 other than CANCEL, the server gathers the list of
locations and returns a final response of class 3xx or it refuses the alternative locations and returns a final response of class 3xx or it
request. For CANCEL requests, it SHOULD also return a 2xx response. refuses the request. For well-formed CANCEL requests, it SHOULD
This response ends the SIP transaction. The redirect server maintains return a 2xx response. This response ends the SIP transaction. The
transaction state for the whole SIP transaction. It is up to the redirect server maintains transaction state for the whole SIP
client to detect forwarding loops between redirect servers. transaction. It is up to the client to detect forwarding loops
between redirect servers.
12.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 also accept requests and can return a response of class 2xx. they also accept requests and can return a response of class 2xx.
12.3 Proxy Server 12.3 Proxy Server
This section outlines processing rules for proxy servers. A proxy This section outlines processing rules for proxy servers. A proxy
server can either be stateful or stateless. When stateful, a proxy server can either be stateful or stateless. When stateful, a proxy
remembers the incoming request which generated outgoing requests, and remembers the incoming request which generated outgoing requests, and
the outgoing requests. A stateless proxy forgets all information once the outgoing requests. A stateless proxy forgets all information once
an outgoing request is generated. A forking proxy SHOULD be stateful. an outgoing request is generated. A forking proxy SHOULD be stateful.
A stateful proxy MAY become stateless at any time, but SHOULD remain Proxies that accept TCP connections MUST be stateful.
stateful until it sends a definitive response upstream.
Otherwise, if the proxy were to lose a request, the TCP
client would never retransmit it.
A stateful proxy SHOULD NOT become stateless until after it sends a
definitive response upstream, at least 32 seconds after it
received a definitive response.
A stateful proxy acts as a virtual UAS/UAC. It implements the server A stateful proxy acts as a virtual UAS/UAC. It implements the server
state machine when receiving requests, and the client state machine state machine when receiving requests, and the client state machine
for generating outgoing requests, with the exception of receiving a for generating outgoing requests, with the exception of receiving a
2xx response to an INVITE. Instead of generating an ACK, the 2xx 2xx response to an INVITE. Instead of generating an ACK, the 2xx
response is always forwarded upstream towards the caller. response is always forwarded upstream towards the caller.
Furthermore, ACK's for 200 responses to INVITE's are always proxied Furthermore, ACK's for 200 responses to INVITE's are always proxied
downstream towards the UAS, as they would be for a stateless proxy. 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 A stateless proxy does not act as a virtual UAS/UAC (as this would
skipping to change at page 87, line 42 skipping to change at page 91, line 4
12.3.2 Proxying Responses 12.3.2 Proxying Responses
A proxy only processes a response if the topmost Via field matches 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 one of its addresses. A response with a non-matching top Via field
MUST be dropped. MUST be dropped.
12.3.3 Stateless Proxy: Proxying Responses 12.3.3 Stateless Proxy: Proxying Responses
A stateless proxy removes its own Via field, and checks the address 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 in the next Via field. In the case of UDP, the response is sent to
protocol, the proxy checks to see if it has a connection currently the address listed in the "maddr" tag if present, otherwise to the
open to that address. If so, the response is sent on that connection. "received" tag if present, and finally to the address in the "sent-
Otherwise, a new TCP connection is opened to the address and port in by" field. A proxy MUST remain stateful when handling requests
the Via field, and the response is sent there. In the case of UDP, received via TCP.
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. A stateless proxy MUST NOT generate its own provisional responses.
12.3.4 Stateful Proxy: Receiving Requests 12.3.4 Stateful Proxy: Receiving Requests
When a stateful proxy receives a request, it checks the To, From When a stateful proxy receives a request, it checks the To, From
(including tags), Call-ID and CSeq against existing request records. (including tags), Call-ID and CSeq against existing request records.
If the tuple exists, the request is a retransmission. The provisional If the tuple exists, the request is a retransmission. The provisional
or final response sent previously is retransmitted, as per the server or final response sent previously is retransmitted, as per the server
state machine. If the tuple does not exist, the request corresponds state machine. If the tuple does not exist, the request corresponds
skipping to change at page 88, line 29 skipping to change at page 91, line 34
12.3.5 Stateful Proxy: Receiving ACKs 12.3.5 Stateful Proxy: Receiving ACKs
When an ACK request is received, it is either processed locally or When an ACK request is received, it is either processed locally or
proxied. To make this determination, the To, From, CSeq and Call-ID proxied. To make this determination, the To, From, CSeq and Call-ID
fields are compared against those in previous requests. If there is 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. 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 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 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 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 3xx, 4xx, 5xx or 6xx response, but no 2xx response, the ACK is
processed locally, as it is acknowledging the response generated by processed locally if the tag in the To field of the ACK matches the
the proxy. tag sent by the proxy in the response.
12.3.6 Stateful Proxy: Receiving Responses 12.3.6 Stateful Proxy: Receiving Responses
When a proxy server receives a response that has passed the Via When a proxy server receives a response that has passed the Via
checks, the proxy server checks the To (without the tag), From checks, the proxy server checks the To (without the tag), From
(including the tag), Call-ID and CSeq against values seen in previous (including the tag), Call-ID and CSeq against values seen in previous
requests. If there is no match, the response is forwarded upstream to 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 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" tag in the Via field is examined. If it matches a known
branch identifier, the response is for the given branch, and branch identifier, the response is for the given branch, and
processed by the virtual client for the given branch. Otherwise, the processed by the virtual client for the given branch. Otherwise, the
response is dropped. response is dropped.
A stateful proxy should obey the rules in Section 12.4 to determine 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, if the response should be proxied upstream. If it is to be proxied,
the same rules for stateless proxies above are followed. the same rules for stateless proxies above are followed, with the
following addition for TCP. If request was received via TCP
(indicated by the protocol in the top Via header, the proxy checks to
see if it has a connection currently open to that address. If so, the
response is sent on that connection. Otherwise, a new TCP connection
is opened to the address and port in the Via field, and the response
is sent there. Note that this implies that a UAC or proxy MUST be
prepared to receive responses on the incoming side of a TCP
connection. Definitive non 200-class responses MUST be retransmitted
by the proxy, even over a TCP connection.
12.3.7 Stateless, Non-Forking Proxy 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 12.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
skipping to change at page 89, line 29 skipping to change at page 92, line 44
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.
Successful responses to an INVITE request SHOULD contain a Contact Successful responses to an INVITE request SHOULD contain a Contact
header field so that the following ACK or BYE bypasses the proxy header field so that the following ACK or BYE bypasses the proxy
search mechanism. If the proxy requires future requests to be routed search mechanism. If the proxy requires future requests to be routed
through it, it adds a Record-Route header to the request (Section through it, it adds a Record-Route header to the request (Section
6.29). 6.29).
The following pseudo-code describes the behavior of a proxy server The following C-code describes the behavior of a proxy server issuing
issuing several requests in response to an incoming INVITE request. several requests in response to an incoming INVITE request. The
The function request(r, a, b) sends a SIP request of type r to function request(r, a, b) sends a SIP request of type r to address a,
address a, with branch id b. await_response() waits until a response with branch id b. await_response() waits until a response is received
is received and returns the response. close(a) closes the TCP and returns the response. close(a) closes the TCP connection to
connection to client with address a. response(r) sends a response to client with address a. response(r) sends a response to the client.
the client. ismulticast() returns 1 if the location is a multicast ismulticast() returns 1 if the location is a multicast address and
address and zero otherwise. The variable timeleft indicates the zero otherwise. The variable timeleft indicates the amount of time
amount of time left until the maximum response time has expired. The left until the maximum response time has expired. The variable
variable recurse indicates whether the server will recursively try recurse indicates whether the server will recursively try addresses
addresses returned through a 3xx response. A server MAY decide to returned through a 3xx response. A server MAY decide to recursively
recursively try only certain addresses, e.g., those which are within try only certain addresses, e.g., those which are within the same
the same domain as the proxy server. Thus, an initial multicast domain as the proxy server. Thus, an initial multicast request can
request can trigger additional unicast requests. trigger additional unicast requests.
/* request type */ /* request type */
typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method; typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method;
process_request(Method R, int N, address_t address[]) process_request(Method R, int N, address_t address[])
{ {
struct { struct {
address_t address; /* address */
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 */
skipping to change at page 90, line 48 skipping to change at page 94, line 14
outgoing[i].done = 1; outgoing[i].done = 1;
break; break;
} }
} }
} }
/* CANCEL: respond, fork and wait for responses */ /* CANCEL: respond, fork and wait for responses */
else if (class < 0) { else if (class < 0) {
best.status = 200; best.status = 200;
response(best); response(best);
for (i = 0; i < N; i++) { for (i = 0; i < N; i++) {
if (!outgoing[i].done)
request(CANCEL, address[i], outgoing[i].branch); request(CANCEL, address[i], outgoing[i].branch);
} }
best.status = -1; best.status = -1;
} }
/* Send an ACK */
if (class != 2) {
if (R == INVITE) request(ACK, r.a, r.branch);
}
if (class == 2) { if (class == 2) {
if (r.status < best) best = r; if (r.status < best.status) 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);
} }
else if (class == 4) { else if (class == 4) {
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 (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);
best = r; best = r;
break; break;
} }
} }
/* 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;
skipping to change at page 93, line 49 skipping to change at page 97, line 19
by the request and to prevent infinite request loops. However, the by the request and to prevent infinite request loops. However, the
information given by them can also provide useful information to an information given by them can also provide useful information to an
attacker. Section 6.22 describes how a sender can request that Via attacker. Section 6.22 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. All implementations SHOULD support PGP-based read the message. All implementations SHOULD support PGP-based
encryption and MAY implement other schemes. encryption [33] and MAY implement other schemes.
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 and 5 need to be read and with "n" in the "enc." column in Table 4 and 5 need to be read and
returned by proxies and thus MUST NOT be encrypted end-to-end. returned by proxies and thus MUST NOT be encrypted end-to-end.
Possibly sensitive information that needs to be made available as Possibly sensitive information that needs to be made available as
plaintext include destination address (To) and the forwarding path plaintext include destination address (To) and the forwarding path
(Via) of the call. The Authorization header field MUST remain in the (Via) of the call. The Authorization header field MUST remain in the
skipping to change at page 96, line 31 skipping to change at page 99, line 46
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 need to encrypt a SIP request if the end system Proxies 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.
13.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 or network layer.
13.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.22) SHOULD encrypt the header field. As only the proxy that section 6.22) 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 97, line 13 skipping to change at page 100, line 29
number SHOULD be used by the proxy and maintained in the cache. number SHOULD be used by the proxy and maintained in the cache.
It is possible for replies to get directed to the wrong It is possible for replies to get directed to the wrong
originator if the cache entry gets reused, so great care needs originator if the cache entry gets reused, so great care needs
to be taken to ensure this does not happen. to be taken to ensure this does not happen.
o The server MAY use a secret key to encrypt the Via field, a o The server MAY use a secret key to encrypt the Via field, a
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 replay attacks and to ensure that
that no two requests from the same previous hop have the same no two requests from the same previous hop have the same
encrypted Via field. This is the preferred solution. encrypted Via field. This is the preferred solution.
13.2 Message Integrity and Access Control: Authentication 13.2 Message Integrity and Access Control: Authentication
Protective measures need to be taken to prevent an active attacker Protective measures need to be taken to prevent an active attacker
from modifying and replaying SIP requests and responses. The same from modifying and replaying SIP requests and responses. 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. However, the "basic" and "digest" authentication mechanism message. However, the "basic" and "digest" authentication mechanism
offer authentication only, without message integrity. offer authentication only, without message integrity.
skipping to change at page 99, line 10 skipping to change at page 102, line 24
Call-ID: 187602141351@worcester.bell-telephone.com Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here. Subject: Mr. Watson, come here.
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
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
Clients wishing to authenticate requests MUST construct the portion
of the mesage below the Authorization header using a canonical form.
This allows a proxy to parse the message, take it apart, and
reconstruct it, without causing an authentication failure due to
extra white space, for example. Canonical form consists of the
following rules:
o Header field names are capitalized as shown in this document
o No white space between the header name and the colon
o A single space after the colon
o No white space before or after a semicolon separating
parameters
o No white space before or after an equal sign separating a
parameter from its value
o No line folding
o No comma separated lists of header values; each must appear as
a separate header
Note that if a message is encrypted and authenticated using a digital Note that if a message is encrypted and authenticated using a digital
signature, when the message is generated encryption is performed signature, when the message is generated encryption is performed
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.
skipping to change at page 99, line 31 skipping to change at page 103, line 24
request that requires authenticated responses is described in section request that requires authenticated responses is described in section
13.2.1. 13.2.1.
13.2.1 Trusting responses 13.2.1 Trusting responses
There is the possibility that an eavesdropper listens to requests and There is the possibility that an eavesdropper listens to requests and
then injects unauthenticated responses that terminate, redirect or then injects unauthenticated responses that 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 need to be particularly careful with 3xx redirection Clients need to be particularly careful with 3xx redirection
responses. Thus a client receiving, for example, a 301 (Moved responses. Thus a client receiving, for example, a 301 (Moved
Permanently) which was not authenticated when the public key of the Permanently) which was not authenticated when the public key of the
called user agent is known to the client, and authentication was called user agent is known to the client, and authentication was
requested in the request SHOULD be treated as suspicious. The correct requested in the request SHOULD be treated as suspicious. The correct
behaviour in such a case would be for the called-user to form a dated behaviour in such a case would be for the called-user to form a dated
response containing the Contact field to be used, to sign it, and response containing the Contact field to be used, to sign it, and
give this signed stub response to the proxy that will provide the give this signed stub response to the proxy that will provide the
redirection. Thus the response can be authenticated correctly. A redirection. Thus the response can be authenticated correctly. A
client SHOULD NOT automatically redirect such a request to the new client SHOULD NOT automatically redirect such a request to the new
location without alerting the user to the authentication failure location without alerting the user to the authentication failure
skipping to change at page 101, line 4 skipping to change at page 104, line 42
14.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
authenticates itself with a request signed with the client's private authenticates itself with a request signed with the client's private
key. The server can then ascertain the origin of the request if it key. The server can then ascertain the origin of the request if it
has access to the public key, preferably signed by a trusted third has access to the public key, preferably signed by a trusted third
party. party.
14.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 = * (";" pgp-params ) pgp-challenge = * (";" pgp-params )
pgp-params = realm | pgp-version | pgp-algorithm 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
performing the authentication and MAY additionally indicate the performing the authentication and MAY additionally indicate the
collection of users who might have access. An example might be " collection of users who might have access. An example might be "
Users with call-out privileges ". Users with call-out privileges ".
pgp-algorithm: A string indicating the PGP message integrity check pgp-algorithm: The value of this parameter indicates the PGP message
(MIC) to be used to produce the signature. If this not present integrity check (MIC) to be used to produce the signature. If
it is assumed to be "md5". The currently defined values are this not present it is assumed to be "md5". The currently
"md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm. defined values are "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"
14.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 ___ 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 [33], as it appears
the "BEGIN PGP MESSAGE" and "END PGP MESSAGE" delimiters, between the "BEGIN PGP MESSAGE" and "END PGP MESSAGE"
without the version indication. The signature is included delimiters, without the version indication. The signature is
without any linebreaks. included without any linebreaks.
The signature is computed across the request method, request version The signature is computed across the request method, request version
and header fields following the Authorization header and the message and header fields following the Authorization header and the message
body, in the same order as they appear in the message. The request body, in the same order as they appear in the message. The request
method and version are prepended to the header fields without any method and version are prepended to the header fields without any
white space. The signature is computed across the headers as sent, white space. The signature is computed across the headers as sent,
including any folding and the terminating CRLF. The CRLF following including any folding (folding is the insertion of a CR-LF followed
the Authorization header is NOT included in the signature. by a space to allow headers to span multiple lines in a message) and
the terminating CRLF. The CRLF following the Authorization header is
NOT included in the signature.
Using the ASCII-armored version is about 25% less space- Using the ASCII-armored version is about 25% less space-
efficient than including the binary signature, but it is efficient than including the binary signature, but it is
significantly easier for the receiver to piece together. significantly easier for the receiver to piece together.
Versions of the PGP program always include the full Versions of the PGP program always include the full
(compressed) signed text in their output unless ASCII- (compressed) signed text in their output unless ASCII-
armored mode ( -sta ) is specified. Typical signatures are armored mode ( -sta ) is specified. Typical signatures are
about 200 bytes long. -- The PGP signature mechanism allows about 200 bytes long. -- The PGP signature mechanism allows
the client to simply pass the request to an external PGP the client to simply pass the request to an external PGP
program. This relies on the requirement that proxy servers program. This relies on the requirement that proxy servers
skipping to change at page 103, line 4 skipping to change at page 106, line 44
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"
14.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"
14.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 from the
"pgp -kxa user ". pgp key ring with the "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"
skipping to change at page 104, line 7 skipping to change at page 108, line 4
sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu
bmVAY3MuY29sdW1iaWEuZWR1Pg== bmVAY3MuY29sdW1iaWEuZWR1Pg==
=+y19" =+y19"
15 Examples 15 Examples
In the following examples, we often omit the message body and the In the following examples, we often omit the message body and the
corresponding Content-Length and Content-Type headers for brevity. corresponding Content-Length and Content-Type headers for brevity.
15.1 Registration 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 bell-tel.com. In 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:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP 128.16.64.19 Via: SIP/2.0/UDP saturn.bell-tel.com
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 Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sip:saturn.bell-tel.com:3890;transport=udp> Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp>
Expires: 7200 Expires: 7200
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 saturn.bell-tel.com
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: 1345441868@saturn.bell-tel.com Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 REGISTER CSeq: 2 REGISTER
Contact: * Contact: *
Expires: 0 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 saturn.bell-tel.com
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: 81791800@saturn.bell-tel.com Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 REGISTER CSeq: 3 REGISTER
Contact: sip:tawatson@example.com Contact: 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, T. Watson:
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 pluto.bell-tel.com
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 Call-ID: 17320@pluto.bell-tel.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: sip:tawatson@example.com Contact: sip:tawatson@example.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. In the latter case, the server at
address indicated in the Request-URI. Then, Max-Forwards header could example.com would proxy the request to the address indicated in the
be used to restrict the registration to that server. Request-URI. Then, Max-Forwards header could be used to restrict the
registration to that server.
15.2 Invitation to a Multicast Conference 15.2 Invitation to a 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 [6]) as the session description format.
15.2.1 Request 15.2.1 Request
C->S: INVITE sip:schooler@vlsi.cs.caltech.edu SIP/2.0 C->S: INVITE sip:schooler@cs.caltech.edu SIP/2.0
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
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 Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE CSeq: 1 INVITE
Subject: SIP will be discussed, too Subject: SIP will be discussed, too
Content-Type: application/sdp Content-Type: application/sdp
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
The Via fields list the hosts along the path from invitation The From request header above states that the request was initiated
initiator (the last element of the list) towards the invitee. In the by mjh@isi.edu and addressed to schooler@caltech.edu (From header
fields). The Via fields list the hosts along the path from invitation
initiator (the last element of the list) towards the callee. In the
example above, the message was last multicast to the administratively example above, the message was last multicast to the administratively
scoped group 239.128.16.254 with a ttl of 16 from the host scoped group 239.128.16.254 with a ttl of 16 from the host
131.215.131.131 csvax.cs.caltech.edu. The second Via header field indicates that it
was originally sent from the host north.east.isi.edu. The Request-URI
The request header above states that the request was initiated by indicates that the request is currently being being addressed to
mjh@isi.edu from the host 128.16.64.19 schooler@caltech.edu is being schooler@cs.caltech.edu, the local address that csvax looked up for
invited; the message is currently being routed to the callee.
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.
15.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
From: Mark Handley <sip:mjh@isi.edu> From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472 To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@oregon.isi.edu Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 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 are response, which means the request was successful. The Via headers 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
skipping to change at page 107, line 15 skipping to change at page 111, line 19
In addition, the Contact header gives details of the host where the In addition, the Contact 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;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
From: Mark Handley <sip:mjh@isi.edu> From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472 To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@oregon.isi.edu Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: sip:es@jove.cs.caltech.edu Contact: sip:es@jove.cs.caltech.edu
The caller confirms the invitation by sending a request to the The caller confirms the invitation by sending an ACK request to the
location named in the Contact header: location named in the Contact 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
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 Via: SIP/2.0/UDP north.east.isi.edu
;maddr=239.128.16.254;ttl=16
From: Mark Handley <sip:mjh@isi.edu> From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472 To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@oregon.isi.edu Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 ACK CSeq: 1 ACK
15.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 kton.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:watson@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE CSeq: 1 INVITE
Subject: Mr. Watson, come here. Subject: Mr. Watson, come here.
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. s=Mr. Watson, come here.
c=IN IP4 135.180.144.94 c=IN IP4 kton.bell-tel.com
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 Via: SIP/2.0/UDP kton.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:watson@bell-tel.com> ;tag=37462311 To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE 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 Via: SIP/2.0/UDP kton.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:watson@bell-tel.com> ;tag=37462311 To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE 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 Via: SIP/2.0/UDP kton.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:watson@bell-tel.com> ;tag=37462311 To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE 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 Via: SIP/2.0/UDP kton.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:watson@bell-tel.com> ;tag=37462311 To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE 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 Via: SIP/2.0/UDP kton.bell-tel.com
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> ;tag=37462311 To: <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: sip:watson@boston.bell-tel.com Contact: 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 s=I'm on my way
c=IN IP4 135.180.161.25 c=IN IP4 boston.bell-tel.com
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 c.bell-tel.com, Bell will send to
port 5004 at 135.180.161.25. port 5004 at boston.bell-tel.com.
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 agreed on the set of media, Watson confirms Since the two sides have agreed on the set of media, Bell 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 kton.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:watson@bell-tel.com> ;tag=37462311 To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 ACK CSeq: 1 ACK
15.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 Via: SIP/2.0/UDP kton.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. A. Watson <sip:watson@bell-tel.com> ;tag=37462311 To: T. A. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 2 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 a BYE from the callee will
will traverse the same proxies as the original INVITE. traverse the same proxies as the original INVITE.
15.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 t.watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has
registered with the IEEE proxy server (P) called sip.ieee.org registered with the IEEE proxy server (P) called sip.ieee.org. The
registration for the home machine of Watson, at watson@h.bell-tel.com IEEE server also has a registration for the home machine of Watson,
(H), as well as a permanent registration at watson@acm.org (A). For at watson@h.bell-tel.com (H), as well as a permanent registration at
brevity, the examples omit the session description. watson@acm.org (A). For brevity, the examples omit the session
description and Via header fields.
Watson's user agent sends the invitation to the SIP server for the Bell'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:t.watson@ieee.org 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>
Call-ID: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE CSeq: 1 INVITE
The SIP server at ieee.org tries the four addresses in parallel. It The SIP server at ieee.org tries the four addresses in parallel. It
sends the 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 sip.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: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 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 sip.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>;tag=87454273 To: T. Watson <sip:t.watson@ieee.org>;tag=87454273
Call-ID: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 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 sip.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>;tag=37462311 To: T. Watson <sip:t.watson@ieee.org>;tag=87454273
Call-ID: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 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 sip.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: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 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:t.watson@x.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.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: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 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 sip.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: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 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. via the proxy to Bell.
X->P: SIP/2.0 200 OK X->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.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> ;tag=192137601 To: T. Watson <sip:t.watson@ieee.org> ;tag=192137601
Call-ID: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: sip:t.watson@x.bell-tel.com Contact: 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 sip.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
Contact: sip:t.watson@y.bell-tel.com Contact: 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> ;tag=35253448 To: T. Watson <sip:t.watson@ieee.org> ;tag=35253448
Call-ID: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 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 sip.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: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 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 sip.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: 31415@kton.bell-tel.com Call-ID: 31415@c.bell-tel.com
CSeq: 1 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: