draft-ietf-mmusic-sip-11.txt   draft-ietf-mmusic-sip-12.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft Handley/Schulzrinne/Schooler/Rosenberg Internet Draft Handley/Schulzrinne/Schooler/Rosenberg
ietf-mmusic-sip-11.txt ISI/Columbia U./Caltech/Bell Labs. ietf-mmusic-sip-12.txt ISI/Columbia U./Caltech/Bell Labs.
December 15, 1998 January 15, 1999
Expires: June 1999 Expires: July 1999
SIP: Session Initiation Protocol SIP: Session Initiation Protocol
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress''. material or to cite them other than as ``work in progress''.
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
ABSTRACT ABSTRACT
The Session Initiation Protocol (SIP) is an application- The Session Initiation Protocol (SIP) is an application-
layer control (signaling) protocol for creating, layer control (signaling) protocol for creating,
modifying and terminating sessions with one or more modifying and terminating sessions with one or more
participants. These sessions include Internet multimedia participants. These sessions include Internet multimedia
skipping to change at page 7, line 41 skipping to change at page 7, line 41
(Section 1.4.4). Instead of directly reaching the intended callee, a (Section 1.4.4). Instead of directly reaching the intended callee, a
SIP request may be redirected or may trigger a chain of new SIP SIP request may be redirected or may trigger a chain of new SIP
requests by proxies (Section 1.4.5). Users can register their requests by proxies (Section 1.4.5). Users can register their
location(s) with SIP servers (Section 4.2.6). location(s) with SIP servers (Section 4.2.6).
1.4.1 SIP Addressing 1.4.1 SIP Addressing
The "objects" addressed by SIP are users at hosts, identified by a The "objects" addressed by SIP are users at hosts, identified by a
SIP URL. The SIP URL takes a form similar to a mailto or telnet URL, SIP URL. The SIP URL takes a form similar to a mailto or telnet URL,
i.e., user@host. The user part is a user name or a telephone number. i.e., user@host. The user part is a user name or a telephone number.
The host part is either a domain name having a DNS SRV (RFC 2052 The host part is either a domain name or a numeric network address.
[14]), CNAME or A record (RFC 1035 [15]), or a numeric network See section 2 for a detailed discussion of SIP URL's.
address. See section 2 for a detailed discussion of SIP URL's.
A user's SIP address can be obtained out-of-band, can be learned via A user's SIP address can be obtained out-of-band, can be learned via
existing media agents, can be included in some mailers' message existing media agents, can be included in some mailers' message
headers, or can be recorded during previous invitation interactions. headers, or can be recorded during previous invitation interactions.
In many cases, a user's SIP URL can be guessed from their email In many cases, a user's SIP URL can be guessed from their email
address. address.
A SIP URL address can designate an individual (possibly located at A SIP URL address can designate an individual (possibly located at
one of several end systems), the first available person from a group one of several end systems), the first available person from a group
of individuals or a whole group. The form of the address, for of individuals or a whole group. The form of the address, for
skipping to change at page 8, line 27 skipping to change at page 8, line 27
can reject unauthorized or undesired call attempts. can reject unauthorized or undesired call attempts.
1.4.2 Locating a SIP Server 1.4.2 Locating a SIP Server
When a client wishes to send a request, the client either sends it to When a client wishes to send a request, the client either sends it to
a locally configured SIP proxy server (as in HTTP), independent of a locally configured SIP proxy server (as in HTTP), independent of
the Request-URI, or sends it to the IP address and port corresponding the Request-URI, or sends it to the IP address and port corresponding
to the Request-URI. to the Request-URI.
For the latter case, the client must determine the protocol, port and For the latter case, the client must determine the protocol, port and
IP address of a server to send the request to. A client SHOULD follow IP address of a server to which to send the request. A client SHOULD
the steps below to obtain this information. At each step, unless follow the steps below to obtain this information, but MAY follow the
stated otherwise, the client SHOULD try to contact a server at the alternative, optional procedure defined in Appendix D. At each step,
port number listed in the Request-URI. If no port number is present unless stated otherwise, the client SHOULD try to contact a server at
in the Request-URI, the client uses port 5060. If the Request-URI the port number listed in the Request-URI. If no port number is
specifies a protocol (TCP or UDP), the client contacts the server present in the Request-URI, the client uses port 5060. If the
using that protocol. If no protocol is specified, the client tries Request-URI specifies a protocol (TCP or UDP), the client contacts
UDP (if UDP is supported), and if the attempt fails, then tries TCP the server using that protocol. If no protocol is specified, the
(if TCP is supported). client tries UDP (if UDP is supported). If the attempt fails, or if
the client doesn't support UDP but supports TCP, it then tries TCP.
The client tries to find one or more addresses for the server by
querying DNS. There are several different ways it may query DNS, and
these are listed in the steps below. If a step elicits no addresses,
the client SHOULD continue to the next step. However if a step
elicits one or more addresses, but no SIP server at any of those
addresses responds, then the client concludes the server is down and
SHOULD NOT continue on to the next step.
1. If the host portion of the Request-URI is an IP address,
the client contacts the server at the given address. If the
host portion of the Request-URI is not an IP address, the
client proceeds to the next step.
2. An implementation MAY use the experimental procedure in
Appendix D at this step. This step relies on DNS SRV
records, which are currently experimental and may change
before being published as a standard. If this step is used,
and no servers are returned in the DNS query, the client
proceeds to the next step.
3. The client queries the name server for CNAME records with A client SHOULD be able to interpret explicit network notifications
the QNAME=sip.host, where host is the host portion of the (such as ICMP messages) which indicate that a server is not
Request-URI, as described in RFC 2219 [16]. For each reachable, rather than relying solely on timeouts. (For socket-based
address in the answer, the client attempts to contact a programs: For TCP, connect() returns ECONNREFUSED if the client could
server at that address. If, however, there were no CNAME not connect to a server at that address. For UDP, the socket needs to
records, the client goes to the next step. be bound to the destination address using connect() rather than
sendto() or similar so that a second write() fails with ECONNREFUSED
if there is no server listening) If the client finds the server is
not reachable at a particular address, it SHOULD behave as if it had
received a 400-class error response to that request.
4. The client queries the name server for A records with the The client tries to find one or more addresses for the SIP server by
QNAME=sip.host, where host is the host portion of the querying DNS. The procedure is as follows:
Request-URI, as described in RFC 2219 [16]. For each
address in the answer, the client attempts to contact a
server at that address. If, however, there were no A
records, the client goes to the next step.
5. The client queries the name server for CNAME records for 1. If the host portion of the Request-URI is an IP address,
the host portion of the Request-URI. For each address in the client contacts the server at the given address.
the answer, the client attempts to contact a server at that Otherwise, the client proceeds to the next step.
address. If, however, there were no CNAME records, the
client goes to the next step.
6. The client queries the name server for A records for the 2. The client queries the DNS server for address records for
host portion of the Request-URI. For each address in the the host portion of the Request-URI. If the DNS server
answer, the client attempts to contact a server at that returns no address records, the client stops, as it has
address. If there were no A records, the client stops, as been unable to locate a server. By address record, we mean
it has been unable to locate a server. A RR's, AAAA RR's, or other similar address records, chosen
according to the client's network protocol capabilities.
A client SHOULD rely on explicit network notifications to determine There are no mandatory rules on how to select a host name
that a server is not reachable, rather than relying on timeouts. In for a SIP server. Users are encouraged to name their SIP
particular, a client SHOULD be prepared to receive ICMP port, servers using the sip.domainname (i.e., sip.example.com)
protocol, or host unreachable messages as a form of explicit convention, as specified in RFC 2219 [16]. Users may only
notifications, and MAY be prepared to process other messages. (For know an email address instead of a full SIP URL for a
socket-based programs: For TCP, connect() returns ECONNREFUSED if the callee, however. In that case, implementations may be able
client could not connect to a server at that address. For UDP, the to increase the likelihood of reaching a SIP server for
socket needs to be bound to the destination address using connect() that domain by constructing a SIP URL from that email
rather than sendto() or similar so that a second write() fails with address by prefixing the host name with "sip.". In the
ECONNREFUSED if there is no server listening) If the client finds the future, this mechanism is likely to become unnecessary as
server is not reachable at a particular address, it SHOULD behave as better DNS techniques, such as the one in Appendix D,
if it had received a 400-class error response to that request. become widely available.
A client MAY cache a successful DNS query result. A successful query A client MAY cache a successful DNS query result. A successful query
is one which contained records in the answer, and a server was is one which contained records in the answer, and a server was
contacted at one of the addresses from the answer. When the client contacted at one of the addresses from the answer. When the client
wishes to send a request to the same host, it MUST start the search wishes to send a request to the same host, it MUST start the search
as if it had just received this answer from the name server. The as if it had just received this answer from the name server. The
client MUST expire the cache entry after the DNS time-to-live value client MUST follow the procedures in RFC1035 [15] regarding DNS cache
has elapsed. If the client does not find a SIP server among the invalidation when the DNS time-to-live expires.
addresses listed in the cached answer, it MUST start the search at
the beginning of the sequence described above.
For example, consider a client which wishes to send a SIP request.
The Request-URI for the destination is sip:user@company.com. The
client only supports UDP. It would follow these steps:
1. The host portion is not an IP address, so the client goes
to step 2 above.
2. The client decides to implement the optional SRV record
step. The client does a DNS query of
QNAME="sip.udp.company.com", QCLASS=IN, QTYPE=SRV. Since it
doesn't support TCP, it omits the TCP query. There were no
addresses in the DNS response, so the client goes to the
next step.
3. The client does a DNS query of QNAME="sip.company.com",
QCLASS=IN, QTYPE=CNAME. There were no addresses in the DNS
response. The client therefore goes to the next step.
4. The client does a DNS query of QNAME="sip.company.com",
QCLASS=IN, QTYPE=A. There is one answer. The client tries
that address using UDP at port 5060, and succeeds at
delivering the request.
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 requwwests 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. All responses to a request contain the same values in transaction. All responses to a request contain the same values in
the Call-ID, CSeq, To, and From fields (with the possible addition of the Call-ID, CSeq, To, and From fields (with the possible addition of
a tag in the To field (section 6.37)). This allows responses to be a tag in the To field (section 6.37)). This allows responses to be
matched with requests. The ACK request following an INVITE is not matched with requests. The ACK request following an INVITE is not
part of the transaction since it may traverse a different set of part of the transaction since it may traverse a different set of
hosts. 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
skipping to change at page 14, line 4 skipping to change at page 13, line 9
response to receiving the invitation request, it is possible that a response to receiving the invitation request, it is possible that a
client is reached, independently, by more than one copy of the client is reached, independently, by more than one copy of the
invitation request. Each of these copies bears the same Call-ID. The invitation request. Each of these copies bears the same Call-ID. The
user agent MUST return the same status response returned in the first user agent MUST return the same status response returned in the first
response. Duplicate requests are not an error. response. Duplicate requests are not an error.
1.4.6 Changing an Existing Session 1.4.6 Changing an Existing Session
In some circumstances, it is desirable to change the parameters of an In some circumstances, it is desirable to change the parameters of an
existing session. This is done by re-issuing the INVITE, using the existing session. This is done by re-issuing the INVITE, using the
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@lab : ( work ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( lab ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+
====> SIP request
....> SIP response
^
| non-SIP protocols
|
Figure 2: Example of SIP redirect server
same Call-ID, but a new or different body or header fields to convey same Call-ID, but a new or different body or header fields to convey
the new information. This re INVITE MUST have a higher CSeq than any the new information. This re INVITE MUST have a higher CSeq than any
previous request from the client to the server. previous request from the client to the server.
For example, two parties may have been conversing and then want to For example, two parties may have been conversing and then want to
add a third party, switching to multicast for efficiency. One of the add a third party, switching to multicast for efficiency. One of the
participants invites the third party with the new multicast address participants invites the third party with the new multicast address
and simultaneously sends an INVITE to the second party, with the new and simultaneously sends an INVITE to the second party, with the new
multicast session description, but with the old call identifier. multicast session description, but with the old call identifier.
skipping to change at page 15, line 49 skipping to change at page 14, line 5
perform parallel searches without requiring TCP connection state for perform parallel searches without requiring TCP connection state for
each outstanding request, and to use multicast. Routers can more each outstanding request, and to use multicast. Routers can more
readily snoop SIP UDP packets. TCP allows easier passage through readily snoop SIP UDP packets. TCP allows easier passage through
existing firewalls. existing firewalls.
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.
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@lab : ( work ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( lab ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+
====> SIP request
....> SIP response
^
| non-SIP protocols
|
Figure 2: Example of SIP redirect server
For concreteness, this document will only refer to Internet For concreteness, this document will only refer to Internet
protocols. However, SIP MAY also be used directly with protocols protocols. However, SIP MAY also be used directly with protocols
such as ATM AAL5, IPX, frame relay or X.25. The necessary naming such as ATM AAL5, IPX, frame relay or X.25. The necessary naming
conventions are beyond the scope of this document. User agents SHOULD conventions are beyond the scope of this document. User agents SHOULD
implement both UDP and TCP transport. Proxy, registrar, and redirect implement both UDP and TCP transport. Proxy, registrar, and redirect
servers MUST implement both UDP and TCP transport. servers MUST implement both UDP and TCP transport.
1.5.3 Text-Based 1.5.3 Text-Based
SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This
skipping to change at page 16, line 47 skipping to change at page 16, line 5
escaped and that the "set of characters reserved within any given URI escaped and that the "set of characters reserved within any given URI
component is defined by that component. In general, a character is component is defined by that component. In general, a character is
reserved if the semantics of the URI changes if the character is reserved if the semantics of the URI changes if the character is
replaced with its escaped US-ASCII encoding" [12]. replaced with its escaped US-ASCII encoding" [12].
The URI character classes referenced above are described in Appendix The URI character classes referenced above are described in Appendix
C. C.
The components of the SIP URI have the following meanings. The components of the SIP URI have the following meanings.
user: If the host is an Internet telephony gateway, the user field
MAY also encode a telephone number using the notation of
SIP-URL = "sip:" [ userinfo "@" ] hostport SIP-URL = "sip:" [ userinfo "@" ] hostport
url-parameters [ headers ] url-parameters [ headers ]
userinfo = user [ ":" password ] userinfo = user [ ":" password ]
user = *( unreserved | escaped user = *( unreserved | escaped
| ";" | "&" | "=" | "+" | "$" | "," ) | "&" | "=" | "+" | "$" | "," )
password = *( unreserved | escaped password = *( unreserved | escaped
| ";" | "&" | "=" | "+" | "$" | "," ) | "&" | "=" | "+" | "$" | "," )
hostport = host [ ":" port ] hostport = host [ ":" port ]
host = hostname | IPv4address host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ] hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum toplabel = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit port = *digit
url-parameters = *( ";" url-parameter ) url-parameters = *( ";" url-parameter )
url-parameter = transport-param | user-param | method-param url-parameter = transport-param | user-param | method-param
| ttl-param | maddr-param | other-param | ttl-param | maddr-param | other-param
skipping to change at page 17, line 41 skipping to change at page 16, line 42
header = hname "=" hvalue header = hname "=" hvalue
hname = 1*uric hname = 1*uric
hvalue = *uric hvalue = *uric
uric = reserved | unreserved | escaped uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | "," "$" | ","
digits = 1*DIGIT digits = 1*DIGIT
Figure 3: SIP URL syntax Figure 3: SIP URL syntax
user: If the host is an Internet telephony gateway, the user field
MAY also encode a telephone number using the notation of
telephone-subscriber (Fig. 4). The telephone number is a special telephone-subscriber (Fig. 4). The telephone number is a special
case of a user name and cannot be distinguished by a BNF. Thus, case of a user name and cannot be distinguished by a BNF. Thus,
a URL parameter, user, is added to distinguish telephone numbers a URL parameter, user, is added to distinguish telephone numbers
from user names. The phone identifier is to be used when from user names. The phone identifier is to be used when
connecting to a telephony gateway. Even without this parameter, connecting to a telephony gateway. Even without this parameter,
recipients of SIP URLs MAY interpret the pre-@ part as a phone
number if local restrictions on the name space for user name
telephone-subscriber = global-phone-number | local-phone-number telephone-subscriber = global-phone-number | local-phone-number
global-phone-number = "+" 1*phonedigit [isdn-subaddress] global-phone-number = "+" 1*phonedigit [isdn-subaddress]
[post-dial] [post-dial]
local-phone-number = 1*(phonedigit | dtmf-digit | local-phone-number = 1*(phonedigit | dtmf-digit |
pause-character) [isdn-subaddress] pause-character) [isdn-subaddress]
[post-dial] [post-dial]
isdn-subaddress = ";isub=" 1*phonedigit isdn-subaddress = ";" "isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit | dtmf-digit post-dial = ";" "postd=" 1*(phonedigit | dtmf-digit
| pause-character) | pause-character)
phonedigit = DIGIT | visual-separator phonedigit = DIGIT | visual-separator
visual-separator = "-" | "." visual-separator = "-" | "."
pause-character = one-second-pause | wait-for-dial-tone pause-character = one-second-pause | wait-for-dial-tone
one-second-pause = "p" one-second-pause = "p"
wait-for-dial-tone = "w" wait-for-dial-tone = "w"
dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D"
Figure 4: SIP URL syntax; telephone subscriber Figure 4: SIP URL syntax; telephone subscriber
recipients of SIP URLs MAY interpret the pre-@ part as a phone
number if local restrictions on the name space for user name
allow it. allow it.
If a server handles SIP addresses for another domain, it MUST URL-
encode the "@" character (%40). The ";" character MUST be URL-
encoded, as otherwise it is not possible to distinguish the case
host;parameter and user;moreuser@host in one parsing pass.
password: The SIP scheme MAY use the format "user:password" in the password: The SIP scheme MAY use the format "user:password" in the
userinfo field. The use of passwords in the userinfo is NOT userinfo field. The use of passwords in the userinfo is NOT
RECOMMENDED, because the passing of authentication information RECOMMENDED, because the passing of authentication information
in clear text (such as URIs) has proven to be a security risk in in clear text (such as URIs) has proven to be a security risk in
almost every case where it has been used. almost every case where it has been used.
host: The mailto: URL and RFC 822 email addresses require that host: The mailto: URL and RFC 822 email addresses require that
numeric host addresses ("host numbers") are enclosed in square numeric host addresses ("host numbers") are enclosed in square
brackets (presumably, since host names might be numeric), while brackets (presumably, since host names might be numeric), while
host numbers without brackets are used for all other URLs. The host numbers without brackets are used for all other URLs. The
skipping to change at page 20, line 4 skipping to change at page 18, line 46
Table 2 summarizes where the components of the SIP URL can be used Table 2 summarizes where the components of the SIP URL can be used
and what default values they assume if not present. and what default values they assume if not present.
Examples of SIP URLs are: Examples of SIP URLs are:
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;user=phone sip:+1-212-555-1212:1234@gateway.com;user=phone
sip:1212@gateway.com
sip:alice@10.1.2.3
default Req.-URI To From Contact external default Req.-URI To From Contact external
user -- x x x x x user -- x x x x x
password -- x x x x password -- x x x x
host mandatory x x x x x host mandatory x x x x x
port 5060 x x x x x port 5060 x x x x x
user-param ip x x x x x user-param ip x x x x x
method INVITE x x method INVITE x x
maddr-param -- x x maddr-param -- x x
ttl-param 1 x x ttl-param 1 x x
transp.-param -- x x transp.-param -- x x
headers -- x x headers -- x x
Table 2: Use and default values of URL components for SIP headers, Table 2: Use and default values of URL components for SIP headers,
Request-URI and references Request-URI and references
sip:1212@gateway.com
sip:alice@10.1.2.3
sip:alice@example.com sip:alice@example.com
sip:alice sip:alice
sip:alice@registrar.com;method=REGISTER sip:alice@registrar.com;method=REGISTER
Within a SIP message, URLs are used to indicate the source and Within a SIP message, URLs are used to indicate the source and
intended destination of a request, redirection addresses and the intended destination of a request, redirection addresses and the
current destination of a request. Normally all these fields will current destination of a request. Normally all these fields will
contain SIP URLs. contain SIP URLs.
SIP URLs are case-insensitive, so that for example the two URLs SIP URLs are case-insensitive, so that for example the two URLs
skipping to change at page 23, line 4 skipping to change at page 21, line 38
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 Request-Line = Method SP Request-URI SP SIP-Version CRLF
4.2 Methods 4.2 Methods
The methods are defined below. Methods that are not supported by a The methods are defined below. Methods that are not supported by a
proxy or redirect server are treated by that server as if they were proxy or redirect server are treated by that server as if they were
an OPTIONS method and forwarded accordingly. Methods that are not an OPTIONS method and forwarded accordingly. Methods that are not
supported by a user agent server or registrar cause a 501 (Not
Implemented) response to be returned (Section 7). As in HTTP, the
Method token is case-sensitive.
general-header = Accept ; Section 6.7 general-header = Accept ; Section 6.7
| Accept-Encoding ; Section 6.8 | Accept-Encoding ; Section 6.8
| Accept-Language ; Section 6.9 | Accept-Language ; Section 6.9
| Call-ID ; Section 6.12 | Call-ID ; Section 6.12
| Contact ; Section 6.13 | Contact ; Section 6.13
| CSeq ; Section 6.17 | CSeq ; Section 6.17
| Date ; Section 6.18 | Date ; Section 6.18
| Encryption ; Section 6.19 | Encryption ; Section 6.19
| Expires ; Section 6.20 | Expires ; Section 6.20
| From ; Section 6.21 | From ; Section 6.21
skipping to change at page 23, line 44 skipping to change at page 22, line 45
response-header = Allow ; Section 6.10 response-header = Allow ; Section 6.10
| Proxy-Authenticate ; Section 6.26 | Proxy-Authenticate ; Section 6.26
| Retry-After ; Section 6.32 | Retry-After ; Section 6.32
| Server ; Section 6.34 | Server ; Section 6.34
| Unsupported ; Section 6.38 | Unsupported ; Section 6.38
| Warning ; Section 6.41 | Warning ; Section 6.41
| WWW-Authenticate ; Section 6.42 | WWW-Authenticate ; Section 6.42
Table 3: SIP headers Table 3: SIP headers
supported by a user agent server or registrar cause a 501 (Not
Implemented) response to be returned (Section 7). As in HTTP, the
Method token is case-sensitive.
Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" Method = "INVITE" | "ACK" | "OPTIONS" | "BYE"
| "CANCEL" | "REGISTER" | "CANCEL" | "REGISTER"
4.2.1 INVITE 4.2.1 INVITE
The INVITE method indicates that the user or service is being invited The INVITE method indicates that the user or service is being invited
to participate in a session. The message body contains a description to participate in a session. The message body contains a description
of the session to which the callee is being invited. For two-party of the session to which the callee is being invited. For two-party
calls, the caller indicates the type of media it is able to receive calls, the caller indicates the type of media it is able to receive
and possibly the media it is willing to send as well as their and possibly the media it is willing to send as well as their
parameters such as network destination. A success response MUST parameters such as network destination. A success response MUST
indicate in its message body which media the callee wishes to receive indicate in its message body which media the callee wishes to receive
and MAY indicate the media the callee is going to send. and MAY indicate the media the callee is going to send.
Not all session description formats have the ability to Not all session description formats have the ability to
skipping to change at page 32, line 4 skipping to change at page 30, line 43
example, IETF, ISO, ITU-T, other international standardization example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of bodies, a consortium or a particular company or group of
companies); companies);
o A reference to a further description, if available, for o A reference to a further description, if available, for
example (in order of preference) an RFC, a published paper, a example (in order of preference) an RFC, a published paper, a
patent filing, a technical report, documented source code or a patent filing, a technical report, documented source code or a
computer manual; computer manual;
o Contact information (postal and email address); o Contact information (postal and email address);
Registrations should be sent to iana@iana.org.
This procedure has been borrowed from RTSP [4] and the RTP This procedure has been borrowed from RTSP [4] and the RTP
AVP [26]. AVP [26].
5 Response 5 Response
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with a SIP response message. The response message format is responds with a SIP response message. The response message format is
shown below: shown below:
Response = Status-Line ; Section 5.1 Response = Status-Line ; Section 5.1
skipping to change at page 35, line 4 skipping to change at page 33, line 36
SIP header fields are similar to HTTP header fields in both syntax SIP header fields are similar to HTTP header fields in both syntax
and semantics. In particular, SIP header fields follow the syntax for and semantics. In particular, SIP header fields follow the syntax for
message-header as described in [H4.2]. The rules for extending header message-header as described in [H4.2]. The rules for extending header
fields over multiple lines, and use of multiple message-header fields fields over multiple lines, and use of multiple message-header fields
with the same field-name, described in [H4.2] also apply to SIP. The with the same field-name, described in [H4.2] also apply to SIP. The
rules in [H4.2] regarding ordering of header fields apply to SIP, rules in [H4.2] regarding ordering of header fields apply to SIP,
with the exception of Via fields, see below, whose order matters. with the exception of Via fields, see below, whose order matters.
Additionally, header fields which are hop-by-hop MUST appear before Additionally, header fields which are hop-by-hop MUST appear before
any header fields which are end-to-end. Proxies SHOULD NOT reorder any header fields which are end-to-end. Proxies SHOULD NOT reorder
header fields. Proxies add Via header fields and MAY add other hop-
by-hop header fields. They can modify certain header fields, such as
Max-Forwards 6.23 and "fix up" the Via header fields with "received"
Client-Error = "400" ; Bad Request Client-Error = "400" ; Bad Request
| "401" ; Unauthorized | "401" ; Unauthorized
| "402" ; Payment Required | "402" ; Payment Required
| "403" ; Forbidden | "403" ; Forbidden
| "404" ; Not Found | "404" ; Not Found
| "405" ; Method Not Allowed | "405" ; Method Not Allowed
| "406" ; Not Acceptable | "406" ; Not Acceptable
| "407" ; Proxy Authentication Required | "407" ; Proxy Authentication Required
| "408" ; Request Timeout | "408" ; Request Timeout
| "409" ; Conflict | "409" ; Conflict
skipping to change at page 35, line 39 skipping to change at page 34, line 39
Server-Error = "500" ; Internal Server Error Server-Error = "500" ; Internal Server Error
| "501" ; Not Implemented | "501" ; Not Implemented
| "502" ; Bad Gateway | "502" ; Bad Gateway
| "503" ; Service Unavailable | "503" ; Service Unavailable
| "504" ; Gateway Time-out | "504" ; Gateway Time-out
| "505" ; SIP Version not supported | "505" ; SIP Version not supported
Figure 8: Server error status codes Figure 8: Server error status codes
header fields. Proxies add Via header fields and MAY add other hop-
by-hop header fields. They can modify certain header fields, such as
Max-Forwards 6.23 and "fix up" the Via header fields with "received"
parameters as described in Section 6.40.1. Proxies MUST NOT alter any parameters as described in Section 6.40.1. Proxies MUST NOT alter any
fields that are authenticated (see Section 13.2). fields that are authenticated (see Section 13.2).
The header fields required, optional and not applicable for each
method are listed in Table 4 and Table 5. The table uses "o" to
Global-Failure | "600" ; Busy Everywhere Global-Failure | "600" ; Busy Everywhere
| "603" ; Decline | "603" ; Decline
| "604" ; Does not exist anywhere | "604" ; Does not exist anywhere
| "606" ; Not Acceptable | "606" ; Not Acceptable
Figure 9: Global failure status codes Figure 9: Global failure status codes
The header fields required, optional and not applicable for each
method are listed in Table 4 and Table 5. The table uses "o" to
indicate optional, "m" mandatory and "-" for not applicable. A "*" indicate optional, "m" mandatory and "-" for not applicable. A "*"
indicates that the header fields are needed only if message body is indicates that the header fields are needed only if message body is
not empty. See sections 6.15, 6.16 and 8 for details. not empty. See sections 6.15, 6.16 and 8 for details.
The "where" column describes the request and response types with The "where" column describes the request and response types with
which the header field can be used. "R" refers to header fields that which the header field can be used. "R" refers to header fields that
can be used in requests (that is, request and general header fields). can be used in requests (that is, request and general header fields).
"r" designates a response or general-header field as applicable to "r" designates a response or general-header field as applicable to
all responses, while a list of numeric values indicates the status all responses, while a list of numeric values indicates the status
codes with which the header field can be used. "g" and "e" designate codes with which the header field can be used. "g" and "e" designate
skipping to change at page 37, line 5 skipping to change at page 35, line 44
header fields not defined in this specification that it does not header fields not defined in this specification that it does not
understand. A proxy MUST NOT remove or modify header fields not understand. A proxy MUST NOT remove or modify header fields not
defined in this specification that it does not understand. A compact defined in this specification that it does not understand. A compact
form of these header fields is also defined in Section 9 for use over 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 UDP when the request has to fit into a single packet and size is an
issue. issue.
Table 6 in Appendix A lists those header fields that different client Table 6 in Appendix A lists those header fields that different client
and server types MUST be able to parse. and server types MUST be able to parse.
6.1 General Header Fields
where enc. e-e ACK BYE CAN INV OPT REG where enc. e-e ACK BYE CAN INV OPT REG
__________________________________________________________ __________________________________________________________
Accept R e - - - o o o Accept R e - - - o o o
Accept 415 e - - - o o o Accept 415 e - - - o o o
Accept-Encoding R e - - - o o o Accept-Encoding R e - - - o o o
Accept-Encoding 415 e - - - o o o Accept-Encoding 415 e - - - o o o
Accept-Language R e - o o o o o Accept-Language R e - o o o o o
Accept-Language 415 e - o o o o o Accept-Language 415 e - o o o o o
Allow 200 e - - - - m - Allow 200 e - - - - m -
Allow 405 e o o o o o o Allow 405 e o o o o o o
skipping to change at page 37, line 36 skipping to change at page 36, line 35
Date g e o o o o o o Date g e o o o o o o
Encryption g n e o o o o o o Encryption g n e o o o o o o
Expires g e - - - o - o Expires g e - - - o - o
From gc n e m m m m m m From gc n e m m m m m m
Hide R n h o o o o o o Hide R n h o o o o o o
Max-Forwards R n e o o o o o o Max-Forwards R n e o o o o o o
Organization g c h - - - o o o Organization g c h - - - o o o
Table 4: Summary of header fields, A--O Table 4: Summary of header fields, A--O
6.1 General Header Fields
General header fields apply to both request and response messages. General header fields apply to both request and response messages.
The "general-header" field names can be extended reliably only in The "general-header" field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of general experimental header fields MAY be given the semantics of general
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be "general-header" fields. Unrecognized header fields are treated as be "general-header" fields. Unrecognized header fields are treated as
"entity-header" fields. "entity-header" fields.
6.2 Entity Header Fields 6.2 Entity Header Fields
The "entity-header" fields define meta-information about the The "entity-header" fields define meta-information about the
message-body or, if no body is present, about the resource identified message-body or, if no body is present, about the resource identified
by the request. The term "entity header" is an HTTP 1.1 term where by the request. The term "entity header" is an HTTP 1.1 term where
the response body can contain a transformed version of the message the response body can contain a transformed version of the message
body. The original message body is referred to as the "entity". We
retain the same terminology for header fields but usually refer to
where enc. e-e ACK BYE CAN INV OPT REG where enc. e-e ACK BYE CAN INV OPT REG
___________________________________________________________________ ___________________________________________________________________
Proxy-Authenticate 407 n h o o o o o o Proxy-Authenticate 407 n h o o o o o o
Proxy-Authorization R n h o o o o o o Proxy-Authorization R n h o o o o o o
Proxy-Require R n h o o o o o o Proxy-Require R n h o o o o o o
Priority R c e - - - o - - Priority R c e - - - o - -
Require R e o o o o o o Require R e o o o o o o
Retry-After R c e - - - - - o Retry-After R c e - - - - - o
Retry-After 404,480,486 c e o o o o o o Retry-After 404,480,486 c e o o o o o o
503 c e o o o o o o 503 c e o o o o o o
skipping to change at page 38, line 32 skipping to change at page 37, line 32
To gc(1) n e m m m m m m To gc(1) n e m m m m m m
Unsupported 420 e o o o o o o Unsupported 420 e o o o o o o
User-Agent g c e o o o o o o User-Agent g c e o o o o o o
Via gc(2) n e m m m m m m Via gc(2) n e m m m m m m
Warning r e o o o o o o Warning r e o o o o o o
WWW-Authenticate 401 c e o o o o o o WWW-Authenticate 401 c e o o o o o o
Table 5: Summary of header fields, P--Z; (1): copied with possible Table 5: Summary of header fields, P--Z; (1): copied with possible
addition of tag; (2): UAS removes first Via header field addition of tag; (2): UAS removes first Via header field
body. The original message body is referred to as the "entity". We
retain the same terminology for header fields but usually refer to
the "message body" rather then the entity as the two are the same in the "message body" rather then the entity as the two are the same in
SIP. SIP.
6.3 Request Header Fields 6.3 Request Header Fields
The "request-header" fields allow the client to pass additional The "request-header" fields allow the client to pass additional
information about the request, and about the client itself, to the information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics server. These fields act as request modifiers, with semantics
equivalent to the parameters of a programming language method equivalent to the parameters of a programming language method
invocation. invocation.
skipping to change at page 44, line 52 skipping to change at page 43, line 52
"maddr" is a multicast address, the value of "ttl" is used as "maddr" is a multicast address, the value of "ttl" is used as
the time-to-live value. the time-to-live value.
Note that the Contact header field MAY also refer to a different Note that the Contact header field MAY also refer to a different
entity than the one originally called. For example, a SIP call entity than the one originally called. For example, a SIP call
connected to GSTN gateway may need to deliver a special information connected to GSTN gateway may need to deliver a special information
announcement such as "The number you have dialed has been changed." announcement such as "The number you have dialed has been changed."
A Contact response header field can contain any suitable URI A Contact response header field can contain any suitable URI
indicating where the called party can be reached, not limited to SIP indicating where the called party can be reached, not limited to SIP
URLs. For example, it can contain a phone or fax, mailto: (RFC 2368, URLs. For example, it could contain URL's for phones, fax, or irc (if
[28]) or irc: URL. they were defined) or a mailto: (RFC 2368, [28]) URL.
The following parameters are defined. Additional parameters may be The following parameters are defined. Additional parameters may be
defined in other specifications. defined in other specifications.
q: The "qvalue" indicates the relative preference among the locations q: The "qvalue" indicates the relative preference among the locations
given. "qvalue" values are decimal numbers from 0 to 1, with given. "qvalue" values are decimal numbers from 0 to 1, with
higher values indicating higher preference. higher values indicating higher preference.
action: The "action" parameter is used only when registering with the action: The "action" parameter is used only when registering with the
REGISTER request. It indicates whether the client wishes that REGISTER request. It indicates whether the client wishes that
skipping to change at page 45, line 28 skipping to change at page 44, line 28
SHOULD indicate the mode used. This parameter is ignored for SHOULD indicate the mode used. This parameter is ignored for
other requests. other requests.
expires: The "expires" parameter indicates how long the URI is valid. expires: The "expires" parameter indicates how long the URI is valid.
The parameter is either a number indicating seconds or a quoted The parameter is either a number indicating seconds or a quoted
string containing a SIP-date. If this parameter is not provided, string containing a SIP-date. If this parameter is not provided,
the value of the Expires header field determines how long the the value of the Expires header field determines how long the
URI is valid. Implementations MAY treat values larger than URI is valid. Implementations MAY treat values larger than
2**32-1 (4294967295 or 136 years) as equivalent to 2**32-1. 2**32-1 (4294967295 or 136 years) as equivalent to 2**32-1.
Contact = ( "Contact" | "m" ) ":" Contact = ( "Contact" | "m" ) ":" ("*" | (1# ( name-addr | addr-spec )
("*" | (1# ( name-addr | addr-spec )
[ *( ";" contact-params ) ] [ comment ] )) [ *( ";" contact-params ) ] [ comment ] ))
name-addr = [ display-name ] "<" addr-spec ">" name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI addr-spec = SIP-URL | URI
display-name = *token | quoted-string display-name = *token | quoted-string
contact-params = "q" "=" qvalue contact-params = "q" "=" qvalue
| "action" "=" "proxy" | "redirect" | "action" "=" "proxy" | "redirect"
| "expires" "=" delta-seconds | <"> SIP-date <"> | "expires" "=" delta-seconds | <"> SIP-date <">
| extension-attribute | extension-attribute
skipping to change at page 64, line 44 skipping to change at page 63, line 44
additional "received" attribute, as described 6.40.2. additional "received" attribute, as described 6.40.2.
A host behind a network address translator (NAT) or A host behind a network address translator (NAT) or
firewall may not be able to insert a network address into firewall may not be able to insert a network address into
the Via header that can be reached by the next hop beyond the Via header that can be reached by the next hop beyond
the NAT. Use of the received attribute allows SIP requests the NAT. Use of the received attribute allows SIP requests
to traverse NAT's which only modify the source IP address. to traverse NAT's which only modify the source IP address.
NAT's which modify port numbers, called Network Address NAT's which modify port numbers, called Network Address
Port Translator's (NAPT) will not properly pass SIP when Port Translator's (NAPT) will not properly pass SIP when
transported on UDP, in which case an application layer transported on UDP, in which case an application layer
gateway is required. When run over TCP, SIP stands a better gateway is required. When run over TCP, SIP stands a
chance of traversing NAT's, since its port usage is better chance of traversing NAT's, since its behavior is
identical to HTTP in this case. similar to HTTP in this case (but of course on different
ports).
A proxy sending a request to a multicast address MUST add the "maddr" A proxy sending a request to a multicast address MUST add the "maddr"
parameter to its Via header field, and SHOULD add the "ttl" parameter to its Via header field, and SHOULD add the "ttl"
parameter. If a server receives a request which contained an "maddr" parameter. If a server receives a request which contained an "maddr"
parameter in the topmost Via field, it SHOULD send the response to parameter in the topmost Via field, it SHOULD send the response to
the multicast address listed in the "maddr" parameter. the multicast address listed in the "maddr" parameter.
If a proxy server receives a request which contains its own address If a proxy server receives a request which contains its own address
in the Via header value, it MUST respond with a 482 (Loop Detected) in the Via header value, it MUST respond with a 482 (Loop Detected)
status code. status code.
skipping to change at page 67, line 46 skipping to change at page 66, line 46
protocol-version = token protocol-version = token
transport = "UDP" | "TCP" | token transport = "UDP" | "TCP" | token
sent-by = ( host [ ":" port ] ) | ( concealed-host ) sent-by = ( host [ ":" port ] ) | ( concealed-host )
concealed-host = token concealed-host = token
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
Figure 11: Syntax of Via header field Figure 11: Syntax of Via header field
The "branch" parameter is included by every forking proxy. The token The "branch" parameter is included by every forking proxy. The token
MUST be unique for each distinct request generated when a proxy MUST be unique for each distinct request generated when a proxy
forks. When a response arrives at the proxy it can use the branch forks. CANCEL requests MUST have the same branch value as the
value to figure out which branch the response corresponds to. A proxy corresponding forked request. When a response arrives at the proxy
which generates a single request (non-forking) MAY also insert the it can use the branch value to figure out which branch the response
"branch" parameter. The identifier has to be unique only within a set corresponds to. A proxy which generates a single request (non-
of isomorphic requests. forking) MAY also insert the "branch" parameter. The identifier has
to be unique only within a set of isomorphic requests.
Via: SIP/2.0/UDP first.example.com:4000;ttl=16 Via: SIP/2.0/UDP first.example.com:4000;ttl=16
;maddr=224.2.0.1 (Example) ;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example)
Via: SIP/2.0/UDP adk8 Via: SIP/2.0/UDP adk8
6.41 Warning 6.41 Warning
The Warning response-header field is used to carry additional The Warning response-header field is used to carry additional
information about the status of a response. Warning headers are sent information about the status of a response. Warning headers are sent
with responses and have the following format: with responses and have the following format:
Warning = "Warning" ":" 1#warning-value Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text warning-value = warn-code SP warn-agent SP warn-text
skipping to change at page 73, line 23 skipping to change at page 72, line 25
the requesting client SHOULD retry at the new address given by the the requesting client SHOULD retry at the new address given by the
Contact header field (Section 6.13). The caller SHOULD update any Contact header field (Section 6.13). The caller SHOULD update any
local directories, address books and user location caches with this local directories, address books and user location caches with this
new value and redirect future requests to the address(es) listed. 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 the request at the new address(es) The requesting client SHOULD retry the request at the new address(es)
given by the Contact header field (Section 6.13). The duration of given by the Contact header field (Section 6.13). The duration of
the redirection can be indicated through an Expires (Section 6.20) the redirection can be indicated through an Expires (Section 6.20)
header. header. If there is no explicit expiration time, the address is only
valid for this call and MUST NOT be cached for future calls.
7.3.4 305 Use Proxy 7.3.4 305 Use Proxy
The requested resource MUST be accessed through the proxy given by The requested resource MUST be accessed through the proxy given by
the Contact field. The Contact field gives the URI of the proxy. The the Contact field. The Contact field gives the URI of the proxy. The
recipient is expected to repeat this single request via the proxy. recipient is expected to repeat this single request via the proxy.
305 responses MUST only be generated by user agent servers. 305 responses MUST only be generated by user agent servers.
7.3.5 380 Alternative Service 7.3.5 380 Alternative Service
skipping to change at page 88, line 44 skipping to change at page 88, line 5
10.6 Reliability for ACK Requests 10.6 Reliability for ACK Requests
The ACK request does not generate responses. It is only generated The ACK request does not generate responses. It is only generated
when a response to an INVITE request arrives (see Section 10.5). This when a response to an INVITE request arrives (see Section 10.5). This
behavior is independent of the transport protocol. Note that the ACK behavior is independent of the transport protocol. Note that the ACK
request MAY take a different path than the original INVITE request, request MAY take a different path than the original INVITE request,
and MAY even cause a new TCP connection to be opened in order to send and MAY even cause a new TCP connection to be opened in order to send
it. it.
10.7 ICMP Handling
Handling of ICMP messages in the case of UDP messages is
straightforward. For requests, a host, network, port, or protocol
+===========+ +===========+
* * * *
...........>* Initial *<;;;;;;;;;; ...........>* Initial *<;;;;;;;;;;
: 7 INVITE * * ; : 7 INVITE * * ;
: sent +===========+ ; : sent +===========+ ;
: | ; : | ;
: | - ; : | - ;
: | INVITE ; : | INVITE ;
: | ; : | ;
: v ; : v ;
skipping to change at page 91, line 4 skipping to change at page 90, line 4
V---* * : V---* * :
ACK * Confirmed * : ACK * Confirmed * :
|-->* * : |-->* * :
***************** . ***************** .
: : : :
:......................>: :......................>:
event event
message sent message sent
Figure 13: State transition diagram of server for INVITE method Figure 13: State transition diagram of server for INVITE method
10.7 ICMP Handling
Handling of ICMP messages in the case of UDP messages is
straightforward. For requests, a host, network, port, or protocol
unreachable error SHOULD be treated as if a 400-class response was unreachable error SHOULD be treated as if a 400-class response was
received. For responses, these errors SHOULD cause the server to received. For responses, these errors SHOULD cause the server to
cease retransmitting the response. cease retransmitting the response.
Source quench ICMP messages SHOULD be ignored. TTL exceeded errors Source quench ICMP messages SHOULD be ignored. TTL exceeded errors
SHOULD be ignored. Parameter problem errors SHOULD be treated as if a SHOULD be ignored. Parameter problem errors SHOULD be treated as if a
400-class response was received. 400-class response was received.
11 Behavior of SIP User Agents 11 Behavior of SIP User Agents
skipping to change at page 109, line 37 skipping to change at page 108, line 42
The rules for digest authentication follow those defined in [36], The rules for digest authentication follow those defined in [36],
with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following
differences: differences:
1. The URI included in the challenge has the following BNF: 1. The URI included in the challenge has the following BNF:
URI = SIP-URL URI = SIP-URL
2. The BNF for digest-uri-value is: 2. The BNF for digest-uri-value is:
digest-uri-value = Request-URI ; a defined in Section digest-uri-value = Request-URI ;as defined in Section
4.3 4.3
3. The example procedure for choosing a nonce based on Etag 3. The example procedure for choosing a nonce based on Etag
does not work for SIP. does not work for SIP.
4. The Authentication-Info and Proxy-Authentication-Info 4. The Authentication-Info and Proxy-Authentication-Info
fields are not used in SIP. fields are not used in SIP.
5. The text in [36] regarding cache operation does not apply 5. The text in [36] regarding cache operation does not apply
to SIP. to SIP.
6. [36] requires that a server check that the URI in the 6. [36] requires that a server check that the URI in the
skipping to change at page 115, line 46 skipping to change at page 115, line 10
jon.diligent registers his boss, T. Watson: jon.diligent registers his boss, T. Watson:
C->S: REGISTER sip:bell-tel.com SIP/2.0 C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP pluto.bell-tel.com Via: SIP/2.0/UDP pluto.bell-tel.com
From: sip:jon.diligent@bell-tel.com From: sip:jon.diligent@bell-tel.com
To: sip:watson@bell-tel.com To: sip:watson@bell-tel.com
Call-ID: 17320@pluto.bell-tel.com Call-ID: 17320@pluto.bell-tel.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: sip:tawatson@example.com Contact: sip:tawatson@example.com
The request could be send to either the registrar at bell-tel.com or The request could be sent to either the registrar at bell-tel.com or
the server at example.com. In the latter case, the server at the server at example.com. In the latter case, the server at
example.com would proxy the request to the address indicated in the example.com would proxy the request to the address indicated in the
Request-URI. Then, Max-Forwards header could be used to restrict the Request-URI. Then, Max-Forwards header could be used to restrict the
registration to that server. registration to that server.
16.2 Invitation to a Multicast Conference 16.2 Invitation to a Multicast Conference
The first example invites schooler@vlsi.cs.caltech.edu to a multicast The first example invites schooler@vlsi.cs.caltech.edu to a multicast
session. All examples use the Session Description Protocol (SDP) (RFC session. All examples use the Session Description Protocol (SDP) (RFC
2327 [6]) as the session description format. 2327 [6]) as the session description format.
skipping to change at page 119, line 32 skipping to change at page 118, line 43
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
S->C: SIP/2.0 200 OK S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.com Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com> From: A. Bell <sip:a.g.bell@bell-tel.com>
To: <sip:watson@bell-tel.com> ;tag=37462311 To: <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: sip:watson@boston.bell-tel.com Contact: sip:watson@boston.bell-tel.com
Content-Type: application/sdp
Content-Length: ... Content-Length: ...
v=0 v=0
o=watson 4858949 4858949 IN IP4 192.1.2.3 o=watson 4858949 4858949 IN IP4 192.1.2.3
s=I'm on my way s=I'm on my way
c=IN IP4 boston.bell-tel.com c=IN IP4 boston.bell-tel.com
m=audio 5004 RTP/AVP 0 3 m=audio 5004 RTP/AVP 0 3
The example illustrates the use of informational status responses. The example illustrates the use of informational status responses.
Here, the reception of the call is confirmed immediately (100), then, Here, the reception of the call is confirmed immediately (100), then,
possibly after some database mapping delay, the call rings (180) and possibly after some database mapping delay, the call rings (180) and
is then queued, with periodic status updates. is then queued, with periodic status updates.
Watson can only receive PCMU and GSM. Note that Watson's list of Watson can only receive PCMU and GSM. Note that Watson's list of
codecs may or may not be a subset of the one offered by Bell, as each codecs may or may not be a subset of the one offered by Bell, as each
party indicates the data types it is willing to receive. Watson will party indicates the data types it is willing to receive. Watson will
send audio data to port 3456 at c.bell-tel.com, Bell will send to send audio data to port 3456 at c.bell-tel.com, Bell will send to
port 5004 at boston.bell-tel.com. port 5004 at boston.bell-tel.com.
skipping to change at page 129, line 38 skipping to change at page 129, line 5
This section describes the use of the Session Description Protocol This section describes the use of the Session Description Protocol
(SDP) (RFC 2327 [6]). (SDP) (RFC 2327 [6]).
B.1 Configuring Media Streams B.1 Configuring Media Streams
The caller and callee align their media descriptions so that the nth The caller and callee align their media descriptions so that the nth
media stream ("m=" line) in the caller's session description media stream ("m=" line) in the caller's session description
corresponds to the nth media stream in the callee's description. corresponds to the nth media stream in the callee's description.
All media descriptions SHOULD contain "a=rtpmap" mappings from RTP
payload types to encodings.
This allows easier migration away from static payload
types.
If the callee wants to neither send nor receive a stream offered by
the caller, the callee sets the port number of that stream to zero in
its media description.
There currently is no other way than port zero for the
callee to refuse a bidirectional stream offered by the
type UAC proxy UAS registrar type UAC proxy UAS registrar
_____________________________________________________ _____________________________________________________
Accept R - o m m Accept R - o m m
Accept-Encoding R - - m m Accept-Encoding R - - m m
Accept-Language R - b b b Accept-Language R - b b b
Allow 405 o - - - Allow 405 o - - -
Authorization R a o a a Authorization R a o a a
Call-ID g m m m m Call-ID g m m m m
Content-Encoding g m - m m Content-Encoding g m - m m
Content-Length g m m m m Content-Length g m m m m
skipping to change at page 130, line 38 skipping to change at page 129, line 39
Route R - m - - Route R - m - -
Timestamp g o o m m Timestamp g o o m m
To g m m m m To g m m m m
Unsupported r b b - - Unsupported r b b - -
User-Agent g b - b - User-Agent g b - b -
Via g m m m m Via g m m m m
WWW-Authenticate 401 a - - - WWW-Authenticate 401 a - - -
Table 6: Header Field Processing Requirements Table 6: Header Field Processing Requirements
All media descriptions SHOULD contain "a=rtpmap" mappings from RTP
payload types to encodings.
This allows easier migration away from static payload
types.
If the callee wants to neither send nor receive a stream offered by
the caller, the callee sets the port number of that stream to zero in
its media description.
There currently is no other way than port zero for the
callee to refuse a bidirectional stream offered by the
caller. Both caller and callee need to be aware what media caller. Both caller and callee need to be aware what media
tools are to be started. tools are to be started.
For example, assume that the caller Alice has included the following For example, assume that the caller Alice has included the following
description in her INVITE request. It includes an audio stream and description in her INVITE request. It includes an audio stream and
two bidirectional video streams, using H.261 (payload type 31) and two bidirectional video streams, using H.261 (payload type 31) and
MPEG (payload type 32). MPEG (payload type 32).
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
skipping to change at page 138, line 26 skipping to change at page 137, line 38
qdtext = <any TEXT-UTF8 except <">> qdtext = <any TEXT-UTF8 except <">>
The backslash character ("\") MAY be used as a single-character The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs. quoting mechanism only within quoted-string and comment constructs.
quoted-pair = " \ " CHAR quoted-pair = " \ " CHAR
D Using SRV DNS Records D Using SRV DNS Records
The following procedure is experimental and relies on DNS SRV records The following procedure is experimental and relies on DNS SRV records
(RFC 2052 [14]). (RFC 2052 [14]). The steps listed below are used in place of the two
steps in section 1.4.2.
To determine the IP address of a SIP server to deliver a request to,
the following steps are followed. The Request-URI is examined. If it
does not specify a protocol (TCP or UDP), the client queries the name
server for SRV records for both UDP (if supported by the client) and
TCP (if supported by the client) SIP servers. The format of these
queries is defined in RFC 2052 [14]. Otherwise, the client queries
the name server for SIP servers available through the protocol
specified in the Request-URI. If the client does not support the
protocol specified in the Request-URI, it gives up. The results of
the query or queries are merged together and ordered based on
priority. Then, the searching technique outlined in RFC 2052 [14] is
used to select servers in order. The user then attempts to contact
each server in the order listed. If no port number is specified in
the Request-URI, the client uses the port number returned in the DNS
response, not port 5060.
E IANA Considerations
Section 4.4 describes a name space and mechanism for registering SIP
options.
Section 6.41 describes the name space for registering SIP warn-codes.
F Changes in Version -11
Since version -10, the following changes have been made. These
changes reflect IESG comments.
o Respecting DNS TTL's for cacheing of queries changed from
SHOULD to MUST.
o Default MTU for UDP requests changed from 1400 to 1500.
o Added note to status 480 indicating that a redirect server
could use this as well to indicate that it doesn't know where
the user is, for example, because all of the user's contact
information has expired.
o Added description for status 305. (May need to consider If a step elicits no addresses, the client continues to the next
whether we need both Location and Contact here, for step. However if a step elicits one or more addresses, but no SIP
compatibility with HTTP.) server at any of those addresses responds, then the client concludes
the server is down and doesn't continue on to the next step.
o Use of CRLF for line termination is a SHOULD. When SRV records are to be used, the protocol to use when querying
for the SRV record is "sip". SRV records contain port numbers for
servers, in addition to IP addresses; the client always uses this
port number when contacting the SIP server. Otherwise, the port
number in the SIP URI is used, if present. If there is no port in the
URI, the default port, 5060, is used.
o Clarifications and minor changes in DNS procedures for finding 1. If the host portion of the Request-URI is an IP address,
a SIP server. the client contacts the server at the given address. If the
host portion of the Request-URI is not an IP address, the
client proceeds to the next step.
o Message retransmission timers exponentially back off 2. The Request-URI is examined. If it contains an explicit
(incorporated since -09). port number, the next two steps are skipped.
o BNF fixed up, changed TEXT BNF to allow for UTF-8. 3. The Request-URI is examined. If it does not specify a
protocol (TCP or UDP), the client queries the name server
for SRV records for both UDP (if supported by the client)
and TCP (if supported by the client) SIP servers. The
format of these queries is defined in RFC 2052 [14]. The
results of the query or queries are merged together and
ordered based on priority. Then, the searching technique
outlined in RFC 2052 [14] is used to select servers in
order. If DNS doesn't return any records, the user goes to
the last step. Otherwise, the user attempts to contact each
server in the order listed. If no server is contacted, the
user gives up.
o More explicit rules on using HTTP basic and digest were added. 4. If the Request-URI specifies a protocol (TCP or UDP) that
Proxy-to-proxy authentication is disallowed due to is supported by the client, the client queries the name
incompatibilities with UDP transport. server for SRV records for SIP servers of that protocol
type only. If the client does not support the protocol
specified in the Request-URI, it gives up. The searching
technique outlined in RFC 2052 [14] is used to select
servers from the DNS response in order. If DNS doesn't
return any records, the user goes to the last step.
Otherwise, the user attempts to contact each server in the
order listed. If no server is contacted, the user gives up.
o IANA registered options are prefixed by org.iana.sip instead 5. The client queries the name server for address records for
of org.ietf.sip. the host portion of the Request-URI. If there were no
address records, the client stops, as it has been unable to
locate a server. By address record, we mean A RR's, AAAA
RR's, or their most modern equivalent.
o Date, Expires field only supports RFC 1123 formatting, as A client MAY cache a successful DNS query result. A successful query
opposed to HTTP, which also supports RFC 850 and asctime date is one which contained records in the answer, and a server was
formats. contacted at one of the addresses from the answer. When the client
wishes to send a request to the same host, it starts the search as if
it had just received this answer from the name server. The server
uses the procedures specified in RFC1035 [15] regarding cache
invalidation when the time-to-live of the DNS result expires. If the
client does not find a SIP server among the addresses listed in the
cached answer, it starts the search at the beginning of the sequence
described above.
o Changed the default reason phrase for 413 to align with the For example, consider a client that wishes to send a SIP request. The
newest HTTP revision. Request-URI for the destination is sip:user@company.com. The client
only supports UDP. It would follow these steps:
o Added requirement for CRLF line termination in 1. The host portion is not an IP address, so the client goes
canonicalization rules. Clarified canonicalization rules to step 2 above.
o Default language for warn-text changed from English to i- 2. The client does a DNS query of QNAME="sip.udp.company.com",
default. QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it
omits the TCP query. There were no addresses in the DNS
response, so the client goes to the next step.
o Use of transport and network level security changed to MAY 3. The client does a DNS query for A records for
from RECOMMENDED. "company.com". An address is found, so that client attempts
to contact a server at that address at port 5060.
o Mandated use of the name-addr form in the To field if addr- E IANA Considerations
spec contains a semicolon, comma, or question mark. This is in
line with From and Contact, but was omitted from the To
section accidentally in previous versions
o Fixed deviation in BNF between ASCII and PostScript versions Section 4.4 describes a name space and mechanism for registering SIP
of spec. options.
o Made consistent the usage of the Contact expires parameter. Section 6.41 describes the name space for registering SIP warn-codes.
o Fixed inconsistency in usage of Contact header in 181 and 1xx F Changes in Version -12
responses.
o Fixed inconsistency regarding encryption of Call-ID. Call-ID Since version -11, the following changes have been made. These
should be in the clear. changes reflect IESG comments.
o Rewrote SDP section for greater clarity; included discussion o Section 16.3 was missing Content-Type header.
of behavior for delayed session description.
o Updated minimal requirements table, correcting inconsistencies o The DNS search procedure has changed. Reference to CNAME
with the text. lookups has been removed since their usage is implicit in
normal DNS procedures. Also, automatically appending a sip. to
the domain name in the URL before lookup has been removed. A
note has been added discussing the creating of SIP URL's from
email addresses and encourages the usage of rfc2219.
o Changed state diagram to include timing information. o Semicolon removed from user and password BNF in SIP URL.
o Added nonce parameter in PGP WWW-Authenticate and o An email address for IANA registrations is now listed.
Authorization header fields to prevent replay attacks.
o Fixed inconsistent use of quotation marks (between example and o For the Moved Temporarily redirect response, no default value
syntax) for version and pgp-algorithm in PGP (Ch. 14). for the expiration of this address is specified. This has been
clarified; the redirected address is only valid for the
duration of the call. This is consistent with exising text
under the Contact header description which indicates that the
values should not be cached.
o delta-time values may be capped at 2**32. o Clarification that CANCEL and ACK's should have the same Via
branch parameter as the request they cancel or acknowledge.
G Acknowledgments G Acknowledgments
We wish to thank the members of the IETF MMUSIC WG for their comments We wish to thank the members of the IETF MMUSIC WG for their comments
and suggestions. Detailed comments were provided by Anders and suggestions. Detailed comments were provided by Anders
Kristensen, Jim Buller, Dave Devanathan, Yaron Goland, Christian Kristensen, Jim Buller, Dave Devanathan, Yaron Goland, Christian
Huitema, Gadi Karmi, Jonathan Lennox, Keith Moore, Vern Paxson, Moshe Huitema, Gadi Karmi, Jonathan Lennox, Keith Moore, Vern Paxson, Moshe
J. Sambol, and Eric Tremblay. J. Sambol, and Eric Tremblay.
This work is based, inter alia, on [37,38]. This work is based, inter alia, on [37,38].
skipping to change at page 144, line 43 skipping to change at page 144, line 17
Research and Experience , vol. 4, pp. 99--120, June 1993. ISI Research and Experience , vol. 4, pp. 99--120, June 1993. ISI
reprint series ISI/RS-93-359. reprint series ISI/RS-93-359.
[38] H. Schulzrinne, "Personal mobility for multimedia services in [38] H. Schulzrinne, "Personal mobility for multimedia services in
the Internet," in European Workshop on Interactive Distributed the Internet," in European Workshop on Interactive Distributed
Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar. Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar.
1996. 1996.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (1998). All Rights Reserved. Copyright (c) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 145, line 31 skipping to change at page 145, line 9
Table of Contents Table of Contents
1 Introduction ........................................ 2 1 Introduction ........................................ 2
1.1 Overview of SIP Functionality ....................... 2 1.1 Overview of SIP Functionality ....................... 2
1.2 Terminology ......................................... 4 1.2 Terminology ......................................... 4
1.3 Definitions ......................................... 4 1.3 Definitions ......................................... 4
1.4 Overview of SIP Operation ........................... 7 1.4 Overview of SIP Operation ........................... 7
1.4.1 SIP Addressing ...................................... 7 1.4.1 SIP Addressing ...................................... 7
1.4.2 Locating a SIP Server ............................... 8 1.4.2 Locating a SIP Server ............................... 8
1.4.3 SIP Transaction ..................................... 10 1.4.3 SIP Transaction ..................................... 9
1.4.4 SIP Invitation ...................................... 11 1.4.4 SIP Invitation ...................................... 10
1.4.5 Locating a User ..................................... 13 1.4.5 Locating a User ..................................... 12
1.4.6 Changing an Existing Session ........................ 13 1.4.6 Changing an Existing Session ........................ 13
1.4.7 Registration Services ............................... 15 1.4.7 Registration Services ............................... 13
1.5 Protocol Properties ................................. 15 1.5 Protocol Properties ................................. 13
1.5.1 Minimal State ....................................... 15 1.5.1 Minimal State ....................................... 13
1.5.2 Lower-Layer-Protocol Neutral ........................ 15 1.5.2 Lower-Layer-Protocol Neutral ........................ 13
1.5.3 Text-Based .......................................... 16 1.5.3 Text-Based .......................................... 15
2 SIP Uniform Resource Locators ....................... 16 2 SIP Uniform Resource Locators ....................... 15
3 SIP Message Overview ................................ 20 3 SIP Message Overview ................................ 19
4 Request ............................................. 22 4 Request ............................................. 21
4.1 Request-Line ........................................ 22 4.1 Request-Line ........................................ 21
4.2 Methods ............................................. 22 4.2 Methods ............................................. 21
4.2.1 INVITE .............................................. 24 4.2.1 INVITE .............................................. 22
4.2.2 ACK ................................................. 24 4.2.2 ACK ................................................. 23
4.2.3 OPTIONS ............................................. 25 4.2.3 OPTIONS ............................................. 24
4.2.4 BYE ................................................. 25 4.2.4 BYE ................................................. 24
4.2.5 CANCEL .............................................. 26 4.2.5 CANCEL .............................................. 25
4.2.6 REGISTER ............................................ 27 4.2.6 REGISTER ............................................ 26
4.3 Request-URI ......................................... 29 4.3 Request-URI ......................................... 28
4.3.1 SIP Version ......................................... 30 4.3.1 SIP Version ......................................... 29
4.4 Option Tags ......................................... 31 4.4 Option Tags ......................................... 29
4.4.1 Registering New Option Tags with IANA ............... 31 4.4.1 Registering New Option Tags with IANA ............... 30
5 Response ............................................ 32 5 Response ............................................ 31
5.1 Status-Line ......................................... 32 5.1 Status-Line ......................................... 31
5.1.1 Status Codes and Reason Phrases ..................... 32 5.1.1 Status Codes and Reason Phrases ..................... 31
6 Header Field Definitions ............................ 34 6 Header Field Definitions ............................ 33
6.1 General Header Fields ............................... 37 6.1 General Header Fields ............................... 35
6.2 Entity Header Fields ................................ 37 6.2 Entity Header Fields ................................ 36
6.3 Request Header Fields ............................... 38 6.3 Request Header Fields ............................... 37
6.4 Response Header Fields .............................. 39 6.4 Response Header Fields .............................. 38
6.5 End-to-end and Hop-by-hop Headers ................... 39 6.5 End-to-end and Hop-by-hop Headers ................... 38
6.6 Header Field Format ................................. 39 6.6 Header Field Format ................................. 38
6.7 Accept .............................................. 40 6.7 Accept .............................................. 39
6.8 Accept-Encoding ..................................... 40 6.8 Accept-Encoding ..................................... 39
6.9 Accept-Language ..................................... 40 6.9 Accept-Language ..................................... 39
6.10 Allow ............................................... 41 6.10 Allow ............................................... 40
6.11 Authorization ....................................... 41 6.11 Authorization ....................................... 40
6.12 Call-ID ............................................. 41 6.12 Call-ID ............................................. 40
6.13 Contact ............................................. 43 6.13 Contact ............................................. 42
6.14 Content-Encoding .................................... 46 6.14 Content-Encoding .................................... 45
6.15 Content-Length ...................................... 46 6.15 Content-Length ...................................... 45
6.16 Content-Type ........................................ 47 6.16 Content-Type ........................................ 46
6.17 CSeq ................................................ 48 6.17 CSeq ................................................ 47
6.18 Date ................................................ 49 6.18 Date ................................................ 48
6.19 Encryption .......................................... 50 6.19 Encryption .......................................... 49
6.20 Expires ............................................. 51 6.20 Expires ............................................. 50
6.21 From ................................................ 52 6.21 From ................................................ 51
6.22 Hide ................................................ 53 6.22 Hide ................................................ 52
6.23 Max-Forwards ........................................ 54 6.23 Max-Forwards ........................................ 53
6.24 Organization ........................................ 55 6.24 Organization ........................................ 54
6.25 Priority ............................................ 55 6.25 Priority ............................................ 54
6.26 Proxy-Authenticate .................................. 56 6.26 Proxy-Authenticate .................................. 55
6.27 Proxy-Authorization ................................. 57 6.27 Proxy-Authorization ................................. 56
6.28 Proxy-Require ....................................... 57 6.28 Proxy-Require ....................................... 56
6.29 Record-Route ........................................ 57 6.29 Record-Route ........................................ 56
6.30 Require ............................................. 58 6.30 Require ............................................. 57
6.31 Response-Key ........................................ 59 6.31 Response-Key ........................................ 58
6.32 Retry-After ......................................... 60 6.32 Retry-After ......................................... 59
6.33 Route ............................................... 60 6.33 Route ............................................... 59
6.34 Server .............................................. 61 6.34 Server .............................................. 60
6.35 Subject ............................................. 61 6.35 Subject ............................................. 60
6.36 Timestamp ........................................... 61 6.36 Timestamp ........................................... 60
6.37 To .................................................. 62 6.37 To .................................................. 61
6.38 Unsupported ......................................... 63 6.38 Unsupported ......................................... 62
6.39 User-Agent .......................................... 64 6.39 User-Agent .......................................... 63
6.40 Via ................................................. 64 6.40 Via ................................................. 63
6.40.1 Requests ............................................ 64 6.40.1 Requests ............................................ 63
6.40.2 Receiver-tagged Via Header Fields ................... 65 6.40.2 Receiver-tagged Via Header Fields ................... 64
6.40.3 Responses ........................................... 65 6.40.3 Responses ........................................... 64
6.40.4 User Agent and Redirect Servers ..................... 66 6.40.4 User Agent and Redirect Servers ..................... 65
6.40.5 Syntax .............................................. 67 6.40.5 Syntax .............................................. 66
6.41 Warning ............................................. 68 6.41 Warning ............................................. 67
6.42 WWW-Authenticate .................................... 70 6.42 WWW-Authenticate .................................... 69
7 Status Code Definitions ............................. 70 7 Status Code Definitions ............................. 69
7.1 Informational 1xx ................................... 71 7.1 Informational 1xx ................................... 70
7.1.1 100 Trying .......................................... 71 7.1.1 100 Trying .......................................... 70
7.1.2 180 Ringing ......................................... 71 7.1.2 180 Ringing ......................................... 70
7.1.3 181 Call Is Being Forwarded ......................... 71 7.1.3 181 Call Is Being Forwarded ......................... 70
7.1.4 182 Queued .......................................... 71 7.1.4 182 Queued .......................................... 70
7.2 Successful 2xx ...................................... 71 7.2 Successful 2xx ...................................... 70
7.2.1 200 OK .............................................. 71 7.2.1 200 OK .............................................. 71
7.3 Redirection 3xx ..................................... 72 7.3 Redirection 3xx ..................................... 71
7.3.1 300 Multiple Choices ................................ 72 7.3.1 300 Multiple Choices ................................ 71
7.3.2 301 Moved Permanently ............................... 73 7.3.2 301 Moved Permanently ............................... 72
7.3.3 302 Moved Temporarily ............................... 73 7.3.3 302 Moved Temporarily ............................... 72
7.3.4 305 Use Proxy ....................................... 73 7.3.4 305 Use Proxy ....................................... 72
7.3.5 380 Alternative Service ............................. 73 7.3.5 380 Alternative Service ............................. 72
7.4 Request Failure 4xx ................................. 73 7.4 Request Failure 4xx ................................. 72
7.4.1 400 Bad Request ..................................... 73 7.4.1 400 Bad Request ..................................... 72
7.4.2 401 Unauthorized .................................... 73 7.4.2 401 Unauthorized .................................... 73
7.4.3 402 Payment Required ................................ 74 7.4.3 402 Payment Required ................................ 73
7.4.4 403 Forbidden ....................................... 74 7.4.4 403 Forbidden ....................................... 73
7.4.5 404 Not Found ....................................... 74 7.4.5 404 Not Found ....................................... 73
7.4.6 405 Method Not Allowed .............................. 74 7.4.6 405 Method Not Allowed .............................. 73
7.4.7 406 Not Acceptable .................................. 74 7.4.7 406 Not Acceptable .................................. 73
7.4.8 407 Proxy Authentication Required ................... 74 7.4.8 407 Proxy Authentication Required ................... 73
7.4.9 408 Request Timeout ................................. 74 7.4.9 408 Request Timeout ................................. 74
7.4.10 409 Conflict ........................................ 75 7.4.10 409 Conflict ........................................ 74
7.4.11 410 Gone ............................................ 75 7.4.11 410 Gone ............................................ 74
7.4.12 411 Length Required ................................. 75 7.4.12 411 Length Required ................................. 74
7.4.13 413 Request Entity Too Large ........................ 75 7.4.13 413 Request Entity Too Large ........................ 74
7.4.14 414 Request-URI Too Long ............................ 75 7.4.14 414 Request-URI Too Long ............................ 74
7.4.15 415 Unsupported Media Type .......................... 75 7.4.15 415 Unsupported Media Type .......................... 74
7.4.16 420 Bad Extension ................................... 76 7.4.16 420 Bad Extension ................................... 75
7.4.17 480 Temporarily Unavailable ......................... 76 7.4.17 480 Temporarily Unavailable ......................... 75
7.4.18 481 Call Leg/Transaction Does Not Exist ............. 76 7.4.18 481 Call Leg/Transaction Does Not Exist ............. 75
7.4.19 482 Loop Detected ................................... 76 7.4.19 482 Loop Detected ................................... 75
7.4.20 483 Too Many Hops ................................... 76 7.4.20 483 Too Many Hops ................................... 75
7.4.21 484 Address Incomplete .............................. 76 7.4.21 484 Address Incomplete .............................. 75
7.4.22 485 Ambiguous ....................................... 77 7.4.22 485 Ambiguous ....................................... 76
7.4.23 486 Busy Here ....................................... 77 7.4.23 486 Busy Here ....................................... 76
7.5 Server Failure 5xx .................................. 77 7.5 Server Failure 5xx .................................. 77
7.5.1 500 Server Internal Error ........................... 78 7.5.1 500 Server Internal Error ........................... 77
7.5.2 501 Not Implemented ................................. 78 7.5.2 501 Not Implemented ................................. 77
7.5.3 502 Bad Gateway ..................................... 78 7.5.3 502 Bad Gateway ..................................... 77
7.5.4 503 Service Unavailable ............................. 78 7.5.4 503 Service Unavailable ............................. 77
7.5.5 504 Gateway Time-out ................................ 78 7.5.5 504 Gateway Time-out ................................ 77
7.5.6 505 Version Not Supported ........................... 78 7.5.6 505 Version Not Supported ........................... 77
7.6 Global Failures 6xx ................................. 79 7.6 Global Failures 6xx ................................. 78
7.6.1 600 Busy Everywhere ................................. 79 7.6.1 600 Busy Everywhere ................................. 78
7.6.2 603 Decline ......................................... 79 7.6.2 603 Decline ......................................... 78
7.6.3 604 Does Not Exist Anywhere ......................... 79 7.6.3 604 Does Not Exist Anywhere ......................... 78
7.6.4 606 Not Acceptable .................................. 79 7.6.4 606 Not Acceptable .................................. 78
8 SIP Message Body .................................... 80 8 SIP Message Body .................................... 79
8.1 Body Inclusion ...................................... 80 8.1 Body Inclusion ...................................... 79
8.2 Message Body Type ................................... 80 8.2 Message Body Type ................................... 79
8.3 Message Body Length ................................. 80 8.3 Message Body Length ................................. 79
9 Compact Form ........................................ 80 9 Compact Form ........................................ 80
10 Behavior of SIP Clients and Servers ................. 81 10 Behavior of SIP Clients and Servers ................. 81
10.1 General Remarks ..................................... 82 10.1 General Remarks ..................................... 81
10.1.1 Requests ............................................ 82 10.1.1 Requests ............................................ 81
10.1.2 Responses ........................................... 82 10.1.2 Responses ........................................... 81
10.2 Source Addresses, Destination Addresses and 10.2 Source Addresses, Destination Addresses and
Connections .................................................... 83 Connections .................................................... 82
10.2.1 Unicast UDP ......................................... 83 10.2.1 Unicast UDP ......................................... 82
10.2.2 Multicast UDP ....................................... 83 10.2.2 Multicast UDP ....................................... 82
10.3 TCP ................................................. 84 10.3 TCP ................................................. 83
10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER 10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER
Requests ....................................................... 85 Requests ....................................................... 84
10.4.1 UDP ................................................. 85 10.4.1 UDP ................................................. 84
10.4.2 TCP ................................................. 86 10.4.2 TCP ................................................. 85
10.5 Reliability for INVITE Requests ..................... 86 10.5 Reliability for INVITE Requests ..................... 85
10.5.1 UDP ................................................. 87 10.5.1 UDP ................................................. 86
10.5.2 TCP ................................................. 88 10.5.2 TCP ................................................. 87
10.6 Reliability for ACK Requests ........................ 88 10.6 Reliability for ACK Requests ........................ 87
10.7 ICMP Handling ....................................... 88 10.7 ICMP Handling ....................................... 90
11 Behavior of SIP User Agents ......................... 91 11 Behavior of SIP User Agents ......................... 90
11.1 Caller Issues Initial INVITE Request ................ 91 11.1 Caller Issues Initial INVITE Request ................ 90
11.2 Callee Issues Response .............................. 91 11.2 Callee Issues Response .............................. 90
11.3 Caller Receives Response to Initial Request ......... 91 11.3 Caller Receives Response to Initial Request ......... 90
11.4 Caller or Callee Generate Subsequent Requests ....... 92 11.4 Caller or Callee Generate Subsequent Requests ....... 91
11.5 Receiving Subsequent Requests ....................... 92 11.5 Receiving Subsequent Requests ....................... 91
12 Behavior of SIP Proxy and Redirect Servers .......... 92 12 Behavior of SIP Proxy and Redirect Servers .......... 92
12.1 Redirect Server ..................................... 93 12.1 Redirect Server ..................................... 92
12.2 User Agent Server ................................... 93 12.2 User Agent Server ................................... 92
12.3 Proxy Server ........................................ 93 12.3 Proxy Server ........................................ 92
12.3.1 Proxying Requests ................................... 94 12.3.1 Proxying Requests ................................... 93
12.3.2 Proxying Responses .................................. 94 12.3.2 Proxying Responses .................................. 93
12.3.3 Stateless Proxy: Proxying Responses ................. 94 12.3.3 Stateless Proxy: Proxying Responses ................. 93
12.3.4 Stateful Proxy: Receiving Requests .................. 94 12.3.4 Stateful Proxy: Receiving Requests .................. 93
12.3.5 Stateful Proxy: Receiving ACKs ...................... 94 12.3.5 Stateful Proxy: Receiving ACKs ...................... 93
12.3.6 Stateful Proxy: Receiving Responses ................. 95 12.3.6 Stateful Proxy: Receiving Responses ................. 94
12.3.7 Stateless, Non-Forking Proxy ........................ 95 12.3.7 Stateless, Non-Forking Proxy ........................ 94
12.4 Forking Proxy ....................................... 96 12.4 Forking Proxy ....................................... 95
13 Security Considerations ............................. 99 13 Security Considerations ............................. 98
13.1 Confidentiality and Privacy: Encryption ............. 99 13.1 Confidentiality and Privacy: Encryption ............. 99
13.1.1 End-to-End Encryption ............................... 99 13.1.1 End-to-End Encryption ............................... 99
13.1.2 Privacy of SIP Responses ............................ 102 13.1.2 Privacy of SIP Responses ............................ 101
13.1.3 Encryption by Proxies ............................... 103 13.1.3 Encryption by Proxies ............................... 102
13.1.4 Hop-by-Hop Encryption ............................... 103 13.1.4 Hop-by-Hop Encryption ............................... 102
13.1.5 Via field encryption ................................ 103 13.1.5 Via field encryption ................................ 102
13.2 Message Integrity and Access Control: 13.2 Message Integrity and Access Control:
Authentication ................................................. 104 Authentication ................................................. 103
13.2.1 Trusting responses .................................. 106 13.2.1 Trusting responses .................................. 106
13.3 Callee Privacy ...................................... 107 13.3 Callee Privacy ...................................... 107
13.4 Known Security Problems ............................. 107 13.4 Known Security Problems ............................. 107
14 SIP Authentication using HTTP Basic and Digest 14 SIP Authentication using HTTP Basic and Digest
Schemes ........................................................ 108 Schemes ........................................................ 107
14.1 Framework ........................................... 108 14.1 Framework ........................................... 107
14.2 Basic Authentication ................................ 109 14.2 Basic Authentication ................................ 108
14.3 Digest Authentication ............................... 109 14.3 Digest Authentication ............................... 108
14.4 Proxy-Authentication ................................ 110 14.4 Proxy-Authentication ................................ 109
15 SIP Security Using PGP .............................. 110 15 SIP Security Using PGP .............................. 109
15.1 PGP Authentication Scheme ........................... 110 15.1 PGP Authentication Scheme ........................... 109
15.1.1 The WWW-Authenticate Response Header ................ 110 15.1.1 The WWW-Authenticate Response Header ................ 110
15.1.2 The Authorization Request Header .................... 112 15.1.2 The Authorization Request Header .................... 111
15.2 PGP Encryption Scheme ............................... 113 15.2 PGP Encryption Scheme ............................... 112
15.3 Response-Key Header Field for PGP ................... 114 15.3 Response-Key Header Field for PGP ................... 113
16 Examples ............................................ 114 16 Examples ............................................ 113
16.1 Registration ........................................ 114 16.1 Registration ........................................ 113
16.2 Invitation to a Multicast Conference ................ 116 16.2 Invitation to a Multicast Conference ................ 115
16.2.1 Request ............................................. 116 16.2.1 Request ............................................. 115
16.2.2 Response ............................................ 117 16.2.2 Response ............................................ 116
16.3 Two-party Call ...................................... 118 16.3 Two-party Call ...................................... 117
16.4 Terminating a Call .................................. 120 16.4 Terminating a Call .................................. 119
16.5 Forking Proxy ....................................... 120 16.5 Forking Proxy ....................................... 119
16.6 Redirects ........................................... 124 16.6 Redirects ........................................... 123
16.7 Negotiation ......................................... 126 16.7 Negotiation ......................................... 125
16.8 OPTIONS Request ..................................... 127 16.8 OPTIONS Request ..................................... 126
A Minimal Implementation .............................. 127 A Minimal Implementation .............................. 127
A.1 Client .............................................. 128 A.1 Client .............................................. 127
A.2 Server .............................................. 128 A.2 Server .............................................. 128
A.3 Header Processing ................................... 129 A.3 Header Processing ................................... 128
B Usage of the Session Description Protocol (SDP) B Usage of the Session Description Protocol (SDP)
................................................................ 129 ................................................................ 128
B.1 Configuring Media Streams ........................... 129 B.1 Configuring Media Streams ........................... 128
B.2 Setting SDP Values for Unicast ...................... 131 B.2 Setting SDP Values for Unicast ...................... 130
B.3 Multicast Operation ................................. 132 B.3 Multicast Operation ................................. 131
B.4 Delayed Media Streams ............................... 133 B.4 Delayed Media Streams ............................... 132
B.5 Putting Media Streams on Hold ....................... 133 B.5 Putting Media Streams on Hold ....................... 132
B.6 Subject and SDP "s=" Line ........................... 133 B.6 Subject and SDP "s=" Line ........................... 132
B.7 The SDP "o=" Line ................................... 133 B.7 The SDP "o=" Line ................................... 133
C Summary of Augmented BNF ............................ 133 C Summary of Augmented BNF ............................ 133
C.1 Basic Rules ......................................... 136 C.1 Basic Rules ......................................... 135
D Using SRV DNS Records ............................... 138 D Using SRV DNS Records ............................... 137
E IANA Considerations ................................. 139 E IANA Considerations ................................. 139
F Changes in Version -11 .............................. 139 F Changes in Version -12 .............................. 139
G Acknowledgments ..................................... 140 G Acknowledgments ..................................... 140
H Authors' Addresses .................................. 141 H Authors' Addresses .................................. 140
I Bibliography ........................................ 141 I Bibliography ........................................ 141
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/