draft-ietf-mmusic-sip-04.txt   draft-ietf-mmusic-sip-05.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft Handley/Schulzrinne/Schooler Internet Draft Handley/Schulzrinne/Schooler
draft-ietf-mmusic-sip-04.txt ISI/Columbia U./Caltech draft-ietf-mmusic-sip-05.txt ISI/Columbia U./Caltech
November 11, 1997 May 14, 1998
Expires: April 1, 1998 Expires: November 1998
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 2, line 10 skipping to change at page 2, line 10
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
should be addressed to the working group's mailing list should be addressed to the working group's mailing list
at confctrl@isi.edu and/or the authors. at confctrl@isi.edu and/or the authors.
1 Introduction 1 Introduction
1.1 Overview of SIP Functionality 1.1 Overview of SIP Functionality
The Session Initiation Protocol (SIP) is an application-layer The Session Initiation Protocol (SIP) is an application-layer
protocol that can establish and control multimedia sessions or calls. protocol that can establish, modify and terminate multimedia sessions
These multimedia sessions include multimedia conferences, distance or calls. These multimedia sessions include multimedia conferences,
learning, Internet telephony and similar applications. SIP can invite distance learning, Internet telephony and similar applications. SIP
a person to both unicast and multicast sessions; the initiator does can invite a person to both unicast and multicast sessions; the
not necessarily have to be a member of the session it is inviting to. initiator does not necessarily have to be a member of the session to
Media and participants can be added to an existing session. SIP can which it is inviting users. Media and participants can be added to an
be used to "call" both persons and "robots", for example, to invite a existing session. SIP can be used to "call" both persons and
media storage device to record an ongoing conference or to invite a "robots", for example, to invite a media storage device to record an
video-on-demand server to play a video into a conference. (SIP does ongoing conference or to invite a video-on-demand server to play a
not directly control these services, however; see RTSP [1].) video into a conference. (SIP does not directly control these
services, however; see RTSP [1].)
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 may be advertised using multicast protocols such as SAP (Sessions may be advertised using multicast protocols such as SAP
[2], electronic mail, news groups, web pages or directories (LDAP), [2], electronic mail, news groups, web pages or directories (LDAP),
among others.) among 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. Section 14 discusses these services in detail. subscriber services. These facilities also enable personal mobility
SIP supports personal mobility telecommunications intelligent network
services, this is defined as: "Personal mobility is the ability of services, this is defined as: "Personal mobility is the ability of
end users to originate and receive calls and access subscribed end users to originate and receive calls and access subscribed
telecommunication services on any terminal in any location, and the telecommunication services on any terminal in any location, and the
ability of the network to identify end users as they move. Personal ability of the network to identify end users as they move. Personal
mobility is based on the use of a unique personal identity (i.e., mobility is based on the use of a unique personal identity (i.e.,
'personal number')." [3]. Personal mobility complements terminal mobility complements terminal mobility, i.e., the ability to maintain
mobility, i.e., the ability to maintain communications when moving a communications when moving a single end system from one network to
single end system from one network to another. another.
SIP supports some or all of five facets of establishing and SIP supports some or all of five facets of establishing and
terminating multimedia communications: terminating multimedia 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;
skipping to change at page 3, line 4 skipping to change at page 2, line 51
terminating multimedia communications: terminating multimedia 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.
SIP can also initiate multi-party calls using a multipoint control
unit (MCU) or fully-meshed interconnection instead of multicast.
Internet telephony gateways that connect PSTN parties may also use
SIP to set up calls between them.
SIP is designed as part of the overall IETF multimedia data and
control architecture [4] currently incorporating protocols such as
RSVP (RFC 2205 [5]) for reserving network resources, the real-time
transport protocol (RTP) (RFC 1889 [6]) for transporting real-time
data and providing QOS feedback, the real-time streaming protocol
(RTSP) [1] for controlling delivery of streaming media, the session
announcement protocol (SAP) [2] for advertising multimedia sessions
via multicast and the session description protocol (SDP) (RFC 2327
[7]) for describing multimedia sessions, but the functionality and
operation of SIP does not depend on any of these protocols.
SIP may also be used in conjunction with other call setup and SIP may also be used in conjunction with other call setup and
signaling protocols. In that mode, an end system uses SIP protocol signaling protocols. In that mode, an end system uses SIP protocol
exchanges to determine the appropriate end system address and exchanges to determine the appropriate end system address and
protocol from a given address that is protocol-independent. For protocol from a given address that is protocol-independent. For
example, SIP may be used to determine that the party may be reached example, SIP may be used to determine that the party may be reached
via H.323, obtain the H.245 gateway and user address and then use via H.323, obtain the H.245 gateway and user address and then use
H.225.0 to establish the call [4]. In another example, it may be used H.225.0 to establish the call [8]. In another example, it may be used
to determine that the callee is reachable via the public switched to determine that the callee is reachable via the public switched
telephone network (PSTN) and indicate the phone number to be called, telephone network (PSTN) and indicate the phone number to be called,
possibly suggesting an Internet-to-PSTN gateway to be used. possibly suggesting an Internet-to-PSTN gateway to be used.
SIP can also initiate multi-party calls using a multipoint control
unit (MCU) or fully-meshed interconnection instead of multicast.
Internet telephony gateways that connect PSTN parties may also use
SIP to set up calls between them.
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. but SIP can be used to introduce conference control protocols. SIP
does not allocate multicast addresses.
SIP does not allocate multicast addresses, leaving this functionality
to protocols such as SAP [2].
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 may convey to the reservation. SIP does not reserve resources, but may convey to the
invited system the information necessary to do this. Quality-of- invited system the information necessary to do this. Quality-of-
service guarantees, if required, may depend on knowing the full service guarantees, if required, may depend on knowing the full
membership of the session; this information may or may not be known membership of the session; this information may or may not be known
to the agent performing session invitation. to the agent performing session invitation.
SIP is designed as part of the overall IETF multimedia data and
control architecture [5] currently incorporating protocols such as
RSVP [6] for reserving network resources, the real-time transport
protocol (RTP) [7] for transporting real-time data and providing QOS
feedback, the real-time streaming protocol (RTSP) [8] for controlling
delivery of streaming media, the session announcement protocol (SAP)
[2] for advertising multimedia sessions via multicast and the session
description protocol (SDP) [9] for describing multimedia sessions,
but the functionality and operation of SIP does not depend on any of
these protocols.
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 [10] and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and
and indicate requirement levels for compliant SIP implementations. 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) [11]. The following terms have special Transport Protocol (HTTP) (RFC 2068 [10]). The following terms have
significance for SIP. special significance for SIP.
Call: A call consists of a single invitation attempt from a single Call: A call consists of all participants in a conference invited by
user. A SIP call is identified by a globally unique call-id a common source. A SIP call is identified by a globally unique
(Section 6.12. Thus, if a user is, for example, invited to the call-id (Section 6.12). Thus, if a user is, for example, invited
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 MCU-
based conference, each participant uses a separate call to based call-in conference, each participant uses a separate call
invite himself to the MCU. to invite himself to the MCU.
Client: An application program that establishes connections for the Client: An application program that establishes connections for the
purpose of sending requests. Clients may or may not interact purpose of sending requests. Clients may or may not interact
directly with a human user. directly with a human user.
Conference: A multimedia session (see below), identified by a common
session description. A conference may have zero or more members
and includes the cases of a multicast conference, a full-mesh
conference and a two-party "telephone call", as well as
combinations of these.
Downstream: Requests sent in the direction from the caller to the
callee.
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 responses are final. opposed to a provisional response that does not. All 2xx, 3xx,
4xx, 5xx and 6xx responses are final.
Initiator, calling party: 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 a 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
participation in a session. A successful SIP invitation consists participation in a session. A successful SIP invitation consists
of two transactions: an INVITE request followed by a ACK of two transactions: an INVITE request followed by an ACK
request. request.
Invitee, invited user, called party: The person or service that the Invitee, invited user, called party, callee: The person or service
calling party is trying to invite to a conference. that the calling party is trying to invite to a conference.
Isomorphic request or response: Two requests or responses are defined
to be isomorphic for the purposes of this document if they have
the same values for the Call-ID, To, From and CSeq header
fields. In addition, requests have to have the same Request-
URI.
Location server: See location service Location server: See location service
Location service: A service used by a SIP redirect or proxy server to Location service: A location service is used by a SIP redirect or
obtain information about a callee's possible location(s). proxy server to obtain information about a callee's possible
Location services are offered by location servers. Location location(s). Location services are offered by location servers.
servers may be co-located with a SIP server, but the manner in Location servers may be co-located with a SIP server, but the
which a SIP server requests location services is beyond the manner in which a SIP server requests location services is
scope of the document. beyond the scope of this document.
Parallel search: In a parallel search, a proxy issues several
requests to possible user locations upon receiving an incoming
request. Rather than issuing one request and then waiting for
the final response before issuing the next request as in a
sequential search , a parallel search issues requests without
waiting for the result of previous requests.
Provisional response: A response used by the server to indicate Provisional response: A response used by the server to indicate
progress, but that does not terminate a SIP transaction. All 1xx progress, but that does not terminate a SIP transaction. 1xx
and 6xx responses are provisional. Other responses are responses are provisional, other responses are considered final
considered final.
Proxy, proxy server: An intermediary program that acts as both a Proxy, proxy server: An intermediary program that acts as both a
server and a client for the purpose of making requests on behalf server and a client for the purpose of making requests on behalf
of other clients. Requests are serviced internally or by passing of other clients. Requests are serviced internally or by passing
them on, possibly after translation, to other servers. A proxy them on, possibly after translation, to other servers. A proxy
must interpret, and, if necessary, rewrite a request message must interpret, and, if necessary, rewrite a request message
before forwarding it. before forwarding it.
Redirect server: A server that accepts a SIP request, maps the Redirect server: A redirect server is a server that accepts a SIP
address into zero or more new addresses and returns these request, maps the address into zero or more new addresses and
addresses to the client. Unlike a proxy server, it does not returns these addresses to the client. Unlike a proxy server ,
initiate its own SIP request. Unlike a user agent server, it it does not initiate its own SIP request. Unlike a user agent
does not accept calls. server , it does not accept calls.
Server: An application program that accepts requests in order to Registrar: A registrar is server that accepts REGISTER requests. A
service requests and sends back responses to those requests. registrar is typically co-located with a proxy or redirect
Servers are either proxy, redirect or user agent servers. An server.
application program may act as both server and client.
Ringback: Ringback is the signaling tone produced by the calling
client's application indicating that a called party is being
alerted (ringing).
Server: A server is an application program that accepts requests in
order to service requests and sends back responses to those
requests. Servers are either proxy, redirect or user agent
servers.
Session: "A multimedia session is a set of multimedia senders and Session: "A multimedia session is a set of multimedia senders and
receivers and the data streams flowing from senders to receivers and the data streams flowing from senders to
receivers. A multimedia conference is an example of a multimedia receivers. A multimedia conference is an example of a multimedia
session." [9] (Note: a session as defined here may comprise one session." (RFC 2327, [7]) (A session as defined for SDP may
or more RTP sessions.) Since the word session is used comprise one or more RTP sessions.) As defined, a callee may be
differently by protocols relevant to SIP, this document avoids invited several times, by different calls, to the same session.
the term altogether. If SDP is used, a session is defined by the concatenation of the
user name , session id , network type , 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 for a sent from the server to the client. A transaction is for a
single call (identified by a Call-ID, Section 6.12). There can single call (identified by a Call-ID, Section 6.12) and may be
only be one pending transaction between a server and client for identified by a CSeq sequence number (Section 6.16). If there
each call id. is no CSeq, there can only be one pending transaction between a
server and client for each call id.
User agent server, called user agent: The server application that Upstream: Responses sent in the direction from the called client to
contacts the user when a SIP request is received and that the caller.
returns a reply on behalf of the user. The reply may accept,
reject or redirect the call. (Note: in SIP, user agents can be URL-encoded: A character string encoded according to RFC 1738,
both clients and servers.) Section 2.2 [11].
User agent client (UAC), calling user agent: A user agent client is a
client application that initiates the SIP request.
User agent server (UAS), called user agent: A user agent server is a
server application that contacts the user when a SIP request is
received and that returns a response on behalf of the user. The
response may accept, reject or redirect the call.
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
a server. For example, a typical multimedia conference control a server. For example, a typical multimedia conference control
application would act as a client to initiate calls or to invite application would act as a client to initiate calls or to invite
others to conferences and as a user agent server to accept others to conferences and as a user agent server to accept
invitations. The properties of the different SIP server types are invitations. The properties of the different SIP server types are
summarized in Table 1. summarized in Table 1.
1.4 Summary of SIP Operation
This section explains the basic protocol functionality and operation.
property redirect proxy user agent property redirect proxy user agent
server server server server server server
_______________________________________________________ _______________________________________________________
also acts as client no yes no also acts as client no yes no
return 1xx status yes yes yes return 1xx status yes yes yes
return 2xx status no yes yes return 2xx status no yes yes
return 3xx status yes yes yes return 3xx status yes yes yes
return 4xx status yes yes yes return 4xx status yes yes yes
return 5xx status yes yes yes return 5xx status yes yes yes
return 6xx status no yes yes return 6xx status no yes yes
insert Via header no yes no insert Via header no yes no
accept ACK no yes yes accept ACK no yes yes
Table 1: Properties of the different SIP server types Table 1: Properties of the different SIP server types
1.4 Summary of SIP 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 trigger a chain of new SIP requests SIP request may be redirected or may trigger a chain of new SIP
by proxies (Section 1.4.5). Users can register with SIP servers requests by proxies (Section 1.4.5). Users can register their
(Section 4.2.5). location(s) with SIP servers (Section 4.2.6).
1.4.1 SIP Addressing 1.4.1 SIP Addressing
SIP addresses contain a user and host part. The user part is an SIP addresses contain a user and host part. The user part is a user
operating-system user name. The host part is either a domain name name, a civil name or a telephone number. The host part is either a
having a DNS A (address) record, or a numeric network address. domain name having a DNS SRV (RFC 2052 [12]), MX (RFC 974 [13], CNAME
Examples include: or A record (RFC 1035 [14]), or a numeric network address.
mjh@metro.isi.edu A user's SIP address can be obtained out-of-band, can be learned via
hgs@erlang.cs.columbia.edu
root@[193.175.132.42]
root@193.175.132.42
A user's 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, the SIP address can be the same as a user's electronic
mail address, but this is not required. SIP can thus leverage off the
domain name system (DNS) to provide a first-stage location
mechanisms.
SIP addresses may contain a moniker (such as a civil name) or user Examples include:
name and domain name that may not map into a single host. [1]
SIP addresses may use any unambiguous user name, including aliases,
identifying the called party as the user part of the address. They
may use a domain name having an MX [12], SRV [13] or A [14] record
for the host part. These addresses may have different degrees of
location- and provider-independence and are often chosen to be
mnemonic. In many cases, the SIP address can be the same as a user's
electronic mail address, but this is not required. SIP can thus
leverage off the domain name system (DNS) to provide a first-stage
location mechanisms. Examples of SIP names include
M.Handley@cs.ucl.ac.uk
H.G.Schulzrinne@ieee.org
info@ietf.org
mjh@metro.isi.edu
watson@bell-telephone.com
root@[193.175.132.42]
root@193.175.132.42
An address can designate an individual (possibly located at one of An address can designate an individual (possibly located at one of
several end systems), the first available person from a group of several end systems), the first available person from a group of
individuals or a whole group. The form of the address, e.g., individuals or a whole group. The form of the address, e.g.,
sales@example.com , is not sufficient, in general, to determine the sales@example.com , is not sufficient, in general, to determine the
intent of the caller. 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.
When used within SIP, SIP addresses are written as SIP URLs (Section Since SIP requests and responses may also contain non-SIP addresses,
sec:url), e.g., sip://info@ietf.org as SIP requests and responses may e.g., telephone numbers, SIP addresses are written as SIP URLs
also contain non-SIP addresses, e.g., telephone numbers. (Section 2) when used within SIP headers. For example,
1.4.2 Locating a SIP Server sip:info@ietf.org
_________________________
[1] We avoid the term location-independent , since 1.4.2 Locating a SIP Server
the address may indeed refer to a specific location,
e.g., a company department.
A SIP client MUST follow the following steps to resolve the host part A SIP client MUST follow the following steps to resolve the host part
of a callee address. If a client only supports TCP or UDP, but not of a callee address. If a client supports only TCP or UDP, but not
both, the respective address type is omitted. If the SIP address both, the client omits the respective address type. If the SIP
contains a port number, that number is to be used, otherwise, the the address contains a port number, that number is to be used, otherwise,
default port number. The default port number for UDP and TCP is the the default port number 5060 is to be used. The default port number
same. is the same for UDP and TCP. In all cases, the client first attempts
to contact the server using UDP, then TCP.
1. If the SIP address is a numeric IP address, contact a SIP A client SHOULD rely on ICMP "Port Unreachable" messages rather than
server at that address. time-outs to determine that a server is not reachable at a particular
address. (For socket-based programs: For TCP, connect() returns
ECONNREFUSED if there is no server at the designated address; for
UDP, the socket should be bound to the destination address using
connect() rather than sendto() or similar so that a second write()
fails with ECONNREFUSED
2. If the SIP address does not contain a port number and if If the SIP address contains a numeric IP address, the client contacts
there is a SRV DNS resource record [13] of type sip.udp, the SIP server at that address. Otherwise, the client follows the
contact the listed SIP servers in the order of the steps below.
preference values contained in those resource records,
using UDP as a transport protocol at the port number listed
in the DNS resource record. [TBD: What if the SIP URL
contains a port number?]
3. If the SIP address does not contain a port number and if 1. If there is a SRV DNS resource record (RFC 2052 [12]) of
there is a SRV DNS resource record [13] of type sip.tcp, type sip.udp, contact the listed SIP servers in the order
contact the listed SIP servers in the order of the of the preference values contained in those resource
preference value contained in those resource records, using records, using UDP as a transport protocol at the port
TCP as a transport protocol at the port number listed in number given in the URL or, if none provided, the one
the DNS resource record. listed in the DNS resource record.
4. If there is a DNS MX record [12], contact the hosts listed 2. If there is a SRV DNS resource record (RFC 2052 [12]) of
in their order of preference at the default port number type sip.tcp, contact the listed SIP servers in the order
(TBD). For each host listed, first try to contact the SIP of the preference value contained in those resource
records, using TCP as a transport protocol at the port
number given in the URL or, if none provided, the one
listed in the DNS resource record.
3. If there is a DNS MX record (RFC 974 [13]), contact the
hosts listed in their order of preference at the port
number listed in the URL or the default SIP port number if
none. For each host listed, first try to contact the SIP
server using UDP, then TCP. server using UDP, then TCP.
5. Finally, check if there is a DNS CNAME or A record for the 4. 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 given host and try to contact a SIP server at the one or
more addresses listed, again trying first UDP, then TCP. more addresses listed, again trying first UDP, then TCP.
6. If all of the above methods fail, the caller MAY contact an If all of the above methods fail to locate a server, the caller MAY
SMTP server at the user's host and use the SMTP EXPN contact an SMTP server at the user's host and use the SMTP EXPN
command to obtain an alternate address and repeat the steps command to obtain an alternate address and repeat the steps above. As
above. As a last resort, a client MAY choose to deliver the a last resort, a client MAY choose to deliver the session description
session description to the callee using electronic mail. to the callee using electronic mail.
If a server is found using one of the methods below, the other
methods are not tried. A client SHOULD rely on ICMP "Port
Unreachable" messages rather than time-outs to determine that a
server is not reachable at a particular address.
A client MAY cache the result of the reachability steps for a A client MAY cache the result of the reachability steps for a
particular address and retry that host address for the next call. If particular address and retry that host address for the next call. If
the client does not find a SIP server at the cached address, it MUST the client does not find a SIP server at the cached address, it MUST
start the search at the beginning of the sequence. start the search at the beginning of the sequence.
Implementation note for socket-based programs: For TCP, connect()
returns ECONNREFUSED if there is no server at the designated address;
for UDP, the socket should be bound to the destination address using
connect() rather than sendto() or similar.
This sequence is modeled after that described for SMTP, This sequence is modeled after that described for SMTP,
where MX records are to be checked before A records [15]. where MX records are to be checked before A records (RFC
1123 [15]).
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. transaction. The ACK request following an INVITE is not part of
the 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. Thus, the client SHOULD are carried over the same TCP connection (see Section 10). Several
maintain the connection until a final response has been received. SIP requests from the same client to the same server may use the same
Several SIP requests from the same client to the same server may use TCP connection or may open a new connection for each request.
the same TCP connection or may open a new connection for each
request. If the client sent the request sends via unicast UDP, the If the client sent the request via unicast UDP, the response is sent
response is sent to the source address of the UDP request. to the address contained in the next Via header field (Section 6.43)
(Implementation note: use recvfrom() to obtain the source address and of the response. If the request is sent via multicast UDP, the
port of the request.) If the request is sent via multicast UDP, the
response is directed to the same multicast address and destination response is directed to the same multicast address and destination
port. For UDP, reliability is achieved using retransmission (Section port. For UDP, reliability is achieved using retransmission (Section
11). 10).
Need motivation why we ALWAYS want to have a multicast
return.
The SIP message format and operation is independent of the transport The SIP message format and operation is independent of the transport
protocol. protocol.
1.4.4 SIP Invitation 1.4.4 SIP Invitation
A successful SIP invitation consists of two requests, INVITE A successful SIP invitation consists of two requests, INVITE
followed by ACK. The INVITE (Section 4.2.1) request asks the callee followed by ACK. The INVITE (Section 4.2.1) request asks the callee
to join a particular conference or establish a two-party to join a particular conference or establish a two-party
conversation. After the callee has agreed to participate in the call, conversation. After the callee has agreed to participate in the call,
the caller confirms that it has received that response by sending an the caller confirms that it has received that response by sending an
ACK (Section 4.2.2) request. If the call is rejected or otherwise ACK (Section 4.2.2) request. If the caller no longer wants to
unsuccessful, the caller sends a BYE request instead of an ACK. participate in the call, it 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 format, that provides the called party with example written in SDP (RFC 2327, [7]) format, that provides the
enough information to join the session. For multicast sessions, the called party with enough information to join the session. For
session description enumerates the media types and formats that may multicast sessions, the session description enumerates the media
be distributed to that session. For unicast session, the session types and formats that may be distributed to that session. For
description enumerates the media types and formats that the caller is unicast session, the session description enumerates the media types
willing to receive and where it wishes the media data to be sent. In and formats that the caller is willing to receive and where it wishes
either case, if the callee wishes to accept the call, it responds to the media data to be sent. In either case, if the callee wishes to
the invitation by returning a similar description listing the media accept the call, it responds to the invitation by returning a similar
it wishes to receive. For a multicast session, the callee should only description listing the media it wishes to receive. For a multicast
return a session description if it is unable to receive the media session, the callee should only return a session description if it is
indicated in the caller's description. The caller may ignore the unable to receive the media indicated in the caller's description.
session description returned or use it to change the global session The caller may ignore the session description returned or use it to
description. change the global session description.
The session description may refer to a session start time in the
future. Actual transmission of data SHOULD not start until the time
indicated in the session description.
The protocol exchanges for the INVITE method are shown in Fig. 1 for The protocol exchanges for the INVITE method are shown in Fig. 1 for
a proxy server and in Fig. 2 for a redirect server. The proxy server a proxy server and in Fig. 2 for a redirect server. In Fig. 1, the
accepts the INVITE request (step 1), contacts the location service proxy server accepts the INVITE request (step 1), contacts the
with all or parts of the address (step 2) and obtains a more precise location service with all or parts of the address (step 2) and
location (step 3). The proxy server then issues a SIP INVITE request obtains a more precise location (step 3). The proxy server then
to the address(es) returned by the location service (step 4). The issues a SIP INVITE request to the address(es) returned by the
user agent server alerts the user (step 5) and returns a success location service (step 4). The user agent server alerts the user
indication to the proxy server (step 6). The proxy server then (step 5) and returns a success indication to the proxy server (step
returns the success result to the original caller (step 7). The 6). The proxy server then returns the success result to the original
receipt of this message is confirmed by the caller using an ACK caller (step 7). The receipt of this message is confirmed by the
message, which is forwarded to the callee (steps 8 and 9), with a caller using an ACK request, which is forwarded to the callee (steps
response returned (steps 10 and 11). All requests have the same 8 and 9). All requests and responses have the same Call-ID.
Call-ID.
The redirect server accepts the INVITE request (step 1), contacts
the location service as before (steps 2 and 3) and, instead of
contacting the newly found address itself, returns the address to the
caller (step 4). The caller issues a new request, with a new call-ID,
to the address returned by the first server (step 6). In the example,
the call succeeds (step 7). The caller and callee complete the
handshanke with an ACK (steps 8 and 9).
The next section discusses what happens if the location service
returns more than one possible alternative.
1.4.5 Locating a User
+....... cs.columbia.edu .......+ +....... cs.columbia.edu .......+
: : : :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ( location ) : : ( location ) :
: ( service ) : : ( service ) :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ^ | : : ^ | :
: | hgs@play : : | hgs@play :
: 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 ========================> tune =========> play : : cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) :
: <........................ <......... : : <........................( )<.........( ) :
: : 7: 200 OK : 6: 200 OK : : : 7: 200 OK : ( )6: 200 OK ( ) :
: : : ( tune ) ( play ) :
: : 8: ACK : ( )9: ACK ( ) :
: ========================>(~~~~~~)=========>(~~~~~~) :
+.....................+ +...............................+ +.....................+ +...............................+
====> SIP request ====> SIP request
....> SIP response
----> non-SIP protocols ----> non-SIP protocols
Figure 1: Example of SIP proxy server Figure 1: Example of SIP proxy server
A callee may move between a number of different end systems over The redirect server shown in Fig. 2 accepts the INVITE request (step
time. These locations can be dynamically registered with the SIP 1), contacts the location service as before (steps 2 and 3) and,
server (Section 4.2.5) or a location server, typically for a single instead of contacting the newly found address itself, returns the
administrative domain, or a location server may use other protocols, address to the caller (step 4), which is then acknowledged via an
such as finger [16], rwho, multicast-based protocols or operating- ACK request (step 5). The caller issues a new request, with the same
system dependent mechanism to actively determine the end system where call-ID but a higher CSeq, to the address returned by the first
a user might be reachable. The location services yield a list of a server (step 6). In the example, the call succeeds (step 7). The
zero or more possible locations, possibly even sorted in order of caller and callee complete the handshake with an ACK (step 8).
likelihood of success.
The location server can be part of the SIP server or the SIP server The next section discusses what happens if the location service
may use a different protocol (e.g., finger [16] or LDAP [17]) to map returns more than one possible alternative.
addresses. A single user may be registered at different locations,
either because she is logged in at several hosts simultaneously or
because the location server has (temporarily) inaccurate information.
The action taken on receiving a list of locations varies with the
type of SIP server. A SIP redirect server simply returns the list to
the client sending the request as Location headers (Section 6.18). A
SIP proxy server can sequentially or in parallel try the addresses
+....... cs.columbia.edu .......+ +....... cs.columbia.edu .......+
: : : :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ( location ) : : ( location ) :
: ( service ) : : ( service ) :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ^ | : : ^ | :
: | hgs@play : : | hgs@play :
: 2| 3| : : 2| 3| :
: | | : : | | :
: henning | : : henning | :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | : +.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | | : : : henning@cs.col: | | :
: cz@cs.tu-berlin.de =======================> tune : : cz@cs.tu-berlin.de =======================>(~~~~~~) :
: ^ | <....................... : : | ^ | <.......................( ) :
: . | : 4: 302 Moved : : : | . | : 4: 302 Moved : ( ) :
+...........|.........+ hgs@play : : : | . | : hgs@play : ( tune ) :
. | : : : | . | : : ( ) :
. | 5: INVITE hgs@play.cs.columbia.edu 6: ring : : | . | : 5: ACK : ( ) :
. ==================================================> play : : | . | =======================>(~~~~~~) :
..................................................... : : | . | : : :
7: 200 OK : : +.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@play.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( play ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+ +...............................+
====> SIP request ====> SIP request
....> SIP response
----> non-SIP protocols ----> non-SIP protocols
Figure 2: Example of SIP redirect server Figure 2: Example of SIP redirect server
until the call is successful (2xx response) or the callee has 1.4.5 Locating a User
declined the call (60x response). With sequential attempts, a proxy
server can implement an "anycast" service. A callee may move between a number of different end systems over
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
more other protocols, such as finger (RFC 1288 [16]), rwhois (RFC
2167 [17]), LDAP (RFC 1777 [18]), multicast-based protocols or
operating-system dependent mechanism to actively determine the end
system where a user might be reachable. A location server may return
several locations because the user is logged in at several hosts
simultaneously or because the location server has (temporarily)
inaccurate information. The SIP server combines the results to yield
a list of a zero or more locations. It is recommended that each
location server sorts results according to the likelihood of success.
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
client sending the request as Location headers (Section 6.25). A SIP
proxy server can sequentially or in parallel try the addresses until
the call is successful (2xx response) or the callee has declined the
call (6xx response). With sequential attempts, a proxy server can
implement an "anycast" service.
If a proxy server forwards a SIP request, it MUST add itself to the If a proxy server forwards a SIP request, it MUST add itself to the
end of the list of forwarders noted in the Via (Section 6.33) end of the list of forwarders noted in the Via (Section 6.43)
headers. The Via trace ensures that replies can take the same path headers. The Via trace ensures that replies can take the same path
back, thus ensuring correct operation through compliant firewalls and back, ensuring correct operation through compliant firewalls and
loop-free requests. On the reply path, each host most remove its Via, avoiding request loops. On the response path, each host MUST remove
so that routing internal information is hidden from the callee and its Via, so that routing internal information is hidden from the
outside networks. When a multicast request is made, first the host callee and outside networks. When a multicast request is made, first
making the request, then the multicast address itself are added to the host making the request, then the multicast address itself are
the path. A proxy server MUST check that it does not generate a added to the path. A proxy server MUST check that it does not
request to a host listed in the Via list. (Note: If a host has generate a request to a host listed in the Via list. (Note: If a
several names or network addresses, this may not always work. Thus, host has several names or network addresses, this may not always
each host also checks if it is part of the Via list.) work. Thus, each host also checks if it is part of the Via list.)
A SIP invitation may traverse more than one SIP proxy server. If one 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. invitation request. Each of these copies bears the same Call-ID. The
The user agent MUST return the appropriate status response, but user agent MUST return the appropriate status response. Duplicate
SHOULD NOT alert the user. requests are not an error, so there is no need to alert the user.
As discussed in Section 1.4.1, a SIP address may designate a group
rather than an individual. A client indicates using the Reach
request header whether it wants to reach the first available
individual or treat the address as a group, to be invited as a whole.
The default is to attempt to reach the first available callee. If
the address is designated as a group address, a proxy server MUST
return the list of individuals instead of attempting to connect to
these. (Otherwise, the proxy cannot report errors, redirections and
call status individually. For example, some may be contacted
successfully, while one of the group may be reachable under a
different address.)
1.4.6 Changing an Existing Session 1.4.6 Changing an Existing Session
In some circumstances, it may be necessary to change the parameters In some circumstances, it may be necessary to change the parameters
of an existing session. For example, two parties may have been of an existing session. For example, two parties may have been
conversing and then want to add a third party, switching to multicast conversing and then want to add a third party, switching to multicast
for efficiency. One of the participants invites the third party with for efficiency. One of the participants invites the third party with
the new multicast address and simultaneously sends an INVITE to the the new multicast address and simultaneously sends an INVITE to the
second party, with the new multicast session description, but the old second party, with the new multicast session description, but with
call identifier. the old call identifier.
1.4.7 Registration Services 1.4.7 Registration Services
The REGISTER and UNREGISTER requests allow a client to let a proxy The REGISTER request allows a client to let a proxy or redirect
or redirect server know which address it may be reached under. A server know which address(es) it may be reached under. A client may
client may also use it to install call handling features at the also use it to install call handling features at the server.
server.
1.5 Protocol Properties 1.5 Protocol Properties
1.5.1 Minimal State 1.5.1 Minimal State
A single conference session or call may involve one or more SIP A single conference session or call may involve one or more SIP
request-response transactions. Proxy server do not have to keep state request-response transactions. Proxy servers do not have to keep
for a particular call, however, they maintain state for a single SIP state for a particular call, however, they maintain state for a
transaction, as discussed in Section 12. single SIP transaction, as discussed in Section 11.
For efficiency, a server may cache the results of location service For efficiency, a server may cache the results of location service
requests. requests.
1.5.2 Transport-Protocol Neutral 1.5.2 Lower-Layer-Protocol Neutral
SIP is able to utilize both UDP and TCP as transport protocols. UDP SIP makes minimal assumptions about the underlying transport and
allows the application to more carefully control the timing of network-layer protocols. The lower-layer may provide either a packet
messages and their retransmission, to perform parallel searches or a byte stream service, with reliable or unreliable service.
without requiring TCP connection state for each outstanding request,
and to use multicast. Routers can more readily snoop SIP UDP In an Internet context, SIP is able to utilize both UDP and TCP as
packets. TCP allows easier passage through existing firewalls, and transport protocols, among others. UDP allows the application to more
given the similar protocol design, allows common servers for SIP, carefully control the timing of messages and their retransmission, to
HTTP and the Real Time Streaming Protocol (RTSP) [1]. perform parallel searches without requiring TCP connection state for
each outstanding request, and to use multicast. Routers can more
readily snoop SIP UDP packets. TCP allows easier passage through
existing firewalls, and given the similar protocol design, allows
common servers for SIP, HTTP and the Real Time Streaming Protocol
(RTSP) [1].
When TCP is used, SIP can use one or more connections to attempt to When TCP is used, SIP can use one or more connections to attempt to
contact a user or to modify parameters of an existing conference. contact a user or to modify parameters of an existing conference.
Different SIP requests for the same SIP call may use different TCP Different SIP requests for the same SIP call may use different TCP
connections or a single persistent connection, as appropriate. connections or a single persistent connection, as appropriate.
Clients SHOULD implement both UDP and TCP transport, servers MUST. User agents SHOULD implement both UDP and TCP transport, proxy and
redirect servers MUST.
For concreteness, this document will only refer to Internet
protocols. However, SIP may also be used directly with protocols
such as ATM AAL5, IPX, frame relay or X.25. The necessary naming
conventions are beyond the scope of this document.
1.5.3 Text-Based 1.5.3 Text-Based
SIP is text based. This allows easy implementation in languages such SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This
as Tcl and Perl, allows easy debugging, and most importantly, makes allows easy implementation in languages such as Java, Tcl and Perl,
SIP flexible and extensible. As SIP is used for initiating multimedia allows easy debugging, and most importantly, makes SIP flexible and
conferences rather than delivering media data, it is believed that extensible. As SIP is used for initiating multimedia conferences
the additional overhead of using a text-based protocol is not rather than delivering media data, it is believed that the additional
significant. overhead of using a text-based protocol is not significant.
2 SIP Uniform Resource Locators 2 SIP Uniform Resource Locators
SIP URLs are used within SIP messages to indicate the originator and SIP URLs are used within SIP messages to indicate the originator,
recipient of a SIP request, and to specify redirection addresses. A current destination and final recipient of a SIP request, and to
SIP URL may also be embedded in web pages or other hyperlinks to specify redirection addresses. A SIP URL can also be embedded in web
indicate that a user or service may be called. pages or other hyperlinks to indicate that a user or service may be
called.
Because interaction with some resources may require message headers Because interaction with some resources may require message headers
or message bodies to be specified as well as the SIP address, the sip or message bodies to be specified as well as the SIP address, the SIP
URL scheme is defined to allow setting SIP request-header fields and URL scheme is defined to allow setting SIP request-header fields and
the SIP message-body. (This is similar to the mailto: URL.) the SIP message-body. (This is similar to the mailto: URL [19].)
A SIP URL follows the guidelines of RFC 1630 [18,19] and takes the A SIP URL follows the guidelines of RFC 1630, as revised, [20,21] and
following form: takes the following form:
SIP-URL = short-sip-url | full-sip-url SIP-URL = full-sip-url
full-sip-url = "sip://" ( user | phone ) [ ":" password ] full-sip-url = "sip:" ( user | phone ) [ ":" password ]
"@" [ host | nhost ]
url-parameters [ headers ]
short-sip-url = ( user | phone) [ ":" password ]
"@" [ host | nhost ] : port "@" [ host | nhost ] : port
user = ; defined in RFC 1738 [20] url-parameters [ headers ]
phone = "+" DIGIT *( DIGIT | "-" | "." ) user = ; defined in RFC 1738 [11]
phone = telephone-subscriber
telephone-subscriber = ;
defined in [22]
password = *( unreserved | escaped |
";" | " " | "=" | "+" | "$" | "," )
host = ; defined in RFC 1738 host = ; defined in RFC 1738
nhost = "[" hostnumber "]" | hostnumber nhost = hostnumber
hostnumber = digits "." digits "." digits "." digits hostnumber = digits "." digits "." digits "." digits
port = *digit port = digits
url-parameters = *( ";" url-parameter) url-parameters = *( ";" url-parameter)
url-parameter = transport-param | url-parameter = transport-param |
ttl-param | maddr-param ttl-param | maddr-param | other-param
transport-param = "transport=" ( "udp" | "tcp" ) transport-param = "transport=" ( "udp" | "tcp" )
ttl-param = "ttl=" ttl ttl-param = "ttl=" ttl
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
maddr-param = "maddr=" maddr maddr-param = "maddr=" maddr
maddr = ; dotted decimal multicast address maddr = ; dotted decimal multicast address
other-param = *uric
headers = "?" header *( " " header ) headers = "?" header *( " " header )
header = hname "=" hvalue header = hname "=" hvalue
hname = *urlc hname = *uric
hvalue = *urlc hvalue = *uric
urlc = ; defined in [19] uric = ; defined in [21]
digits = 1*digit digits = 1*DIGIT
Thus, a SIP URL can take either a short form or a full form. The Thus, a SIP URL can take either a short form or a full form. The
short form MAY only be used within SIP messages where the scheme short form MAY only be used within SIP messages where the scheme
(SIP) can be assumed. In all other cases, and when parameters are (SIP) can be assumed. In all other cases, and when parameters are
required to be specified, the full form MUST be used. required to be specified, the full form MUST be used.
Note that all URL reserved characters must be encoded. The special Note that all URL reserved characters MUST be encoded. The special
hname "body" indicates that the associated hvalue is the message- hname "body" indicates that the associated hvalue is the message-
body of the SIP INVITE request. Within sip URLs, the characters body of the SIP INVITE request. Within sip URLs, the characters
"?", "=", "&" are reserved. "?", "=", "&" are reserved.
The mailto: URL and RFC 822 email addresses require that numeric The mailto: URL and RFC 822 email addresses require that numeric
host addresses ("host numbers") are enclosed in square brackets host addresses ("host numbers") are enclosed in square brackets
(presumably, since host names might be numeric), while host numbers (presumably, since host names might be numeric), while host numbers
without brackets are used for all other URLs. The SIP URL allows both without brackets are used for all other URLs. The SIP URL requires
forms. the latter form.
The password parameter can be used for a basic authentication The password parameter can be used for a basic authentication
mechanism that takes the place of an unlisted telephone number. Also, mechanism that takes the place of an unlisted telephone number. Also,
for Internet telephony gateways, it may serve as a PIN. Including for Internet telephony gateways, it may serve as a personal
just the password in the URL is more convenient than including a identification number (PIN). Including just the password in the URL
whole authentication header. This approach may be reasonably secure is more convenient than including a whole authentication header. This
if the URL is part of a secure web page. Unless the SIP transaction approach may be reasonably secure if the URL is part of a secured web
is carried over a secure network connection, this carries the same page. Unless the SIP transaction is carried over a secure network
security risks as all URL-based passwords and should only be used connection, this carries the same security risks as all URL-based
when security requirements are low. In almost all circumstances, use passwords and should only be used when security requirements are low.
of the Authorization (Section 6.10) header is preferred. In general, it is NOT RECOMMENDED and use of the Authorization
(Section 6.11) header is preferred.
The phone identifier is to be used when connecting to a telephony The phone identifier is to be used when connecting to a telephony
gateway. The phone number follows the rules for international numbers gateway. The phone number follows the rules for international numbers
in ITU Recommendation E.123, with only numbers and hyphens allowed. in ITU Recommendation E.123, with only numbers and hyphens allowed.
Examples of short and full-form SIP URLs are: Examples of short and full-form SIP URLs are:
j.doe@big.com j.doe@big.com
sip://j.doe@big.com sip:j.doe@big.com
sip://j.doe:secret@big.com;transport=tcp sip:j.doe:secret@big.com;transport=tcp
sip://j.doe@big.com?subject=project sip:j.doe@big.com?subject=project
sip://+1-212-555-1212:1234@gateway.com sip:+1-212-555-1212:1234@gateway.com
sip://alice@[10.1.2.3] sip:alice@[10.1.2.3]
sip://alice@10.1.2.3 sip:alice@10.1.2.3
Within a SIP message, URLs are used to indicate the source and Within a SIP message, URLs are used to indicate the source and
intended destination of a request, redirection addresses and the intended destination of a request, redirection addresses and the
current destination of a request. Normally all these fields will current destination of a request. Normally all these fields will
contain SIP URLs. When additional parameters are not required, the contain SIP URLs. When additional parameters are not required, the
short form SIP URL can be used unambiguously. short form SIP URL can be used unambiguously.
SIP URLs are case-insensitive, so that sip:j.doe@example.com and
SIP:J.Doe@Example.com are equivalent.
In some circumstances a non-SIP URL may be used in a SIP message. An In some circumstances a non-SIP URL may be used in a SIP message. An
example might be making a call from a telephone which is relayed by a example might be making a call from a telephone which is relayed by a
gateway onto the internet as a SIP request. In such a case, the gateway onto the internet as a SIP request. In such a case, the
source of the call is really the telephone number of the caller, and source of the call is really the telephone number of the caller, and
so a SIP URL is inappropriate and a phone URL might be used instead. so a SIP URL is inappropriate and a phone URL might be used instead.
Thus where SIP specifies user addresses it allows these addresses to To allow for this flexibility, SIP headers that specify user
be URLs. addresses allow these addresses to be SIP and non-SIP URLs.
Clearly not all URLs are appropriate to be used in a SIP message as a Clearly not all URLs are appropriate to be used in a SIP message as a
user address. The correct behavior when an unknown scheme is user address. The correct behavior when an unknown scheme is
encountered by a SIP server is defined in the context of each of the encountered by a SIP server is defined in the context of each of the
header fields that use a SIP URL. header fields that use a SIP URL.
SIP URLs can define specific parameters of the request, including the SIP URLs can define specific parameters of the request, including the
transport mechanism (UDP or TCP) and the use of multicast to make a transport mechanism (UDP or TCP) and the use of multicast to make a
request. These parameters are added after the host and are separated request. These parameters are added after the host and are separated
by semi-colons. For example, to specify to call j.doe@big.com using by semi-colons. 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 multicast to 239.255.255.1 with a ttl of 15, the following URL would
be used: be used:
sip://j.doe@big.com;maddr=239.255.255.1;ttl=15 sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
The transport protocol UDP is to be assumed when a multicast address The transport protocol UDP is to be assumed when a multicast address
is given. is given.
3 SIP Message Overview 3 SIP Message Overview
SIP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 2279 [23]). Lines are terminated by CRLF, but
receivers should be prepared to also interpret CR and LF by
themselves as line terminators.
Since much of the message syntax is identical to HTTP/1.1, rather Except for the above difference in character sets, much of the
than repeating it here we use [HX.Y] to refer to Section X.Y of the message syntax is identical to HTTP/1.1, rather than repeating it
current HTTP/1.1 specification [11]. In addition, we describe SIP in here we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1
both prose and an augmented Backus-Naur form (BNF) [H2.1] described specification (RFC 2068 [10]). In addition, we describe SIP in both
in detail in [21]. prose and an augmented Backus-Naur form (BNF) [H2.1] described in
detail in RFC 2234 [24].
All SIP messages are text-based and use HTTP/1.1 conventions [H4.1], Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP
except for the additional ability of SIP to use UDP. When sent over transactions can be carried in a single TCP connection or UDP
TCP or UDP, multiple SIP transactions can be carried in a single TCP datagram. UDP datagrams, including all headers, should not normally
connection or UDP datagram. UDP datagrams, including all headers, be larger than the path maximum transmission unit (MTU) if the MTU is
should not normally be larger than the path maximum transmission unit known, or 1400 bytes if the MTU is unknown.
(MTU) if the MTU is known, or 1500 bytes if the MTU is unknown.
The 1400 bytes accommodates lower-layer packet headers The 1400 bytes accommodates lower-layer packet headers
within the "typical" MTU of around 1500 bytes. There are within the "typical" MTU of around 1500 bytes. Recent
few MTU values around 1 kB; the next value is 1006 bytes studies [25] indicate that an MTU of 1500 bytes is a
for SLIP and 296 for low-delay PPP [22]. Recent studies reasonable assumption. The next lower common MTU values are
[23] indicate that an MTU of 1500 bytes is a reasonable 1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191
assumption. Thus, another reasonable value would be a [26]). Thus, another reasonable value would be a message
message size of 950 bytes, to accommodate packet headers size of 950 bytes, to accommodate packet headers within the
within the SLIP MTU without fragmentation. SLIP MTU without fragmentation.
A SIP message is either a request from a client to a server, or a A SIP message is either a request from a client to a server, or a
response from a server to a client. response from a server to a client.
SIP-message ___ Request | Response ; SIP messages SIP-message ___ Request | Response
Both Request (section 4) and Response (section 5) messages use the Both Request (section 4) and Response (section 5) messages use the
generic message format of RFC 822 [24] for transferring entities (the generic-message format of RFC 822 [27] for transferring entities (the
payload of the message). Both types of message consist of a start- body of the message). Both types of message consist of a start-line,
line, one or more header fields (also known as "headers"), an empty one or more header fields (also known as "headers"), an empty line
line (i.e., a line with nothing preceding the carriage-return line- (i.e., a line with nothing preceding the carriage-return line-feed (
feed ( CRLF)) indicating the end of the header fields, and an CRLF)) indicating the end of the header fields, and an optional
optional message-body. To avoid confusion with similar-named headers message-body. To avoid confusion with similar-named headers in HTTP,
in HTTP, we refer to the header describing the message body as entity we refer to the header describing the message body as entity headers.
headers. These components are described in detail in the upcoming These components are described in detail in the upcoming sections.
sections.
generic-message = start-line generic-message = start-line
*message-header *message-header
CRLF CRLF
[ message-body ] [ message-body ]
start-line = Request-Line | Section 4.1 start-line = Request-Line | Section 4.1
Status-Line Section 5.1 Status-Line Section 5.1
message-header = *( general-header message-header = *( general-header
| request-header | request-header
| response-header
| entity-header ) | entity-header )
In the interest of robustness, any leading empty line(s) MUST be In the interest of robustness, any leading empty line(s) MUST be
ignored. In other words, if the Request or Response message begins ignored. In other words, if the Request or Response message begins
with a CRLF, the CRLF should be ignored. with a CRLF, the CRLF should be ignored.
4 Request 4 Request
The Request message format is shown below: The Request message format is shown below:
skipping to change at page 19, line 5 skipping to change at page 19, line 40
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
Request-URI and the protocol version, and ending with CRLF. The Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF are allowed elements are separated by SP characters. No CR or LF are allowed
except in the final CRLF sequence. except in the final CRLF sequence.
Request-Line ___ Method SP Request-URI SP SIP-Version CRLF
general-header = Call-ID ; Section 6.12 general-header = Call-ID ; Section 6.12
| CSeq ; Section 6.26 | CSeq ; Section 6.16
| Date ; Section 6.15 | Date ; Section 6.17
| Expires ; Section 6.16 | Encryption ; Section 6.18
| From ; Section 6.17 | Expires ; Section 6.20
| Via ; Section 6.33 | From ; Section 6.21
entity-header = Content-Length ; Section 6.13 | Record-Route ; Section 6.33
| Content-Type ; Section 6.14 | Timestamp ; Section 6.39
request-header = Accept ; Section 6.6 | Via ; Section 6.43
| Accept-Language ; Section 6.7 entity-header = Content-Encoding ; Section 6.13
| Authorization ; Section 6.10 | Content-Length ; Section 6.14
| Call-Disposition ; Section 6.11 | Content-Type ; Section 6.15
| Organization ; Section 6.19 | ETag ; Section 6.19
| Priority ; Section 6.20 request-header = Accept ; Section 6.7
| Proxy-Authorization ; Section 6.22 | Accept-Encoding ; Section 6.8
| Require ; Section 6.24 | Accept-Language ; Section 6.9
| Subject ; Section 6.28 | Authorization ; Section 6.11
| To ; Section 6.31 | Hide ; Section 6.22
| User-Agent ; Section 6.32 | If-Match ; Section 6.23
response-header = Location ; Section 6.18 | If-None-Match ; Section 6.24
| Proxy-Authenticate ; Section 6.21 | Location ; Section 6.25
| Public ; Section 6.23 | Max-Forwards ; Section 6.26
| Retry-After ; Section 6.25 | Organization ; Section 6.27
| Server ; Section 6.27 | Priority ; Section 6.28
| Unsupported ; Section 6.29 | Proxy-Authorization ; Section 6.30
| Warning ; Section 6.34 | Proxy-Require ; Section 6.31
| WWW-Authenticate ; Section 6.35 | Route ; Section 6.35
| Require ; Section 6.32
| Response-Key ; Section 6.34
| Subject ; Section 6.38
| To ; Section 6.40
| User-Agent ; Section 6.42
response-header = Allow ; Section 6.10
| Location ; Section 6.25
| Proxy-Authenticate ; Section 6.29
| Retry-After ; Section 6.36
| Server ; Section 6.37
| Unsupported ; Section 6.41
| Warning ; Section 6.44
| WWW-Authenticate ; Section 6.45
Table 2: SIP headers Table 2: SIP headers
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 SHOULD be treated by that server as if they proxy or redirect server are treated by that server as if they were
were an INVITE method and forwarded accordingly. an INVITE method and forwarded accordingly.
Methods that are not supported by a user agent server should cause a Methods that are not supported by a user agent server cause a 501
"501 Not Implemented" response to be returned (Section 7). (Not Implemented) response to be returned (Section 7).
method = "INVITE" | "ACK" | "OPTIONS" Method = "ACK" | "BYE" | "CANCEL" | "INVITE"
| "BYE" | "REGISTER" | "UNREGISTER" | "OPTIONS" | "REGISTER"
4.2.1 INVITE 4.2.1 INVITE
The INVITE method indicates that the user or service is being The INVITE method indicates that the user or service is being
invited to participate in a session. The message body contains a invited to participate in a session. The message body contains a
description of the session the callee is being invited to. For two- description of the session to which the callee is being invited. For
party calls, the caller indicates the type of media it is able to two-party calls, the caller indicates the type of media it is able to
receive as well as their parameters such as network destination. If receive as well as their parameters such as network destination. If
the session description format allows this, it may also indicate the session description format allows this, it may also indicate
"send-only" media. A success response indicates in its message body "send-only" media. A success response indicates in its message body
which media the callee wishes to receive. which media the callee wishes to receive.
A server MAY automatically respond to an invitation for a conference A server MAY automatically respond to an invitation for a conference
the user is already participating in, identified either by the SIP the user is already participating in, identified either by the SIP
Call-ID or a globally unique identifier within the session Call-ID or a globally unique identifier within the session
description, with a "200 OK" response. description, with a 200 (OK) response.
A user agent MUST check any version identifiers in the session If a user agents receives an INVITE with a new CSeq sequence
description to see if it has changed. If the version number has number, it MUST check any version identifiers in the session
changed, the user agent server MUST adjust the session parameters description or, if there are no version identifiers, the content of
accordingly, possibly after asking the user for confirmation. the session description to see if it has changed. If the session
(Versioning of the session description may be used to accomodate the description has changed, the user agent server MUST adjust the
capabilities of new arrivals to a conference or change from a unicast session parameters accordingly, possibly after asking the user for
to a multicast conference.) confirmation. (Versioning of the session description may be used to
accommodate the 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 a SIP server. This method MUST be supported by a SIP server and client.
4.2.2 ACK 4.2.2 ACK
ACK request confirms that the client has received a final response to The ACK request confirms that the client has received a final
an INVITE request. See Section 11 for details. This method MUST be response to an INVITE request. 2xx responses are acknowledged by
supported by a SIP server and client. client user agents, all other final responses by the first proxy or
client user agent to receive the response. The Via is always
initialized to the host that originates the ACK request, i.e., the
client user agent after a 2xx response or the first proxy to receive
a non-2xx final response. The ACK request is forwarded as the
corresponding INVITE request, based on its Request-URI. See Section
10 for details. This method MUST be supported by a SIP server and
client.
The ACK request MAY contain a message body with the final session
description to be used by the callee. If the ACK message body is
empty, the callee uses the session description in the INVITE
request.
4.2.3 OPTIONS 4.2.3 OPTIONS
The client is being queried as to its capabilities. A server that The client is being queried as to its capabilities. A server that
believes it can contact the user, such as a user agent where the user believes it can contact the user, such as a user agent where the user
is logged in and has been recently active, MAY respond to this is logged in and has been recently active, MAY respond to this
request with a capability set. Support of this method is OPTIONAL. request with a capability set. Support of this method is REQUIRED.
A called user agent MAY return a status reflecting how it would have
responded to an invitation, e.g., 600 (Busy).
4.2.4 BYE 4.2.4 BYE
The client indicates to the server that it wishes to abort the call The user agent client uses BYE to indicate to the server that it
attempt. The leaving party can use a Location header field to wishes to abort the call. A BYE request is forwarded like an INVITE
indicate that the recipient of request should contact the named request. It terminates any on-going searches for the named call. A
address. This implements the "call transfer" telephony caller SHOULD issue a BYE request before aborting a call ("hanging
functionality. A client SHOULD also use this method to indicate to up"). Note that a BYE request may also be issued by the callee.
the callee that it wishes to abort an on-going call attempt.
With UDP, the caller has no other way to signal her intent If the INVITE request contained a Location header, the callee sends
to drop the call attempt and the callee side will keep the BYE request to that address rather than the From address.
"ringing". When using TCP, a client MAY also close the
connection to abort a call attempt. Support of this method
is OPTIONAL.
Support of this method is OPTIONAL. This method MUST be supported by proxy servers and SHOULD be
supported by all other SIP server types.
4.2.5 REGISTER 4.2.5 CANCEL
The CANCEL request cancels any pending searches, but does not
terminate an accepted call at a particular user agent. (A call is
considered accepted if the callee has returned a 200 (OK) status
response.) A proxy SHOULD issue a CANCEL request to all destinations
that have not yet returned a final response after it has received a
2xx or 6xx response for one or more of the parallel-search requests.
A proxy that receives a CANCEL request forwards the request to all
destinations with pending requests triggered by an INVITE. The
Call-ID, To and From in the CANCEL request are identical to those
contained in the CANCEL request, but the Via header field is
initialized to the proxy issuing the CANCEL request.
A redirect server or user agent server returns 200 (OK) if the Call-
ID exists and 481 (Invalid Call-ID) if not, but takes no further
action. In particular, any existing call is unaffected.
The BYE request cannot be used to cancel branches of a
parallel search, since several branches may, through
intermediate proxies, find the same user agent server and
then terminate the call.
This method MUST be supported by proxy servers and SHOULD be
supported by all other SIP server types.
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 request line to a SIP server. The host part of the request-URI the To header to a SIP server.
SHOULD correspond to (one of the aliases of) name of the server or to
the domain that it represents, if location-independent. After
registration, the server MAY forward incoming SIP requests to the the
network source address and port from the registration request. A
server SHOULD silently drop the registration after one hour, unless
refreshed by the client. A client may request and a server may
indicate or lower or higher refresh interval and indicate the
interval through the Expires header (Section 6.16). A single address
(if host-independent) may be registered from several different
clients.
If the request contains a Location header, requests for the A user agent SHOULD register with a local server on startup by
request-URI will be directed to the address(es) given. sending a REGISTER request to the well-known "all SIP servers"
multicast address, 224.0.1.75, with a time-to-live value of 1.
Support of this method is OPTIONAL. SIP user agents on the same subnet MAY listen to that address and use
it to become aware of the location of other local users [28];
however, they do not respond to the request.
The REGISTER request interprets header fields as follows. We define
"address-of-record" as the SIP address that the registry knows the
registrand under, typically of the form "user@domain" rather than
"user@host". In third-party registration, the entity issuing the
request is different from the entity being registered.
To: The To header field contains the address-of-record whose
registration is to be created or updated.
From: The From header field contains the address-of-record of the
person responsible for the registration. For first-party
registration, it is identical to the To header field value.
Request-URI: The Request-URI names the destination of the
registration request, i.e., the domain of the registrar. The
user name MUST be empty. Generally, the domains in the
Request-URI and the To header have the same value; however, it
is possible to register as a "visitor", while maintaining one's
name. For example, a traveller alice@acme.com may register under
@atlanta.ayh.org
Location: If the request contains a Location header field, requests
for the Request-URI will also be directed to the address(es)
given. It is recommended that user agents include both SIP UDP
and TCP addresses in their registration. Registrations are
additive.
We cannot require that registration and requests use the
same transport protocol, as multicast registrations may be
quite useful.
Otherwise, future call control requests will be directed to the
network source address of the REGISTER request, using the To
address in the REGISTER request as the Request-URI. If the
registration is changed while a user agent or proxy server processes
an invitation, the new information should be used.
This allows a service known as "directed pick-up".
After registration, the server MAY forward incoming SIP requests to
the network source address and port that originated the registration
request. A server SHOULD silently drop the registration after one
hour, unless refreshed by the client. A client may request a lower or
higher refresh interval through the Expires header (Section 6.20).
Based on this request and its configuration, the server chooses the
expiration interval and indicates it through the Expires header in
the response. A single address (if host-independent) may be
registered from several different clients.
A client cancels an existing registration by sending a REGISTER
request with an expiration time ( Expires) of zero seconds for a
particular Location or the wildcard Location designated by a "*"
for all registrations.
The server SHOULD return the current list of registrations in the 200
response as Location header fields.
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,
so that some cannot use the default port number. Each such so that some cannot use the default port number. Each such
server would register with a server for the administrative server would register with a server for the administrative
domain. domain. Since a client may not have easy access to the host
address or port number, using the source address and port
4.2.6 UNREGISTER from the request itself seems simpler.
A client cancels an existing registration established for the Support of this method is RECOMMENDED.
Request-URI with REGISTER with the UNREGISTER method. If it
unregisters a Request-URI unknown to the servers, the server returns
a 200 (OK) response. Support of this method is OPTIONAL.
4.3 Request-URI 4.3 Request-URI
The Request-URI field is a SIP URL as described in Section 2 or a The Request-URI field is a SIP URL as described in Section 2 or a
general URI. It indicates the user or service that this request is general URI. It indicates the user or service to which this request
being addressed to. Unlike the To field, the Request-URI field may is being addressed. Unlike the To field, the Request-URI field may
be re-written by proxies. For example, a proxy may perform a lookup be re-written by proxies. For example, a proxy may perform a lookup
on the contents of the To field to resolve a username from a mail on the contents of the To field to resolve a username from a mail
alias, and then use this username as part of the Request-URI field alias, and then use this username as part of the Request-URI field
of requests it generates. of requests it generates.
If a SIP server receives a request contain a URI indicating a scheme 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
request to the address indicated or return a 404 (Not Found) response
if it is unwilling or unable to do so. The case where the Request-URI
and server host name disagrees occurs, for example, for a firewall
proxy that handles outgoing calls. It is similar to the operation of
HTTP proxies.
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
field contains a scheme it does understand. field contains a scheme it does understand.
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 conditionally compliant with this specification, applications sending
SIP messages MUST include a SIP-Version of "SIP/2.0". SIP messages 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.24) and Unsupported SIP. These tags are used in Require (Section 6.32) and Unsupported
(Section 6.29) fields. (Section 6.41) fields.
Syntax: Syntax:
option-tag ___ 1*OCTET ; LWS must be URL-escaped option-tag ___ 1*urlc
The creator of a new SIP option should either prefix the option with The creator of a new SIP option should either prefix the option with
a reverse domain name (e.g., "com.foo.mynewfeature" is an apt name a reverse domain name or register the new option with the Internet
for a feature whose inventor can be reached at "foo.com"), or Assigned Numbers Authority (IANA). For example,
register the new option with the Internet Assigned Numbers Authority "com.foo.mynewfeature" is an apt name for a feature whose inventor
(IANA). can be reached at "foo.com". 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-
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 should When registering a new SIP option, the following information should
be provided: be provided:
oName and description of option. The name may be of any length, oName 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
should not contain any spaces, control characters or periods. MUST NOT contain any spaces, control characters or periods.
oIndication of who has change control over the option (for oIndication 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);
oA reference to a further description, if available, for example o A reference to a further description, if available, for
(in order of preference) an RFC, a published paper, a patent example (in order of preference) an RFC, a published paper, a
filing, a technical report, documented source code or a patent filing, a technical report, documented source code or a
computer manual; computer manual;
oFor proprietary options, contact information (postal and email oFor proprietary options, 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
skipping to change at page 23, line 37 skipping to change at page 27, line 9
CRLF CRLF
[ message-body ] ; Section 8 [ message-body ] ; Section 8
[H6] applies except that HTTP-Version is replaced by SIP-Version. [H6] applies except that HTTP-Version is replaced by SIP-Version.
Also, SIP defines additional response codes and does not use some Also, SIP defines additional response codes and does not use some
HTTP codes. HTTP codes.
5.1 Status-Line 5.1 Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version ((Section 4.3.1) followed by a numeric of the protocol version (Section 4.3.1) followed by a numeric
Status-Code and its associated textual phrase, with each element Status-Code and its associated textual phrase, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence. final CRLF sequence.
Status-Line ___ SIP-version SP Status-Code SP Reason-Phrase CRLF Status-Line ___ SIP-version SP Status-Code SP Reason-Phrase CRLF
5.1.1 Status Codes and Reason Phrases 5.1.1 Status Codes and Reason Phrases
The Status-Code is a 3-digit integer result code that indicates the The Status-Code is a 3-digit integer result code that indicates the
outcome of the attempt to understand and satisfy the request. The outcome of the attempt to understand and satisfy the request. The
Reason-Phrase is intended to give a short textual description of the Reason-Phrase is intended to give a short textual description of the
Status-Code. The Status-Code is intended for use by automata, Status-Code. The Status-Code is intended for use by automata,
whereas the Reason-Phrase is intended for the human user. The client whereas the Reason-Phrase is intended for the human user. The client
is not required to examine or display the Reason-Phrase. is not required to examine or display the Reason-Phrase.
We provide an overview of the Status-Code below, and provide full We provide an overview of the Status-Code below, and provide full
definitions in section 7. The first digit of the Status-Code defines definitions in Section 7. The first digit of the Status-Code defines
the class of response. The last two digits do not have any the class of response. The last two digits do not have any
categorization role. SIP/2.0 allows 6 values for the first digit: categorization role. SIP/2.0 allows 6 values for the first digit:
1xx: Informational -- request received, continuing process; 1xx: Informational -- request received, continuing process;
2xx: Success -- the action was successfully received, understood, and 2xx: Success -- the action was successfully received, understood, and
accepted; accepted;
3xx: Redirection -- further action must be taken in order to complete 3xx: Redirection -- further action must be taken in order to complete
the request; the request;
skipping to change at page 25, line 4 skipping to change at page 28, line 19
Status-Code = Informational Fig. 3 Status-Code = Informational Fig. 3
| Success Fig. 3 | Success Fig. 3
| Redirection Fig. 4 | Redirection Fig. 4
| Client-Error Fig. 5 | Client-Error Fig. 5
| Server-Error Fig. 6 | Server-Error Fig. 6
| Global-Failure Fig. 7 | Global-Failure Fig. 7
| extension-code | extension-code
extension-code = 3DIGIT extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF> Reason-Phrase = *<TEXT, excluding CR, LF>
Informational = "100" ; Trying Informational = "100" ; Trying
| "180" ; Ringing | "180" ; Ringing
| "181" ; Queued | "181" ; Call Is Being Forwarded
Success = "200" ; OK Success = "200" ; OK
Figure 3: Informational and success status codes Figure 3: Informational and success status codes
Redirection = "300" ; Multiple Choices Redirection = "300" ; Multiple Choices
| "301" ; Moved Permanently | "301" ; Moved Permanently
| "302" ; Moved Temporarily | "302" ; Moved Temporarily
| "303" ; See Other | "303" ; See Other
| "305" ; Use Proxy | "305" ; Use Proxy
| "380" ; Alternative Service | "380" ; Alternative Service
Figure 4: Redirection status codes Figure 4: Redirection status codes
SIP response codes are extensible. SIP applications are not required
to understand the meaning of all registered response codes, though
such understanding is obviously desirable. However, applications MUST
understand the class of any response code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 response code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if a client
receives an unrecognized response code of 431, it can safely assume
that there was something wrong with its request and treat the
response as if it had received a 400 response code. In such cases,
user agents SHOULD present to the user the message body returned with
the response, since that message body is likely to include human-
readable information which will explain the unusual status.
6 Header Field Definitions
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
| "407" ; Proxy Authentication Required | "407" ; Proxy Authentication Required
| "408" ; Request Timeout | "408" ; Request Timeout
| "409" ; Conflict | "409" ; Conflict
| "410" ; Gone | "410" ; Gone
| "411" ; Length Required | "411" ; Length Required
| "412" ; Precondition Failed | "412" ; Precondition Failed
| "413" ; Request Message Body Too Large | "413" ; Request Message Body Too Large
| "414" ; Request-URI Too Large | "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type | "415" ; Unsupported Media Type
| "420" ; Bad Extension | "420" ; Bad Extension
| "480" ; Temporarily not available | "480" ; Temporarily not available
| "481" ; Invalid Call-ID | "481" ; Invalid Call-ID
| "482" ; Loop Detected | "482" ; Loop Detected
| "483" ; Too Many Hops
Figure 5: Client error status codes Figure 5: Client error status codes
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 6: Server error status codes Figure 6: Server error status codes
SIP header fields are similar to HTTP header fields in both syntax SIP response codes are extensible. SIP applications are not required
and semantics [H4.2], [H14]. In general the ordering of the header to understand the meaning of all registered response codes, though
fields is not of importance (with the exception of Via fields, see such understanding is obviously desirable. However, applications MUST
below), but proxies MUST NOT reorder or otherwise modify header understand the class of any response code, as indicated by the first
fields other than by adding a new Via field. This allows an digit, and treat any unrecognized response as being equivalent to the
authentication field to be added after the Via fields that will not x00 response code of that class, with the exception that an
be invalidated by proxies. unrecognized response MUST NOT be cached. For example, if a client
receives an unrecognized response code of 431, it can safely assume
The header fields required, optional and not applicable for each
Global-Failure | "600" ; Busy Global-Failure | "600" ; Busy
| "603" ; Decline | "603" ; Decline
| "604" ; Does not exist anywhere | "604" ; Does not exist anywhere
| "606" ; Not Acceptable | "606" ; Not Acceptable
Figure 7: Global failure status Codes Figure 7: Global failure status Codes
method are listed in Table 3. The Content-Type and Content-Length that there was something wrong with its request and treat the
headers are required when there is a valid message body (of non-zero response as if it had received a 400 (Bad Request) response code. In
length) associated with the message (Section 8). such cases, user agents SHOULD present to the user the message body
returned with the response, since that message body is likely to
include human-readable information which will explain the unusual
status.
Other headers may be added as required; a server MAY ignore headers 6 Header Field Definitions
that it does not understand. A compact form of these header fields is
also defined in Section 10 for use over UDP when the request has to SIP header fields are similar to HTTP header fields in both syntax
fit into a single packet and size is an issue. 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), but proxies MUST NOT reorder or otherwise modify header
fields other than by adding a new Via or other hop-by-hop field.
Proxies MUST NOT, for example, change how header fields are broken
across lines. This allows an authentication field to be added after
the Via fields that will not be invalidated by proxies.
The header fields required, optional and not applicable for each
method are listed in Table 3. The table uses "o" to indicate
optional, "m" mandatory and "-" for not applicable. A "*" indicates
that the header fields are needed only if message body is not empty:
The Content-Type and Content-Length headers are required when there
is a valid message body (of non-zero length) associated with the
message (Section 8).
The "type" column describes the request and response types the header
field may be used for. A numeric value indicates the status code for
a response, while "R" refers to any request header, "r" to any
response header. "g" and "e" designate general (Section 6.1) and
entity header (Section 6.2) fields, respectively.
The "enc." column describes whether this message header 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.
The "e-e" column has a value of "e" for end-to-end and a value of "h"
for hop-by-hop headers.
Other headers may be added as required; a server MAY ignore optional
headers that it does not understand. A compact form of these header
fields is also defined in Section 9 for use over UDP when the request
has to fit into a single packet and size is an issue.
Table 4 in Appendix A indicates which system components should be
capable of parsing which header fields.
6.1 General Header Fields 6.1 General Header Fields
There are a few header fields that have general applicability for There are a few header fields that have general applicability for
both request and response messages. These header fields apply only to both request and response messages. These header fields apply only to
the message being transmitted. the message being transmitted.
General-header field names can be extended reliably only in 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. be general-header fields.
6.2 Entity Header Fields 6.2 Entity Header Fields
Entity-header fields define meta-information about the message-body Entity-header fields define meta-information about the message-body
or, if no body is present, about the resource identified by the or, if no body is present, about the resource identified by the
request. The term "entity header" is an HTTP 1.1 term where the reply request. The term "entity header" is an HTTP 1.1 term where the
body may contain a transformed version of the message body. The response body may contain a transformed version of the message body.
original message body is referred to as the "entity". We retain the The original message body is referred to as the "entity". We retain
same terminology for header fields but usually refer to the "message the same terminology for header fields but usually refer to the
body" rather then the entity as the two are the same in SIP. "message body" rather then the entity as the two are the same in SIP.
6.3 Request Header Fields 6.3 Request Header Fields
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
type ACK BYE INV OPT REG UNR
_________________________________________________________________
Accept R o - o o o o
Accept-Language R o o o o o o
Allow 405 o o o o o o
Also R - - o - - -
Authorization R o o o o o o
Call-Disposition R - o o - - -
Call-ID g m m m o - -
Content-Length g - - * * - -
Content-Type g - - * * - -
CSeq g o o o o o o
Date g o o o o o o
Expires g - - o o o -
From R m m m m o o
Location R - o - - o -
Location r - - o o - -
Organization R - - o o - -
Proxy-Authenticate R o o o o o o
Proxy-Authorization R o o o o o o
Priority R - - o - - -
Public r - - - o - -
Require R o o o o o o
Retry-After 600,603 - - o - - -
Server r o o o o o o
Subject R - - o - - -
Timestamp g o o o o o o
To g m m m m m m
Unsupported r o o o o o o
User-Agent R o o o o o o
Via g m m m m m m
Warning r o o o o o o
WWW-Authenticate 401 o o o o o o
Table 3: Summary of header fields. "o": optional, "m": mandatory, "-
": not applicable, "R': request header, "r": response header, "g":
general header, "*": needed if message body is not empty. A numeric
value in the "type" column indicates the status code the header field
is used with.
equivalent to the parameters on a programming language method equivalent to the parameters on a programming language method
invocation. invocation.
Request-header field names can be extended reliably only in 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.
skipping to change at page 29, line 21 skipping to change at page 32, line 19
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 as
entity-header fields. entity-header fields.
6.5 Header Field Format 6.5 End-to-end and Hop-by-hop Headers
End-to-end headers must be transmitted unmodified across all proxies,
while hop-by-hop headers may be modified or added by proxies.
6.6 Header Field Format
Header fields ( general-header, request-header, response-header, and Header fields ( general-header, request-header, response-header, and
entity-header) follow the same generic header format as that given in entity-header) follow the same generic header format as that given in
Section 3.1 of RFC 822 [24]. Section 3.1 of RFC 822 [27,29].
Each header field consists of a name followed by a colon (":") and Each header field consists of a name followed by a colon (":") and
the field value. Field names are case-insensitive. The field value the field value. Field names are case-insensitive. The field value
may be preceded by any amount of leading white space (LWS), though a may be preceded by any amount of leading white space (LWS), though a
single space (SP) is preferred. Header fields can be extended over single space (SP) is preferred. Header fields can be extended over
multiple lines by preceding each extra line with at least one SP or multiple lines by preceding each extra line with at least one SP or
horizontal tab (HT). Applications SHOULD follow HTTP "common form" horizontal tab (HT). Applications SHOULD follow HTTP "common form"
when generating these constructs, since there might exist some when generating these constructs, since there might exist some
implementations that fail to accept anything beyond the common forms. implementations that fail to accept anything beyond the common forms.
skipping to change at page 29, line 47 skipping to change at page 33, line 4
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 or combinations and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string> of token, tspecials, and quoted-string>
The order in which header fields are received is not significant if The order in which header fields are received is not significant if
the header fields have different field names. Multiple header fields the header fields have different field names. Multiple header fields
with the same field-name may be present in a message if and only if with the same field-name may be present in a message if and only if
the entire field-value for that header field is defined as a comma- the entire field-value for that header field is defined as a comma-
type enc. e-e ACK BYE CAN INV OPT REG
________________________________________________________________________________
Accept R e o o o o o o
Accept-Encoding R e o o o o o o
Accept-Language R n 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
Call-ID g n e m m m m o -
Content-Encoding e e * - - * * *
Content-Length e e m - - m m m
Content-Type e e * - - * * *
CSeq g n e m m m m m o
Date g e o o o o o o
Encryption g n e o o o o o o
ETag 200 e - - - o - -
Expires g e - - - o o o
From R e m m m m m m
Hide R n h o o o o o o
If-Match R e o o - - - -
If-None-Match R e o o - - - -
Location R e - - - - - o
Location 3xx e - - o o o o
Location 2xx e - - o o o -
Max-Forwards R n e o o o o o o
Organization R c e - - - o o o
Proxy-Authenticate 407 n h o o o o o o
Proxy-Authorization R n h o o o o o o
Proxy-Require R n h o o o o o o
Priority R c e - - - o - -
Require R n e o o o o o o
Retry-After R c e - - - - - o
Retry-After 600,603 c e - - - o - -
Response-Key R c e - o o o o o
Record-Route R h o o o o o o
Record-Route 2xx h o o o o o o
Route R h - o o o o o
Server r c e o o o o o o
Subject R c e - - - o - -
Timestamp g e o o o o o o
To g n e m m m m m m
Unsupported 420 e o o o o o o
User-Agent R c e o o o o o o
Via g n e m m m m m m
Warning r e o o o o o o
WWW-Authenticate 401 c e o o o o o o
Table 3: Summary of header fields
separated list (i.e., #(values) ). It MUST be possible to combine the separated list (i.e., #(values) ). It MUST be possible to combine the
multiple header fields into one "field-name: field-value" pair, multiple header fields into one "field-name: field-value" pair,
without changing the semantics of the message, by appending each without changing the semantics of the message, by appending each
subsequent field-value to the first, each separated by a comma. The subsequent field-value to the first, each separated by a comma. The
order in which header fields with the same field-name are received is order in which header fields with the same field-name are received is
therefore significant to the interpretation of the combined field therefore significant to the interpretation of the combined field
value, and thus a proxy MUST NOT change the order of these field value, and thus a proxy MUST NOT change the order of these field
values when a message is forwarded. values when a message is forwarded.
Field names are not case-sensitive, although their values may be. Field names are not case-sensitive, although their values may be.
6.6 Accept 6.7 Accept
See [H14.1] for syntax. This request header field is used only with See [H14.1] for syntax. This request-header field is used only with
the OPTIONS and INVITE request methods to indicate what description the OPTIONS and INVITE request methods to indicate what media types
formats are acceptable in the response. are acceptable in the response.
Example: Example:
Accept: application/sdp;level=1, application/x-private Accept: application/sdp;level=1, application/x-private, text/html
6.7 Accept-Language 6.8 Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings [H3.4.1] that are acceptable in the
response. See [H14.3].
6.9 Accept-Language
See [H14.4] for syntax. The Accept-Language request header can be See [H14.4] for syntax. The Accept-Language request header can be
used to allow the client to indicate to the server in which language used to allow the client to indicate to the server in which language
it would prefer to receive reason phrases. This may also be used as a it would prefer to receive reason phrases, session descriptions or
hint by the proxy as to which destination to connect the call to status responses carried as message bodies. This may also be used as
a hint by the proxy to which destination to connect the call to
(e.g., for selecting a human operator). (e.g., for selecting a human operator).
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.8 Allow 6.10 Allow
See [H14.7]. The Allow entity-header field lists the set of methods
See [H14.7]. supported by the resource identified by the Request-URI. The purpose
of this field is strictly to inform the recipient of valid methods
6.9 Also associated with the resource. An Allow header field MUST be present
in a 405 (Method Not Allowed) response.
The Also request header advises the callee to send invitations to
the addresses listed. This supports third-party call initiation
(Section 13).
Also ___ "Also" ":" 1#( SIP-URL ) [ comment ] 6.11 Authorization
Example: See [H14.8] and [30]. A user agent that wishes to authenticate itself
with a server -- usually, but not necessarily, after receiving a 401
response -- MAY do so by including an Authorization request-header
field with the request. The Authorization field value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
Also: sip://jones@foo.com, sip://mueller@bar.edu 6.12 Call-ID
6.10 Authorization The Call-ID general header uniquely identifies a particular
invitation. Note that a single multimedia conference may give rise to
several calls with different Call-IDs, e.g., if a user invites a
single individual several times to the same (long-running)
conference.
See [H14.8]. For an INVITE request, a callee client application alerts the user
only if the user has not responded previously to the Call-ID in the
INVITE request. If the user is already a member of the conference and
the conference parameters contained in the session description have
not changed, a callee client application MAY silently accept the
call, regardless of the Call-ID. An invitation for an existing
Call-ID or session may change the parameters of the conference. A
client application MAY decide to simply indicate to the user that the
conference parameters have been changed and accept the invitation
automatically or it MAY require user confirmation.
6.11 Call-Disposition A user may be invited to the same conference or call using several
different Call-IDs. If desired, the client may use identifiers
within the session description to detect this duplication. For
example, SDP contains a session id and version number in the origin (
o) field.
The Call-Disposition request header field allows the client to The Call-ID may be any string consisting of the unreserved URI
indicate how the server is to handle the call. The following options characters that can be guaranteed to be globally unique for the
can be used singly or in combination: duration of the request. Call-IDs are case-sensitive and are not
URL-encoded.
all: If the user part of the SIP request address identifies a group Since the Call-ID is generated by and for SIP, there is no
rather than an individual, the " all" feature indicates that all reason to deal with the complexity of URL-encoding and
members of the group should be alerted rather than the default case-ignoring string comparison.
of locating the first available individual from that group.
Section 1.4.1 describes the behavior of proxy servers when
resolving group aliases.
do-not-forward: The "do-not-forward" request prohibits proxies from The form local-id@host is recommended, where host is either the
forwarding the call to another individual (e.g., the call is fully qualified domain name or a globally routable IP address. The
personal or the caller does not want to be shunted to a local-id is a version-4 (random) UUID [31].
secretary if the line is busy.)
queue: If the called party is temporarily unreachable, e.g., because Using cryptographically random identifiers provides some
it is in another call, the caller can indicate that it wants to protection against session hijacking.
have its call queued rather than rejected immediately. If the
call is queued, the server returns "181 Queued" (see Section
7.1.3). A pending call be terminated by a BYE request (Section
4.2.4).
Call-Disposition ___ "Call-Disposition" ":" 1#( "all" | "do-not-forward" Call-ID = ( "Call-ID" | "i" ) ":" UUID "@" host
| "queue" ) UUID = ; see [31]
Example: Example:
Call-Disposition: all, do-not-forward, queue Call-ID: 3436538253725150855@foo.bar.com
HS: This header is experimental. The name is based on the
SMTP Content-Disposition header.
6.12 Call-ID
The Call-ID general header uniquely identifies a particular
invitation. Note that a single multimedia conference may give rise to
several calls with different Call-IDs, e.g., if a user invites
several different people. Since the Call-ID is unique for each
caller, a user may invited to the same conference using several
different Call-IDs. If desired, it must use identifiers within the
session description to detect this duplication. Calls to different
callee MUST always use different Call-IDs unless they are the result
of a proxy server "forking" a single request.
The Call-ID may be any URL-encoded string that can be guaranteed to
be globally unique for the duration of the request. Using the
initiator's IP-address, process id, and instance (if more than one
request is being made simultaneously) satisfies this requirement.
The form local-id@host is recommended, where host is either the
fully qualified domain name or a globally routable IP address, and
local-id depends on the application and operating system of the host,
but is an ID that can be guaranteed to be unique during this session
initiation request.
Call-ID ___ ( "Call-ID" | "i" ) ":" atom "@" host
Example: 6.13 Content-Encoding
Call-ID: 9707211351.AA08181@foo.bar.com The Content-Encoding entity-header field is used as a modifier to
the media-type. When present, its value indicates what additional
content codings have been applied to the entity-body, and thus what
decoding mechanisms MUST be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing
the identity of its underlying media type. See [H14.11].
6.13 Content-Length 6.14 Content-Length
The Content-Length entity-header field indicates the size of the The Content-Length entity-header field indicates the size of the
message-body, in decimal number of octets, sent to the recipient. message-body, in decimal number of octets, sent to the recipient.
Content-Length = "Content-Length" ":" 1*DIGIT Content-Length = "Content-Length" ":" 1*DIGIT
An example is An example is
Content-Length: 3495 Content-Length: 3495
Applications SHOULD use this field to indicate the size of the Applications MUST 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 MAY be omitted or set to zero. Section 8 describes how to header MUST be set to zero. If a server receives a message without
determine the length of the message body. Content-Length, it MUST assume it to be zero. Section 8 describes
how to determine the length of the message body.
6.14 Content-Type 6.15 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. message-body sent to the recipient.
Content-Type ___ "Content-Type" ":" media-type Content-Type = "Content-Type" ":" media-type
An example of the field is Example of this header field are
Content-Type: application/sdp Content-Type: application/sdp
Content-Type: text/html; charset=ISO-8859-4
6.15 Date 6.16 CSeq
Clients MUST add the CSeq (command sequence) general-header field to
every request. A CSeq request header field contains a single decimal
sequence number chosen by the requesting client and the request
method. The sequence number MUST be expressible as a 64-bit unsigned
integer. The initial value of the sequence number is arbitrary.
Consecutive requests that differ in request method, headers or body,
but have the same Call-ID MUST contain strictly monotonically
increasing and contiguous sequence numbers; sequence numbers do not
wrap around. Retransmissions of the same request carry the same
sequence number, but an INVITE with a different message body (a
"re-invitation") acquires a new, higher sequence number. A server
responding to a request containing a CSeq header MUST echo the value
in the response. If the Method value is missing, the server fills it
it appropriately.
The ACK request MUST contain the same CSeq value as the INVITE
request that it refers to, while a BYE or CANCEL request cancelling
an invitation MUST have a higher sequence number.
A user agent server MUST remember the highest sequence number for any
INVITE request with the same Call-ID value. The server MUST respond
to, but ignore any INVITE request with a lower sequence number.
All requests spawned in a parallel search have the same CSeq value
as the request triggering the parallel search.
CSeq = "CSeq" ":" 1*DIGIT Method
Strictly speaking, CSeq header fields are needed for any
SIP request that can be cancelled by a BYE or CANCEL
request or where a client can issue several requests for
the same Call-ID in close succession. Without a sequence
number, the response to an INVITE could be mistaken for
the response to the cancellation ( BYE or CANCEL). Also,
if the network duplicates packets or if an ACK is delayed
until the server has sent an additional response, the
client could interpret an old response as the response to a
re-invitation issued shortly thereafter. Using CSeq also
makes it easy for the server to distinguish different
versions of an invitation, without comparing the message
body.
The Method value allows the client to distinguish the response to an
INVITE request from that of a CANCEL response.
At 64 bits, a server could generate one request a second for about
500 billion years before needing to wrap around.
Forked requests must have the same CSeq as there would be ambiguity
otherwise between these forked requests and later BYE issued by the
client user agent.
Example:
CSeq: 4711 INVITE
6.17 Date
General header field. See [H14.19]. General header field. See [H14.19].
The Date header field is useful for simple devices without The Date header field is useful for simple devices without
their own clock. their own clock.
6.16 Expires 6.18 Encryption
The Encryption general-header field specifies that the content has
been encrypted. Section 12 describes the overall SIP security
architecture and algorithms. It is intended for end-to-end encryption
of requests and responses. Requests are encrypted with a public key
belonging to the entity named in the To header field. Responses are
encrypted with the public key conveyed in the Response-Key header
field.
SIP chose not to adopt HTTP's Content-Transfer-Encoding
header because the encrypted body may contain additional
SIP header fields as well as the body of the message.
For any encrypted message, at least the message body and possibly
other message header fields are encrypted. An application receiving a
request or response containing an Encryption header field decrypts
the body and then concatenates the plaintext to the request line and
headers of the original message. Message headers in the decrypted
part completely replace those with the same field name in the
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
concatenation.) Note that the request method and Request-URI cannot
be encrypted.
Encryption only provides privacy; the recipient has no
guarantee that the request or response came from the party
listed in the From message header, only that the sender
used the recipients public key. However, proxies will not
be able to modify the request or response.
Encryption = "Encryption" ":" encryption-scheme 1*SP
#encryption-params
encryption-scheme = token
encryption-params = token "=" ( token | quoted-string )
The token indicates the form of encryption used; it is
described in section 12.
The following example for a message encrypted with ASCII-armored PGP
was generated by applying "pgp -ea" to the payload to be encrypted.
INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Content-Length: 885
Encryption: PGP,version=2.6.2,encoding=ascii
hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red
h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs
ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR
RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA
zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu
X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6
IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/
GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E
WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed
wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO
z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+
6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2
z8X9N4MhMyXEVuC9rt8/AUhmVQ==
=bOW+
Since proxies may 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.19 ETag
The ETag response-header field labels an instance of the callee. A
callee MUST include an ETag in a 200 response to an INVITE if the
Location response-header field is not sufficient to uniquely identify
the callee. Typically, this is the case if the Location header
points to a proxy rather than the callee itself. (If requests are
forked, it is possible that two or more people "pick up the phone"
for the same call.)
If the caller receives a 2xx response containing an entity tag, it
MUST include a If-Match (Section 6.23) request-header field with
that entity tag in the ACK or BYE. It would send a BYE with the
entity tag if it does not wish to talk to this particular instance of
the callee.
The entity tag consists of an opaque quoted string. An entity tag
MUST be unique across all instances associated with a particular To
URI. A given entity tag value may be used for different URIs without
implying anything about the equivalence of those URIs. It is
RECOMMENDED that the entity tag is a cryptographically random
identifier with at least 32 bits of randomness.
Note that SIP does not use the concept of "weak" entity tags [H3.11].
ETag = "ETag" ":" entity-tag
entity-tag = quoted-string
6.20 Expires
The Expires entity-header field gives the date and time after which The Expires entity-header field gives the date and time after which
the message content expires. the message content expires.
This header field is currently defined only for the REGISTER and This header field is currently defined only for the REGISTER and
INVITE methods. For REGISTER, it is a request and response-header INVITE methods. For REGISTER, it is a request and response-header
field and allows the client to indicate how long the registration field and allows the client to indicate how long the registration is
should be valid; the server uses it to indicate when the client has to be valid; the server uses it to indicate when the client has to
to re-register. The server's choice overrides that of the client. The re-register. The server's choice overrides that of the client. The
server MAY choose a shorter time interval than that requested by the server MAY choose a shorter time interval than that requested by the
client, but SHOULD not choose a longer one. client, but SHOULD not choose a longer one.
For INVITE, it is a request and response-header field. In a request, For INVITE, it is a request and response-header field. In a request,
the callee can limit the validity of an invitation. (For example, if the callee can limit the validity of an invitation. (For example, if
a client wants to limit how long a search should take at most or when a client wants to limit how long a search should take at most or when
a conference being invited to is time-limited. A user interface may a conference invitation is time-limited. A user interface may take
take this is as a hint to leave the invitation window on the screen this is as a hint to leave the invitation window on the screen even
even if the user is not currently at the workstation.) In a 302 if the user is not currently at the workstation.) This also limits
response, a server can advise the client of the maximal duration of the duration of a search. If the request expires before the search
the redirection. completes, the proxy returns a 408 (Request Timeout) status. In a
302 (Moved Temporarily) response, a server can advise the client of
the maximal duration of 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. request. The latter approach is preferable for short durations, as
it does not depend on clients and servers sharing a synchronized
clock.
Expires ___ "Expires" ":" ( HTTP-date | delta-seconds ) Expires = "Expires" ":" ( HTTP-date | delta-seconds )
Two example of its use are Two example 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.17 From 6.21 From
Requests MUST and responses SHOULD contain a From header field,
indicating the invitation initiator. The field MUST be a SIP URL as
defined in Section 2. Only a single initiator and a single invited
user are allowed to be specified in a single SIP request. The sense
of To and From header fields is maintained from request to
response, i.e., if the From header is sip://bob@example.edu in the
request then it is MUST also be sip://bob@example.edu in the response
to that request.
The From field is a URL and not a simple SIP address (Section 1.4.1 Requests and responses MUST contain a From general-header field,
address to allow a gateway to relay a call into a SIP request and indicating the invitation initiator. The server copies the To and
still produce an appropriate From field. From header fields from the request to the response.
From ___ ( "From" | "f" ) ":" *1( ( SIP-URL | URL ) [ comment ] ) From = ( "From" | "f" ) ":" ( name-addr | addr-spec )
name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI
display-name = *token | quoted-string
Examples: Examples:
From: agb@bell-telephone.com (A. G. Bell) From: A. G. Bell <sip:agb@bell-telephone.com>
From: +12125551212@server.phone2net.com From: sip:+12125551212@server.phone2net.com
6.18 Location 6.22 Hide
The Location response header can be used with a 2xx or 3xx response The Hide request header field indicates that the path comprised of
codes to indicate a new location to try. It contains a URL giving the the Via header fields (Section 6.43) should be hidden from
new location or username to try, or may simply specify additional subsequent proxies and user agents. It can take two forms: Hide:
transport parameters. A "301 Moved Permanently" or "302 Moved route and Hide:hop. Hide header fields are typically added by the
Temporarily" response SHOULD contain a Location field containing the client user agent, but MAY be added by any proxy along the path.
URL giving a new address to try. A 301 or 302 response may also give
the same location and username that was being tried but specify
additional transport parameters such as a multicast address to try or
a change of SIP transport from UDP to TCP or vice versa.
A user agent or redirect server sending a definitive, positive If a request contains the " Hide: route" header field, all following
response (2xx), SHOULD insert a Location response header indicating proxies SHOULD hide their previous hop. If a request contains the "
the SIP address under which it is reachable most directly for future Hide: hop" header field, only the next proxy SHOULD hide the previous
SIP requests. This may be the address of the server itself or that of hop and then remove the Hide option unless it also wants to remain
a proxy (e.g., if the host is behind a firewall). anonymous.
A Location response header may contain any suitable URL indicating A server hides the previous hop by encrypting the host and port
parts of the top-most Via header with an algorithm of its choice.
Servers SHOULD add additional "salt" to the host and port
information prior to encryption to prevent malicious downstream
proxies from guessing earlier parts of the path based on seeing
identical encrypted Via headers. Hidden Via fields are marked with
the hidden Via option, as described in Section 6.43.
A server that is capable of hiding Via headers MUST attempt to
decrypt all Via headers marked as "hidden" to perform loop
detection. Servers that are not capable of hiding can ignore hidden
Via fields in their loop detection algorithm.
If hidden headers were not marked, a proxy would have to
decrypt all headers to detect loops, just in case one was
encrypted, as the Hide: Hop option may have been removed
along the way.
A host MUST NOT add such a " Hide:hop" header field unless it can
guarantee it will only send a request for this destination to the
same next hop. The reason for this is that it is possible that the
request will loop back through this same hop from a downstream proxy.
The loop will be detected by the next hop if the choice of next hop
is fixed, but could loop an arbitrary number of times otherwise.
A client requesting " Hide: route" can only rely on keeping the
request path private if it sends the request to a trusted proxy.
Hiding the route of a SIP request may be of limited value if the
request results in data packets being exchanged directly between the
calling and called user agent.
The use of Hide header fields is discouraged unless path privacy is
truly needed; Hide fields impose extra processing costs and
restrictions for proxies and can cause requests to generate 482 (Loop
Detected) responses that could otherwise be avoided.
The encryption of Via header fields is described in more detail in
Section 12.
The Hide header field has the following syntax:
Hide = "Hide" ":" ( "route" | "hop" )
6.23 If-Match
The If-Match request-header field is used with a method to make it
conditional. The server MUST NOT perform the request unless it had
returned one of the listed entity tags in a ETag header field in a
200 response for the same Call-ID. The "*" tag matches all entity
tags, as well as the case where the server that had not returned an
entity tag. If there is no match, a user agent server MUST return a
412 (Precondition Failed) response, while a proxy server forwards the
request according to the Request-URI. A proxy server that receives
an ACK with a matching entity tag MUST NOT forward the request.
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
The If-Match allows a caller to select among a set of callee that
answer to the same request-URI and To.
Example:
If-Match: "83ja", "148293289"
6.24 If-None-Match
The If-None-Match request-header field is used with a method to make
the method conditional. The server compares the list of entity tags
in the If-None-Match header to the entity tag that it had returned
in an ETag header (Section 6.19) as part of a 200 response for the
same Call-ID. The value "*" matches any entity tag. If one of the
entity tag in the If-None-Match header matches the ETag entity tag,
a user agent server MUST NOT perform the method requested and respond
with a status of 412 (Precondition Failed) instead while a proxy
server forwards the request. (The "*" value is included for symmetry
with If-Match only and currently has no practical application.)
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
Example:
If-None-Match: "83ja", "148293289"
6.25 Location
The Location general-header field can appear in requests, 2xx
responses and 3xx responses.
REGISTER requests: REGISTER requests MAY contain Location header
fields. They indicate under which locations the user may be
reachable. The REGISTER request defines a wildcard Location
field, "*". that is only used with Expires: 0 to remove all
registrations for a particular user.
INVITE and ACK requests: INVITE and ACK requests MAY contain
Location headers indicating the location the request is
originating from.
This allows the callee to send a BYE directly to the
caller instead of through a series of proxies. The Via
header is not sufficient since the desired address may be
that of a proxy.
3xx responses: The Location response-header field can be used with a
3xx response codes to indicate one or more addresses to try. It
can appear in responses to INVITE and OPTIONS methods. The
Location header field contains URIs giving the new locations or
user names to try, or may simply specify additional transport
parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily)
response SHOULD contain a Location field containing URIs of new
addressed to be tried. A 301 or 302 response may also give the
same location and username that was being tried but specify
additional transport parameters such as a multicast address to
try or a change of SIP transport from UDP to TCP or vice versa.
INVITE 2xx responses: A user agent server sending a definitive,
positive response (2xx), MAY insert a Location response header
indicating the SIP address under which it is reachable most
directly for future SIP requests, such as ACK. This may be the
address of the server itself or that of a proxy, e.g., if the
host is behind a firewall. The value of this Location header is
copied into the Request-URI and the To header of subsequent
ACK and BYE requests for this call.
REGISTER 2xx responses: Similarly, a REGISTER response SHOULD return
all locations that a user is currently reachable under.
Note that the Location header may also refer to a different entity
than the one originally called. For example, a SIP call connected to
GSTN gateway may need to deliver a special information announcement
such as "The number you have dialed has been changed."
A Location response header may contain any suitable URI indicating
where the called party may be reached, not limited to SIP URLs. For where the called party may be reached, not limited to SIP URLs. For
example, it may contain a phone or fax URL [25], a mailto: URL [26] example, it may contain a phone or fax URL [22], a mailto: URL [19]
or irc. or irc: URL.
The following parameters are defined: The following parameters are defined. Additional parameters may be
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.
class: The class parameter whether this terminal is found in a action: The action is only used when registering with the REGISTER
residential or business setting. (A caller may defer a personal request. It indicates how the client wishes forwarding to occur,
call if only a business line is available, for example.) by proxying or by redirection. The action taken if this
parameter is not specified depends on server configuration. In
description: The description field further describes, as text, the its response, the registrar SHOULD indicate the mode used. This
terminal. It is expected that the user interface will render parameter is ignored for other requests.
this text.
duplex: The duplex parameter lists whether the terminal can Location = ( "Location" | "m" ) ("*" | (1# (( SIP-URL | URI )
simultaneously send and receive ("full"), alternate between *( ";" location-params )))
sending and receiving ("half"), can only receive ("receive-
only") or only send ("send-only"). Typically, a caller will
prefer a full-duplex terminal over a half-duplex terminal and
these over receive-only or send-only terminals.
features: The feature list enumerates additional features of this location-params = "q" "=" qvalue
terminal. Values for this field are for further study. | "action" "=" "proxy" | "redirect"
| extension-attribute
extension-attribute = extension-name [ "=" extension-value ]
language: The language parameter lists, in order of preference, the Example:
languages spoken by the person answering. This feature may be
used to have a caller automatically select the appropriate
attendant or customer service representative, without having to
declare its own language skills.
media: The media tag lists the media types supported by the terminal. Location: sip:watson@worcester.bell-telephone.com ;q=0.7,
Currently, the names defined in SDP may be used [9]: "audio", mailto:watson@bell-telephone.com ;q=0.1
"video", "whiteboard", "text" and "data".
mobility: The mobility parameter indicates if the terminal is fixed 6.26 Max-Forwards
or mobile. In some locales, this may affect voice quality or
charges.
priority: The priority tag indicates the minimum priority level this The Max-Forwards request-header field may be used with any SIP
terminal is to be used for. It can be used for automatically method to limit the number of proxies or gateways that can forward
restricting the choice of terminals available to the user. the request to the next inbound server. This can also be useful when
the client is attempting to trace a request chain which appears to be
failing or looping in mid-chain. [H14.31]
service: The service tag describes what service is being provided by Max-Forwards = "Max-Forwards" ":" 1*DIGIT
the terminal.
Location = ( "Location" | "m" ) ( SIP-URL | URL ) The Max-Forwards value is a decimal integer indicating the remaining
*( ";" location-params ) number of times this request message may be forwarded.
extension-name = token
extension-value = *( token | quoted-string | LWS | extension-specials)
extension-specials = < any element of tspecials except <"> >
language-tag = < see [H3.10] >
priority-tag = "urgent" | "normal" | "non-urgent"
service-tag = "fax" | "IP" | "PSTN" | "ISDN" | "pager"
media-tag = < see SDP: "audio" | "video" | "email" ...
feature-list = "voice-mail" | "attendant"
location-params = "q" "=" qvalue Each proxy or gateway recipient of a request containing a Max-
| "class" "=" ( "personal" | "business" ) Forwards header field MUST check and update its value prior to
| "description" "=" quoted-string forwarding the request. If the received value is zero (0), the
| "duplex" "=" ( "full" | "half" | recipient MUST NOT forward the request. Instead, for the OPTIONS and
"receive-only" | "send-only" ) REGISTER methods, it MUST respond as the final recipient. For all
| "features" "=" 1# feature-list other methods, the server returns 483 (Too many hops).
| "language" "=" 1# language-tag
| "media" "=" 1# media-tag
| "mobility" "=" ( "fixed" | "mobile" )
| "priority" "=" 1# priority-tag
| "service" "=" 1# service-tag
| extension-attributes
extension-attribute = extension-name "=" extension-value
Examples: If the received Max-Forwards value is greater than zero, then the
forwarded message MUST contain an updated Max-Forwards field with a
value decremented by one (1).
Location: sip://watson@worcester.bell-telephone.com ;service=IP,voice-mail Example:
;media=audio ;duplex=full ;q=0.7;
Location: phone://1-415-555-1212 ; service=ISDN;mobility=fixed;
language=en,es,iw ;q=0.5
Location: phone://1-800-555-1212 ; service=pager;mobility=mobile;
duplex=send-only;media=text; q=0.1; priority=urgent;
description="For emergencies only"
Location: mailto:watson@bell-telephone.com
Location: http://www.bell-telephone.com/~watson
Attributes which are unknown should be omitted. New tags for class- Max-Forwards: 6
tag and service-tag can be registered with IANA. The media tag uses
Internet media types, e.g., audio, video, application/x-wb, etc. This
is meant for indicating general communication capability, sufficient
for the caller to choose an appropriate address.
6.19 Organization 6.27 Organization
The Organization request-header fields conveys the name of the The Organization request-header field conveys the name of the
organization to which the callee belongs. It may be inserted by organization to which the callee belongs. It may also be inserted by
proxies at the boundary of an organization and may be used by client proxies at the boundary of an organization and may be used by client
software to filter calls. software to filter calls.
6.20 Priority Organization = "Organization" ":" *text
The priority request header signals the urgency of the call to the 6.28 Priority
The Priority request header signals the urgency of the call to the
callee. callee.
Priority = "Priority" ":" priority-value Priority = "Priority" ":" priority-value
priority-value = "urgent" | "normal" | "non-urgent" priority-value = "emergency" | "urgent" | "normal" | "non-urgent"
Example: The value of "emergency" should only be used when life, limb or
property are in imminent danger.
Examples:
Subject: A tornado is heading our way! Subject: A tornado is heading our way!
Priority: urgent Priority: emergency
Subject: Weekend plans
Priority: non-urgent
6.21 Proxy-Authenticate These are the values of RFC 2076, with the addition of
"emergency".
See [H14.33]. 6.29 Proxy-Authenticate
6.22 Proxy-Authorization The Proxy-Authenticate response-header field MUST be included as
part of a 407 (Proxy Authentication Required) response. The field
value consists of a challenge that indicates the authentication
scheme and parameters applicable to the proxy for this Request-URI.
See [H14.34]. See [H14.33] for further details.
6.23 Public A client SHOULD cache the credentials used for a particular proxy
server and realm for the next request to that server. Credentials
are, in general, valid for a specific value of the Request-URI at a
particular proxy server. If a client contacts a proxy server that has
required authentication in the past, but the client does not have
credentials for the particular Request-URI, it MAY attempt to use
the most-recently used credential. The server responds with 401
(Unauthorized) if the client guessed wrong.
See [H14.35]. This suggested caching behavior is motivated by proxies
restricting phone calls to authenticated users. It seems
likely that in most cases, all destinations require the
same password. Note that end-to-end authentication is
likely to be destination-specific.
6.24 Require 6.30 Proxy-Authorization
The Require header is used by clients to query the server about The Proxy-Authorization request-header field allows the client to
options that it may or may not support. The server MUST respond to identify itself (or its user) to a proxy which requires
this header by returning status code "420 Bad Extension" and list authentication. The Proxy-Authorization field value consists of
those options it does not understand in the Unsupported header. credentials containing the authentication information of the user
agent for the proxy and/or realm of the resource being requested. See
[H14.34] for further details.
Require ___ "Require" ":" 1#option-tag 6.31 Proxy-Require
The Proxy-Require header is used to indicate proxy-sensitive
features that MUST be supported by the proxy. Any Proxy-Require
header features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client if not supported.
Servers treat this field identically to the Require field.
See Section 6.32 for more details on the mechanics of this message
and a usage example.
6.32 Require
The Require request header is used by clients to tell user agent
servers about options that the client expects the server to support
in order to properly process the request. If a server does not
understand the option, it MUST respond by returning status code 420
(Bad Extension) and list those options it does not understand in the
Unsupported header.
Require = "Require" ":" 1#option-tag
Example: Example:
C->S: INVITE sip:watson@bell-telephone.com SIP/2.0 C->S: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: com.example.billing Require: com.example.billing
Payment: sheep_skins, conch_shells Payment: sheep_skins, conch_shells
S->C: SIP/2.0 420 Bad Extension S->C: SIP/2.0 420 Bad Extension
Unsupported: com.example.billing Unsupported: com.example.billing
This is to make sure that the client-server interaction will proceed This is to make sure that the client-server interaction
optimally when all options are understood by both sides, and only will proceed without delay when all options are understood
slow down if options are not understood (as in the example above). by both sides, and only slow down if options are not
For a well-matched client-server pair, the interaction proceeds understood (as in the example above). For a well-matched
quickly, saving a round-trip often required by negotiation client-server pair, the interaction proceeds quickly,
mechanisms. In addition, it also removes ambiguity when the client saving a round-trip often required by negotiation
requires features that the server does not understand. mechanisms. In addition, it also removes ambiguity when the
client requires features that the server does not
understand. Some features, such as call handling fields,
are only of interest to end systems.
We explored using the W3C's PEP proposal for this Proxy and redirect servers MUST ignore features that are not
functionality. However, Require, Proxy-Require, and understood. If a particular extension requires that intermediate
Unsupported allow the addition of extensions with far less devices support it, the extension should be tagged in the Proxy-
complexity. Require field instead (see Section 6.31).
This field roughly corresponds to the PEP field in the PEP draft. 6.33 Record-Route
6.25 Retry-After The Record-Route request and response header field is added to an
INVITE request by any proxy that insists on being in the path of
subsequent ACK and BYE requests for the same call. It contains a
globally reachable Request-URI that identifies the proxy server.
Each proxy server adds its Request-URI to the beginning of the list.
The Retry-After response header field can be used with a "503 The client copies the Record-Route header unchanged into the
Service Unavailable" response to indicate how long the service is response. ( Record-Route is only relevant for 2xx responses.)
expected to be unavailable to the requesting client and with a "404
Not Found", "600 Busy", "603 Decline" response to indicate when the
called party may be available again. The value of this field can be
either an HTTP-date or an integer number of seconds (in decimal)
after the time of the response. An optional comment can be used to
indicate additional information about the time of callback. An
optional duration parameter indicates how long the called party will
be reachable starting at the initial time of availability.
Retry-After ___ "Retry-After" ":" ( HTTP-date | delta-seconds ) The calling user agent client copies the Record-Route header into a
Route header of subsequent requests, reversing the order of requests,
so that the first entry is closest to the caller. If the response
contained a Location header field, the calling user agent adds its
content as the last Route header. Unless this would cause a loop,
any clientMUST send any subsequent requests for this Call-ID to the
first Request-URI in the Route request header and remove that entry.
Some proxies, such as those controlling firewalls or in an
automatic call distribution (ACD) system, need to maintain
call state and thus need to receive any BYE and ACK
packets for the call.
The Record-Route header field has the following syntax:
Record-Route = "Record-Route" ":" 1# request-uri
Example for a request that has traversed the hosts ieee.org and
bell-telephone.com , in that order:
Record-Route: sip:a.g.bell@bell-telephone.com, sip:a.bell@ieee.org
6.34 Response-Key
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
response with. The syntax is:
Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param
key-scheme = token
key-param = token "=" ( token | quoted-string )
The key-scheme gives the type of encryption to be used for response.
Section 12 describes security schemes.
If the client insists that the server return an encrypted response,
it includes a
Require: org.ietf.sip.encrypt-response
header field in its request. If the client cannot encrypt for
whatever reason, it MUST follow normal Require header field
procedures and return an 420 (Bad Extension) response. If this
Require header is not present, a client SHOULD still encrypt, but MAY
return an unencrypted response if unable to.
6.35 Route
The Route request header determines the route taken by a 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-URI. The
operation is further described in Section 6.33.
The Route header field has the following syntax:
Route = "Route" ":" 1# request-uri
6.36 Retry-After
The Retry-After response header field can be used with a 503
(Service Unavailable) response to indicate how long the service is
expected to be unavailable to the requesting client and with a 404
(Not Found), 600 (Busy), or 603 (Decline) response to indicate when
the called party may be available again. The value of this field can
be either an HTTP-date or an integer number of seconds (in decimal)
after the time of the response.
A REGISTER request may include this header field when deleting
registrations with Location: *; Expires: 0. The Retry-After value
then indicates when the user might again be reachable. The registrar
MAY then include this information in responses to future calls.
An optional comment can be used to indicate additional information
about the time of callback. An optional duration parameter indicates
how long the called party will be reachable starting at the initial
time of availability. If no duration parameter is given, the service
is assumed to be available indefinitely.
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 GMD;duration=3600 Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600
Retry-After: 120 Retry-After: 120
In the third example, the callee is reachable for one hour starting In the third example, the callee is reachable for one hour starting
at 21:00 GMT. In the last example, the delay is 2 minutes. at 21:00 GMT. In the last example, the delay is 2 minutes.
6.26 CSeq 6.37 Server
The CSeq (command sequence) header field MAY be added by a SIP
client making a request if it needs to distinguish responses to
several consecutive requests sent with the same Call-ID. A CSeq
field contains a single decimal sequence number chosen by the
requesting client. Consecutive different requests made with the same
Call-ID MUST contain strictly monotonically increasing sequence
numbers; the sequence space MAY NOT be contiguous. Retransmissions of
the same request carry the same sequence number. A server responding
to a request containing a sequence number MUST echo the sequence
number back in the response. The ACK request MUST contain the same
CSeq value as the INVITE request that it refers to.
CSeq = "CSeq" ":" 1*DIGIT
CSeq header fields are NOT needed for SIP requests using the INVITE
or OPTIONS methods but may be needed for future methods.
Example:
CSeq: 4711
6.27 Server
See [H14.39]. The Server response-header field contains information about the
software used by the user agent server to handle the request. See
[H14.39].
6.28 Subject 6.38 Subject
This is intended to provide a summary, or indicate the nature, of the This is intended to provide a summary, or indicate the nature, of the
call, allowing call filtering without having to parse the session call, allowing call filtering without having to parse the session
description. (Also, the session description may not necessarily use description. (Also, the session description may not necessarily use
the same subject indication as the invitation.) the same subject indication as the invitation.)
Subject ___ ( "Subject" | "s" ) ":" *text Subject = ( "Subject" | "s" ) ":" *text
Example: Example:
Subject: Tune in - they are talking about your work! Subject: Tune in - they are talking about your work!
6.29 Unsupported 6.39 Timestamp
The Unsupported response header lists the features not supported by
the server.
See Section 6.24 for a usage example and motivation.
6.30 Timestamp
The timestamp general header describes when the client sent the The timestamp general header describes when the client sent the
request to the server. The value of the timestamp is of significance request to the server. The value of the timestamp is of significance
only to the client and may use any timescale. The server MUST echo only to the client and may use any timescale. The server MUST echo
the exact same value and MAY, if it has accurate information about the exact same value and MAY, if it has accurate information about
this, add a floating point number indicating the number of seconds this, add a floating point number indicating the number of seconds
that has elapsed since it has received the request. The timestamp is that have elapsed since it has received the request. The timestamp is
used by the client to compute the round-trip time to the server so used by the client to compute the round-trip time to the server so
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.31 To 6.40 To
The To request header field specifies the invited user, with the The To request header field specifies the invited user, with the
same SIP URL syntax as the From field. same SIP URL syntax as the From field.
To = ( "To" | "t" ) ":" ( SIP-URL | URL ) [ comment ] To = ( "To" | "t" ) ":" ( name-addr | addr-spec )
If a SIP server receives a request destined To a URL indicating a A SIP server returns a 400 (Bad Request) response if it receives a
scheme other than SIP and that is unknown to it, the server returns a request with a To header field containing a URI with a scheme it
"400 bad request" response. does not recognize.
Example: Example:
To: sip://operator@cs.columbia.edu (The Operator) To: The Operator <sip:operator@cs.columbia.edu>
To: sip:+12125551212@server.phone2net.com
6.32 User-Agent 6.41 Unsupported
See [H14.42]. The Unsupported response header lists the features not supported by
the server. See Section 6.32 for a usage example and motivation.
6.33 Via 6.42 User-Agent
The User-Agent request-header field contains information about the
client user agent originating the request. See [H14.42].
6.43 Via
The Via field indicates the path taken by the request so far. This The Via field indicates the path taken by the request so far. This
prevents request looping and ensures replies take the same path as prevents request looping and ensures replies take the same path as
the requests, which assists in firewall traversal and other unusual the requests, which assists in firewall traversal and other unusual
routing situations. routing situations.
The client originating the request MUST insert a Via field 6.43.1 Requests
containing its address to the request. Each subsequent proxy server
that sends the request onwards MUST add its own additional Via The client originating the request MUST insert into the request a Via
field, which MUST be added before any existing Via fields. field containing its host name or network address and, if not the
default port number, the port number it wishes to receive responses
at. (Note that this port number may differ from the UDP source port
number of the request.) A fully-qualified domain name is RECOMMENDED.
Each subsequent proxy server that sends the request onwards MUST add
its own additional Via field before any existing Via fields.
A proxy that receives a redirection (3xx) response and then searches
recursively, MUST use the same Via headers as on the original
request.
A proxy SHOULD check the top-most Via header to ensure that it
contains the sender's correct network address, as seen from that
proxy. If the sender's address is incorrect, the proxy should add an
additional received attribute, as described below.
A host behind a network address translator (NAT) or
firewall may not be able to insert a network address into
the Via header that can be reached by the next hop beyond
the NAT. Hosts behind NATs or NAPTs should insert the local
port number of the outgoing socket, rather than the port
number for incoming requests, as NAPTs assume that
responses return with reversed source and destination
ports.
Additionally, if the message goes to a multicast address, an extra Additionally, if the message goes to a multicast address, an extra
Via field is added before all the others giving the multicast address Via field is added by the sender before all the other Via fields
and TTL. giving the multicast address and TTL.
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. (This it MUST respond with a 482 (Loop Detected) status code.
prevents a malfunctioning proxy server from causing loops. Also, it
cannot be guaranteed that a proxy server can always detect that the This prevents a malfunctioning proxy server from causing
address returned by a location service refers to a host listed in the loops. Also, it cannot be guaranteed that a proxy server
Via list, as a single host may have aliases or several network can always detect that the address returned by a location
interfaces.) service refers to a host listed in the Via list, as a
single host may have aliases or several network interfaces.
6.43.2 Receiver-tagged Via Fields
Normally every host that sends or forwards a SIP message adds a Via
field indicating the path traversed. However, it is possible that
Network Address Translators (NAT) may change the source address of
the request, in which case the Via field cannot be relied on to route
replies. To prevent this, a proxy SHOULD check the top-most Via
header to ensure that it contains the sender's correct network
address, as seen from that proxy. If the sender's address is
incorrect, the proxy should add a received tag to the Via field
inserted by the previous hop. Such a modified Via field is known as a
receiver-tagged Via field. An example is:
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
In this example, the message went from 10.0.0.1 and through a NAT
using external address border.ieee.org (199.172.136.3) to
erlang.bell-telephone.com tagged the previous hop's Via field with
the address that it actually came from.
6.43.3 Responses
In the return path, Via fields are processed by a proxy or client In the return path, Via fields are processed by a proxy or client
according to the following rules: according to the following rules:
oIf the first Via field in the reply received is the client's 1. The first Via field should indicate the proxy or client
or server's local address, remove the Via field and process processing this message. If it does not, discard the
the reply. message. Otherwise, remove this Via field.
oIf the first Via field in a reply is a multicast address, 2. If the second Via field in a response is a multicast
remove that Via field before sending to the multicast address. address, remove that Via field, and send the message to
the multicast address indicated.
3. If the second Via field is a receiver-tagged field
(Section 6.43.2) send the message to the address in the
received tag rather than that in the main part of the Via
field.
4. If the second Via field exists, send the message to the
address indicated. If there is no second Via field, this
response is destined for this client.
These rules ensure that a proxy server only has to check the first These rules ensure that a proxy server only has to check the first
Via field in a reply to see if it needs processing. Via field in a response to see if it needs processing.
6.43.4 Syntax
The format for a Via header is: The format for a Via header is:
Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by
*( ";" via-params ) [ comment ] ) *( ";" via-params ) [ comment ] )
via-params = "ttl" "=" ttl via-params = via-hidden | via-ttl | via-received | via-branch
via-hidden = "hidden"
via-ttl = "ttl" "=" ttl
via-received = "received" "=" host
via-branch = "branch" "=" token
sent-protocol = [ protocol-name "/" ] protocol-version sent-protocol = [ protocol-name "/" ] protocol-version
[ "/" transport ] [ "/" transport ]
protocol-name = "SIP" | token protocol-name = "SIP" | token
protocol-version = token protocol-version = token
transport = "UDP" | "TCP" transport = "UDP" | "TCP" | token
sent-by = host [ ":" port ] sent-by = ( host [ ":" port ] ) | ( concealed-host )
concealed-host = token
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
The "ttl" parameter is included only if the address is a multicast The "ttl" parameter is included only if the address is a multicast
address. address. The " received" parameter is added only for receiver-added
Via fields (Section 6.43.2). For reasons of privacy, a client or
proxy may wish to hide its Via information by encrypting it (see
Section 6.22). The " hidden" parameter is included if this header
was hidden by the upstream proxy (see 6.22).
Example: The " branch" parameter is included by every forking proxy. The
token uniquely identifies a branch of a particular search. The
identifier has to be unique only within a set of isomorphic requests.
Note that privacy of the proxy relies on the cooperation of the next
hop, as the next-hop proxy will, by necessity, know the IP address
and port number of the source host.
Via: SIP/2.0/UDP first.example.com:4000 Via: SIP/2.0/UDP first.example.com:4000
Via: SIP/2.0/UDP adk8
6.34 Warning 6.44 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 = 2DIGIT warn-code = 3DIGIT "." 2DIGIT
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 and character set that The warn-text should be in a natural language that is most likely to
is most likely to be intelligible to the human user receiving the be intelligible to the human user receiving the response. This
response. This decision may be based on any available knowledge, such decision may be based on any available knowledge, such as the
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, the Content-Language field in a response, etc. The default request, the Content-Language field in a response, etc. The default
language is English. language is English.
Any server may add Warning headers to a response. New Warning Any server may add Warning headers to a response. New Warning
headers should be added after any existing Warning headers. A proxy headers MUST be added after any existing Warning headers. A proxy
server MUST NOT delete any Warning header that it received with a server MUST NOT delete any Warning header that it received with a
response. response.
When multiple Warning headers are attached to a response, the user When multiple Warning headers are attached to a response, the user
agent SHOULD display as many of them as possible, in the order that agent SHOULD display as many of them as possible, in the order that
they appear in the response. If it is not possible to display all of they appear in the response. If it is not possible to display all of
the warnings, the user agent should follow these heuristics: the warnings, the user agent first displays warnings that appear
early in the response.
oWarnings that appear early in the response take priority over
those appearing later in the response.
oWarnings in the user's preferred character set take priority
over warnings in other character sets but with identical
warn-codes and warn-agents.
Systems that generate multiple Warning headers should order them Systems that generate multiple Warning headers should order them
with this user agent behavior in mind. with this user agent behavior in mind.
Example: Example:
Warning: 606.4 isi.edu Multicast not available Warning: 606.4 isi.edu Multicast not available
Warning: 606.2 isi.edu Incompatible protocol (RTP/XXP) Warning: 606.2 isi.edu Incompatible protocol (RTP/XXP)
6.35 WWW-Authenticate 6.45 WWW-Authenticate
See [H14.46]. The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages. The field value consists of at
least one challenge that indicates the authentication scheme(s) and
parameters applicable to the Request-URI.
See [H14.46] and [30].
The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages.
The content of the realm parameter SHOULD be displayed to the user.
A user agent SHOULD cache the authorization credentials for a given
value of the destination ( To header) and realm and attempt to re-use
these values on the next request for that destination.
In addition to the "basic" and "digest" authentication schemes
defined in the specifications cited above, SIP defines a new scheme,
PGP (RFC 2015, [32]), Section 13. Other schemes, such as S-MIME, are
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. Response codes not defined those that are appropriate are given here. Other HTTP/1.1 response
by HTTP/1.1 have codes x80 upwards to avoid clashes with future HTTP codes should not be used. Response codes not defined by HTTP/1.1 have
response codes. Also, SIP defines a new class, 6xx. The default codes x80 upwards to avoid clashes with future HTTP response codes.
behavior for unknown response codes is given for each category of Also, SIP defines a new class, 6xx. The default behavior for unknown
codes. response codes is given for each category of codes.
7.1 Informational 1xx 7.1 Informational 1xx
Informational responses indicate that the server or proxy contacted Informational responses indicate that the server or proxy contacted
is performing some further action and does not yet have a definitive is performing some further action and does not yet have a definitive
response. The client SHOULD wait for a further response from the response. The client SHOULD wait for a further response from the
server, and the server SHOULD send such a response without further server, and the server SHOULD send such a response without further
prompting. If UDP transport is being used, the client SHOULD prompting. Typically a server should send a 1xx response if it
periodically re-send the request in case the final response is lost. expects to take more than 200 ms to obtain a final response.
Typically a server should send a "1xx" response if it expects to take
more than one second to obtain a final reply.
7.1.1 100 Trying 7.1.1 100 Trying
Some further action is being taken (e.g., the request is being Some unspecified action is being taken on behalf of this call (e.g.,
forwarded) but the user has not yet been located. a database is being consulted), but the user has not yet been
located.
7.1.2 180 Ringing 7.1.2 180 Ringing
The user agent or conference server has located a possible location The called user agent has located a possible location where the user
where the user has been recently and is trying to alert them. has been recently and is trying to alert them.
7.1.3 181 Queued 7.1.3 181 Call Is Being Forwarded
The called party was temporarily unavailable, but the caller A proxy server MAY use this status code to indicate that the call is
indicated via a "Call-Disposition: Queue" directive (Section 6.11) to being forwarded to a different set of destinations. The new
queue the call rather than reject it. When the callee becomes destinations are listed in Location headers. Proxies SHOULD be
available, it will return the appropriate final status response. The configurable not to reveal this information.
reason phrase MAY give further details about the status of the call,
e.g., "5 calls queued; expected waiting time is 15 minutes". The
server may issue several 181 responses to update the caller about the
status of the queued call.
7.2 Successful 2xx 7.2 Successful 2xx
The request was successful and MUST terminate a search. The request was successful and MUST terminate a search.
7.2.1 200 OK 7.2.1 200 OK
The request was successful in contacting the user, and the user has The request has succeeded. The information returned with the response
agreed to participate. depends on the method used in the request, for example:
BYE: The call has been terminated. The message body is empty.
CANCEL: The search has been cancelled. The message body is empty.
INVITE: The callee has agreed to participate; the message body
indicates the callee's capabilities.
OPTIONS: The callee has agreed to share its capabilities, included in
the message body.
REGISTER: The registration has succeeded. The message body is empty.
7.3 Redirection 3xx 7.3 Redirection 3xx
3xx responses give information about the user's new location, or 3xx responses give information about the user's new location, or
about alternative services that may be able to satisfy the call. about alternative services that may be able to satisfy the call. They
They SHOULD terminate an existing search, and MAY cause the initiator SHOULD terminate an existing search, and MAY cause the initiator to
to begin a new search if appropriate. begin a new search if appropriate.
Any redirection (3xx) response MUST NOT suggest any of the addresses
in the Via (Section 6.43) path of the request in the Location header
field. (Addresses match if their host and port number match.)
7.3.1 300 Multiple Choices 7.3.1 300 Multiple Choices
The requested resource corresponds to any one of a set of The address in the request resolved to several choices, each with its
representations, each with its own specific location, and agent- own specific location, and the user (or user agent) can select a
driven negotiation (i.e., controlled by the SIP client) is being preferred communication end point and redirect its request to that
provided so that the user (or user agent) can select a preferred location.
communication end point and redirect its request to that location.
The response SHOULD include an entity containing a list of resource The response SHOULD include an entity containing a list of resource
characteristics and location(s) from which the user or user agent can characteristics and location(s) from which the user or user agent can
choose the one most appropriate. The entity format is specified by choose the one most appropriate, if allowed by the Accept request
the media type given in the Content-Type header field. Depending header. The entity format is specified by the media type given in the
upon the format and the capabilities of the user agent, selection of Content-Type header field. The choices SHOULD also be listed as
the most appropriate choice may be performed automatically. However, Location fields (Section 6.25). Unlike HTTP, the SIP response may
this specification does not define any standard for such automatic contain several Location fields or a list of addresses in a
selection. Location field. User agents MAY use the Location field value for
automatic redirection or MAY ask the user to confirm a choice.
The choices SHOULD also be listed as Location fields (Section 6.18). However, this specification does not define any standard for such
Unlike HTTP, the SIP response may contain several Location fields. automatic selection.
User agents MAY use the Location field value for automatic
redirection or MAY ask the user to confirm a choice. This header is appropriate if the callee can be reached at
several different locations and the server cannot or
prefers not to proxy the request.
7.3.2 301 Moved Permanently 7.3.2 301 Moved Permanently
The requesting client should retry on the new address given by the The user can no longer be found at the address in the Request-URI and
Location field because the user has permanently moved and the address the requesting client should retry at the new address given by the
this response is in reply to is no longer a current address for the Location header field (Section 6.25). The caller SHOULD update any
user. A 301 response MUST NOT suggest any of the hosts in the Via local directories, address books and user location caches with this
(Section 6.33) path of the request as the user's new location. new value and redirect future requests to the address(es) listed.
7.3.3 302 Moved Temporarily 7.3.3 302 Moved Temporarily
The requesting client should retry on the new address(es) given by The requesting client should retry the request at the new address(es)
the Location header. A 302 response MUST NOT suggest any of the hosts given by the Location header field (Section 6.25). The duration of
in the Via (Section 6.33) path of the request as the user's new the redirection can be indicated through an Expires (Section 6.20)
location. The duration of the redirection can be indicated through header.
an Expires (Section 6.16) 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.
7.3.5 381 Ambiguous
The callee address provided in the request was ambiguous. The
response MAY contain a listing of possible unambiguous addresses in
Location headers.
Revealing alternatives may infringe on privacy concerns of the user
or the organization. It MUST be possible to configure a server to
respond with status 404 (Not Found) or to suppress the listing of
possible choices if the request address was ambiguous.
Example response to a request with the URL lee@example.com :
381 Ambiguous SIP/2.0
Location: carol.lee@example.com (Carol Lee)
Location: p.lee@example.com (Ping Lee)
Location: lee.foote@example.com (Lee M. Foote)
Some email and voice mail systems provide this
functionality. A status code separate from 300 is used
since the semantics are different: for 300, it is assumed
that the same person or service will be reached by the
choices provided. While an automated choice or sequential
search makes sense for a 300 response, user intervention is
required for a 381 response.
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 may be successful. same request to a different server may 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.
skipping to change at page 47, line 4 skipping to change at page 61, line 37
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. the domain specified in the Request-URI. This status is also
returned if the domain in the Request-URI does not match any of the
domains handled by the recipient of the request.
7.4.6 405 Method Not Allowed 7.4.6 405 Method Not Allowed
The method specified in the Request-Line is not allowed for the The method specified in the Request-Line is not allowed for the
address identified by the Request-URI. The response MUST include an address identified by the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the indicated Allow header containing a list of valid methods for the indicated
address. address.
7.4.7 407 Proxy Authentication Required 7.4.7 407 Proxy Authentication Required
This code is similar to 401 (Unauthorized), but indicates that the This code is similar to 401 (Unauthorized), but indicates that the
client MUST first authenticate itself with the proxy. The proxy MUST client MUST first authenticate itself with the proxy. The proxy MUST
return a Proxy-Authenticate header field (section 6.21) containing a return a Proxy-Authenticate header field (section 6.29) containing a
challenge applicable to the proxy for the requested resource. The challenge applicable to the proxy for the requested resource. The
client MAY repeat the request with a suitable Proxy-Authorization client MAY repeat the request with a suitable Proxy-Authorization
header field (section 6.22). SIP access authentication is explained header field (section 6.30). SIP access authentication is explained
in section [H11]. in section 12.3 and [H11].
This status code should be used for applications where access to the This status code should be used for applications where access to the
communication channel (e.g., a telephony gateway) rather than the communication channel (e.g., a telephony gateway) rather than the
callee herself requires authentication. callee herself requires authentication.
7.4.8 408 Request Timeout 7.4.8 408 Request Timeout
The client did not produce a request within the time that the server The server could not produce a response, e.g., a user location,
was prepared to wait. The client MAY repeat the request without within the time indicated in the request via the Expires header.
modifications at any later time. The client MAY repeat the request without modifications at any later
time.
7.4.9 420 Bad Extension 7.4.9 412 Precondition Failed
The server did not understand the protocol extension specified with The precondition given in one or more of the request-header fields
strength "must". evaluated to false when it was tested on the server. Preconditions
include If-Match (Section 6.23) and If-None-Match (Section 6.24).
7.4.10 480 Temporarily Unavailable 7.4.10 420 Bad Extension
The server did not understand the protocol extension specified in a
Require (Section 6.32) header field.
7.4.11 480 Temporarily Unavailable
The callee's end system was contacted successfully but the callee is The callee's end system was contacted successfully but the callee is
currently unavailable (e.g., not logged in or logged in in such a currently unavailable (e.g., not logged in or logged in in such a
manner as to preclude communication with the callee). The response manner as to preclude communication with the callee). The response
may indicate a better time to call in the Retry-After header. The may indicate a better time to call in the Retry-After header. The
user may also be available elsewhere (unbeknownst to this host), user may also be available elsewhere (unbeknownst to this host),
thus, this response does not terminate any searches. The reason thus, this response does not terminate any searches. The reason
phrase SHOULD indicate the more precise cause as to why the callee is phrase SHOULD indicate the more precise cause as to why the callee is
unavailable. This value SHOULD be setable by the user agent. unavailable. This value SHOULD be setable by the user agent.
7.4.11 481 Invalid Call-ID 7.4.12 481 Invalid Call-ID
The server received a BYE or ACK request with a Call-ID value it
does not recognize.
7.4.12 482 Loop Detected The server received a BYE or CANCEL request with a Call-ID (Section
6.12 value it does not recognize. (A server simply discards an ACK
with an invalid Call-ID.)
7.4.13 482 Loop Detected
The server received a request with a Via path containing itself. The server received a request with a Via path containing itself.
7.4.14 483 Too Many Hops
The server received a request that contains more Via entries (hops)
than allowed by the Max-Forwards header field.
7.4.15 484 Address Incomplete
The server received a request with a To address or Request-URI that
was incomplete. Additional information should be provided.
This status code allows overlapped dialing.
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 SHOULD 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.
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
The server, while acting as a gateway or proxy, received an invalid The server, while acting as a gateway or proxy, received an invalid
response from the upstream server it accessed in attempting to response from the downstream server it accessed in attempting to
fulfill the request. fulfill the request.
7.5.4 503 Service Unavailable 7.5.4 503 Service Unavailable
The server is currently unable to handle the request due to a The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server. The implication temporary overloading or maintenance of the server. The implication
is that this is a temporary condition which will be alleviated after is that this is a temporary condition which will be alleviated after
some delay. If known, the length of the delay may be indicated in a some delay. If known, the length of the delay may be indicated in a
Retry-After header. If no Retry-After is given, the client SHOULD Retry-After header. If no Retry-After is given, the client MUST
handle the response as it would for a 500 response. handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish to server has to use it when becoming overloaded. Some servers may wish
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 upstream server (e.g., a location server) it response from the server (e.g., a location server) it accessed in
accessed in attempting to complete the request. attempting to complete the request.
7.5.6 505 Version Not Supported
The server does not support, or refuses to support, the SIP protocol
version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request
using the same major version as the client, other than with this
error message. The response SHOULD contain an entity describing why
that version is not supported and what other protocols are supported
by that server.
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 7.6.1 600 Busy
The callee's end system was contacted successfully but the callee is The callee's end system was contacted successfully but the callee is
busy and does not wish to take the call at this time. The response busy and does not wish to take the call at this time. The response
may indicate a better time to call in the Retry-After header. If the may indicate a better time to call in the Retry-After header. If the
callee does not wish to reveal the reason for declining the call, the callee does not wish to reveal the reason for declining the call, the
callee should use status code 680 instead. callee should use status code 603 (Decline) instead.
7.6.2 603 Decline 7.6.2 603 Decline
The callee's machine was successfully contacted but the user The callee's machine was successfully contacted but the user
explicitly does not wish to participate. The response may indicate a explicitly does not wish to or cannot participate. The response may
better time to call in the Retry-After header. indicate a better time to call in the Retry-After header.
7.6.3 604 Does not exist anywhere 7.6.3 604 Does Not Exist Anywhere
The server has authoritative information that the user indicated in The server has authoritative information that the user indicated in
the To request field does not exist anywhere. Searching for the user the To request field does not exist anywhere. Searching for the user
elsewhere will not yield any results. elsewhere will not yield any results.
7.6.4 606 Not Acceptable 7.6.4 606 Not Acceptable
The user's agent was contacted successfully but some aspects of the The user's agent was contacted successfully but some aspects of the
session profile (the requested media, bandwidth, or addressing style) session description such as the requested media, bandwidth, or
were not acceptable. addressing style were not acceptable.
A "606 Not Acceptable" reply means that the user wishes to A 606 (Not Acceptable) response means that the user wishes to
communicate, but cannot adequately support the session described. The communicate, but cannot adequately support the session described. The
"606 Not Acceptable" reply MAY contain a list of reasons in a Warning 606 (Not Acceptable) response MAY contain a list of reasons in a
header describing why the session described cannot be supported. Warning header describing why the session described cannot be
These reasons can be one or more of: supported. These reasons can be one or more of:
606.1 Insufficient Bandwidth: The bandwidth specified in the session 606.1 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.
606.2 Incompatible Protocol: One or more protocols described in the 606.2 Incompatible Protocol: One or more protocols described in the
request are not available. request are not available.
606.3 Incompatible Format: One or more media formats described in the 606.3 Incompatible Format: One or more media formats described in the
request is not available. request is not available.
606.4 Multicast not available: The site where the user is located 606.4 Multicast Not Available: The site where the user is located
does not support multicast. does not support multicast.
606.5 Unicast not available: The site where the user is located does 606.5 Unicast Not Available: The site where the user is located does
not support unicast communication (usually due to the presence not support unicast communication (usually due to the presence
of a firewall). of a firewall).
Other reasons are likely to be added later. It is hoped that Other reasons are likely to be added later. It is hoped that
negotiation will not frequently be needed, and when a new user is negotiation will not frequently be needed, and when a new user is
being invited to join a pre-existing lightweight session, negotiation being invited to join an already existing conference, negotiation may
may not be possible. It is up to the invitation initiator to decide not be possible. It is up to the invitation initiator to decide
whether or not to act on a "606 Not Acceptable" reply. whether or not to act on a 606 (Not Acceptable) response.
8 SIP Message Body 8 SIP Message Body
The session description body gives details of the session the user is
being invited to join. Its Internet media type MUST be given by the
Content-type header field, and the body length in bytes MUST be given
by the Content-Length header field. If the body has undergone any
encoding (such as compression) then this MUST be indicated by the
Content-encoding header field, otherwise Content-encoding MUST be
omitted.
8.1 Body Inclusion 8.1 Body Inclusion
For a request message, the presence of a body is signaled by the For a request message, the presence of a body is signaled by the
inclusion of a Content-Length header. A body may be included in a inclusion of a Content-Length header. Only ACK, INVITE, OPTIONS
request only when the request method allows one. and REGISTER requests may contain message bodies. For ACK, INVITE
and OPTIONS, the message body is always a session description. The
use of message bodies for REGISTER requests is for further study.
For response messages, whether or not a body is included is dependent For response messages, whether or not a body is included is dependent
on both the request method and the response message's response code. on both the request method and the response message's response code.
All 1xx informational responses MUST NOT include a body. All other All responses MAY include a body, although it may be of zero length.
responses MAY include a payload, although it may be of zero length. Message bodies for 1xx responses contain advisory information about
the progress of the request, 2xx responses contain session
descriptions; for responses with status 300 or greater, the session
body MAY contain additional, human-readable information about the
reasons for failure. It is RECOMMENDED that information in 1xx and
300 and greater responses be of type text/plain or text/html
8.2 Message Body Length 8.2 Message Body Type
If no body is present in a message, then the Content-Length header The Internet media type of the message body MUST be given by the
MAY be omitted or set to zero. When a body is included, its length in Content-Type header field, If the body has undergone any encoding
bytes is indicated in the Content-Length header and is determined by (such as compression) then this MUST be indicated by the Content-
one of the following: Encoding header field, otherwise Content-Encoding MUST be omitted.
1. Any response message which MUST NOT include a body (such as If applicable, the character set of the message body is indicated as
the 1xx responses) is always terminated by the first empty part of the Content-Type header-field value.
line after the header fields, regardless if any entity-
header fields are present.
2. Otherwise, a Content-Length header MUST be present (this 8.3 Message Body Length
requirement differs from HTTP/1.1). Its value in bytes
represents the length of the message body. The body length in bytes MUST be given by the Content-Length header
field. If no body is present in a message, then the Content-Length
header MUST set to zero. If a server receives a message without
Content-Length, it MUST assume it to be zero.
The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
(Note: The chunked encoding modifies the body of a message in order (Note: The chunked encoding modifies the body of a message in order
to transfer it as a series of chunks, each with its own size to transfer it as a series of chunks, each with its own size
indicator.) indicator.)
9 Examples 9 Compact Form
9.1 Invitation to Multimedia Conference
The first example invites schooler@vlsi.cs.caltech.edu to a multicast
session.
9.1.1 Request
C->S: INVITE schooler@vlsi.cs.caltech.edu SIP/2.0
Via: SIP/2.0/UDP 239.128.16.254 16
Via: SIP/2.0/UDP 131.215.131.131
Via: SIP/2.0/UDP 128.16.64.19
From: mjh@isi.edu (Mark Handley)
Subject: SIP will be discussed, too
To: schooler@cs.caltech.edu (Eve Schooler)
Call-ID: 62729-27@oregon.isi.edu
Content-type: application/sdp
CSeq: 4711
Content-Length: 187
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0
The Via fields list the hosts along the path from invitation
initiator (the first element of the list) towards the invitee. In the
example above, the message was last multicast to the administratively
scoped group 239.128.16.254 with a ttl of 16 from the host
131.215.131.131
The request header above states that the request was initiated by
mjh@isi.edu the host 128.16.64.19 schooler@cs.caltech.edu is being
invited; the message is currently being routed to
schooler@vlsi.cs.caltech.edu
In this case, the session description is using the Session
Description Protocol (SDP), as stated in the Content-type header.
The header is terminated by an empty line and is followed by a
message body containing the session description.
9.1.2 Reply
The called user agent, directly or indirectly through proxy servers,
indicates that it is alerting ("ringing") the called party:
S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 239.128.16.254 16
Via: SIP/2.0/UDP 131.215.131.131
Via: SIP/2.0/UDP 128.16.64.19 1
From: mjh@isi.edu
Call-ID: 62729-27@128.16.64.19
Location: sip://es@jove.cs.caltech.edu
CSeq: 4711
A sample reply to the invitation is given below. The first line of
the reply states the SIP version number, that it is a "200 OK" reply,
which means the request was successful. The Via headers are taken
from the request, and entries are removed hop by hop as the reply
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 taken
directly from the original request, along with the remaining fields
of the request message. The original sense of From field is
preserved (i.e., it is the session initiator).
In addition, the Location header gives details of the host where the
user was located, or alternatively the relevant proxy contact point
which should be reachable from the caller's host.
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP 239.128.16.254 16
Via: SIP/2.0/UDP 131.215.131.131
Via: SIP/2.0/UDP 128.16.64.19 1
From: mjh@isi.edu
To: schooler@cs.caltech.edu
Call-ID: 62729-27@128.16.64.19
Location: sip://es@jove.cs.caltech.edu
CSeq: 4711
The caller confirms the invitation by sending a request to the
location named in the Location header:
C->S: ACK schooler@jove.cs.caltech.edu SIP/2.0
From: mjh@isi.edu
To: schooler@cs.caltech.edu
Call-ID: 62729-27@128.16.64.19
CSeq: 4711
9.2 Two-party Call
A two-party call proceeds as above. The only difference is
For two-party Internet phone calls, the response must contain a
description of where to send data to. In the example below, Bell
calls Watson. Bell indicates that he can receive RTP audio codings 0
(PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4).
C->S: INVITE watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: a.g.bell@bell-telephone.com (A. Bell)
To: watson@bell-telephone.com (T. A. Watson)
Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here.
Content-type: application/sdp
Content-Length: ...
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
c=IN IP4 135.180.144.94
m=audio 3456 RTP/AVP 0 3 4 5
S->C: SIP/2.0 200 OK
From: a.g.bell@bell-telephone.com (A. Bell)
To: watson@bell-telephone.com
Call-ID: 187602141351@worcester.bell-telephone.com
Location: sip://watson@boston.bell-telephone.com
Content-Length: ...
v=0
o=watson 4858949 4858949 IN IP4 192.1.2.3
c=IN IP4 135.180.161.25
m=audio 5004 RTP/AVP 0 3
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
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
port 5004 at 135.180.161.25.
9.3 Aborting a Call
If the caller wants to abort a pending call, it sends a BYE request.
C->S: BYE schooler@jove.cs.caltech.edu
From: mjh@isi.edu
To: schooler@cs.caltech.edu
Call-ID: 62729-27@128.16.64.19
9.3.1 Redirects
Replies with status codes "301 Moved Permanently" or "302 Moved
Temporarily" SHOULD specify another location using the Location
field.
S->C: SIP/2.0 302 Moved temporarily
Via: SIP/2.0/UDP 131.215.131.131
Via: SIP/2.0/UDP 128.16.64.19
From: mjh@isi.edu
To: schooler@cs.caltech.edu
Call-ID: 62729-27@128.16.64.19
Location: sip://239.128.16.254;ttl=16;transport=udp
Content-length: 0
In this example, the proxy located at 131.215.131.131 is being
advised to contact the multicast group 239.128.16.254 with a ttl of
16 and UDP transport. In normal situations, a server would not
suggest a redirect to a local multicast group unless, as in the above
situation, it knows that the previous proxy or client is within the
scope of the local group. If the request is redirected to a multicast
group, a proxy server SHOULD query the multicast address itself
rather than sending the redirect back towards the client as multicast
may be scoped; this allows a proxy within the appropriate scope
regions to make the query.
9.3.2 Alternative Services
An example of a "350 Alternative Service" reply is:
S->C: SIP/2.0 350 Alternative Service
Via: SIP/2.0/UDP 131.215.131.131
Via: SIP/2.0/UDP 128.16.64.19
From: mjh@isi.edu
To: schooler@cs.caltech.edu
Call-ID: 62729-27@128.16.64.19
Location: recorder@131.215.131.131
Content-type: application/sdp
Content-length: 146
v=0
o=mm-server 2523535 0 IN IP4 131.215.131.131
s=Answering Machine
i=Leave an audio message
c=IN IP4 131.215.131.131
t=0 0
m=audio 12345 RTP/AVP 0
In this case, the answering server provides a session description
that describes an "answering machine". If the invitation initiator
decides to take advantage of this service, it should send an
invitation request to the answering machine at 131.215.131.131 with
the session description provided (modified as appropriate for a
unicast session to contain the appropriate local address and port for
the invitation initiator). This request SHOULD contain a different
Call-ID from the one in the original request. An example would be:
C->S: INVITE mm-server@131.215.131.131 SIP/2.0
Via: SIP/2.0/UDP 128.16.64.19
From: mjh@isi.edu
To: schooler@cs.caltech.edu
Call-ID: 62729-28@128.16.64.19
Content-type: application/sdp
Content-length: 146
v=0
o=mm-server 2523535 0 IN IP4 131.215.131.131
s=Answering Machine
i=Leave an audio message
c=IN IP4 128.16.64.19
t=0 0
m=audio 26472 RTP/AVP 0
Invitation initiators MAY choose to treat a "350 Alternative Service"
reply as a failure if they wish to do so.
9.3.3 Negotiation
An example of a "606 Not Acceptable" reply is:
S->C: SIP/2.0 606 Not Acceptable
From: mjh@isi.edu
To: schooler@cs.caltech.edu
Call-ID:62729-27@128.16.64.19
Location: mjh@131.215.131.131
Warning: 606.1 Insufficient bandwidth (only have ISDN),
606.3 Incompatible format,
606.4 Multicast not available
Content-Type: application/sdp
Content-Length: 50
v=0
s=Lets talk
b=CT:128
c=IN IP4 131.215.131.131
m=audio 3456 RTP/AVP 7 0 13
m=video 2232 RTP/AVP 31
In this example, the original request specified 256 kb/s total
bandwidth, and the reply states that only 128 kb/s is available. The
original request specified GSM audio, H.261 video, and WB whiteboard.
The audio coding and whiteboard are not available, but the reply
states that DVI, PCM or LPC audio could be supported in order of
preference. The reply also states that multicast is not available.
In such a case, it might be appropriate to set up a transcoding
gateway and re-invite the user.
9.4 OPTIONS Request
A caller Alice can use an OPTIONS request to find out the
capabilities of a potential callee Bob, without "ringing" the
designated address. In this case, Bob indicates that he can be
reached at three different addresses, ranging from voice-over-IP to a
PSTN phone to a pager.
C->S: OPTIONS bob@example.com SIP/2.0
From: alice@anywhere.org (Alice)
To: bob@example.com (Bob)
Accept: application/sdp
S->C: SIP/2.0 200 OK
Location: sip://bob@host.example.com ;service=IP,voice-mail
;media=audio ;duplex=full ;q=0.7
Location: phone://1-415-555-1212 ; service=ISDN;mobility=fixed;
language=en,es,iw ;q=0.5
Location: phone://1-800-555-1212 ; service=pager;mobility=mobile;
duplex=send-only;media=text; q=0.1
Alternatively, Bob could have returned a description of
C->S: OPTIONS bob@example.com SIP/2.0
From: alice@anywhere.org (Alice)
To: bob@example.com (Bob)
Accept: application/sdp
S->C: SIP/2.0 200 OK
Content-Length: 81
Content-Type: application/sdp
v=0
m=audio 0 RTP/AVP 0 1 3 99
m=video 0 RTP/AVP 29 30
a:rtpmap:98 SX7300/8000
10 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
reply is larger than the MTU. To reduce this problem, a more compact response is larger than the MTU. To reduce this problem, a more
form of SIP is also defined by using alternative names for common compact form of SIP is also defined by using alternative names for
header fields. These short forms are NOT abbreviations, they are common header fields. These short forms are NOT abbreviations, they
field names. No other abbreviations are allowed. 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
l Content-Length l Content-Length
m Location from "moved" m Location from "moved"
s Subject s Subject
t To t To
v Via v Via
Thus the header in section 14.2 could also be written:
Thus the header in section 9.1 could also be written:
INVITE schooler@vlsi.caltech.edu SIP/2.0 INVITE schooler@vlsi.caltech.edu SIP/2.0
v:SIP/2.0/UDP 239.128.16.254 16 v:SIP/2.0/UDP 239.128.16.254 16
v:SIP/2.0/UDP 131.215.131.131 v:SIP/2.0/UDP 131.215.131.131
v:SIP/2.0/UDP 128.16.64.19 v:SIP/2.0/UDP 128.16.64.19
f:mjh@isi.edu f:mjh@isi.edu
t:schooler@cs.caltech.edu t:schooler@cs.caltech.edu
i:62729-27@128.16.64.19 i:62729-27@128.16.64.19
c:application/sdp c:application/sdp
l:187 l:187
skipping to change at page 58, line 46 skipping to change at page 67, line 30
e=mbone@somewhere.com e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127 c=IN IP4 224.2.0.1/127
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
Mixing short field names and long field names is allowed, but not Mixing short field names and long field names is allowed, but not
recommended. Servers MUST accept both short and long field names for recommended. Servers MUST accept both short and long field names for
requests. Proxies MUST NOT translate a request between short and long requests. Proxies MUST NOT translate a request between short and long
forms if authentication fields are present. forms if authentication fields are present.
11 SIP Transport 10 SIP Transport
SIP is defined so it can use either UDP or TCP as a transport
protocol.
11.1 Achieving Reliability For UDP Transport 10.1 General Remarks
11.1.1 General Operation SIP is defined so it can use either UDP (unicast or multicast) or TCP
as a transport protocol; it provides its own reliability mechanism.
SIP assumes no additional reliability from IP. Requests or replies 10.1.1 Requests
may be lost. A SIP client SHOULD simply retransmit a SIP request
periodically with timer T1 (default value of T1: once a second) until
it receives a response, or until it has reached a set limit on the
number of retransmissions. The default limit is 20.
SIP requests and replies are matched up by the client using the Stateful proxies mark outgoing requests with the branch parameter in
Call-ID header field; thus, a server can only have one outstanding the Via header.
request per call at any given time.
If the reply is a provisional response, the initiating client SHOULD Servers ignore isomorphic requests, but retransmit the appropriate
continue retransmitting the request, albeit less frequently, using response. (SIP requests are said to be idempotent , i.e., receiving
timer T2. The default retransmission interval T2 is 5 seconds. more than one copy of a request does not change the server state.)
After the server sends a final response, it cannot be sure the client If a stateful proxy, user agent or redirect server cannot respond to
has received the response, and thus SHOULD cache the results for at a request with a final response within 200 ms, it MUST issue a
least 30 seconds to avoid having to, for example, contact the user or provisional (1xx) response as soon as possible. Stateless proxies
user location server again upon receiving a retransmission. MUST NOT issue provisional responses on their own.
11.1.2 INVITE After receiving a CANCEL request from an upstream client, a stateful
proxy server SHOULD send a CANCEL on all branches where it has not
yet received a final response.
10.1.2 Responses
Responses are mapped to requests by the matching To, From, Call-ID,
CSeq headers and the branch parameter of the first Via header.
Responses terminate request retransmissions even if they have Via
headers that cause them to be delivered to an upstream client.
A stateful proxy may receive a response that it does not have state
for, that is, where it has no a record of an isomorphic request. If
the Via header field indicates that the upstream server used TCP, the
proxy actively opens a TCP connection to that address. Thus, proxies
have to be prepared to receive responses on the incoming side of
passive TCP connections, even though most responses will arrive on
the incoming side of an active connection. (An active connection is a
TCP connection initiated by the proxy, a passive connection is one
accepted by the proxy, but initiated by another entity.)
100 responses are not forwarded, other 1xx responses MAY be
forwarded, possibly after the server eliminates responses with status
codes that had already been sent earlier. 2xx responses are forwarded
according to the Via header. Once a stateful proxy has received a
2xx response, it MUST NOT forward non-2xx final responses. Responses
with status 300 and higher are retransmitted by each stateful proxy
until the next upstream proxy sends an ACK (see below for timing
details) or CANCEL.
A stateful proxy can remove state for a call attempt and close any
connections 20 seconds after receiving the first final response.
The 20 second window is given by the maximum retransmission
duration of 200 responses (10 times T4), in case the ACK
is lost somewhere on the way to the called user agent or
the next stateful proxy.
10.2 Unicast UDP
UDP packets MUST have a source address that is valid as a destination
for requests and responses. Responses are returned to the address
listed in the Via header field (Section 6.43), not the source
address of the request.
10.3 Multicast UDP
Requests may be multicast. Multicast requests SHOULD have a time-to-
live value of no greater than one, i.e., be restricted to the local
network.
If the request was received via multicast, the response is also
returned via multicast. The server delays its response by a random
interval between zero and one second. Servers do not return 404 (Not
Found) responses and SHOULD suppress responses if they hear a lower-
numbered or 6xx response from another group member prior to sending.
Servers do not respond to CANCEL requests received via multicast.
10.4 BYE, CANCEL, OPTIONS
A SIP client SHOULD retransmit a BYE, CANCEL, or OPTIONS request
periodically with timer T1 until it receives a response, or until it
has reached a set limit on the number of retransmissions. If the
response is provisional, the client continues to retransmit the
request, albeit less frequently, using timer T2. The default values
of timer T1 and T2 are 1 and 5 seconds, respectively. The default
retransmit limit is 20 times. 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 100 seconds to avoid
having to, for example, contact the user or user location server
again upon receiving a retransmission.
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.5 seconds. 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 should consist of one
request and a few responses, round-trip time estimation
seems less than helpful. 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.39), 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.5 REGISTER
A client MAY repeat its registration attempts at intervals of 2, 4,
8, ..., 512, 512, ... seconds if it receives no response.
Retransmitting REGISTER indefinitely ensures that a user
will eventually be able to register after a registrar
recovers from a crash. The period is chosen so that even on
a large LAN, there will not be more than about one
REGISTER request per second.
10.6 ACK
The ACK request does not generate responses. It is only
retransmitted when a response to an INVITE request arrives.
10.7 INVITE
Special considerations apply for the INVITE method. Special considerations apply for the INVITE method.
1. After receiving an invitation, considerable time may elapse 1. After receiving an invitation, considerable time may elapse
before the server can determine the outcome. For example, before the server can determine the outcome. For example,
the called party may be "rung" or extensive searches may be the called party may be "rung" or extensive searches may be
performed, so delays between the request and a definitive performed, so delays between the request and a definitive
response can reach several tens of seconds. If either response can reach several tens of seconds. If either
caller or callee are automated servers not directly caller or callee are automated servers not directly
controlled by a human being, a call attempt may be controlled by a human being, a call attempt may be
unbounded in time. unbounded in time.
It is undesirable to retransmit the INVITE request, as this 2. If a telephony user interface is modeled or if we need to
introduces additional network traffic. The retransmission interface to the PSTN, the caller's user interface will
interval would have to be no more than about a second, since the provide "ringback", a signal that the callee is being
callee would encounter a "dead" voice path if the "200 OK" alerted. (The status response 180 (Trying) may be used to
response is lost. initiate ringback.) Once the callee picks up, the caller
needs to know so that it can enable the voice path and stop
ringback. The callee's response to the invitation could get
lost. Unless the response is transmitted reliably, the
caller will continue to hear ringback while the callee
assumes that the call exists.
2. It is possible that the invitation request reaches the 3. The client has to be able to terminate an on-going request,
callee and the callee is willing to take the call, but that e.g., because it is no longer willing to wait for the
the final response (200 OK, in this case) is lost on the connection or search to succeed. The server will have to
way to the caller. If the session still exists but the wait several round-trip times to interpret the lack of
initiator gives up on including the user, the contacted request retransmissions as the end of a call. If the call
user has sufficient information to be able to join the succeeds shortly after the caller has given up, the callee
session. However, if the session no longer exists because will "pick up the phone" and not be "connected".
the invitation initiator "hung up" before the reply arrived
and the session was to be two-way, the conferencing system
should be prepared to deal with this circumstance.
3. If a telephony user interface is modeled or if we need to A SIP client SHOULD retransmits a SIP INVITE request periodically
interface to the PSTN, the caller will provide "ringback", with timer T1 until it receives a response, or until it has reached a
a signal that the callee is being alerted. Once the callee set limit on the number of retransmissions. If the response is
picks up, the caller needs to know so that it can enable provisional, the client continues to retransmit the request, albeit
the voice path and stop ringback. The callee's response to less frequently, using timer T3. The default values of timer T1 and
the invitation could get lost. Unless the response is T3 are 1 and 30 seconds, respectively. The default retransmit limit
transmitted reliably, the caller will continue to hear is 20.
ringback while the callee assumes that the call exists.
4. The client has to be able to terminate an on-going request, The value of T3 was chosen so that for most normal phone
e.g., because it is no longer willing to wait for the calls, only one INVITE request will be issued. Typically,
connection or search to succeed. One cannot rely on the a phone switches to an answering machine or voice mail
absence of request retransmission, since the server would after about 20--22 seconds.
have to continue honoring the request for several request
retransmission periods, that is, possible tens of seconds
if only one or two packets can be lost.
The first problem is solved by indicating progress to the caller: the Upon receiving a final response, the client sends an ACK to the
server returns a provisional response indicating it is searching or address listed in the Location header field contained in the
ringing the user. response. The To header field in the ACK request assumes the value
of the Location header field. If the response did not contain a
Location header, the client uses the same To header field as for the
INVITE request and sends the ACK to the same destination as the
original INVITE request.
The second and third problems are solved by having the server The server retransmits the final response at intervals of T4 (default
retransmit the final response at intervals of T3 (default value of T3 value of T4 = 2 seconds) until it receives an ACK request for the
= 2 seconds) until it receives an ACK request for the same Call-ID same Call-ID and CSeq from the same From source or until it has
and CSeq or until it has retransmitted the final response 10 times. retransmitted the final response 10 times. The ACK request MUSTNOT be
The ACK request is acknowledged only once. If the request is acknowledged to prevent a response- ACK feedback loop.
syntactically valid and the Request-URI matches that in the INVITED
request with the same Call-ID, the server answers with status code
200, otherwise with status code 400.
Fig. 8 and 9 show the client and server state diagram for Fig. 8 and 9 show the client and server state diagram for
invitations. invitations.
11.2 Connection Management for TCP Using the mechanism in Sec. 10.4 does not work well for the
long delays between INVITE and a final response. If the
200 response gets 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.
Blindly retransmitting the response increases the probability of
success, but at the cost of significantly higher processing and
network load.
10.8 TCP Connections
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
exactly one final response. one or more final responses. (Typically, transactions contain exactly
one final response, but there are exceptional circumstances, where,
+===========+ +===========+
| Initial | | Initial |
+===========+ +===========+
| |
| |
| - | -
| ------ | ------
| INVITE | INVITE
+------v v +------v v
T1 +-----------+ T1 +-----------+
------ | Calling |--------+ ------ | Calling |--------+
INVITE +-----------+ | INVITE +-----------+ |
+------| | | | +------| | | |
+----------------+ | | +----------------+ | |
| | 1xx | >= 200 | | 1xx | >= 200
| | --- | ------ | | --- | ------
| | - | ACK | | - | ACK
| | | | | |
| +------v v v-----| | | +------v v v-----| |
| T2 +-----------+ 1xx | | T3 +-----------+ 1xx |
| ------ | Ringing | --- | | ------ | Ringing | --- |
| INVITE +-----------+ - | | INVITE +-----------+ - |
| +------| | |-----+ | | +------| | |-----+ |
| | | | | |
| 2xx | | | 2xx | |
| --- | 2xx | | --- | 2xx |
| ACK | --- | | ACK | --- |
| | ACK | | | ACK |
+----------------+ | | +----------------+ | |
+------v | v | +------v | v |
skipping to change at page 61, line 46 skipping to change at page 72, line 45
--- | Completed |<-------+ --- | Completed |<-------+
ACK +-----------+ ACK +-----------+
+------| +------|
event event
------- -------
message message
Figure 8: State transition diagram of client for INVITE method Figure 8: State transition diagram of client for INVITE method
The client MAY close the connection at any time. Closing the for example, multiple 200 responses may be generated.)
connection before receiving a final response signals that the client
wishes to abort the request.
After sending an INVITE request, the client keeps the connection
open until the first final response arrives. If that response has a
+===========+ +===========+
| Initial |<-------------+ | Initial |<-------------+
+===========+ | +===========+ |
| | | |
| | | |
| INVITE | | INVITE |
| ------ | | ------ |
| 1xx | | 1xx |
+------v v | +------v v |
INVITE +-----------+ | INVITE +-----------+ |
------ | Searching | | ------ | Searching | |
1xx +-----------+ | 1xx +-----------+ |
+------| | | +---------------->+ +------| | | +---------------->+
| | | | | |
failure | | callee picks up | failure | | callee picks up |
------- | | --------------- | ------- | | --------------- |
>= 300 | | 200 | >= 300 | | 200 |
| | | BYE | | | BYE
+------v v v v-----| | --- +------v v v v-----| | ---
INVITE +-----------+ T3 | 200 INVITE +-----------+ T4 | 200
------ | Answered | ------ | ------ | Answered | ------ |
status +-----------+ status | status +-----------+ status |
+------| | | |-----+ | +------| | | |-----+ |
| +---------------->+ | +---------------->+
| | | |
| ACK | | ACK |
| --- | | --- |
| 200 | | - |
| | | |
+------v v | +------v v |
ACK +-----------+ | ACK +-----------+ |
--- | Connected | | --- | Connected | |
200 +-----------+ | - +-----------+ |
+------| | | +------| | |
+-----------------+ +-----------------+
event event
------- -------
message message
Figure 9: State transition diagram of server for INVITE method Figure 9: State transition diagram of server for INVITE method
The server SHOULD NOT close the TCP connection until it has sent its status code of 300 or larger, the client sends an ACK. If the
final response, at which point it MAY close the TCP connection if it response status code is 2xx and the client is a user agent client, it
wishes to. However, normally it is the client's responsibility to sends an ACK. If the client is not a user agent, the response is
close the connection. forwarded upstream.
The client MAY close the connection at any time. The server SHOULD
NOT close the TCP connection until it has sent its final response, at
which point it MAY close the TCP connection if it wishes to. However,
normally it is the client's responsibility to close the connection.
If the server leaves the connection open, and if the client so 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).
12 Behavior of SIP Servers If a server needs to return a response to a client and no longer has
a connection open to that client, it MAY open a connection to the
address listed in the Via header. Thus, a proxy MUST be prepared to
receive both requests and responses on a "passive" connection.
11 Behavior of SIP Servers
This section describes behavior of a SIP server in detail. Servers This section describes behavior of a SIP server in detail. Servers
can operate in proxy or redirect mode. Proxy servers can "fork" can operate in proxy or redirect mode. Proxy servers can "fork"
connections, i.e., a single incoming request spawns several outgoing connections, i.e., a single incoming request spawns several outgoing
(client) requests. (client) requests.
A proxy server always inserts a Via header field containing its own A proxy server always inserts a Via header field containing its own
address into those requests that are caused by an incoming request. address into those requests that are caused by an incoming request.
To prevent loops, a server MUST check if its own address is already Each proxy MUST insert a " branch" parameter (Section 6.43). To
prevent loops, a server MUST check if its own address is already
contained in the Via header of the incoming request. contained in the Via header of the incoming request.
A proxy server MAY convert a version-x SIP request or response to a
version-y request or response, where x may be larger, smaller or
equal to y.
This rule allows a proxy to serve as a go-between between
two servers that have no version of the protocol in common.
We define an "A--B proxy" as a proxy that receives SIP requests over We define an "A--B proxy" as a proxy that receives SIP requests over
transport protocol A and issues requests, acting as a SIP client, transport protocol A and issues requests, acting as a SIP client,
using transport protocol B. If not stated explicitly, rules apply to using transport protocol B. If not stated explicitly, rules apply to
any combination of transport protocols. For conciseness, we only any combination of transport protocols. For conciseness, we only
describe behavior with UDP and TCP, but the same rules apply for any describe behavior with UDP and TCP, but the same rules apply for any
unreliable datagram or reliable protocol, respectively. unreliable datagram or reliable protocol, respectively.
The detailed connection behavior for UDP and TCP is described in The detailed connection behavior for UDP and TCP is described in
Section 11. Section 10.
12.1 Redirect Server
11.1 Redirect Server
A redirect server does not issue any SIP requests of its own. It can A redirect server does not issue any SIP requests of its own. It can
return a response that refuses or redirects the request. After return a response that refuses or redirects the request. After
receiving an INVITE request, a redirect server proceeds through the receiving an INVITE request, once the server has gathered the list
following steps: of alternative locations or has decided to refuse the call, it
returns the final response of class 3xx or 6xx. This ends the SIP
1. If the INVITE request cannot be answered immediately transaction. The redirect server maintains transaction state for the
(e.g., because a location server needs to be contacted), it whole SIP transaction.
returns one or more provisional responses.
2. Once the server has gathered the list of alternative
locations or has decided to refuse the call, it returns the
final response. This ends the SIP transaction.
The redirect server maintains transaction state for the whole SIP 11.2 User Agent Server
transaction.
12.2 User Agent Server User agent servers behave similarly to redirect servers, except that
Servers in user agents behave similarly to redirect servers, except they may also accept a call with a response of class 2xx.
that they may also accept a call.
12.3 Proxies Issuing Single Unicast Requests 11.3 Stateless Proxy: Proxy Servers Issuing Single Unicast Requests
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.
Servers may choose to always operate in the mode described in Section However, servers may choose to always operate in a mode that allows
12.4. issuing of several requests, as described in Section 11.4.
The server can forward the request and any responses. It does not The server can forward the request and any responses. It does not
have to maintain any state for the SIP transaction. Reliability is have to maintain any state for the SIP transaction. Reliability is
assured by the next redirect server in the server chain. assured by the next redirect or stateful proxy server in the server
chain.
A proxy server SHOULD cache the result of any address translations A proxy server SHOULD cache the result of any address translations
and the response to speed forwarding. After the cache entry has been and the response to speed forwarding of retransmissions. After the
expired, the server cannot tell whether an incoming request is cache entry has been expired, the server cannot tell whether an
actually a retransmission of an older request, where the TCP side has incoming request is actually a retransmission of an older request.
terminated. It will treat it as a new request. The server will treat it as a new request and commence another
search.
12.4 Proxy Server Issuing Several Requests 11.4 Proxy Server Issuing Several INVITE Requests
The server MUST respond to the request immediately with a 100
(Trying) response.
All requests carry the same Call-ID. For unicast, each of the All requests carry the same Call-ID. For unicast, each of the
requests has a different (host-dependent) Request-URI. For requests has a different (host-dependent) Request-URI. For
multicast, a single request is issued, likely with a host-independent multicast, a single request is issued, likely with a host-independent
Request-URI. A client receiving a multicast query does not have to Request-URI. A client receiving a multicast query does not have to
check whether the host part of the Request-URI matches its own host check whether the host part of the Request-URI matches its own host
or domain name. To avoid response implosion, servers SHOULD NOT or domain name. To avoid response implosion, servers MUST NOT answer
answer multicast requests with a 404 (Not Found) status code. multicast requests with a "404 Not Found" status code. Servers MAY
Servers MAY decide not to answer multicast requests if their response decide not to answer multicast requests if their response would be
would be 5xx. 5xx. Responses to multicast requests are multicast with the same TTL
as the request, where the TTL is derived from the ttl parameter in
the Via header (Section 6.43).
The server MAY respond to the request immediately with a "100 Trying" Successful responses to an INVITE request SHOULD contain a Location
or "180 Ringing" response; otherwise it MAY wait until either the header so that the following ACK or BYE bypasses the proxy search
first response to its requests or the UDP retransmission interval. mechanism. If the proxy requires future requests to be routed through
it, it adds a Record-Route header to the request (Section 6.33).
The following pseudo-code describes the behavior of a proxy server The following pseudo-code describes the behavior of a proxy server
issuing several requests in response to an incoming request. The issuing several requests in response to an incoming INVITE request.
function request(r, a) sends a SIP request r to address a. The function request(r, a, b) sends a SIP request of type r to
await_response() waits until a response is received and returns the address a, with branch id b. await_response() waits until a response
response. close(a) closes the TCP connection to client with address is received and returns the response. close(a) closes the TCP
a. response(s, l, L) sends a response to the client with status s and connection to client with address a. response(s, l, L) sends a
list of locations L, with l entries. ismulticast() returns 1 if the response to the client with status s and list of locations L, with l
location is a multicast address and zero otherwise. The variable entries. ismulticast() returns 1 if the location is a multicast
timeleft indicates the amount of time left until the maximum response address and zero otherwise. The variable timeleft indicates the
time has expired. The variable recurse indicates whether the server amount of time left until the maximum response time has expired. The
will recursively try addresses returned through a 3xx response. A variable recurse indicates whether the server will recursively try
server MAY decide to recursively try only certain addresses, e.g., addresses returned through a 3xx response. A server MAY decide to
those which are within the same domain as the proxy server. Thus, an recursively try only certain addresses, e.g., those which are within
initial multicast request may trigger additional unicast requests. the same domain as the proxy server. Thus, an initial multicast
request may trigger additional unicast requests.
enum {INVITE, /* request type */ /* request type */
ACK, OPTIONS, BYE, REGISTER, UNREGISTER} R; typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method;
int N = 0; /* number of connection attempts */
address_t address[]; /* list of addresses */ process_request(Method R, int N, address_t address[])
{
struct {
address_t address; /* address */
int branch; /* branch id */
int done; /* has responded */
} outgoing;
int done[]; /* address has responded */ int done[]; /* address has responded */
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 best = 1000; /* best response so far */ int best = 1000; /* best response so far */
int timeleft = 120; /* sample timeout value */ int timeleft = 120; /* sample timeout value */
int loc = 0; /* number of locations */ int loc = 0; /* number of locations */
struct { /* response */ struct { /* response */
int status; /* response status */ int status; /* response status; -2: BYE; -1: CANCEL */
char *location; /* redirect locations */ char *location; /* redirect location */
address_t a; /* address of respondent */ address_t a; /* address of respondent */
int branch; /* branch identifier */
} r; } r;
int i; int i;
if (multicast) {
request(R, address[0]);
} else {
N = /* number of addresses to try */
for (i = 0; i < N; i++) { for (i = 0; i < N; i++) {
request(R, address[i]); request(R, address[i], i);
done[i] = 0; outgoing[i].done = 0;
} outgoing[i].branch = i;
} }
while (timeleft > 0 && (heard < N || multicast)) { while (timeleft > 0 && heard < N) {
r = await_response(); r = await_response();
class = r.status / 100; class = r.status / 100;
if (r.status < 0) {
break;
}
if (class >= 2) { if (class >= 2) {
heard++; heard++;
for (i = 0; i < N; i++) { for (i = 0; i < N; i++) {
if (address[i] == r.a) { if (r.branch == outgoing.branch[i]) {
done[i] = 1; outgoing[i].done = 1;
break; break;
} }
} }
} }
if (class == 2) { if (class == 2) {
best = r.status; best = r.status;
break; break;
} }
else if (class == 3) { else if (class == 3) {
skipping to change at page 66, line 23 skipping to change at page 77, line 48
if (recurse) { if (recurse) {
multicast = 0; multicast = 0;
N++; N++;
request(R, r.location); request(R, r.location);
} else if (!ismulticast(r.location)) { } else if (!ismulticast(r.location)) {
locations[loc++] = r.location; locations[loc++] = r.location;
best = r.status; best = r.status;
} }
} }
else if (class == 4) { else if (class == 4) {
request(ACK, r.a, r.branch);
if (best >= 400) best = r.status; if (best >= 400) best = r.status;
} }
else if (class == 5) { else if (class == 5) {
request(ACK, r.a, r.branch);
if (best >= 500) best = r.status; if (best >= 500) best = r.status;
} }
else if (class == 6) { else if (class == 6) {
request(ACK, r.a, r.branch);
best = r.status; best = r.status;
break; break;
} }
} }
/* CANCEL or BYE */
if (r.status < 0) {
response(200, loc, 0);
/* BYE */
if (r.status == -2) {
for (i = 0; i < N; i++) {
request(BYE, address[i], i);
}
}
}
else {
/* We haven't heard anything useful from anybody. */ /* We haven't heard anything useful from anybody. */
if (best == 1000) { if (best == 1000) {
best = 404; best = 404;
} }
if (best/100 != 3) loc = 0; if (best/100 != 3) loc = 0;
response(best, loc, locations); response(best, loc, locations);
}
/* /*
* Close the other pending transactions by sending BYE. * Close the other pending transactions by sending CANCEL.
*/ */
if (r.status > -1) {
for (i = 0; i < N; i++) { for (i = 0; i < N; i++) {
if (!done[i]) { if (!outgoing[i].done) {
request(BYE, address[i]); request(CANCEL, address[i], outgoing[i].branch);
if (tcp) close(a); if (tcp) close(a);
} }
} }
}
}
Responses are processed as follows. The process completes when all
requests have been answered by final status responses (for unicast)
or 60 seconds have elapsed (for multicast). A proxy MAY send a
CANCEL to all branches and return a 408 (Timeout) to the client after
120 seconds or more.
1xx: The proxy MAY forward the response upstream towards the client.
2xx: The proxy MUST forward the response upstream towards the client,
without sending an ACK downstream.
3xx: The proxy MUST send an ACK and MAY recurse on the listed
Location addresses. Otherwise, the locations in the response are
added to separate lists for 300, 301 and 302 responses
maintained by the proxy. The lowest-numbered 300 response is
returned to the client on completion.
4xx, 5xx: The proxy MUST send an ACK and remember the response if it
has a lower status code than any previous 4xx and 5xx responses.
On completion, the lowest-numbered response is returned if there
were no 2xx or 3xx responses.
6xx: The proxy MUST forward the response to the client and send an
ACK. Other pending requests SHOULD be terminated with CANCEL.
The proxy server must maintain state until all responses have been
received or for 60 seconds if the request was multicast.
After receiving a 2xx or 6xx response, the server SHOULD terminate After receiving a 2xx or 6xx response, the server SHOULD terminate
all other pending requests by sending a BYE request and closing the all other pending requests by sending a CANCEL request and closing
TCP connection, if applicable. (Terminating pending requests is the TCP connection, if applicable. (Terminating pending requests is
advisable as searches consume resources. Also, INVITE requests may advisable as searches consume resources. Also, INVITE requests may
"ring" on a number of workstations if the callee is currently logged "ring" on a number of workstations if the callee is currently logged
in more than once.) in more than once.)
[TBD: How do we cancel multicast requests? Force receivers to listen
for a 200/6xx response and hope that they don't miss one?]
When operating in this mode, a proxy server MUST ignore any responses When operating in this mode, a proxy server MUST ignore any responses
received for Call-IDs that it does not have a pending transaction received for Call-IDs for which it does not have a pending
for. (If server were to forward responses not belonging to a current transaction. (If server were to forward responses not belonging to a
transaction using the Via field, the requesting client would get current transaction using the Via field, the requesting client would
confused if it has just issued another request using the same Call- get confused if it has just issued another request using the same
ID.) Call-ID.)
13 Third-Party Call Initiation If a proxy server receives a BYE request for a pending search or the
TCP connection initiating the search is closed by the upstream
client, the proxy server SHOULD terminate all pending requests by
sending a BYE request and closing the TCP connections, if applicable.
In some circumstances, third-party call control is required, where 11.5 Proxy Server Issuing Several ACK and BYE Requests
the calling party suggests to the called party to invite a (small)
number of other parties. Third-party call control can be used to
implement the following features:
Multipoint-control unit (MCU): Some conferences use a multipoint In most cases, ACK and BYE requests will bypass proxies and reach
control unit to mix, convert and replicate media streams. While the desired party directly, keeping proxies from having to make
this solution has scaling problems, it is widely deployed in forwarding decisions.
traditional telephony and ISDN conferencing settings, as so-
called conference bridges. In a MCU-based conference, the
conference initiator or any authorized member invites a new
participant and indicate the address of the MCU in the Also
header. The invitee then contacts the MCU using the same session
description and requests to be added to the call, just like a
normal two-party call.
Telephony call initiation ("click-to-call"): A SIP INVITE request User agent clients respond to ACK and BYE requests with unknown
containing two addresses in the Also header is sent to a PSTN Call-ID with status code 481 (Invalid Call-ID).
service node that connects these two addresses by a telephone
call.
Fully-meshed small conference: For small conferences, such as adding A proxy MAY maintain call state for a period of its choosing. If a
a third party to a two-party call, multicast may not always be proxy still has list of destinations that it forwarded the last
appropriate or available. Instead, when inviting a new INVITE to, it SHOULD direct ACK requests only to those downstream
participant, the caller asks the new member to call the servers. It SHOULD direct BYE to only those servers that had
remaining members. TBD: Should the call-id be the same or previously responded with 2xx or have not yet responded to the last
different? Need to distinguish between new INVITE for same call INVITE.
and adding a party to a call. Include conference identifier?
TBD: How about just transferring an SDP description with multiple
addresses?
The Also: header (Section 6.9) is used to indicate a list of parties If the proxy has no call state for a particular Call-ID and To
that the callee should invite. destination, it forwards the request to all downstream servers.
14 ISDN and Intelligent Network Services 12 Security Considerations
SIP may be used to support a number of ISDN [27] and Intelligent 12.1 Confidentiality and Privacy: Encryption
Network [28] telephony services, described below. Due to the
fundamental differences between Internet-based telephony and
conferencing as compared to public switched telephone network
(PSTN)-based services, service definitions cannot be precisely the
same. Where large differences beyond addressing and location of
implementation exist, this is indicated below. The term address
implies any SIP address. (Section 1.4.1).
Call transfer (TRA) enables a user to transfer an established (i.e., 12.1.1 SIP Transactions
active) call to a third party. SIP signals this via the Location
header in the BYE (Section 4.2.4) method.
Call forwarding (CF) permits the called user to forward particular SIP transactions can contain sensitive information about the
pre-selected calls to another address. Unlike telephony, the communication patterns and communication content of individuals and
choice of calls to be forwarded depends on program logic thus should be protected against eavesdropping. The SIP message body
contained in any of the SIP servers and can thus be made may also contain encryption keys for the session itself.
dependent on time-of-day, subject of call, media types, urgency
or caller identity, rather than being restricted to matching
list entries. This forwarding service encompasses:
Call forwarding busy/don't answer (CFB/CFNR, SCF-BY/DA) allows the SIP supports three complementary forms of encryption to protect
called user to forward particular pre-selected calls if the privacy:
called user is busy or does not answer within a set time.
Selective call forwarding (SCF) permits the user to have her incoming o End-to-end encryption of the SIP message body and certain
calls addressed to another network destination, no matter what sensitive header fields;
the called party status is, if the calling address is included
in, or excluded from, a screening list. The user's originating
service is unaffected.
Completion of calls to busy subscriber (CCBS) allows a calling user o hop-by-hop encryption to prevent eavesdropping that tracks who
encountering a busy destination to be informed when the busy is calling whom;
destination becomes free, without having to make a new call
attempt. SIP supports services close to CCBS by allowing a
callee to indicate a more opportune time to call back (Section
6.25). Also, calling and called user agents can easily record
the URL of outcoming and incoming calls, so that a user can re-
try or return calls with a single mouse click.
Conferencing (CON) allows the user to communicate simultaneously with o hop-by-hop encryption of Via fields to hide the route a
multiple parties, which may also communicate among themselves. request has taken.
SIP can initiate IP multicast conferences with any number of
participants, conferences where media are mixed by a conference
bridge (multipoint control unit or MCU) and, for exceptional
applications with a small number of participants, fully-meshed
conferences, where each participant sends and receives data to
all other participants.
Conference calling add-on allows a user to add and drop participants Not all of the SIP request can be encrypted end-to-end because header
once the conference is active. fields such as To and Via need to be visible to proxies so that the
SIP request can be routed correctly. Hop-by-hop encryption encrypts
the entire SIP request or response on the wire (the request may
already have been end-to-end encrypted) so that packet sniffers or
other eavesdroppers cannot see who is calling whom. Note that proxies
can still see who is calling whom, and this information may also be
deducible by performing a network traffic analysis, so this provides
a very limited but still worthwhile degree of protection.
Conference calling meet-me (MMC) allows the user to set up a SIP Via fields are used to route a response back along the path
conference or multi-party call, indicating the date, time, taken by the request and to prevent infinite request loops. However,
conference duration, conference media and other parameters. The the information given by them may also provide useful information to
conference session description included in the SIP invitation an attacker. Section 6.22 describes how a sender can request that Via
may indicate a time in the future. For multicast conferences, fields be encrypted by cooperating proxies without compromising the
participants do not have to connect using SIP at the actual time purpose of the Via field.
of the conference; instead, they simply subscribe to the
multicast addresses listed in the announcement. For MCU-based
conferences, the session description may contain the address of
the MCU to be called at the time of the conference.
Destination call routing (DCR) allows customers to specify the 12.2 End-to-End Encryption
routing of their incoming calls to destinations according to
-time of day, day of week, etc.; End-to-end encryption relies on keys shared by the two user agents
involved in the transaction. Typically, the message is sent encrypted
with the public key of the recipient, so that only that recipient can