draft-ietf-mmusic-sip-12.txt   rfc2543.txt 
Internet Engineering Task Force MMUSIC WG Network Working Group M. Handley
Internet Draft Handley/Schulzrinne/Schooler/Rosenberg Request for Comments: 2543 ACIRI
ietf-mmusic-sip-12.txt ISI/Columbia U./Caltech/Bell Labs. Category: Standards Track H. Schulzrinne
January 15, 1999 Columbia U.
Expires: July 1999 E. Schooler
Cal Tech
J. Rosenberg
Bell Labs
March 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 specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Please refer to the current edition of the "Internet
working documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress''.
To learn the current status of any Internet-Draft, please check the Copyright (C) The Internet Society (1999). All Rights Reserved.
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. IESG Note
ABSTRACT The IESG intends to charter, in the near future, one or more working
groups to produce standards for "name lookup", where such names would
include electronic mail addresses and telephone numbers, and the
result of such a lookup would be a list of attributes and
characteristics of the user or terminal associated with the name.
Groups which are in need of a "name lookup" protocol should follow
the development of these new working groups rather than using SIP for
this function. In addition it is anticipated that SIP will migrate
towards using such protocols, and SIP implementors are advised to
monitor these efforts.
The Session Initiation Protocol (SIP) is an application- Abstract
layer control (signaling) protocol for creating,
modifying and terminating sessions with one or more
participants. These sessions include Internet multimedia
conferences, Internet telephone calls and multimedia
distribution. Members in a session can communicate via
multicast or via a mesh of unicast relations, or a
combination of these.
SIP invitations used to create sessions carry session The Session Initiation Protocol (SIP) is an application-layer control
descriptions which allow participants to agree on a set (signaling) protocol for creating, modifying and terminating sessions
of compatible media types. SIP supports user mobility by with one or more participants. These sessions include Internet
proxying and redirecting requests to the user's current multimedia conferences, Internet telephone calls and multimedia
location. Users can register their current location. SIP distribution. Members in a session can communicate via multicast or
is not tied to any particular conference control via a mesh of unicast relations, or a combination of these.
protocol. SIP is designed to be independent of the
lower-layer transport protocol and can be extended with
additional capabilities.
This document is a product of the Multi-party Multimedia SIP invitations used to create sessions carry session descriptions
Session Control (MMUSIC) working group of the Internet which allow participants to agree on a set of compatible media types.
Engineering Task Force. Comments are solicited and SIP supports user mobility by proxying and redirecting requests to
should be addressed to the working group's mailing list the user's current location. Users can register their current
at confctrl@isi.edu and/or the authors. location. SIP is not tied to any particular conference control
protocol. SIP is designed to be independent of the lower-layer
transport protocol and can be extended with additional capabilities.
Table of Contents
1 Introduction ........................................ 7
1.1 Overview of SIP Functionality ....................... 7
1.2 Terminology ......................................... 8
1.3 Definitions ......................................... 9
1.4 Overview of SIP Operation ........................... 12
1.4.1 SIP Addressing ...................................... 12
1.4.2 Locating a SIP Server ............................... 13
1.4.3 SIP Transaction ..................................... 14
1.4.4 SIP Invitation ...................................... 15
1.4.5 Locating a User ..................................... 17
1.4.6 Changing an Existing Session ........................ 18
1.4.7 Registration Services ............................... 18
1.5 Protocol Properties ................................. 18
1.5.1 Minimal State ....................................... 18
1.5.2 Lower-Layer-Protocol Neutral ........................ 18
1.5.3 Text-Based .......................................... 20
2 SIP Uniform Resource Locators ....................... 20
3 SIP Message Overview ................................ 24
4 Request ............................................. 26
4.1 Request-Line ........................................ 26
4.2 Methods ............................................. 27
4.2.1 INVITE .............................................. 28
4.2.2 ACK ................................................. 29
4.2.3 OPTIONS ............................................. 29
4.2.4 BYE ................................................. 30
4.2.5 CANCEL .............................................. 30
4.2.6 REGISTER ............................................ 31
4.3 Request-URI ......................................... 34
4.3.1 SIP Version ......................................... 35
4.4 Option Tags ......................................... 35
4.4.1 Registering New Option Tags with IANA ............... 35
5 Response ............................................ 36
5.1 Status-Line ......................................... 36
5.1.1 Status Codes and Reason Phrases ..................... 37
6 Header Field Definitions ............................ 39
6.1 General Header Fields ............................... 41
6.2 Entity Header Fields ................................ 42
6.3 Request Header Fields ............................... 43
6.4 Response Header Fields .............................. 43
6.5 End-to-end and Hop-by-hop Headers ................... 43
6.6 Header Field Format ................................. 43
6.7 Accept .............................................. 44
6.8 Accept-Encoding ..................................... 44
6.9 Accept-Language ..................................... 45
6.10 Allow ............................................... 45
6.11 Authorization ....................................... 45
6.12 Call-ID ............................................. 46
6.13 Contact ............................................. 47
6.14 Content-Encoding .................................... 50
6.15 Content-Length ...................................... 51
6.16 Content-Type ........................................ 51
6.17 CSeq ................................................ 52
6.18 Date ................................................ 53
6.19 Encryption .......................................... 54
6.20 Expires ............................................. 55
6.21 From ................................................ 56
6.22 Hide ................................................ 57
6.23 Max-Forwards ........................................ 59
6.24 Organization ........................................ 59
6.25 Priority ............................................ 60
6.26 Proxy-Authenticate .................................. 60
6.27 Proxy-Authorization ................................. 61
6.28 Proxy-Require ....................................... 61
6.29 Record-Route ........................................ 62
6.30 Require ............................................. 63
6.31 Response-Key ........................................ 63
6.32 Retry-After ......................................... 64
6.33 Route ............................................... 65
6.34 Server .............................................. 65
6.35 Subject ............................................. 65
6.36 Timestamp ........................................... 66
6.37 To .................................................. 66
6.38 Unsupported ......................................... 68
6.39 User-Agent .......................................... 68
6.40 Via ................................................. 68
6.40.1 Requests ............................................ 68
6.40.2 Receiver-tagged Via Header Fields ................... 69
6.40.3 Responses ........................................... 70
6.40.4 User Agent and Redirect Servers ..................... 70
6.40.5 Syntax .............................................. 71
6.41 Warning ............................................. 72
6.42 WWW-Authenticate .................................... 74
7 Status Code Definitions ............................. 75
7.1 Informational 1xx ................................... 75
7.1.1 100 Trying .......................................... 75
7.1.2 180 Ringing ......................................... 75
7.1.3 181 Call Is Being Forwarded ......................... 75
7.1.4 182 Queued .......................................... 76
7.2 Successful 2xx ...................................... 76
7.2.1 200 OK .............................................. 76
7.3 Redirection 3xx ..................................... 76
7.3.1 300 Multiple Choices ................................ 77
7.3.2 301 Moved Permanently ............................... 77
7.3.3 302 Moved Temporarily ............................... 77
7.3.4 305 Use Proxy ....................................... 77
7.3.5 380 Alternative Service ............................. 78
7.4 Request Failure 4xx ................................. 78
7.4.1 400 Bad Request ..................................... 78
7.4.2 401 Unauthorized .................................... 78
7.4.3 402 Payment Required ................................ 78
7.4.4 403 Forbidden ....................................... 78
7.4.5 404 Not Found ....................................... 78
7.4.6 405 Method Not Allowed .............................. 78
7.4.7 406 Not Acceptable .................................. 79
7.4.8 407 Proxy Authentication Required ................... 79
7.4.9 408 Request Timeout ................................. 79
7.4.10 409 Conflict ........................................ 79
7.4.11 410 Gone ............................................ 79
7.4.12 411 Length Required ................................. 79
7.4.13 413 Request Entity Too Large ........................ 80
7.4.14 414 Request-URI Too Long ............................ 80
7.4.15 415 Unsupported Media Type .......................... 80
7.4.16 420 Bad Extension ................................... 80
7.4.17 480 Temporarily Unavailable ......................... 80
7.4.18 481 Call Leg/Transaction Does Not Exist ............. 81
7.4.19 482 Loop Detected ................................... 81
7.4.20 483 Too Many Hops ................................... 81
7.4.21 484 Address Incomplete .............................. 81
7.4.22 485 Ambiguous ....................................... 81
7.4.23 486 Busy Here ....................................... 82
7.5 Server Failure 5xx .................................. 82
7.5.1 500 Server Internal Error ........................... 82
7.5.2 501 Not Implemented ................................. 82
7.5.3 502 Bad Gateway ..................................... 82
7.5.4 503 Service Unavailable ............................. 83
7.5.5 504 Gateway Time-out ................................ 83
7.5.6 505 Version Not Supported ........................... 83
7.6 Global Failures 6xx ................................. 83
7.6.1 600 Busy Everywhere ................................. 83
7.6.2 603 Decline ......................................... 84
7.6.3 604 Does Not Exist Anywhere ......................... 84
7.6.4 606 Not Acceptable .................................. 84
8 SIP Message Body .................................... 84
8.1 Body Inclusion ...................................... 84
8.2 Message Body Type ................................... 85
8.3 Message Body Length ................................. 85
9 Compact Form ........................................ 85
10 Behavior of SIP Clients and Servers ................. 86
10.1 General Remarks ..................................... 86
10.1.1 Requests ............................................ 86
10.1.2 Responses ........................................... 87
10.2 Source Addresses, Destination Addresses and
Connections ......................................... 88
10.2.1 Unicast UDP ......................................... 88
10.2.2 Multicast UDP ....................................... 88
10.3 TCP ................................................. 89
10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER
Requests ............................................ 90
10.4.1 UDP ................................................. 90
10.4.2 TCP ................................................. 91
10.5 Reliability for INVITE Requests ..................... 91
10.5.1 UDP ................................................. 92
10.5.2 TCP ................................................. 95
10.6 Reliability for ACK Requests ........................ 95
10.7 ICMP Handling ....................................... 95
11 Behavior of SIP User Agents ......................... 95
11.1 Caller Issues Initial INVITE Request ................ 96
11.2 Callee Issues Response .............................. 96
11.3 Caller Receives Response to Initial Request ......... 96
11.4 Caller or Callee Generate Subsequent Requests ....... 97
11.5 Receiving Subsequent Requests ....................... 97
12 Behavior of SIP Proxy and Redirect Servers .......... 97
12.1 Redirect Server ..................................... 97
12.2 User Agent Server ................................... 98
12.3 Proxy Server ........................................ 98
12.3.1 Proxying Requests ................................... 98
12.3.2 Proxying Responses .................................. 99
12.3.3 Stateless Proxy: Proxying Responses ................. 99
12.3.4 Stateful Proxy: Receiving Requests .................. 99
12.3.5 Stateful Proxy: Receiving ACKs ...................... 99
12.3.6 Stateful Proxy: Receiving Responses ................. 100
12.3.7 Stateless, Non-Forking Proxy ........................ 100
12.4 Forking Proxy ....................................... 100
13 Security Considerations ............................. 104
13.1 Confidentiality and Privacy: Encryption ............. 104
13.1.1 End-to-End Encryption ............................... 104
13.1.2 Privacy of SIP Responses ............................ 107
13.1.3 Encryption by Proxies ............................... 108
13.1.4 Hop-by-Hop Encryption ............................... 108
13.1.5 Via field encryption ................................ 108
13.2 Message Integrity and Access Control:
Authentication ...................................... 109
13.2.1 Trusting responses .................................. 112
13.3 Callee Privacy ...................................... 113
13.4 Known Security Problems ............................. 113
14 SIP Authentication using HTTP Basic and Digest
Schemes ............................................. 113
14.1 Framework ........................................... 113
14.2 Basic Authentication ................................ 114
14.3 Digest Authentication ............................... 114
14.4 Proxy-Authentication ................................ 115
15 SIP Security Using PGP .............................. 115
15.1 PGP Authentication Scheme ........................... 115
15.1.1 The WWW-Authenticate Response Header ................ 116
15.1.2 The Authorization Request Header .................... 117
15.2 PGP Encryption Scheme ............................... 118
15.3 Response-Key Header Field for PGP ................... 119
16 Examples ............................................ 119
16.1 Registration ........................................ 119
16.2 Invitation to a Multicast Conference ................ 121
16.2.1 Request ............................................. 121
16.2.2 Response ............................................ 122
16.3 Two-party Call ...................................... 123
16.4 Terminating a Call .................................. 125
16.5 Forking Proxy ....................................... 126
16.6 Redirects ........................................... 130
16.7 Negotiation ......................................... 131
16.8 OPTIONS Request ..................................... 132
A Minimal Implementation .............................. 134
A.1 Client .............................................. 134
A.2 Server .............................................. 135
A.3 Header Processing ................................... 135
B Usage of the Session Description Protocol (SDP)...... 136
B.1 Configuring Media Streams ........................... 136
B.2 Setting SDP Values for Unicast ...................... 138
B.3 Multicast Operation ................................. 139
B.4 Delayed Media Streams ............................... 139
B.5 Putting Media Streams on Hold ....................... 139
B.6 Subject and SDP "s=" Line ........................... 140
B.7 The SDP "o=" Line ................................... 140
C Summary of Augmented BNF ............................ 141
C.1 Basic Rules ......................................... 143
D Using SRV DNS Records ............................... 146
E IANA Considerations ................................. 148
F Acknowledgments ..................................... 149
G Authors' Addresses .................................. 149
H Bibliography ........................................ 150
I Full Copyright Statement ............................ 153
1 Introduction 1 Introduction
1.1 Overview of SIP Functionality 1.1 Overview of SIP Functionality
The Session Initiation Protocol (SIP) is an application-layer control The Session Initiation Protocol (SIP) is an application-layer control
protocol that can establish, modify and terminate multimedia sessions protocol that can establish, modify and terminate multimedia sessions
or calls. These multimedia sessions include multimedia conferences, or calls. These multimedia sessions include multimedia conferences,
distance learning, Internet telephony and similar applications. SIP distance learning, Internet telephony and similar applications. SIP
can invite both persons and "robots", such as a media storage can invite both persons and "robots", such as a media storage
skipping to change at page 4, line 34 skipping to change at page 9, line 27
to the same multicast session by several people, each of these to the same multicast session by several people, each of these
invitations will be a unique call. A point-to-point Internet invitations will be a unique call. A point-to-point Internet
telephony conversation maps into a single SIP call. In a telephony conversation maps into a single SIP call. In a
multiparty conference unit (MCU) based call-in conference, each multiparty conference unit (MCU) based call-in conference, each
participant uses a separate call to invite himself to the MCU. participant uses a separate call to invite himself to the MCU.
Call leg: A call leg is identified by the combination of Call-ID, To Call leg: A call leg is identified by the combination of Call-ID, To
and From. and From.
Client: An application program that sends SIP requests. Clients may Client: An application program that sends SIP requests. Clients may
or may not interact directly with a human user. User agents and or may not interact directly with a human user. User agents and
proxies contain clients (and servers). proxies contain clients (and servers).
Conference: A multimedia session (see below), identified by a common Conference: A multimedia session (see below), identified by a common
session description. A conference can have zero or more members session description. A conference can have zero or more members
and includes the cases of a multicast conference, a full-mesh and includes the cases of a multicast conference, a full-mesh
conference and a two-party "telephone call", as well as conference and a two-party "telephone call", as well as
combinations of these. Any number of calls can be used to combinations of these. Any number of calls can be used to
create a conference. create a conference.
Downstream: Requests sent in the direction from the caller to the Downstream: Requests sent in the direction from the caller to the
callee (i.e., user agent client to user agent server). callee (i.e., user agent client to user agent server).
Final response: A response that terminates a SIP transaction, as Final response: A response that terminates a SIP transaction, as
opposed to a provisional response that does not. All 2xx, 3xx, opposed to a provisional response that does not. All 2xx, 3xx,
4xx, 5xx and 6xx responses are final. 4xx, 5xx and 6xx responses are final.
Initiator, calling party, caller: The party initiating a conference Initiator, calling party, caller: The party initiating a conference
invitation. Note that the calling party does not have to be the invitation. Note that the calling party does not have to be the
same as the one creating the conference. same as the one creating the conference.
Invitation: A request sent to a user (or service) requesting Invitation: A request sent to a user (or service) requesting
participation in a session. A successful SIP invitation consists participation in a session. A successful SIP invitation consists
of two transactions: an INVITE request followed by an ACK of two transactions: an INVITE request followed by an ACK
request. request.
Invitee, invited user, called party, callee: The person or service Invitee, invited user, called party, callee: The person or service
that the calling party is trying to invite to a conference. that the calling party is trying to invite to a conference.
Isomorphic request or response: Two requests or responses are defined Isomorphic request or response: Two requests or responses are defined
to be isomorphic for the purposes of this document if they have to be isomorphic for the purposes of this document if they have
the same values for the Call-ID, To, From and CSeq header the same values for the Call-ID, To, From and CSeq header
fields. In addition, requests have to have the same Request-URI. fields. In addition, isomorphic requests have to have the same
Request-URI.
Location server: See location service. Location server: See location service.
Location service: A location service is used by a SIP redirect or Location service: A location service is used by a SIP redirect or
proxy server to obtain information about a callee's possible proxy server to obtain information about a callee's possible
location(s). Location services are offered by location servers. location(s). Location services are offered by location servers.
Location servers MAY be co-located with a SIP server, but the Location servers MAY be co-located with a SIP server, but the
manner in which a SIP server requests location services is manner in which a SIP server requests location services is
beyond the scope of this document. beyond the scope of this document.
skipping to change at page 5, line 48 skipping to change at page 10, line 43
Proxy, proxy server: An intermediary program that acts as both a Proxy, proxy server: An intermediary program that acts as both a
server and a client for the purpose of making requests on behalf server and a client for the purpose of making requests on behalf
of other clients. Requests are serviced internally or by passing of other clients. Requests are serviced internally or by passing
them on, possibly after translation, to other servers. A proxy them on, possibly after translation, to other servers. A proxy
interprets, and, if necessary, rewrites a request message before interprets, and, if necessary, rewrites a request message before
forwarding it. forwarding it.
Redirect server: A redirect server is a server that accepts a SIP Redirect server: A redirect server is a server that accepts a SIP
request, maps the address into zero or more new addresses and request, maps the address into zero or more new addresses and
returns these addresses to the client. Unlike a proxy server , returns these addresses to the client. Unlike a proxy server ,
it does not initiate its own SIP request. Unlike a user agent it does not initiate its own SIP request. Unlike a user agent
server , it does not accept calls. server , it does not accept calls.
Registrar: A registrar is a server that accepts REGISTER requests. A Registrar: A registrar is a server that accepts REGISTER requests. A
registrar is typically co-located with a proxy or redirect registrar is typically co-located with a proxy or redirect
server and MAY offer location services. server and MAY offer location services.
Ringback: Ringback is the signaling tone produced by the calling Ringback: Ringback is the signaling tone produced by the calling
client's application indicating that a called party is being client's application indicating that a called party is being
alerted (ringing). alerted (ringing).
skipping to change at page 6, line 25 skipping to change at page 11, line 21
requests. Servers are either proxy, redirect or user agent requests. Servers are either proxy, redirect or user agent
servers or registrars. servers or registrars.
Session: From the SDP specification: "A multimedia session is a set Session: From the SDP specification: "A multimedia session is a set
of multimedia senders and receivers and the data streams flowing of multimedia senders and receivers and the data streams flowing
from senders to receivers. A multimedia conference is an example from senders to receivers. A multimedia conference is an example
of a multimedia session." (RFC 2327 [6]) (A session as defined of a multimedia session." (RFC 2327 [6]) (A session as defined
for SDP can comprise one or more RTP sessions.) As defined, a for SDP can comprise one or more RTP sessions.) As defined, a
callee can be invited several times, by different calls, to the callee can be invited several times, by different calls, to the
same session. If SDP is used, a session is defined by the same session. If SDP is used, a session is defined by the
concatenation of the user name , session id , network type , concatenation of the user name , session id , network type ,
address type and address elements in the origin field. address type and address elements in the origin field.
(SIP) transaction: A SIP transaction occurs between a client and a (SIP) transaction: A SIP transaction occurs between a client and a
server and comprises all messages from the first request sent server and comprises all messages from the first request sent
from the client to the server up to a final (non-1xx) response from the client to the server up to a final (non-1xx) response
sent from the server to the client. A transaction is identified sent from the server to the client. A transaction is identified
by the CSeq sequence number (Section 6.17) within a single call by the CSeq sequence number (Section 6.17) within a single call
leg. The ACK request has the same CSeq number as the leg. The ACK request has the same CSeq number as the
corresponding INVITE request, but comprises a transaction of its corresponding INVITE request, but comprises a transaction of its
own. own.
Upstream: Responses sent in the direction from the user agent server Upstream: Responses sent in the direction from the user agent server
to the user agent client. to the user agent client.
URL-encoded: A character string encoded according to RFC 1738, URL-encoded: A character string encoded according to RFC 1738,
Section 2.2 [13]. Section 2.2 [13].
User agent client (UAC), calling user agent: A user agent client is a User agent client (UAC), calling user agent: A user agent client is a
client application that initiates the SIP request. client application that initiates the SIP request.
User agent server (UAS), called user agent: A user agent server is a User agent server (UAS), called user agent: A user agent server is a
server application that contacts the user when a SIP request is server application that contacts the user when a SIP request is
received and that returns a response on behalf of the user. The received and that returns a response on behalf of the user. The
response accepts, rejects or redirects the request. response accepts, rejects or redirects the request.
User agent (UA): An application which contains both a user agent
client and user agent server.
An application program MAY be capable of acting both as a client and An application program MAY be capable of acting both as a client and
a server. For example, a typical multimedia conference control a server. For example, a typical multimedia conference control
application would act as a user agent client to initiate calls or to application would act as a user agent client to initiate calls or to
invite others to conferences and as a user agent server to accept invite others to conferences and as a user agent server to accept
invitations. The properties of the different SIP server types are invitations. The properties of the different SIP server types are
summarized in Table 1. summarized in Table 1.
property redirect proxy user agent registrar property redirect proxy user agent registrar
server server server server server server
__________________________________________________________________ __________________________________________________________________
also acts as a SIP client no yes no no also acts as a SIP client no yes no no
returns 1xx status yes yes yes yes returns 1xx status yes yes yes yes
returns 2xx status no yes yes yes returns 2xx status no yes yes yes
returns 3xx status yes yes yes yes returns 3xx status yes yes yes yes
returns 4xx status yes yes yes yes returns 4xx status yes yes yes yes
returns 5xx status yes yes yes yes returns 5xx status yes yes yes yes
returns 6xx status no yes yes no returns 6xx status no yes yes yes
inserts Via header no yes no no inserts Via header no yes no no
accepts ACK yes yes yes no accepts ACK yes yes yes no
Table 1: Properties of the different SIP server types Table 1: Properties of the different SIP server types
1.4 Overview of SIP Operation 1.4 Overview of SIP Operation
This section explains the basic protocol functionality and operation. This section explains the basic protocol functionality and operation.
Callers and callees are identified by SIP addresses, described in Callers and callees are identified by SIP addresses, described in
Section 1.4.1. When making a SIP call, a caller first locates the Section 1.4.1. When making a SIP call, a caller first locates the
skipping to change at page 7, line 41 skipping to change at page 12, line 40
(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 or a numeric network address. The host part is either a domain name or a numeric network address.
See section 2 for a detailed discussion of SIP URL's. 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
skipping to change at page 9, line 38 skipping to change at page 14, line 40
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 follow the procedures in RFC1035 [15] regarding DNS cache client MUST follow the procedures in RFC1035 [15] regarding DNS cache
invalidation when the DNS time-to-live expires. invalidation when the DNS time-to-live expires.
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 requwwests to that server and receives one or sends one or more SIP requests to that server and receives one or
more responses from the server. A request (and its retransmissions) more responses from the server. A request (and its retransmissions)
together with the responses triggered by that request make up a SIP together with the responses triggered by that request make up a SIP
transaction. 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 10, line 32 skipping to change at page 15, line 36
that it has received that response by sending an ACK (Section 4.2.2) that it has received that response by sending an ACK (Section 4.2.2)
request. If the caller no longer wants to participate in the call, it request. If the caller no longer wants to participate in the call, it
sends a BYE request instead of an ACK. sends a BYE request instead of an ACK.
The INVITE request typically contains a session description, for The INVITE request typically contains a session description, for
example written in SDP (RFC 2327 [6]) format, that provides the example written in SDP (RFC 2327 [6]) format, that provides the
called party with enough information to join the session. For called party with enough information to join the session. For
multicast sessions, the session description enumerates the media multicast sessions, the session description enumerates the media
types and formats that are allowed to be distributed to that session. types and formats that are allowed to be distributed to that session.
For a unicast session, the session description enumerates the media For a unicast session, the session description enumerates the media
types and formats that the caller is willing to receive and where it types and formats that the caller is willing to use and where it
wishes the media data to be sent. In either case, if the callee wishes the media data to be sent. In either case, if the callee
wishes to accept the call, it responds to the invitation by returning wishes to accept the call, it responds to the invitation by returning
a similar description listing the media it wishes to receive. For a a similar description listing the media it wishes to use. For a
multicast session, the callee SHOULD only return a session multicast session, the callee SHOULD only return a session
description if it is unable to receive the media indicated in the description if it is unable to receive the media indicated in the
caller's description or wants to receive data via unicast. caller's description or wants to receive data via unicast.
The protocol exchanges for the INVITE method are shown in Fig. 1 for The protocol exchanges for the INVITE method are shown in Fig. 1 for
a proxy server and in Fig. 2 for a redirect server. (Note that the a proxy server and in Fig. 2 for a redirect server. (Note that the
messages shown in the figures have been abbreviated slightly.) In messages shown in the figures have been abbreviated slightly.) In
Fig. 1, the proxy server accepts the INVITE request (step 1), Fig. 1, the proxy server accepts the INVITE request (step 1),
contacts the location service with all or parts of the address (step contacts the location service with all or parts of the address (step
2) and obtains a more precise location (step 3). The proxy server 2) and obtains a more precise location (step 3). The proxy server
skipping to change at page 12, line 32 skipping to change at page 17, line 35
The action taken on receiving a list of locations varies with the The action taken on receiving a list of locations varies with the
type of SIP server. A SIP redirect server returns the list to the type of SIP server. A SIP redirect server returns the list to the
client as Contact headers (Section 6.13). A SIP proxy server can client as Contact headers (Section 6.13). A SIP proxy server can
sequentially or in parallel try the addresses until the call is sequentially or in parallel try the addresses until the call is
successful (2xx response) or the callee has declined the call (6xx successful (2xx response) or the callee has declined the call (6xx
response). With sequential attempts, a proxy server can implement an response). With sequential attempts, a proxy server can implement an
"anycast" service. "anycast" service.
If a proxy server forwards a SIP request, it MUST add itself to the If a proxy server forwards a SIP request, it MUST add itself to the
end of the list of forwarders noted in the Via (Section 6.40) beginning of the list of forwarders noted in the Via (Section 6.40)
headers. The Via trace ensures that replies can take the same path headers. The Via trace ensures that replies can take the same path
back, ensuring correct operation through compliant firewalls and back, ensuring correct operation through compliant firewalls and
avoiding request loops. On the response path, each host MUST remove avoiding request loops. On the response path, each host MUST remove
its Via, so that routing internal information is hidden from the its Via, so that routing internal information is hidden from the
callee and outside networks. A proxy server MUST check that it does callee and outside networks. A proxy server MUST check that it does
not generate a request to a host listed in the Via sent-by, via- not generate a request to a host listed in the Via sent-by, via-
received or via-maddr parameters (Section 6.40). (Note: If a host has received or via-maddr parameters (Section 6.40). (Note: If a host has
several names or network addresses, this does not always work. Thus, several names or network addresses, this does not always work. Thus,
each host also checks if it is part of the Via list.) each host also checks if it is part of the Via list.)
skipping to change at page 13, line 49 skipping to change at page 19, line 5
or a byte stream service, with reliable or unreliable service. or a byte stream service, with reliable or unreliable service.
In an Internet context, SIP is able to utilize both UDP and TCP as In an Internet context, SIP is able to utilize both UDP and TCP as
transport protocols, among others. UDP allows the application to more transport protocols, among others. UDP allows the application to more
carefully control the timing of messages and their retransmission, to carefully control the timing of messages and their retransmission, to
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
contact a user or to modify parameters of an existing conference.
Different SIP requests for the same SIP call MAY use different TCP
connections or a single persistent connection, as appropriate.
+....... cs.columbia.edu .......+ +....... cs.columbia.edu .......+
: : : :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ( location ) : : ( location ) :
: ( service ) : : ( service ) :
: (~~~~~~~~~~) : : (~~~~~~~~~~) :
: ^ | : : ^ | :
: | hgs@lab : : | hgs@lab :
: 2| 3| : : 2| 3| :
: | | : : | | :
skipping to change at page 15, line 4 skipping to change at page 20, line 4
+...............................+ +...............................+
====> SIP request ====> SIP request
....> SIP response ....> SIP response
^ ^
| non-SIP protocols | non-SIP protocols
| |
Figure 2: Example of SIP redirect server Figure 2: Example of SIP redirect server
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.
Different SIP requests for the same SIP call MAY use different TCP
connections or a single persistent connection, as appropriate.
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 15, line 45 skipping to change at page 21, line 5
part of an email message. part of an email message.
A SIP URL follows the guidelines of RFC 2396 [12] and has the syntax A SIP URL follows the guidelines of RFC 2396 [12] and has the syntax
shown in Fig. 3. The syntax is described using Augmented Backus-Naur shown in Fig. 3. The syntax is described using Augmented Backus-Naur
Form (See Section C). Note that reserved characters have to be Form (See Section C). Note that reserved characters have to be
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
C.
The components of the SIP URI have the following meanings.
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 [ "." ]
skipping to change at page 16, line 42 skipping to change at page 21, 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
The URI character classes referenced above are described in Appendix
C.
The components of the SIP URI have the following meanings.
telephone-subscriber = global-phone-number | local-phone-number
global-phone-number = "+" 1*phonedigit [isdn-subaddress]
[post-dial]
local-phone-number = 1*(phonedigit | dtmf-digit |
pause-character) [isdn-subaddress]
[post-dial]
isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit | dtmf-digit
| pause-character)
phonedigit = DIGIT | visual-separator
visual-separator = "-" | "."
pause-character = one-second-pause | wait-for-dial-tone
one-second-pause = "p"
wait-for-dial-tone = "w"
dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D"
Figure 4: SIP URL syntax; telephone subscriber
user: If the host is an Internet telephony gateway, the user field user: If the host is an Internet telephony gateway, the user field
MAY also encode a telephone number using the notation of 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,
telephone-subscriber = global-phone-number | local-phone-number
global-phone-number = "+" 1*phonedigit [isdn-subaddress]
[post-dial]
local-phone-number = 1*(phonedigit | dtmf-digit |
pause-character) [isdn-subaddress]
[post-dial]
isdn-subaddress = ";" "isub=" 1*phonedigit
post-dial = ";" "postd=" 1*(phonedigit | dtmf-digit
| pause-character)
phonedigit = DIGIT | visual-separator
visual-separator = "-" | "."
pause-character = one-second-pause | wait-for-dial-tone
one-second-pause = "p"
wait-for-dial-tone = "w"
dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D"
Figure 4: SIP URL syntax; telephone subscriber
recipients of SIP URLs MAY interpret the pre-@ part as a phone recipients of SIP URLs MAY interpret the pre-@ part as a phone
number if local restrictions on the name space for user name number if local restrictions on the name space for user name
allow it. allow it.
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.
skipping to change at page 18, line 42 skipping to change at page 24, line 5
Method: The method of the SIP request can be specified with the Method: The method of the SIP request can be specified with the
method parameter. This parameter MUST NOT be used in the From method parameter. This parameter MUST NOT be used in the From
and To header fields and the Request-URI; they are ignored if and To header fields and the Request-URI; they are ignored if
present. present.
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:secret@big.com;transport=tcp
sip:j.doe@big.com?subject=project
sip:+1-212-555-1212:1234@gateway.com;user=phone
sip:1212@gateway.com
sip:alice@10.1.2.3
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:j.doe@big.com
sip:j.doe:secret@big.com;transport=tcp
sip:j.doe@big.com?subject=project
sip:+1-212-555-1212:1234@gateway.com;user=phone
sip:1212@gateway.com
sip:alice@10.1.2.3
sip:alice@example.com sip:alice@example.com
sip:alice sip:alice%40example.com@gateway.com
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
sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All
URL parameters are included when comparing SIP URLs for equality. URL parameters are included when comparing SIP URLs for equality.
skipping to change at page 21, line 11 skipping to change at page 26, line 16
start-line = Request-Line | ;Section 4.1 start-line = Request-Line | ;Section 4.1
Status-Line ;Section 5.1 Status-Line ;Section 5.1
message-header = ( general-header message-header = ( general-header
| request-header | request-header
| response-header | response-header
| entity-header ) | entity-header )
In the interest of robustness, any leading empty line(s) MUST be In the interest of robustness, any leading empty line(s) MUST be
ignored. In other words, if the Request or Response message begins ignored. In other words, if the Request or Response message begins
with one or more CRLF, CR, or LFs, these characters MUST be ignored. with one or more CRLF, CR, or LFs, these characters MUST be ignored.
4 Request 4 Request
The Request message format is shown below: The Request message format is shown below:
Request = Request-Line ; Section 4.1 Request = Request-Line ; Section 4.1
*( general-header *( general-header
| request-header | request-header
| entity-header ) | entity-header )
skipping to change at page 21, line 33 skipping to change at page 27, line 4
[ message-body ] ; Section 8 [ message-body ] ; Section 8
4.1 Request-Line 4.1 Request-Line
The Request-Line begins with a method token, followed by the The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF are allowed elements are separated by SP characters. No CR or LF are allowed
except in the final CRLF sequence. except in the final CRLF sequence.
Request-Line = Method SP Request-URI SP SIP-Version CRLF Request-Line = Method SP Request-URI SP SIP-Version CRLF
4.2 Methods
The methods are defined below. Methods that are not supported by a
proxy or redirect server are treated by that server as if they were
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 22, line 45 skipping to change at page 27, line 44
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
4.2 Methods
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
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.
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 23, line 41 skipping to change at page 29, line 8
(Versioning of the session description can be used to accommodate the (Versioning of the session description can be used to accommodate the
capabilities of new arrivals to a conference, add or delete media or capabilities of new arrivals to a conference, add or delete media or
change from a unicast to a multicast conference.) change from a unicast to a multicast conference.)
This method MUST be supported by SIP proxy, redirect and user agent This method MUST be supported by SIP proxy, redirect and user agent
servers as well as clients. servers as well as clients.
4.2.2 ACK 4.2.2 ACK
The ACK request confirms that the client has received a final The ACK request confirms that the client has received a final
response to an INVITE request. (ACK is used only with INVITE response to an INVITE request. (ACK is used only with INVITE
requests.) 2xx responses are acknowledged by client user agents, all requests.) 2xx responses are acknowledged by client user agents, all
other final responses by the first proxy or client user agent to other final responses by the first proxy or client user agent to
receive the response. The Via is always initialized to the host that receive the response. The Via is always initialized to the host that
originates the ACK request, i.e., the client user agent after a 2xx originates the ACK request, i.e., the client user agent after a 2xx
response or the first proxy to receive a non-2xx final response. The response or the first proxy to receive a non-2xx final response. The
ACK request is forwarded as the corresponding INVITE request, based ACK request is forwarded as the corresponding INVITE request, based
on its Request-URI. See Section 10 for details. on its Request-URI. See Section 10 for details.
The ACK request MAY contain a message body with the final session The ACK request MAY contain a message body with the final session
description to be used by the callee. If the ACK message body is description to be used by the callee. If the ACK message body is
empty, the callee uses the session description in the INVITE request. empty, the callee uses the session description in the INVITE request.
A proxy server receiving an ACK request after having sent a 3xx, 4xx, A proxy server receiving an ACK request after having sent a 3xx, 4xx,
5xx, or 6xx response must make a determination about whether the ACK 5xx, or 6xx response must make a determination about whether the ACK
is for it, or for some user agent or proxy server further downstream. is for it, or for some user agent or proxy server further downstream.
This determination is made by examining the tag in the To field. If This determination is made by examining the tag in the To field. If
the tag in the ACK To header field matches the tag in the To header the tag in the ACK To header field matches the tag in the To header
field of the response, and the From, CSeq and Call-ID header fields field of the response, and the From, CSeq and Call-ID header fields
in the response match those in the ACK, the ACK is meant for the in the response match those in the ACK, the ACK is meant for the
proxy server. Otherwise, the ACK SHOULD be proxied downstream as any proxy server. Otherwise, the ACK SHOULD be proxied downstream as any
other request. other request.
It is possible for a user agent client or proxy server to It is possible for a user agent client or proxy server to
receive multiple 3xx, 4xx, 5xx, and 6xx responses to a receive multiple 3xx, 4xx, 5xx, and 6xx responses to a
request along a single branch. This can happen under request along a single branch. This can happen under
various error conditions, typically when a forking proxy various error conditions, typically when a forking proxy
transitions from stateful to stateless before receiving all transitions from stateful to stateless before receiving all
responses. The various responses will all be identical, responses. The various responses will all be identical,
except for the tag in the To field, which is different for except for the tag in the To field, which is different for
each one. It can therefore be used as a means to each one. It can therefore be used as a means to
skipping to change at page 26, line 19 skipping to change at page 31, line 33
4.2.6 REGISTER 4.2.6 REGISTER
A client uses the REGISTER method to register the address listed in A client uses the REGISTER method to register the address listed in
the To header field with a SIP server. the To header field with a SIP server.
A user agent MAY register with a local server on startup by sending a A user agent MAY register with a local server on startup by sending a
REGISTER request to the well-known "all SIP servers" multicast REGISTER request to the well-known "all SIP servers" multicast
address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped
to ensure it is not forwarded beyond the boundaries of the to ensure it is not forwarded beyond the boundaries of the
administrative system. This MAY be done with either TTL or administrative system. This MAY be done with either TTL or
administrative scopes[25], depending on what is implemented in the administrative scopes [25], depending on what is implemented in the
network. SIP user agents MAY listen to that address and use it to network. SIP user agents MAY listen to that address and use it to
become aware of the location of other local users [20]; however, they become aware of the location of other local users [20]; however, they
do not respond to the request. A user agent MAY also be configured do not respond to the request. A user agent MAY also be configured
with the address of a registrar server to which it sends a REGISTER with the address of a registrar server to which it sends a REGISTER
request upon startup. request upon startup.
Requests are processed in the order received. Clients SHOULD avoid Requests are processed in the order received. Clients SHOULD avoid
sending a new registration (as opposed to a retransmission) until sending a new registration (as opposed to a retransmission) until
they have received the response from the server for the previous one. they have received the response from the server for the previous one.
Clients may register from different locations, by necessity Clients may register from different locations, by necessity
using different Call-ID values. Thus, the CSeq value cannot using different Call-ID values. Thus, the CSeq value cannot
be used to enforce ordering. Since registrations are be used to enforce ordering. Since registrations are
skipping to change at page 27, line 8 skipping to change at page 32, line 23
From: The From header field contains the address-of-record of the From: The From header field contains the address-of-record of the
person responsible for the registration. For first-party person responsible for the registration. For first-party
registration, it is identical to the To header field value. registration, it is identical to the To header field value.
Request-URI: The Request-URI names the destination of the Request-URI: The Request-URI names the destination of the
registration request, i.e., the domain of the registrar. The registration request, i.e., the domain of the registrar. The
user name MUST be empty. Generally, the domains in the Request- user name MUST be empty. Generally, the domains in the Request-
URI and the To header field have the same value; however, it is URI and the To header field have the same value; however, it is
possible to register as a "visitor", while maintaining one's possible to register as a "visitor", while maintaining one's
name. For example, a traveller sip:alice@acme.com (To) might name. For example, a traveler sip:alice@acme.com (To) might
register under the Request-URI sip:atlanta.hiayh.org , with the register under the Request-URI sip:atlanta.hiayh.org , with the
former as the To header field and the latter as the Request-URI. former as the To header field and the latter as the Request-URI.
The request is no longer forwarded once it reached the server The REGISTER request is no longer forwarded once it has reached
whose authoritative domain is the one listed in the Request-URI. the server whose authoritative domain is the one listed in the
Request-URI.
Call-ID: All registrations from a client SHOULD use the same Call-ID Call-ID: All registrations from a client SHOULD use the same Call-ID
header value, at least within the same reboot cycle. header value, at least within the same reboot cycle.
Cseq: Registrations with the same Call-ID MUST have increasing CSeq Cseq: Registrations with the same Call-ID MUST have increasing CSeq
header values. However, the server does not reject out-of-order header values. However, the server does not reject out-of-order
requests. requests.
Contact: The request MAY contain a Contact header field; future non- Contact: The request MAY contain a Contact header field; future non-
REGISTER requests for the URI given in the To header field REGISTER requests for the URI given in the To header field
skipping to change at page 28, line 19 skipping to change at page 33, line 33
telephone network, directed pickup permits a user at a telephone network, directed pickup permits a user at a
remote station who hears his own phone ringing to pick up remote station who hears his own phone ringing to pick up
at that station, dial an access code, and be connected to at that station, dial an access code, and be connected to
the calling user as if he had answered his own phone. the calling user as if he had answered his own phone.
A server MAY choose any duration for the registration lifetime. A server MAY choose any duration for the registration lifetime.
Registrations not refreshed after this amount of time SHOULD be Registrations not refreshed after this amount of time SHOULD be
silently discarded. Responses to a registration SHOULD include an silently discarded. Responses to a registration SHOULD include an
Expires header (Section 6.20) or expires Contact parameters (Section Expires header (Section 6.20) or expires Contact parameters (Section
6.13), indicating the time at which the server will drop the 6.13), indicating the time at which the server will drop the
registration. If none is present, one hour is assumed. Clients MAY registration. If none is present, one hour is assumed. Clients MAY
request a registration lifetime by indicating the time in an Expires request a registration lifetime by indicating the time in an Expires
header in the request. A server SHOULD NOT use a higher lifetime than header in the request. A server SHOULD NOT use a higher lifetime than
the one requested, but MAY use a lower one. A single address (if the one requested, but MAY use a lower one. A single address (if
host-independent) MAY be registered from several different clients. host-independent) MAY be registered from several different clients.
A client cancels an existing registration by sending a REGISTER A client cancels an existing registration by sending a REGISTER
request with an expiration time (Expires) of zero seconds for a request with an expiration time (Expires) of zero seconds for a
particular Contact or the wildcard Contact designated by a "*" for particular Contact or the wildcard Contact designated by a "*" for
all registrations. Registrations are matched based on the user, host, all registrations. Registrations are matched based on the user, host,
port and maddr parameters. port and maddr parameters.
skipping to change at page 30, line 18 skipping to change at page 35, line 33
Syntax: Syntax:
option-tag = token option-tag = token
See Section C for a definition of token. The creator of a new SIP See Section C for a definition of token. The creator of a new SIP
option MUST either prefix the option with their reverse domain name option MUST either prefix the option with their reverse domain name
or register the new option with the Internet Assigned Numbers or register the new option with the Internet Assigned Numbers
Authority (IANA). For example, "com.foo.mynewfeature" is an apt name Authority (IANA). For example, "com.foo.mynewfeature" is an apt name
for a feature whose inventor can be reached at "foo.com". Individual for a feature whose inventor can be reached at "foo.com". Individual
organizations are then responsible for ensuring that option names organizations are then responsible for ensuring that option names
don't collide. Options registered with IANA have the prefix don't collide. Options registered with IANA have the prefix
"org.iana.sip.", options described in RFCs have the prefix "org.iana.sip.", options described in RFCs have the prefix
"org.ietf.rfc.N", where N is the RFC number. Option tags are case- "org.ietf.rfc.N", where N is the RFC number. Option tags are case-
insensitive. insensitive.
4.4.1 Registering New Option Tags with IANA 4.4.1 Registering New Option Tags with IANA
When registering a new SIP option, the following information MUST be When registering a new SIP option, the following information MUST be
provided: provided:
o Name and description of option. The name MAY be of any length, o Name and description of option. The name MAY be of any
but SHOULD be no more than twenty characters long. The name length, but SHOULD be no more than twenty characters long. The
MUST consist of alphanum (See Figure 3) characters only; name MUST consist of alphanum (See Figure 3) characters only;
o Indication of who has change control over the option (for o Indication of who has change control over the option (for
example, IETF, ISO, ITU-T, other international standardization example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of bodies, a consortium or a particular company or group of
companies); companies);
o A reference to a further description, if available, for o A reference to a further description, if available, for
example (in order of preference) an RFC, a published paper, a example (in order of preference) an RFC, a published paper, a
patent filing, a technical report, documented source code or a patent filing, a technical report, documented source code or a
computer manual; computer manual;
o Contact information (postal and email address); o Contact information (postal and email address);
Registrations should be sent to iana@iana.org. 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:
skipping to change at page 33, line 24 skipping to change at page 39, line 4
Figure 5: Informational and success status codes Figure 5: Informational and success status codes
Redirection = "300" ; Multiple Choices Redirection = "300" ; Multiple Choices
| "301" ; Moved Permanently | "301" ; Moved Permanently
| "302" ; Moved Temporarily | "302" ; Moved Temporarily
| "303" ; See Other | "303" ; See Other
| "305" ; Use Proxy | "305" ; Use Proxy
| "380" ; Alternative Service | "380" ; Alternative Service
Figure 6: Redirection status codes Figure 6: Redirection status codes
6 Header Field Definitions
SIP header fields are similar to HTTP header fields in both syntax
and semantics. In particular, SIP header fields follow the syntax for
message-header as described in [H4.2]. The rules for extending header
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
rules in [H4.2] regarding ordering of header fields apply to SIP,
with the exception of Via fields, see below, whose order matters.
Additionally, header fields which are hop-by-hop MUST appear before
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 34, line 39 skipping to change at page 39, 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
parameters as described in Section 6.40.1. Proxies MUST NOT alter any 6 Header Field Definitions
fields that are authenticated (see Section 13.2).
The header fields required, optional and not applicable for each SIP header fields are similar to HTTP header fields in both syntax
method are listed in Table 4 and Table 5. The table uses "o" to and semantics. In particular, SIP header fields follow the syntax for
message-header as described in [H4.2]. The rules for extending header
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
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
rules in [H4.2] regarding ordering of header fields apply to SIP,
with the exception of Via fields, see below, whose order matters.
Additionally, header fields which are hop-by-hop MUST appear before
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 (Section 6.23) and "fix up" the Via header fields with
"received" parameters as described in Section 6.40.1. Proxies MUST
NOT alter any 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
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 35, line 33 skipping to change at page 41, line 5
request to the response. request to the response.
The "enc." column describes whether this message header field MAY be The "enc." column describes whether this message header field MAY be
encrypted end-to-end. A "n" designates fields that MUST NOT be encrypted end-to-end. A "n" designates fields that MUST NOT be
encrypted, while "c" designates fields that SHOULD be encrypted if encrypted, while "c" designates fields that SHOULD be encrypted if
encryption is used. encryption is used.
The "e-e" column has a value of "e" for end-to-end and a value of "h" The "e-e" column has a value of "e" for end-to-end and a value of "h"
for hop-by-hop header fields. for hop-by-hop header fields.
Other header fields can be added as required; a server MUST ignore
header fields not defined in this specification that it does not
understand. A proxy MUST NOT remove or modify header fields not
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
UDP when the request has to fit into a single packet and size is an
issue.
Table 6 in Appendix A lists those header fields that different client
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 36, line 35 skipping to change at page 41, line 36
Date g e o o o o o o Date g e o o o o o o
Encryption g n e o o o o o o Encryption g n e o o o o o o
Expires g e - - - o - o Expires g e - - - o - o
From gc n e m m m m m m From gc n e m m m m m m
Hide R n h o o o o o o Hide R n h o o o o o o
Max-Forwards R n e o o o o o o Max-Forwards R n e o o o o o o
Organization g c h - - - o o o Organization g c h - - - o o o
Table 4: Summary of header fields, A--O Table 4: Summary of header fields, A--O
Other header fields can be added as required; a server MUST ignore
header fields not defined in this specification that it does not
understand. A proxy MUST NOT remove or modify header fields not
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
UDP when the request has to fit into a single packet and size is an
issue.
Table 6 in Appendix A lists those header fields that different client
and server types MUST be able to parse.
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
header fields if all parties in the communication recognize them to
be "general-header" fields. Unrecognized header fields are treated as
"entity-header" fields.
6.2 Entity Header Fields
The "entity-header" fields define meta-information about the
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
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
600,603 c e o o o o o o 600,603 c e o o o o o o
Response-Key R c e - o o o o o Response-Key R c e - o o o o o
Record-Route R h o o o o o o Record-Route R h o o o o o o
Record-Route 2xx h o o o o o o Record-Route 2xx h o o o o o o
Route R h - o o o o o Route R h o o o o o o
Server r c e o o o o o o Server r c e o o o o o o
Subject R c e - - - o - - Subject R c e - - - o - -
Timestamp g e o o o o o o Timestamp g e o o o o o o
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
experimental header fields MAY be given the semantics of general
header fields if all parties in the communication recognize them to
be "general-header" fields. Unrecognized header fields are treated as
"entity-header" fields.
6.2 Entity Header Fields
The "entity-header" fields define meta-information about the
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
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
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 38, line 44 skipping to change at page 44, line 11
MUST follow HTTP "common form" when generating these constructs, MUST follow HTTP "common form" when generating these constructs,
since there might exist some implementations that fail to accept since there might exist some implementations that fail to accept
anything beyond the common forms. anything beyond the common forms.
message-header = field-name ":" [ field-value ] CRLF message-header = field-name ":" [ field-value ] CRLF
field-name = token field-name = token
field-value = *( field-content | LWS ) field-value = *( field-content | LWS )
field-content = < the OCTETs making up the field-value field-content = < the OCTETs making up the field-value
and consisting of either *TEXT-UTF8 and consisting of either *TEXT-UTF8
or combinations of token, or combinations of token,
tspecials, and quoted-string> separators, and quoted-string>
The relative order of header fields with different field names is not The relative order of header fields with different field names is not
significant. Multiple header fields with the same field-name may be significant. Multiple header fields with the same field-name may be
present in a message if and only if the entire field-value for that present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list (i.e., #(values)). header field is defined as a comma-separated list (i.e., #(values)).
It MUST be possible to combine the multiple header fields into one It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the "field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded. change the order of these field values when a message is forwarded.
Field names are not case-sensitive, although their values may be. Field names are not case-sensitive, although their values may be.
skipping to change at page 42, line 34 skipping to change at page 48, line 7
proxies. The Via header is not sufficient since the proxies. The Via header is not sufficient since the
desired address may be that of a proxy. desired address may be that of a proxy.
INVITE 2xx responses: A user agent server sending a definitive, INVITE 2xx responses: A user agent server sending a definitive,
positive response (2xx) MAY insert a Contact response header positive response (2xx) MAY insert a Contact response header
field indicating the SIP address under which it is reachable field indicating the SIP address under which it is reachable
most directly for future SIP requests, such as ACK, within the most directly for future SIP requests, such as ACK, within the
same Call-ID. The Contact header field contains the address of same Call-ID. The Contact header field contains the address of
the server itself or that of a proxy, e.g., if the host is the server itself or that of a proxy, e.g., if the host is
behind a firewall. The value of this Contact header is copied behind a firewall. The value of this Contact header is copied
into the Request-URI of subsequent requests for this call. If into the Request-URI of subsequent requests for this call if the
the response also contains a Record-Route header field, the response did not also contain a Record-Route header. If the
address in the Contact header field is added as the last item in response also contains a Record-Route header field, the address
the Route header field. See Section 6.29 for details. in the Contact header field is added as the last item in the
Route header field. See Section 6.29 for details.
The Contact value SHOULD NOT be cached across calls, as it The Contact value SHOULD NOT be cached across calls, as it
may not represent the most desirable location for a may not represent the most desirable location for a
particular destination address. particular destination address.
INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY
insert a Contact response header. It has the same semantics in a insert a Contact response header. It has the same semantics in a
1xx response as a 2xx INVITE response. Note that CANCEL requests 1xx response as a 2xx INVITE response. Note that CANCEL requests
MUST NOT be sent to that address, but rather follow the same MUST NOT be sent to that address, but rather follow the same
path as the original request. path as the original request.
skipping to change at page 44, line 26 skipping to change at page 50, line ?
client. If this parameter is not specified the action taken client. If this parameter is not specified the action taken
depends on server configuration. In its response, the registrar depends on server configuration. In its response, the registrar
SHOULD indicate the mode used. This parameter is ignored for SHOULD indicate the mode used. This parameter is ignored for
other requests. other requests.
expires: The "expires" parameter indicates how long the URI is valid. expires: The "expires" parameter indicates how long the URI is valid.
The parameter is either a number indicating seconds or a quoted The parameter is either a number indicating seconds or a quoted
string containing 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 seconds or 136 years) as equivalent to
2**32-1.
Contact = ( "Contact" | "m" ) ":" ("*" | (1# ( name-addr | addr-spec )
[ *( ";" contact-params ) ] [ comment ] ))
name-addr = [ display-name ] "<" addr-spec ">" Contact = ( "Contact" | "m" ) ":"
addr-spec = SIP-URL | URI ("*" | (1# (( name-addr | addr-spec )
display-name = *token | quoted-string [ *( ";" contact-params ) ] [ comment ] )))
contact-params = "q" "=" qvalue name-addr = [ display-name ] "<" addr-spec ">"
| "action" "=" "proxy" | "redirect" addr-spec = SIP-URL | URI
| "expires" "=" delta-seconds | <"> SIP-date <"> display-name = *token | quoted-string
| extension-attribute
extension-attribute = extension-name [ "=" extension-value ] contact-params = "q" "=" qvalue
| "action" "=" "proxy" | "redirect"
| "expires" "=" delta-seconds | <"> SIP-date <">
| extension-attribute
Even if the "display-name" is empty, the "name-addr" form MUST be extension-attribute = extension-name [ "=" extension-value ]
used if the "addr-spec" contains a comma, semicolon or question mark.
The Contact header field fulfills functionality similar to
the Location header field in HTTP. However, the HTTP header
only allows one address, unquoted. Since URIs can contain only allows one address, unquoted. Since URIs can contain
commas and semicolons as reserved characters, they can be commas and semicolons as reserved characters, they can be
mistaken for header or parameter delimiters, respectively. mistaken for header or parameter delimiters, respectively.
The current syntax corresponds to that for the To and From The current syntax corresponds to that for the To and From
header, which also allows the use of display names. header, which also allows the use of display names.
Example: Example:
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com> Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600, ;q=0.7; expires=3600,
skipping to change at page 55, line 31 skipping to change at page 60, line 38
"emergency". "emergency".
6.26 Proxy-Authenticate 6.26 Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as part The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response. The field value of a 407 (Proxy Authentication Required) response. The field value
consists of a challenge that indicates the authentication scheme and consists of a challenge that indicates the authentication scheme and
parameters applicable to the proxy for this Request-URI. parameters applicable to the proxy for this Request-URI.
Unlike its usage within HTTP, the Proxy-Authenticate header MUST be Unlike its usage within HTTP, the Proxy-Authenticate header MUST be
passed upstream in the response to tha UAC. In SIP, only UAC's can passed upstream in the response to the UAC. In SIP, only UAC's can
authenticate themselves to proxies. authenticate themselves to proxies.
The syntax for this header is defined in [H14.33]. See 14 for further The syntax for this header is defined in [H14.33]. See 14 for further
details on its usage. details on its usage.
A client SHOULD cache the credentials used for a particular proxy A client SHOULD cache the credentials used for a particular proxy
server and realm for the next request to that server. Credentials server and realm for the next request to that server. Credentials
are, in general, valid for a specific value of the Request-URI at a are, in general, valid for a specific value of the Request-URI at a
particular proxy server. If a client contacts a proxy server that has particular proxy server. If a client contacts a proxy server that has
required authentication in the past, but the client does not have required authentication in the past, but the client does not have
skipping to change at page 56, line 35 skipping to change at page 61, line 46
See [H14.34] for a definition of the syntax, and section 14 for a See [H14.34] for a definition of the syntax, and section 14 for a
discussion of its usage. discussion of its usage.
6.28 Proxy-Require 6.28 Proxy-Require
The Proxy-Require header field is used to indicate proxy-sensitive The Proxy-Require header field is used to indicate proxy-sensitive
features that MUST be supported by the proxy. Any Proxy-Require features that MUST be supported by the proxy. Any Proxy-Require
header field features that are not supported by the proxy MUST be header field features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client if not supported. negatively acknowledged by the proxy to the client if not supported.
Servers treat this field identically to the Require field. Proxy servers treat this field identically to the Require field.
See Section 6.30 for more details on the mechanics of this message See Section 6.30 for more details on the mechanics of this message
and a usage example. and a usage example.
6.29 Record-Route 6.29 Record-Route
The Record-Route request and response header field is added to a The Record-Route request and response header field is added to a
request by any proxy that insists on being in the path of subsequent request by any proxy that insists on being in the path of subsequent
requests for the same call leg. It contains a globally reachable requests for the same call leg. It contains a globally reachable
Request-URI that identifies the proxy server. Each proxy server adds Request-URI that identifies the proxy server. Each proxy server adds
its Request-URI to the beginning of the list. its Request-URI to the beginning of the list.
The server copies the Record-Route header field unchanged into the The server copies the Record-Route header field unchanged into the
response. (Record-Route is only relevant for 2xx responses.) response. (Record-Route is only relevant for 2xx responses.)
The calling user agent client copies the Record-Route header into a The calling user agent client copies the Record-Route header into a
Route header field of subsequent requests within the same call leg, Route header field of subsequent requests within the same call leg,
reversing the order of requests, so that the first entry is closest reversing the order of requests, so that the first entry is closest
to the user agent client. If the response contained a Contact header to the user agent client. If the response contained a Contact header
field, the calling user agent adds its content as the last Route field, the calling user agent adds its content as the last Route
header. Unless this would cause a loop, any client MUST send any header. Unless this would cause a loop, any client MUST send any
subsequent requests for this call leg to the first Request-URI in the subsequent requests for this call leg to the first Request-URI in the
Route request header field and remove that entry. Route request header field and remove that entry.
The calling user agent MUST NOT use the Record-Route header field in The calling user agent MUST NOT use the Record-Route header field in
requests that contain Route header fields. requests that contain Route header fields.
Some proxies, such as those controlling firewalls or in an Some proxies, such as those controlling firewalls or in an
skipping to change at page 60, line 35 skipping to change at page 66, line 9
Subject = ( "Subject" | "s" ) ":" *TEXT-UTF8 Subject = ( "Subject" | "s" ) ":" *TEXT-UTF8
Example: Example:
Subject: Tune in - they are talking about your work! Subject: Tune in - they are talking about your work!
6.36 Timestamp 6.36 Timestamp
The timestamp general-header field describes when the client sent the The timestamp general-header field describes when the client sent the
request to the server. The value of the timestamp is of significance request to the server. The value of the timestamp is of significance
only to the client and MAY use any timescale. The server MUST echo only to the client and it MAY use any timescale. The server MUST echo
the exact same value and MAY, if it has accurate information about the exact same value and MAY, if it has accurate information about
this, add a floating point number indicating the number of seconds this, add a floating point number indicating the number of seconds
that have elapsed since it has received the request. The timestamp is that have elapsed since it has received the request. The timestamp is
used by the client to compute the round-trip time to the server so used by the client to compute the round-trip time to the server so
that it can adjust the timeout value for retransmissions. that it can adjust the timeout value for retransmissions.
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ] delay = *(DIGIT) [ "." *(DIGIT) ]
Note that there MUST NOT be any LWS between a DIGIT and the decimal Note that there MUST NOT be any LWS between a DIGIT and the decimal
skipping to change at page 63, line 44 skipping to change at page 69, line 9
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 gateway is required. When run over TCP, SIP stands a better
better chance of traversing NAT's, since its behavior is chance of traversing NAT's, since its behavior is similar
similar to HTTP in this case (but of course on different to HTTP in this case (but of course on different ports).
ports).
A proxy sending a request to a multicast address MUST add the "maddr" A proxy sending a request to a multicast address MUST add the "maddr"
parameter to its Via header field, and SHOULD add the "ttl" parameter 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 64, line 24 skipping to change at page 69, line 36
This prevents a malfunctioning proxy server from causing This prevents a malfunctioning proxy server from causing
loops. Also, it cannot be guaranteed that a proxy server loops. Also, it cannot be guaranteed that a proxy server
can always detect that the address returned by a location can always detect that the address returned by a location
service refers to a host listed in the Via list, as a service refers to a host listed in the Via list, as a
single host may have aliases or several network interfaces. single host may have aliases or several network interfaces.
6.40.2 Receiver-tagged Via Header Fields 6.40.2 Receiver-tagged Via Header Fields
Normally, every host that sends or forwards a SIP message adds a Via Normally, every host that sends or forwards a SIP message adds a Via
field indicating the path traversed. However, it is possible that field indicating the path traversed. However, it is possible that
Network Address Translators (NAT) changes the source address and port Network Address Translators (NATs) changes the source address and
of the request (e.g., from net-10 to a globally routable address), in port of the request (e.g., from net-10 to a globally routable
which case the Via header field cannot be relied on to route replies. address), in which case the Via header field cannot be relied on to
To prevent this, a proxy SHOULD check the top-most Via header field route replies. To prevent this, a proxy SHOULD check the top-most Via
to ensure that it contains the sender's correct network address, as header field to ensure that it contains the sender's correct network
seen from that proxy. If the sender's address is incorrect, the proxy address, as seen from that proxy. If the sender's address is
MUST add a "received" parameter to the Via header field inserted by incorrect, the proxy MUST add a "received" parameter to the Via
the previous hop. Such a modified Via header field is known as a header field inserted by the previous hop. Such a modified Via header
receiver-tagged Via header field. An example is: field is known as a receiver-tagged Via header field. An example is:
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060 Via: SIP/2.0/UDP erlang.bell-telephone.com:5060
Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3 Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3
In this example, the message originated from 10.0.0.1 and traversed a In this example, the message originated from 10.0.0.1 and traversed a
NAT with the external address border.ieee.org (199.172.136.3) to NAT with the external address border.ieee.org (199.172.136.3) to
reach erlang.bell-telephone.com. The latter noticed the mismatch, reach erlang.bell-telephone.com. The latter noticed the mismatch,
and added a parameter to the previous hop's Via header field, and added a parameter to the previous hop's Via header field,
containing the address that the packet actually came from. (Note that containing the address that the packet actually came from. (Note that
the NAT border.ieee.org is not a SIP server.) the NAT border.ieee.org is not a SIP server.)
skipping to change at page 65, line 39 skipping to change at page 70, line 51
- If neither of the previous cases apply, send the message - If neither of the previous cases apply, send the message
to the address indicated by the "sent-by" value in the to the address indicated by the "sent-by" value in the
second Via header field. second Via header field.
6.40.4 User Agent and Redirect Servers 6.40.4 User Agent and Redirect Servers
A UAS or redirect server sends a response based on one of the A UAS or redirect server sends a response based on one of the
following rules: following rules:
o If the first Via header field in the request contains a o If the first Via header field in the request contains a
"maddr" parameter, send the response to the multicast address "maddr" parameter, send the response to the multicast address
listed there, using the port indicated in "sent-by", or port listed there, using the port indicated in "sent-by", or port
5060 if none is present. The response SHOULD be sent using the 5060 if none is present. The response SHOULD be sent using the
TTL indicated in the "ttl" parameter, or with a TTL of 1 if TTL indicated in the "ttl" parameter, or with a TTL of 1 if
that parameter is not present. For robustness, responses MUST that parameter is not present. For robustness, responses MUST
be sent to the address indicated in the "maddr" parameter even be sent to the address indicated in the "maddr" parameter even
if it is not a multicast address. if it is not a multicast address.
o If the address in the "sent-by" value of the first Via field o If the address in the "sent-by" value of the first Via field
differs from the source address of the packet, send the differs from the source address of the packet, send the
response to the actual packet source address, similar to the response to the actual packet source address, similar to the
treatment for receiver-tagged Via header fields (Section treatment for receiver-tagged Via header fields (Section
6.40.2). 6.40.2).
o If neither of these conditions is true, send the response to o If neither of these conditions is true, send the response to
the address contained in the "sent-by" value. If the request the address contained in the "sent-by" value. If the request
was sent using TCP, use the existing TCP connection if was sent using TCP, use the existing TCP connection if
available. available.
6.40.5 Syntax 6.40.5 Syntax
The format for a Via header field is shown in Fig. 11. The defaults The format for a Via header field is shown in Fig. 11. The defaults
for "protocol-name" and "transport" are "SIP" and "UDP", for "protocol-name" and "transport" are "SIP" and "UDP",
respectively. The "maddr" parameter, designating the multicast respectively. The "maddr" parameter, designating the multicast
address, and the "ttl" parameter, designating the time-to-live (TTL) address, and the "ttl" parameter, designating the time-to-live (TTL)
value, are included only if the request was sent via multicast. The value, are included only if the request was sent via multicast. The
"received" parameter is added only for receiver-added Via fields "received" parameter is added only for receiver-added Via fields
(Section 6.40.2). For reasons of privacy, a client or proxy may wish (Section 6.40.2). For reasons of privacy, a client or proxy may wish
to hide its Via information by encrypting it (see Section 6.22). The to hide its Via information by encrypting it (see Section 6.22). The
"hidden" parameter is included if this header field was hidden by the "hidden" parameter is included if this header field was hidden by the
upstream proxy (see 6.22). Note that privacy of the proxy relies on upstream proxy (see 6.22). Note that privacy of the proxy relies on
the cooperation of the next hop, as the next-hop proxy will, by the cooperation of the next hop, as the next-hop proxy will, by
necessity, know the IP address and port number of the source host. necessity, know the IP address and port number of the source host.
The "branch" parameter is included by every forking proxy. The token
MUST be unique for each distinct request generated when a proxy
forks. CANCEL requests MUST have the same branch value as the
corresponding forked request. When a response arrives at the proxy it
can use the branch value to figure out which branch the response
corresponds to. A proxy which generates a single request (non-
forking) MAY also insert the "branch" parameter. The identifier has
to be unique only within a set of isomorphic requests.
Via: SIP/2.0/UDP first.example.com:4000;ttl=16
;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example)
Via: SIP/2.0/UDP adk8
Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by
*( ";" via-params ) [ comment ] ) *( ";" via-params ) [ comment ] )
via-params = via-hidden | via-ttl | via-maddr via-params = via-hidden | via-ttl | via-maddr
| via-received | via-branch | via-received | via-branch
via-hidden = "hidden" via-hidden = "hidden"
via-ttl = "ttl" "=" ttl via-ttl = "ttl" "=" ttl
via-maddr = "maddr" "=" maddr via-maddr = "maddr" "=" maddr
via-received = "received" "=" host via-received = "received" "=" host
via-branch = "branch" "=" token via-branch = "branch" "=" token
sent-protocol = protocol-name "/" protocol-version "/" transport sent-protocol = protocol-name "/" protocol-version "/" transport
protocol-name = "SIP" | token protocol-name = "SIP" | token
protocol-version = token protocol-version = token
transport = "UDP" | "TCP" | token transport = "UDP" | "TCP" | token
sent-by = ( host [ ":" port ] ) | ( concealed-host ) sent-by = ( host [ ":" port ] ) | ( concealed-host )
concealed-host = token concealed-host = token
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
Figure 11: Syntax of Via header field Figure 11: Syntax of Via header field
The "branch" parameter is included by every forking proxy. The token
MUST be unique for each distinct request generated when a proxy
forks. CANCEL requests MUST have the same branch value as the
corresponding forked request. When a response arrives at the proxy
it can use the branch value to figure out which branch the response
corresponds to. A proxy which generates a single request (non-
forking) MAY also insert the "branch" parameter. The identifier has
to be unique only within a set of isomorphic requests.
Via: SIP/2.0/UDP first.example.com:4000;ttl=16
;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example)
Via: SIP/2.0/UDP adk8
6.41 Warning 6.41 Warning
The Warning response-header field is used to carry additional The Warning response-header field is used to carry additional
information about the status of a response. Warning headers are sent information about the status of a response. Warning headers are sent
with responses and have the following format: with responses and have the following format:
Warning = "Warning" ":" 1#warning-value Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym warn-agent = ( host [ ":" port ] ) | pseudonym
skipping to change at page 68, line 39 skipping to change at page 73, line 50
302 Incompatible transport protocol: One or more transport protocols 302 Incompatible transport protocol: One or more transport protocols
described in the session description are not available. described in the session description are not available.
303 Incompatible bandwidth units: One or more bandwidth measurement 303 Incompatible bandwidth units: One or more bandwidth measurement
units contained in the session description were not understood. units contained in the session description were not understood.
304 Media type not available: One or more media types contained in 304 Media type not available: One or more media types contained in
the session description are not available. the session description are not available.
305 Incompatible media format: One or more media formats contained in 305 Incompatible media format: One or more media formats contained in
the session description available. the session description are not available.
306 Attribute not understood: One or more of the media attributes in 306 Attribute not understood: One or more of the media attributes in
the session description are not supported. the session description are not supported.
307 Session description parameter not understood: A parameter other 307 Session description parameter not understood: A parameter other
than those listed above was not understood. than those listed above was not understood.
330 Multicast not available: The site where the user is located does 330 Multicast not available: The site where the user is located does
not support multicast. not support multicast.
skipping to change at page 72, line 25 skipping to change at page 77, line 41
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. If there is no explicit expiration time, the address is only header. If there is no explicit expiration time, the address is only
valid for this call and MUST NOT be cached for future calls. 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 79, line 30 skipping to change at page 85, line 5
For response messages, the request method and the response status For response messages, the request method and the response status
code determine the type and interpretation of any message body. All code determine the type and interpretation of any message body. All
responses MAY include a body. Message bodies for 1xx responses responses MAY include a body. Message bodies for 1xx responses
contain advisory information about the progress of the request. 2xx contain advisory information about the progress of the request. 2xx
responses to INVITE requests contain session descriptions. In 3xx responses to INVITE requests contain session descriptions. In 3xx
responses, the message body MAY contain the description of responses, the message body MAY contain the description of
alternative destinations or services, as described in Section 7.3. alternative destinations or services, as described in Section 7.3.
For responses with status 400 or greater, the message body MAY For responses with status 400 or greater, the message body MAY
contain additional, human-readable information about the reasons for contain additional, human-readable information about the reasons for
failure. It is RECOMMENDED that information in 1xx and 300 and failure. It is RECOMMENDED that information in 1xx and 300 and
greater responses be of type text/plain or text/html greater responses be of type text/plain or text/html
8.2 Message Body Type 8.2 Message Body Type
The Internet media type of the message body MUST be given by the The Internet media type of the message body MUST be given by the
Content-Type header field. If the body has undergone any encoding Content-Type header field. If the body has undergone any encoding
(such as compression) then this MUST be indicated by the Content- (such as compression) then this MUST be indicated by the Content-
Encoding header field, otherwise Content-Encoding MUST be omitted. If Encoding header field, otherwise Content-Encoding MUST be omitted. If
applicable, the character set of the message body is indicated as applicable, the character set of the message body is indicated as
part of the Content-Type header-field value. part of the Content-Type header-field value.
skipping to change at page 82, line 41 skipping to change at page 88, line 19
The 32 second window is given by the maximum retransmission The 32 second window is given by the maximum retransmission
duration of 200-class responses using the default timers, duration of 200-class responses using the default timers,
in case the ACK is lost somewhere on the way to the called in case the ACK is lost somewhere on the way to the called
user agent or the next stateful proxy. user agent or the next stateful proxy.
10.2 Source Addresses, Destination Addresses and Connections 10.2 Source Addresses, Destination Addresses and Connections
10.2.1 Unicast UDP 10.2.1 Unicast UDP
Responses are returned to the address listed in the Via header field Responses are returned to the address listed in the Via header field
(Section 6.40), not the source address of the request. (Section 6.40), not the source address of the request.
Recall that responses are not generated by the next-hop Recall that responses are not generated by the next-hop
stateless server, but generated by either a proxy server or stateless server, but generated by either a proxy server or
the user agent server. Thus, the stateless proxy can only the user agent server. Thus, the stateless proxy can only
use the Via header field to forward the response. use the Via header field to forward the response.
10.2.2 Multicast UDP 10.2.2 Multicast UDP
Requests MAY be multicast; multicast requests likely feature a host- Requests MAY be multicast; multicast requests likely feature a host-
independent Request-URI. This request SHOULD be scoped to ensure it independent Request-URI. This request SHOULD be scoped to ensure it
is not forwarded beyond the boundaries of the administrative system. is not forwarded beyond the boundaries of the administrative system.
This MAY be done with either TTL or administrative scopes[25], This MAY be done with either TTL or administrative scopes[25],
depending on what is implemented in the network. depending on what is implemented in the network.
A client receiving a multicast query does not have to check whether A client receiving a multicast query does not have to check whether
the host part of the Request-URI matches its own host or domain name. the host part of the Request-URI matches its own host or domain name.
If the request was received via multicast, the response is also If the request was received via multicast, the response is also
returned via multicast. Responses to multicast requests are multicast returned via multicast. Responses to multicast requests are multicast
with the same TTL as the request, where the TTL is derived from the with the same TTL as the request, where the TTL is derived from the
ttl parameter in the Via header (Section 6.40). ttl parameter in the Via header (Section 6.40).
To avoid response implosion, servers MUST NOT answer multicast To avoid response implosion, servers MUST NOT answer multicast
requests with a status code other than 2xx or 6xx. The server delays requests with a status code other than 2xx or 6xx. The server delays
its response by a random interval uniformly distributed between zero its response by a random interval uniformly distributed between zero
and one second. Servers MAY suppress responses if they hear a lower- and one second. Servers MAY suppress responses if they hear a lower-
numbered or 6xx response from another group member prior to sending. numbered or 6xx response from another group member prior to sending.
skipping to change at page 84, line 39 skipping to change at page 90, line 23
10.4.1 UDP 10.4.1 UDP
A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or
REGISTER request with an exponential backoff, starting at a T1 second REGISTER request with an exponential backoff, starting at a T1 second
interval, doubling the interval for each packet, and capping off at a interval, doubling the interval for each packet, and capping off at a
T2 second interval. This means that after the first packet is sent, T2 second interval. This means that after the first packet is sent,
the second is sent T1 seconds later, the next 2*T1 seconds after the second is sent T1 seconds later, the next 2*T1 seconds after
that, the next 4*T1 seconds after that, and so on, until the interval that, the next 4*T1 seconds after that, and so on, until the interval
hits T2. Subsequent retransmissions are spaced by T2 seconds. If the hits T2. Subsequent retransmissions are spaced by T2 seconds. If the
client receives a provisional response, it continues to retransmit client receives a provisional response, it continues to retransmit
the request, but with an interval of T2 seconds. Retransmissions the request, but with an interval of T2 seconds. Retransmissions
cease when the client has sent a total of eleven packets, or receives cease when the client has sent a total of eleven packets, or receives
a definitive response. Default values for T1 and T2 are 500 ms and 4 a definitive response. Default values for T1 and T2 are 500 ms and 4
s, respectively. Clients MAY use larger values, but SHOULD NOT use s, respectively. Clients MAY use larger values, but SHOULD NOT use
smaller ones. Servers retransmit the response upon receipt of a smaller ones. Servers retransmit the response upon receipt of a
request retransmission. After the server sends a final response, it request retransmission. After the server sends a final response, it
cannot be sure the client has received the response, and thus SHOULD cannot be sure the client has received the response, and thus SHOULD
cache the results for at least 10*T2 seconds to avoid having to, for cache the results for at least 10*T2 seconds to avoid having to, for
example, contact the user or location server again upon receiving a example, contact the user or location server again upon receiving a
request retransmission. request retransmission.
skipping to change at page 85, line 32 skipping to change at page 91, line 13
client will not retransmit the same request again. client will not retransmit the same request again.
Each server in a proxy chain generates its own final response to a Each server in a proxy chain generates its own final response to a
CANCEL request. The server responds immediately upon receipt of the CANCEL request. The server responds immediately upon receipt of the
CANCEL request rather than waiting until it has received final CANCEL request rather than waiting until it has received final
responses from the CANCEL requests it generates. responses from the CANCEL requests it generates.
BYE and OPTIONS final responses are generated by redirect and user BYE and OPTIONS final responses are generated by redirect and user
agent servers; REGISTER final responses are generated by registrars. agent servers; REGISTER final responses are generated by registrars.
Note that in contrast to the reliability mechanism described in Note that in contrast to the reliability mechanism described in
Section 10.5, responses to these requests are not retransmitted Section 10.5, responses to these requests are not retransmitted
periodically and not acknowledged via ACK. periodically and not acknowledged via ACK.
10.4.2 TCP 10.4.2 TCP
Clients using TCP do not need to retransmit requests. Clients using TCP do not need to retransmit requests.
10.5 Reliability for INVITE Requests 10.5 Reliability for INVITE Requests
Special considerations apply for the INVITE method. Special considerations apply for the INVITE method.
1. After receiving an invitation, considerable time can elapse 1. After receiving an invitation, considerable time can elapse
skipping to change at page 87, line 19 skipping to change at page 93, line 4
final responses. final responses.
The ACK request MUST NOT be acknowledged to prevent a response-ACK The ACK request MUST NOT be acknowledged to prevent a response-ACK
feedback loop. Fig. 12 and 13 show the client and server state feedback loop. Fig. 12 and 13 show the client and server state
diagram for invitations. diagram for invitations.
The mechanism in Sec. 10.4 would not work well for INVITE The mechanism in Sec. 10.4 would not work well for INVITE
because of the long delays between INVITE and a final because of the long delays between INVITE and a final
response. If the 200 response were to get lost, the callee response. If the 200 response were to get lost, the callee
would believe the call to exist, but the voice path would would believe the call to exist, but the voice path would
be dead since the caller does not know that the callee has
picked up. Thus, the INVITE retransmission interval would
have to be on the order of a second or two to limit the
duration of this state confusion. Retransmitting the
response with an exponential back-off helps ensure that the
response is received, without placing an undue burden on
the network.
10.5.2 TCP
A user agent using TCP MUST NOT retransmit requests, but uses the
same algorithm as for UDP (Section 10.5.1) to retransmit responses
until it receives an ACK.
It is necessary to retransmit 2xx responses as their
reliability is assured end-to-end only. If the chain of
proxies has a UDP link in the middle, it could lose the
response, with no possibility of recovery. For simplicity,
we also retransmit non-2xx responses, although that is not
strictly necessary.
10.6 Reliability for ACK Requests
The ACK request does not generate responses. It is only generated
when a response to an INVITE request arrives (see Section 10.5). This
behavior is independent of the transport protocol. Note that the ACK
request MAY take a different path than the original INVITE request,
and MAY even cause a new TCP connection to be opened in order to send
it.
+===========+ +===========+
* * * *
...........>* Initial *<;;;;;;;;;; ...........>* Initial *<;;;;;;;;;;
: 7 INVITE * * ; : 7 INVITE * * ;
: sent +===========+ ; : sent +===========+ ;
: | ; : | ;
: | - ; : | - ;
: | INVITE ; : | INVITE ;
: | ; : | ;
: v ; : v ;
skipping to change at page 89, line 7 skipping to change at page 94, line 7
; 32s (for proxy); ; 32s (for proxy);
;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;
event (xxx=status) event (xxx=status)
message message
Figure 12: State transition diagram of client for INVITE method Figure 12: State transition diagram of client for INVITE method
7 pkts sent +===============+ 7 pkts sent +===============+
+-------------->* * +-------------->* *
| * Initial *<............... | * Initial *<...............
|;;;;;;;;;;;;;;>* * |;;;;;;;;;;;;;;>* * :
|; +===============+ : |; +===============+ :
|; CANCEL ! : |; CANCEL ! :
|; 200 ! : |; 200 ! INVITE :
|; ! INVITE :
|; ! 1xx : |; ! 1xx :
|; ! : |; ! :
|; v : |; v :
|; ***************** BYE : |; ***************** BYE :
|; INVITE -->* * 200 : |; INVITE -->* * 200 :
|; 1xx <--* Call proceed. *..............>: |; 1xx <--* Call proceed. *..............>:
|; * * : |; * * :
|;;;;;;;;;;;;;;;***************** : |;;;;;;;;;;;;;;;***************** :
|; ! ! : |; ! ! :
|: ! ! : |: ! ! :
skipping to change at page 89, line 37 skipping to change at page 94, line 36
|;INVITE<* *<T1*2^n->* *>INVITE : |;INVITE<* *<T1*2^n->* *>INVITE :
|;status>* failure *>status<-* success *<status : |;status>* failure *>status<-* success *<status :
|; * * * * : |; * * * * :
|;;;;;;;;*********** *********** : |;;;;;;;;*********** *********** :
| ! : | | ! : : | ! : | | ! : :
| ! : | | ! : : | ! : | | ! : :
+-------------!-:-+------------+ ! : : +-------------!-:-+------------+ ! : :
! :.................!..:.........>: ! :.................!..:.........>:
! ! BYE : ! ! BYE :
+---------+---------+ 200 : +---------+---------+ 200 :
! ACK : event ! ACK :
! : message sent v :
v :
***************** : ***************** :
V---* * : V---* * :
ACK * Confirmed * : ACK * Confirmed * :
|-->* * : |-->* * :
***************** . ***************** .
: :
:......................>: :......................>:
event
message sent
Figure 13: State transition diagram of server for INVITE method Figure 13: State transition diagram of server for INVITE method
be dead since the caller does not know that the callee has
picked up. Thus, the INVITE retransmission interval would
have to be on the order of a second or two to limit the
duration of this state confusion. Retransmitting the
response with an exponential back-off helps ensure that the
response is received, without placing an undue burden on
the network.
10.5.2 TCP
A user agent using TCP MUST NOT retransmit requests, but uses the
same algorithm as for UDP (Section 10.5.1) to retransmit responses
until it receives an ACK.
It is necessary to retransmit 2xx responses as their
reliability is assured end-to-end only. If the chain of
proxies has a UDP link in the middle, it could lose the
response, with no possibility of recovery. For simplicity,
we also retransmit non-2xx responses, although that is not
strictly necessary.
10.6 Reliability for ACK Requests
The ACK request does not generate responses. It is only generated
when a response to an INVITE request arrives (see Section 10.5). This
behavior is independent of the transport protocol. Note that the ACK
request MAY take a different path than the original INVITE request,
and MAY even cause a new TCP connection to be opened in order to send
it.
10.7 ICMP Handling 10.7 ICMP Handling
Handling of ICMP messages in the case of UDP messages is Handling of ICMP messages in the case of UDP messages is
straightforward. For requests, a host, network, port, or protocol 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
skipping to change at page 97, line 4 skipping to change at page 102, line 39
request(CANCEL, address[i], outgoing[i].branch); request(CANCEL, address[i], outgoing[i].branch);
} }
best.status = -1; best.status = -1;
} }
/* Send an ACK */ /* Send an ACK */
if (class != 2) { if (class != 2) {
if (R == INVITE) request(ACK, r.a, r.branch); if (R == INVITE) request(ACK, r.a, r.branch);
} }
if (class == 2) { if (class == 2) {
if (r.status < best.status) best = r; if (r.status < best.status) best = r;
break; break;
} }
else if (class == 3) { else if (class == 3) {
/* A server MAY optionally recurse. The server MUST check /* A server MAY optionally recurse. The server MUST check
* whether it has tried this location before and whether the * whether it has tried this location before and whether
* location is part of the Via path of the incoming request. * the location is part of the Via path of the incoming
* This check is omitted here for brevity. Multicast locations * request. This check is omitted here for brevity.
* MUST NOT be returned to the client if the server is not * Multicast locations MUST NOT be returned to the client if
* recursing. * the server is not recursing.
*/ */
if (recurse) { if (recurse) {
multicast = 0; multicast = 0;
N += r.locations; N += r.locations;
for (i = 0; i < r.locations; i++) { for (i = 0; i < r.locations; i++) {
request(R, r.location[i]); request(R, r.location[i]);
} }
} else if (!ismulticast(r.location)) { } else if (!ismulticast(r.location)) {
best = r; best = r;
} }
skipping to change at page 99, line 14 skipping to change at page 104, line 50
13.1 Confidentiality and Privacy: Encryption 13.1 Confidentiality and Privacy: Encryption
13.1.1 End-to-End Encryption 13.1.1 End-to-End Encryption
SIP requests and responses can contain sensitive information about SIP requests and responses can contain sensitive information about
the communication patterns and communication content of individuals. the communication patterns and communication content of individuals.
The SIP message body MAY also contain encryption keys for the session The SIP message body MAY also contain encryption keys for the session
itself. SIP supports three complementary forms of encryption to itself. SIP supports three complementary forms of encryption to
protect privacy: protect privacy:
o End-to-end encryption of the SIP message body and certain o End-to-end encryption of the SIP message body and certain
sensitive header fields; sensitive header fields;
o hop-by-hop encryption to prevent eavesdropping that tracks who o hop-by-hop encryption to prevent eavesdropping that tracks
is calling whom; who is calling whom;
o hop-by-hop encryption of Via fields to hide the route a o hop-by-hop encryption of Via fields to hide the route a
request has taken. request has taken.
Not all of the SIP request or response can be encrypted end-to-end Not all of the SIP request or response can be encrypted end-to-end
because header fields such as To and Via need to be visible to because header fields such as To and Via need to be visible to
proxies so that the SIP request can be routed correctly. Hop-by-hop proxies so that the SIP request can be routed correctly. Hop-by-hop
encryption encrypts the entire SIP request or response on the wire so encryption encrypts the entire SIP request or response on the wire so
that packet sniffers or other eavesdroppers cannot see who is calling that packet sniffers or other eavesdroppers cannot see who is calling
whom. Hop-by-hop encryption can also encrypt requests and responses whom. Hop-by-hop encryption can also encrypt requests and responses
that have been end-to-end encrypted. Note that proxies can still see that have been end-to-end encrypted. Note that proxies can still see
who is calling whom, and this information is also deducible by who is calling whom, and this information is also deducible by
skipping to change at page 101, line 42 skipping to change at page 107, line 31
* o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ *
* c=IN IP4 135.180.144.94$ * * c=IN IP4 135.180.144.94$ *
* m=audio 3456 RTP/AVP 0 3 4 5$ * * m=audio 3456 RTP/AVP 0 3 4 5$ *
************************************************* *************************************************
13.1.2 Privacy of SIP Responses 13.1.2 Privacy of SIP Responses
SIP requests can be sent securely using end-to-end encryption and SIP requests can be sent securely using end-to-end encryption and
authentication to a called user agent that sends an insecure authentication to a called user agent that sends an insecure
response. This is allowed by the SIP security model, but is not a response. This is allowed by the SIP security model, but is not a
good idea. However, unless the correct behaviour is explicit, it good idea. However, unless the correct behavior is explicit, it
would not always be possible for the called user agent to infer what would not always be possible for the called user agent to infer what
a reasonable behaviour was. Thus when end-to-end encryption is used a reasonable behavior was. Thus when end-to-end encryption is used by
by the request originator, the encryption key to be used for the the request originator, the encryption key to be used for the
response SHOULD be specified in the request. If this were not done, response SHOULD be specified in the request. If this were not done,
it might be possible for the called user agent to incorrectly infer it might be possible for the called user agent to incorrectly infer
an appropriate key to use in the response. Thus, to prevent key- an appropriate key to use in the response. Thus, to prevent key-
guessing becoming an acceptable strategy, we specify that a called guessing becoming an acceptable strategy, we specify that a called
user agent receiving a request that does not specify a key to be used user agent receiving a request that does not specify a key to be used
for the response SHOULD send that response unencrypted. for the response SHOULD send that response unencrypted.
Any SIP header fields that were encrypted in a request SHOULD also be Any SIP header fields that were encrypted in a request SHOULD also be
encrypted in an encrypted response. Contact response fields MAY be encrypted in an encrypted response. Contact response fields MAY be
encrypted if the information they contain is sensitive, or MAY be encrypted if the information they contain is sensitive, or MAY be
skipping to change at page 102, line 41 skipping to change at page 108, line 32
13.1.5 Via field encryption 13.1.5 Via field encryption
When Via header fields are to be hidden, a proxy that receives a When Via header fields are to be hidden, a proxy that receives a
request containing an appropriate "Hide: hop" header field (as request containing an appropriate "Hide: hop" header field (as
specified in section 6.22) SHOULD encrypt the header field. As only specified in section 6.22) SHOULD encrypt the header field. As only
the proxy that encrypts the field will decrypt it, the algorithm the proxy that encrypts the field will decrypt it, the algorithm
chosen is entirely up to the proxy implementor. Two methods satisfy chosen is entirely up to the proxy implementor. Two methods satisfy
these requirements: these requirements:
o The server keeps a cache of Via header fields and the o The server keeps a cache of Via header fields and the
associated To header field, and replaces the Via header field associated To header field, and replaces the Via header field
with an index into the cache. On the reverse path, take the with an index into the cache. On the reverse path, take the
Via header field from the cache rather than the message. Via header field from the cache rather than the message.
This is insufficient to prevent message looping, and so an This is insufficient to prevent message looping, and so an
additional ID MUST be added so that the proxy can detect loops. additional ID MUST be added so that the proxy can detect loops.
This SHOULD NOT normally be the address of the proxy as the goal This SHOULD NOT normally be the address of the proxy as the goal
is to hide the route, so instead a sufficiently large random is to hide the route, so instead a sufficiently large random
number SHOULD be used by the proxy and maintained in the cache. number SHOULD be used by the proxy and maintained in the cache.
It is possible for replies to get directed to the wrong It is possible for replies to get directed to the wrong
originator if the cache entry gets reused, so great care needs originator if the cache entry gets reused, so great care needs
to be taken to ensure this does not happen. to be taken to ensure this does not happen.
o The server MAY use a secret key to encrypt the Via field, a o The server MAY use a secret key to encrypt the Via field, a
timestamp and an appropriate checksum in any such message with timestamp and an appropriate checksum in any such message with
the same secret key. The checksum is needed to detect whether the same secret key. The checksum is needed to detect whether
successful decoding has occurred, and the timestamp is successful decoding has occurred, and the timestamp is
required to prevent possible replay attacks and to ensure that required to prevent possible replay attacks and to ensure that
no two requests from the same previous hop have the same no two requests from the same previous hop have the same
encrypted Via field. This is the preferred solution. encrypted Via field. This is the preferred solution.
13.2 Message Integrity and Access Control: Authentication 13.2 Message Integrity and Access Control: Authentication
Protective measures need to be taken to prevent an active attacker Protective measures need to be taken to prevent an active attacker
from modifying and replaying SIP requests and responses. The same from modifying and replaying SIP requests and responses. The same
cryptographic measures that are used to ensure the authenticity of cryptographic measures that are used to ensure the authenticity of
the SIP message also serve to authenticate the originator of the the SIP message also serve to authenticate the originator of the
message. However, the "basic" and "digest" authentication mechanism message. However, the "basic" and "digest" authentication mechanism
offer authentication only, without message integrity. offer authentication only, without message integrity.
Transport-layer or network-layer authentication MAY be used for hop- Transport-layer or network-layer authentication MAY be used for hop-
by-hop authentication. SIP also extends the HTTP WWW-Authenticate by-hop authentication. SIP also extends the HTTP WWW-Authenticate
(Section 6.42) and Authorization (Section 6.11) header field and (Section 6.42) and Authorization (Section 6.11) header field and
their Proxy counterparts to include cryptographically strong their Proxy counterparts to include cryptographically strong
signatures. SIP also supports the HTTP "basic" and "digest" schemes signatures. SIP also supports the HTTP "basic" and "digest" schemes
(see Section 14) and other HTTP authentication schemes to be defined (see Section 14) and other HTTP authentication schemes to be defined
that offer a rudimentary mechanism of ascertaining the identity of that offer a rudimentary mechanism of ascertaining the identity of
the caller. the caller.
Since SIP requests are often sent to parties with which no Since SIP requests are often sent to parties with which no
prior communication relationship has existed, we do not prior communication relationship has existed, we do not
specify authentication based on shared secrets. specify authentication based on shared secrets.
SIP requests MAY be authenticated using the Authorization header SIP requests MAY be authenticated using the Authorization header
field to include a digital signature of certain header fields, the field to include a digital signature of certain header fields, the
skipping to change at page 105, line 9 skipping to change at page 111, line 4
To: T. A. Watson <sip:watson@bell-telephone.com> To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com Call-ID: 187602141351@worcester.bell-telephone.com
Subject: Mr. Watson, come here. Subject: Mr. Watson, come here.
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
v=0 v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5 o=bell 53655765 2353687637 IN IP4 128.3.4.5
c=IN IP4 135.180.144.94 c=IN IP4 135.180.144.94
m=audio 3456 RTP/AVP 0 3 4 5 m=audio 3456 RTP/AVP 0 3 4 5
Clients wishing to authenticate requests MUST construct the portion Clients wishing to authenticate requests MUST construct the portion
of the message below the Authorization header using a canonical form. of the message below the Authorization header using a canonical form.
This allows a proxy to parse the message, take it apart, and This allows a proxy to parse the message, take it apart, and
reconstruct it, without causing an authentication failure due to reconstruct it, without causing an authentication failure due to
extra white space, for example. Canonical form consists of the extra white space, for example. Canonical form consists of the
following rules: following rules:
o No short form header fields o No short form header fields
o Header field names are capitalized as shown in this document o Header field names are capitalized as shown in this document
o No white space between the header name and the colon o No white space between the header name and the colon
o A single space after the colon o A single space after the colon
o Line termination with a CRLF o Line termination with a CRLF
o No line folding o No line folding
o No comma separated lists of header values; each must appear as o No comma separated lists of header values; each must appear
a separate header as a separate header
o Only a single SP between tokens, between tokens and quoted o Only a single SP between tokens, between tokens and quoted
strings, and between quoted strings; no SP after last token or strings, and between quoted strings; no SP after last token or
quoted string quoted string
o No LWS between tokens and separators, except as described o No LWS between tokens and separators, except as described
above for after the colon in header fields above for after the colon in header fields
Note that if a message is encrypted and authenticated using a digital Note that if a message is encrypted and authenticated using a digital
signature, when the message is generated encryption is performed signature, when the message is generated encryption is performed
before the digital signature is generated. On receipt, the digital before the digital signature is generated. On receipt, the digital
signature is checked before decryption. signature is checked before decryption.
A client MAY require that a server sign its response by including a A client MAY require that a server sign its response by including a
Require: org.ietf.sip.signed-response request header field. The Require: org.ietf.sip.signed-response request header field. The
client indicates the desired authentication method via the WWW- client indicates the desired authentication method via the WWW-
Authenticate header. Authenticate header.
The correct behaviour in handling unauthenticated responses to a The correct behavior in handling unauthenticated responses to a
request that requires authenticated responses is described in section request that requires authenticated responses is described in section
13.2.1. 13.2.1.
13.2.1 Trusting responses 13.2.1 Trusting responses
There is the possibility that an eavesdropper listens to requests and There is the possibility that an eavesdropper listens to requests and
then injects unauthenticated responses that terminate, redirect or then injects unauthenticated responses that terminate, redirect or
otherwise interfere with a call. (Even encrypted requests contain otherwise interfere with a call. (Even encrypted requests contain
enough information to fake a response.) enough information to fake a response.)
Clients need to be particularly careful with 3xx redirection Clients need to be particularly careful with 3xx redirection
responses. Thus a client receiving, for example, a 301 (Moved responses. Thus a client receiving, for example, a 301 (Moved
Permanently) which was not authenticated when the public key of the Permanently) which was not authenticated when the public key of the
called user agent is known to the client, and authentication was called user agent is known to the client, and authentication was
requested in the request SHOULD be treated as suspicious. The correct requested in the request SHOULD be treated as suspicious. The correct
behaviour in such a case would be for the called-user to form a dated behavior in such a case would be for the called-user to form a dated
response containing the Contact field to be used, to sign it, and response containing the Contact field to be used, to sign it, and
give this signed stub response to the proxy that will provide the give this signed stub response to the proxy that will provide the
redirection. Thus the response can be authenticated correctly. A redirection. Thus the response can be authenticated correctly. A
client SHOULD NOT automatically redirect such a request to the new client SHOULD NOT automatically redirect such a request to the new
location without alerting the user to the authentication failure location without alerting the user to the authentication failure
before doing so. before doing so.
Another problem might be responses such as 6xx failure responses Another problem might be responses such as 6xx failure responses
which would simply terminate a search, or "4xx" and "5xx" response which would simply terminate a search, or "4xx" and "5xx" response
failures. failures.
skipping to change at page 108, line 43 skipping to change at page 114, line 43
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 ;as defined in Section digest-uri-value = Request-URI ; a 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.
skipping to change at page 110, line 7 skipping to change at page 116, line 7
15.1 PGP Authentication Scheme 15.1 PGP Authentication Scheme
The "pgp" authentication scheme is based on the model that the client The "pgp" authentication scheme is based on the model that the client
authenticates itself with a request signed with the client's private authenticates itself with a request signed with the client's private
key. The server can then ascertain the origin of the request if it key. The server can then ascertain the origin of the request if it
has access to the public key, preferably signed by a trusted third has access to the public key, preferably signed by a trusted third
party. party.
15.1.1 The WWW-Authenticate Response Header 15.1.1 The WWW-Authenticate Response Header
WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge
pgp-challenge = * (";" pgp-params ) pgp-challenge = * (";" pgp-params )
pgp-params = realm | pgp-version | pgp-algorithm | nonce pgp-params = realm | pgp-version | pgp-algorithm | nonce
realm = "realm" "=" realm-value realm = "realm" "=" realm-value
realm-value = quoted-string realm-value = quoted-string
pgp-version = pgp-version = "version" "="
"version" "=" <"> digit *( "." digit ) *letter <"> <"> digit *( "." digit ) *letter <">
pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token ) pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token )
nonce = "nonce" "=" nonce-value nonce = "nonce" "=" nonce-value
nonce-value = quoted-string nonce-value = quoted-string
The meanings of the values of the parameters used above are as The meanings of the values of the parameters used above are as
follows: follows:
realm: A string to be displayed to users so they know which identity realm: A string to be displayed to users so they know which identity
to use. This string SHOULD contain at least the name of the host to use. This string SHOULD contain at least the name of the host
performing the authentication and MAY additionally indicate the performing the authentication and MAY additionally indicate the
collection of users who might have access. An example might be " collection of users who might have access. An example might be "
Users with call-out privileges ". Users with call-out privileges ".
skipping to change at page 127, line 30 skipping to change at page 134, line 22
Require header. A minimal implementation MUST understand SDP (RFC Require header. A minimal implementation MUST understand SDP (RFC
2327, [6]). It MUST be able to recognize the status code classes 1 2327, [6]). It MUST be able to recognize the status code classes 1
through 6 and act accordingly. through 6 and act accordingly.
The following capability sets build on top of the minimal The following capability sets build on top of the minimal
implementation described in the previous paragraph. In general, each implementation described in the previous paragraph. In general, each
capability listed below builds on the ones above it: capability listed below builds on the ones above it:
Basic: A basic implementation adds support for the BYE method to Basic: A basic implementation adds support for the BYE method to
allow the interruption of a pending call attempt. It includes a allow the interruption of a pending call attempt. It includes a
User-Agent header in its requests and indicate its preferred User-Agent header in its requests and indicates its preferred
language in the Accept-Language header. language in the Accept-Language header.
Redirection: To support call forwarding, a client needs to be able to Redirection: To support call forwarding, a client needs to be able to
understand the Contact header, but only the SIP-URL part, not understand the Contact header, but only the SIP-URL part, not
the parameters. the parameters.
Firewall-friendly: A firewall-friendly client understands the Route Firewall-friendly: A firewall-friendly client understands the Route
and Record-Route header fields and can be configured to use a and Record-Route header fields and can be configured to use a
local proxy for all outgoing requests. local proxy for all outgoing requests.
skipping to change at page 128, line 32 skipping to change at page 135, line 25
A.3 Header Processing A.3 Header Processing
Table 6 lists the headers that different implementations support. UAC Table 6 lists the headers that different implementations support. UAC
refers to a user-agent client (calling user agent), UAS to a user- refers to a user-agent client (calling user agent), UAS to a user-
agent server (called user-agent). agent server (called user-agent).
The fields in the table have the following meaning. Type is as in The fields in the table have the following meaning. Type is as in
Table 4 and 5. "-" indicates the field is not meaningful to this Table 4 and 5. "-" indicates the field is not meaningful to this
system (although it might be generated by it). "m" indicates the system (although it might be generated by it). "m" indicates the
field MUST be understood. "b" indicates the field SHOULD be field MUST be understood. "b" indicates the field SHOULD be
understood by a Basic implementation. "r" indicates the field SHOULD understood by a Basic implementation. "r" indicates the field SHOULD
be understood if the system claims to understand redirection. "a" be understood if the system claims to understand redirection. "a"
indicates the field SHOULD be understood if the system claims to indicates the field SHOULD be understood if the system claims to
support authentication. "e" indicates the field SHOULD be understood support authentication. "e" indicates the field SHOULD be understood
if the system claims to support encryption. "o" indicates support of if the system claims to support encryption. "o" indicates support of
the field is purely optional. Headers whose support is optional for the field is purely optional. Headers whose support is optional for
all implementations are not shown. all implementations are not shown.
B Usage of the Session Description Protocol (SDP)
This section describes the use of the Session Description Protocol
(SDP) (RFC 2327 [6]).
B.1 Configuring Media Streams
The caller and callee align their media descriptions so that the nth
media stream ("m=" line) in the caller's session description
corresponds to the nth media stream in the callee's description.
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 129, line 39 skipping to change at page 136, 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
B Usage of the Session Description Protocol (SDP)
This section describes the use of the Session Description Protocol
(SDP) (RFC 2327 [6]).
B.1 Configuring Media Streams
The caller and callee align their media descriptions so that the nth
media stream ("m=" line) in the caller's session description
corresponds to the nth media stream in the callee's description.
All media descriptions SHOULD contain "a=rtpmap" mappings from RTP All media descriptions SHOULD contain "a=rtpmap" mappings from RTP
payload types to encodings. payload types to encodings.
This allows easier migration away from static payload This allows easier migration away from static payload
types. types.
If the callee wants to neither send nor receive a stream offered by 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 the caller, the callee sets the port number of that stream to zero in
its media description. its media description.
skipping to change at page 138, line 15 skipping to change at page 146, line 20
If a step elicits no addresses, the client continues to the next If a step elicits no addresses, the client continues to the next
step. However if a step elicits one or more addresses, but no SIP step. However if a step elicits one or more addresses, but no SIP
server at any of those addresses responds, then the client concludes server at any of those addresses responds, then the client concludes
the server is down and doesn't continue on to the next step. the server is down and doesn't continue on to the next step.
When SRV records are to be used, the protocol to use when querying 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 for the SRV record is "sip". SRV records contain port numbers for
servers, in addition to IP addresses; the client always uses this servers, in addition to IP addresses; the client always uses this
port number when contacting the SIP server. Otherwise, the port 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 number in the SIP URI is used, if present. If there is no port number
URI, the default port, 5060, is used. in the URI, the default port, 5060, is used.
1. If the host portion of the Request-URI is an IP address, 1. If the host portion of the Request-URI is an IP address,
the client contacts the server at the given address. If the the client contacts the server at the given address. If the
host portion of the Request-URI is not an IP address, the host portion of the Request-URI is not an IP address, the
client proceeds to the next step. client proceeds to the next step.
2. The Request-URI is examined. If it contains an explicit 2. The Request-URI is examined. If it contains an explicit
port number, the next two steps are skipped. port number, the next two steps are skipped.
3. The Request-URI is examined. If it does not specify a 3. The Request-URI is examined. If it does not specify a
protocol (TCP or UDP), the client queries the name server protocol (TCP or UDP), the client queries the name server
for SRV records for both UDP (if supported by the client) for SRV records for both UDP (if supported by the client)
and TCP (if supported by the client) SIP servers. The and TCP (if supported by the client) SIP servers. The
format of these queries is defined in RFC 2052 [14]. The format of these queries is defined in RFC 2052 [14]. The
results of the query or queries are merged together and results of the query or queries are merged together and
ordered based on priority. Then, the searching technique ordered based on priority. Then, the searching technique
outlined in RFC 2052 [14] is used to select servers in outlined in RFC 2052 [14] is used to select servers in
order. If DNS doesn't return any records, the user goes to order. If DNS doesn't return any records, the user goes to
the last step. Otherwise, the user attempts to contact each the last step. Otherwise, the user attempts to contact
server in the order listed. If no server is contacted, the each server in the order listed. If no server is
user gives up. contacted, the user gives up.
4. If the Request-URI specifies a protocol (TCP or UDP) that 4. If the Request-URI specifies a protocol (TCP or UDP) that
is supported by the client, the client queries the name is supported by the client, the client queries the name
server for SRV records for SIP servers of that protocol server for SRV records for SIP servers of that protocol
type only. If the client does not support the protocol type only. If the client does not support the protocol
specified in the Request-URI, it gives up. The searching specified in the Request-URI, it gives up. The searching
technique outlined in RFC 2052 [14] is used to select technique outlined in RFC 2052 [14] is used to select
servers from the DNS response in order. If DNS doesn't servers from the DNS response in order. If DNS doesn't
return any records, the user goes to the last step. return any records, the user goes to the last step.
Otherwise, the user attempts to contact each server in the Otherwise, the user attempts to contact each server in the
skipping to change at page 139, line 28 skipping to change at page 147, line 34
For example, consider a client that wishes to send a SIP request. The For example, consider a client that wishes to send a SIP request. The
Request-URI for the destination is sip:user@company.com. The client Request-URI for the destination is sip:user@company.com. The client
only supports UDP. It would follow these steps: only supports UDP. It would follow these steps:
1. The host portion is not an IP address, so the client goes 1. The host portion is not an IP address, so the client goes
to step 2 above. to step 2 above.
2. The client does a DNS query of QNAME="sip.udp.company.com", 2. The client does a DNS query of QNAME="sip.udp.company.com",
QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it
omits the TCP query. There were no addresses in the DNS omits the TCP query. There were no addresses in the DNS
response, so the client goes to the next step. response, so the client goes to the next step.
3. The client does a DNS query for A records for 3. The client does a DNS query for A records for
"company.com". An address is found, so that client attempts "company.com". An address is found, so that client attempts
to contact a server at that address at port 5060. to contact a server at that address at port 5060.
E IANA Considerations E IANA Considerations
Section 4.4 describes a name space and mechanism for registering SIP Section 4.4 describes a name space and mechanism for registering SIP
options. options.
Section 6.41 describes the name space for registering SIP warn-codes. Section 6.41 describes the name space for registering SIP warn-codes.
F Changes in Version -12 F Acknowledgments
Since version -11, the following changes have been made. These
changes reflect IESG comments.
o Section 16.3 was missing Content-Type header.
o The DNS search procedure has changed. Reference to CNAME
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 Semicolon removed from user and password BNF in SIP URL.
o An email address for IANA registrations is now listed.
o For the Moved Temporarily redirect response, no default value
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 Clarification that CANCEL and ACK's should have the same Via
branch parameter as the request they cancel or acknowledge.
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].
H Authors' Addresses G Authors' Addresses
Mark Handley Mark Handley
USC Information Sciences Institute AT&T Center for Internet Research at ISCI (ACIRI)
c/o MIT Laboratory for Computer Science 1947 Center St., Suite 600
545 Technology Square Berkeley, CA 94704-119
Cambridge, MA 02139
USA USA
electronic mail: mjh@isi.edu Email: mjh@aciri.org
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
Eve Schooler Eve Schooler
Computer Science Department 256-80 Computer Science Department 256-80
California Institute of Technology California Institute of Technology
Pasadena, CA 91125 Pasadena, CA 91125
USA USA
electronic mail: schooler@cs.caltech.edu Email: schooler@cs.caltech.edu
Jonathan Rosenberg Jonathan Rosenberg
Lucent Technologies, Bell Laboratories Lucent Technologies, Bell Laboratories
Rm. 4C-526 Rm. 4C-526
101 Crawfords Corner Road 101 Crawfords Corner Road
Holmdel, NJ 07733 Holmdel, NJ 07733
USA USA
electronic mail: jdrosen@bell-labs.com Email: jdrosen@bell-labs.com
I Bibliography H Bibliography
[1] R. Pandya, "Emerging mobile and personal communication systems," [1] Pandya, R., "Emerging mobile and personal communication systems,"
IEEE Communications Magazine , vol. 33, pp. 44--52, June 1995. IEEE Communications Magazine , vol. 33, pp. 44--52, June 1995.
[2] B. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, [2] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation protocol (RSVP) -- version 1 functional "Resource ReSerVation protocol (RSVP) -- version 1 functional
specification," RFC 2205, Internet Engineering Task Force, Oct. 1997. specification", RFC 2205, October 1997.
[3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
transport protocol for real-time applications," RFC 1889, Internet a transport protocol for real-time applications", RFC 1889,
Engineering Task Force, Jan. 1996. Internet Engineering Task Force, Jan. 1996.
[4] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming [4] Schulzrinne, H., Lanphier, R. and A. Rao, "Real time streaming
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. protocol (RTSP)", RFC 2326, April 1998.
1998.
[5] M. Handley, "SAP: Session announcement protocol," Internet Draft, [5] Handley, M., "SAP: Session announcement protocol," Internet
Internet Engineering Task Force, Nov. 1996. Work in progress. Draft, Internet Engineering Task Force, Nov. 1996. Work in
progress.
[6] M. Handley and V. Jacobson, "SDP: session description protocol," [6] Handley, M. and V. Jacobson, "SDP: session description protocol",
RFC 2327, Internet Engineering Task Force, Apr. 1998. RFC 2327, April 1998.
[7] International Telecommunication Union, "Visual telephone systems [7] International Telecommunication Union, "Visual telephone systems
and equipment for local area networks which provide a non-guaranteed and equipment for local area networks which provide a non-
quality of service," Recommendation H.323, Telecommunication guaranteed quality of service," Recommendation H.323,
Standardization Sector of ITU, Geneva, Switzerland, May 1996. Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, May 1996.
[8] International Telecommunication Union, "Control protocol for [8] International Telecommunication Union, "Control protocol for
multimedia communication," Recommendation H.245, Telecommunication multimedia communication," Recommendation H.245,
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Feb. 1998.
[9] International Telecommunication Union, "Media stream [9] International Telecommunication Union, "Media stream
packetization and synchronization on non-guaranteed quality of packetization and synchronization on non-guaranteed quality of
service LANs," Recommendation H.225.0, Telecommunication service LANs," Recommendation H.225.0, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996. Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996.
[10] S. Bradner, "Key words for use in RFCs to indicate requirement [10] Bradner, S., "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. levels", BCP 14, RFC 2119, Mardch 1997.
[11] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners- [11] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1", RFC
Engineering Task Force, Jan. 1997. 2068, January 1997.
[12] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform resource
identifiers (URI): generic syntax," RFC 2396, Internet Engineering identifiers (URI): generic syntax", RFC 2396, August 1998.
Task Force, Aug. 1998.
[13] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform resource [13] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform resource
locators (URL)," RFC 1738, Internet Engineering Task Force, Dec. locators (URL)", RFC 1738, December 1994.
1994.
[14] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the [14] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)," RFC 2052, Internet Engineering Task location of services (DNS SRV)", RFC 2052, October 1996.
Force, Oct. 1996.
[15] P. Mockapetris, "Domain names - implementation and [15] Mockapetris, P., "Domain names - implementation and
specification," RFC STD 13, 1035, Internet Engineering Task Force, specification", STD 13, RFC 1035, Noveberm 1997.
Nov. 1987.
[16] M. Hamilton and R. Wright, "Use of DNS aliases for network [16] Hamilton, M. and R. Wright, "Use of DNS aliases for network
services," RFC 2219, Internet Engineering Task Force, Oct. 1997. services", RFC 2219, October 1997.
[17] D. Zimmerman, "The finger user information protocol," RFC 1288, [17] Zimmerman, D., "The finger user information protocol", RFC 1288,
Internet Engineering Task Force, Dec. 1991. December 1991.
[18] S. Williamson, M. Kosters, D. Blacka, J. Singh, and K. Zeilstra, [18] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
"Referral whois (rwhois) protocol V1.5," RFC 2167, Internet Zeilstra, "Referral whois (rwhois) protocol V1.5", RFC 2167,
Engineering Task Force, June 1997. June 1997.
[19] W. Yeong, T. Howes, and S. Kille, "Lightweight directory access [19] Yeong, W., Howes, T. and S. Kille, "Lightweight directory access
protocol," RFC 1777, Internet Engineering Task Force, Mar. 1995. protocol", RFC 1777, March 1995.
[20] E. M. Schooler, "A multicast user directory service for [20] Schooler, E., "A multicast user directory service for
synchronous rendezvous," Master's Thesis CS-TR-96-18, Department of synchronous rendezvous," Master's Thesis CS-TR-96-18, Department
Computer Science, California Institute of Technology, Pasadena, of Computer Science, California Institute of Technology,
California, Aug. 1996. Pasadena, California, Aug. 1996.
[21] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC [21] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, Internet Engineering Task Force, Jan. 1998. 2279, January 1998.
[22] W. R. Stevens, TCP/IP illustrated: the protocols , vol. 1. [22] Stevens, W., TCP/IP illustrated: the protocols , vol. 1.
Reading, Massachusetts: Addison-Wesley, 1994. Reading, Massachusetts: Addison-Wesley, 1994.
[23] J. Mogul and S. Deering, "Path MTU discovery," RFC 1191, [23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
Internet Engineering Task Force, Nov. 1990. November 1990.
[24] D. Crocker, "Standard for the format of ARPA internet text [24] Crocker, D., "Standard for the format of ARPA internet text
messages," RFC STD 11, 822, Internet Engineering Task Force, Aug. messages", RFC STD 11, RFC 822, August 1982.
1982.
[25] D. Meyer, "Administratively scoped IP multicast," RFC 2365, [25] Meyer, D., "Administratively scoped IP multicast", RFC 2365,
Internet Engineering Task Force, July 1998. July 1998.
[26] H. Schulzrinne, "RTP profile for audio and video conferences [26] Schulzrinne, H., "RTP profile for audio and video conferences
with minimal control," RFC 1890, Internet Engineering Task Force, with minimal control", RFC 1890, January 1996
Jan. 1996.
[27] D. Eastlake, S. Crocker, and J. Schiller, "Randomness [27] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
recommendations for security," RFC 1750, Internet Engineering Task recommendations for security", RFC 1750, December 1994.
Force, Dec. 1994.
[28] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL [28] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
scheme," RFC 2368, Internet Engineering Task Force, July 1998. scheme", RFC 2368, July 1998.
[29] B. Braden, "Requirements for internet hosts - application and [29] Braden, B., "Requirements for internet hosts - application and
support," RFC STD 3, 1123, Internet Engineering Task Force, Oct. support", STD 3, RFC 1123, October 1989.
1989.
[30] J. Palme, "Common internet message headers," RFC 2076, Internet [30] Palme, J., "Common internet message headers", RFC 2076, February
Engineering Task Force, Feb. 1997. 1997.
[31] H. Alvestrand, "IETF policy on character sets and languages," [31] Alvestrand, H., "IETF policy on character sets and languages",
RFC 2277, Internet Engineering Task Force, Jan. 1998. RFC 2277, January 1998.
[32] M. Elkins, "MIME security with pretty good privacy (PGP)," RFC [32] Elkins, M., "MIME security with pretty good privacy (PGP)", RFC
2015, Internet Engineering Task Force, Oct. 1996. 2015, October 1996.
[33] D. Atkins, W. Stallings, and P. Zimmermann, "PGP message [33] Atkins, D., Stallings, W. and P. Zimmermann, "PGP message
exchange formats," RFC 1991, Internet Engineering Task Force, Aug. exchange formats", RFC 1991, August 1996.
1996.
[34] R. Atkinson, "Security architecture for the internet protocol," [34] Atkinson, R., "Security architecture for the internet protocol",
RFC 1825, Internet Engineering Task Force, Aug. 1995. RFC 2401, November 1998.
[35] C. Allen and T. Dierks, "The TLS protocol version 1.0," Internet [35] Allen, C. and T. Dierks, "The TLS protocol version 1.0," RFC
Draft, Internet Engineering Task Force, Nov. 1997. Work in progress. 2246, January 1999.
[36] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, [36] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication:
access authentication," Internet Draft, Internet Engineering Task Basic and digest access authentication," Internet Draft,
Force, Sept. 1998. Work in progress. Internet Engineering Task Force, Sept. 1998. Work in progress.
[37] E. M. Schooler, "Case study: multimedia conference control in a [37] Schooler, E., "Case study: multimedia conference control in a
packet-switched teleconferencing system," Journal of Internetworking: packet-switched teleconferencing system," Journal of
Research and Experience , vol. 4, pp. 99--120, June 1993. ISI Internetworking: Research and Experience , vol. 4, pp. 99--120,
reprint series ISI/RS-93-359. June 1993. ISI reprint series ISI/RS-93-359.
[38] H. Schulzrinne, "Personal mobility for multimedia services in [38] Schulzrinne, H., "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 (1999). 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
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1 Introduction ........................................ 2
1.1 Overview of SIP Functionality ....................... 2
1.2 Terminology ......................................... 4
1.3 Definitions ......................................... 4
1.4 Overview of SIP Operation ........................... 7
1.4.1 SIP Addressing ...................................... 7
1.4.2 Locating a SIP Server ............................... 8
1.4.3 SIP Transaction ..................................... 9
1.4.4 SIP Invitation ...................................... 10
1.4.5 Locating a User ..................................... 12
1.4.6 Changing an Existing Session ........................ 13
1.4.7 Registration Services ............................... 13
1.5 Protocol Properties ................................. 13
1.5.1 Minimal State ....................................... 13
1.5.2 Lower-Layer-Protocol Neutral ........................ 13
1.5.3 Text-Based .......................................... 15
2 SIP Uniform Resource Locators ....................... 15
3 SIP Message Overview ................................ 19
4 Request ............................................. 21
4.1 Request-Line ........................................ 21
4.2 Methods ............................................. 21
4.2.1 INVITE .............................................. 22
4.2.2 ACK ................................................. 23
4.2.3 OPTIONS ............................................. 24
4.2.4 BYE ................................................. 24
4.2.5 CANCEL .............................................. 25
4.2.6 REGISTER ............................................ 26
4.3 Request-URI ......................................... 28
4.3.1 SIP Version ......................................... 29
4.4 Option Tags ......................................... 29
4.4.1 Registering New Option Tags with IANA ............... 30
5 Response ............................................ 31
5.1 Status-Line ......................................... 31
5.1.1 Status Codes and Reason Phrases ..................... 31
6 Header Field Definitions ............................ 33
6.1 General Header Fields ............................... 35
6.2 Entity Header Fields ................................ 36
6.3 Request Header Fields ............................... 37
6.4 Response Header Fields .............................. 38
6.5 End-to-end and Hop-by-hop Headers ................... 38
6.6 Header Field Format ................................. 38
6.7 Accept .............................................. 39
6.8 Accept-Encoding ..................................... 39
6.9 Accept-Language ..................................... 39
6.10 Allow ............................................... 40
6.11 Authorization ....................................... 40
6.12 Call-ID ............................................. 40
6.13 Contact ............................................. 42
6.14 Content-Encoding .................................... 45
6.15 Content-Length ...................................... 45
6.16 Content-Type ........................................ 46
6.17 CSeq ................................................ 47
6.18 Date ................................................ 48
6.19 Encryption .......................................... 49
6.20 Expires ............................................. 50
6.21 From ................................................ 51
6.22 Hide ................................................ 52
6.23 Max-Forwards ........................................ 53
6.24 Organization ........................................ 54
6.25 Priority ............................................ 54
6.26 Proxy-Authenticate .................................. 55
6.27 Proxy-Authorization ................................. 56
6.28 Proxy-Require ....................................... 56
6.29 Record-Route ........................................ 56
6.30 Require ............................................. 57
6.31 Response-Key ........................................ 58
6.32 Retry-After ......................................... 59
6.33 Route ............................................... 59
6.34 Server .............................................. 60
6.35 Subject ............................................. 60
6.36 Timestamp ........................................... 60
6.37 To .................................................. 61
6.38 Unsupported ......................................... 62
6.39 User-Agent .......................................... 63
6.40 Via ................................................. 63
6.40.1 Requests ............................................ 63
6.40.2 Receiver-tagged Via Header Fields ................... 64
6.40.3 Responses ........................................... 64
6.40.4 User Agent and Redirect Servers ..................... 65
6.40.5 Syntax .............................................. 66
6.41 Warning ............................................. 67
6.42 WWW-Authenticate .................................... 69
7 Status Code Definitions ............................. 69
7.1 Informational 1xx ................................... 70
7.1.1 100 Trying .......................................... 70
7.1.2 180 Ringing ......................................... 70
7.1.3 181 Call Is Being Forwarded ......................... 70
7.1.4 182 Queued .......................................... 70
7.2 Successful 2xx ...................................... 70
7.2.1 200 OK .............................................. 71
7.3 Redirection 3xx ..................................... 71
7.3.1 300 Multiple Choices ................................ 71
7.3.2 301 Moved Permanently ............................... 72
7.3.3 302 Moved Temporarily ............................... 72
7.3.4 305 Use Proxy ....................................... 72
7.3.5 380 Alternative Service ............................. 72
7.4 Request Failure 4xx ................................. 72
7.4.1 400 Bad Request ..................................... 72
7.4.2 401 Unauthorized .................................... 73
7.4.3 402 Payment Required ................................ 73
7.4.4 403 Forbidden ....................................... 73
7.4.5 404 Not Found ....................................... 73
7.4.6 405 Method Not Allowed .............................. 73
7.4.7 406 Not Acceptable .................................. 73
7.4.8 407 Proxy Authentication Required ................... 73
7.4.9 408 Request Timeout ................................. 74
7.4.10 409 Conflict ........................................ 74
7.4.11 410 Gone ............................................ 74
7.4.12 411 Length Required ................................. 74
7.4.13 413 Request Entity Too Large ........................ 74
7.4.14 414 Request-URI Too Long ............................ 74
7.4.15 415 Unsupported Media Type .......................... 74
7.4.16 420 Bad Extension ................................... 75
7.4.17 480 Temporarily Unavailable ......................... 75
7.4.18 481 Call Leg/Transaction Does Not Exist ............. 75
7.4.19 482 Loop Detected ................................... 75
7.4.20 483 Too Many Hops ................................... 75
7.4.21 484 Address Incomplete .............................. 75
7.4.22 485 Ambiguous ....................................... 76
7.4.23 486 Busy Here ....................................... 76
7.5 Server Failure 5xx .................................. 77
7.5.1 500 Server Internal Error ........................... 77
7.5.2 501 Not Implemented ................................. 77
7.5.3 502 Bad Gateway ..................................... 77
7.5.4 503 Service Unavailable ............................. 77
7.5.5 504 Gateway Time-out ................................ 77
7.5.6 505 Version Not Supported ........................... 77
7.6 Global Failures 6xx ................................. 78
7.6.1 600 Busy Everywhere ................................. 78
7.6.2 603 Decline ......................................... 78
7.6.3 604 Does Not Exist Anywhere ......................... 78
7.6.4 606 Not Acceptable .................................. 78
8 SIP Message Body .................................... 79
8.1 Body Inclusion ...................................... 79
8.2 Message Body Type ................................... 79
8.3 Message Body Length ................................. 79
9 Compact Form ........................................ 80
10 Behavior of SIP Clients and Servers ................. 81
10.1 General Remarks ..................................... 81
10.1.1 Requests ............................................ 81
10.1.2 Responses ........................................... 81
10.2 Source Addresses, Destination Addresses and
Connections .................................................... 82
10.2.1 Unicast UDP ......................................... 82
10.2.2 Multicast UDP ....................................... 82
10.3 TCP ................................................. 83
10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER
Requests ....................................................... 84
10.4.1 UDP ................................................. 84
10.4.2 TCP ................................................. 85
10.5 Reliability for INVITE Requests ..................... 85
10.5.1 UDP ................................................. 86
10.5.2 TCP ................................................. 87
10.6 Reliability for ACK Requests ........................ 87
10.7 ICMP Handling ....................................... 90
11 Behavior of SIP User Agents ......................... 90
11.1 Caller Issues Initial INVITE Request ................ 90
11.2 Callee Issues Response .............................. 90
11.3 Caller Receives Response to Initial Request ......... 90
11.4 Caller or Callee Generate Subsequent Requests ....... 91
11.5 Receiving Subsequent Requests ....................... 91
12 Behavior of SIP Proxy and Redirect Servers .......... 92
12.1 Redirect Server ..................................... 92
12.2 User Agent Server ................................... 92
12.3 Proxy Server ........................................ 92
12.3.1 Proxying Requests ................................... 93
12.3.2 Proxying Responses .................................. 93
12.3.3 Stateless Proxy: Proxying Responses ................. 93
12.3.4 Stateful Proxy: Receiving Requests .................. 93
12.3.5 Stateful Proxy: Receiving ACKs ...................... 93
12.3.6 Stateful Proxy: Receiving Responses ................. 94
12.3.7 Stateless, Non-Forking Proxy ........................ 94
12.4 Forking Proxy ....................................... 95
13 Security Considerations ............................. 98
13.1 Confidentiality and Privacy: Encryption ............. 99
13.1.1 End-to-End Encryption ............................... 99
13.1.2 Privacy of SIP Responses ............................ 101
13.1.3 Encryption by Proxies ............................... 102
13.1.4 Hop-by-Hop Encryption ............................... 102
13.1.5 Via field encryption ................................ 102
13.2 Message Integrity and Access Control:
Authentication ................................................. 103
13.2.1 Trusting responses .................................. 106
13.3 Callee Privacy ...................................... 107
13.4 Known Security Problems ............................. 107
14 SIP Authentication using HTTP Basic and Digest
Schemes ........................................................ 107
14.1 Framework ........................................... 107
14.2 Basic Authentication ................................ 108
14.3 Digest Authentication ............................... 108
14.4 Proxy-Authentication ................................ 109
15 SIP Security Using PGP .............................. 109
15.1 PGP Authentication Scheme ........................... 109
15.1.1 The WWW-Authenticate Response Header ................ 110
15.1.2 The Authorization Request Header .................... 111
15.2 PGP Encryption Scheme ............................... 112
15.3 Response-Key Header Field for PGP ................... 113
16 Examples ............................................ 113
16.1 Registration ........................................ 113
16.2 Invitation to a Multicast Conference ................ 115
16.2.1 Request ............................................. 115
16.2.2 Response ............................................ 116
16.3 Two-party Call ...................................... 117
16.4 Terminating a Call .................................. 119
16.5 Forking Proxy ....................................... 119
16.6 Redirects ........................................... 123
16.7 Negotiation ......................................... 125
16.8 OPTIONS Request ..................................... 126
A Minimal Implementation .............................. 127
A.1 Client .............................................. 127
A.2 Server .............................................. 128
A.3 Header Processing ................................... 128
B Usage of the Session Description Protocol (SDP)
................................................................ 128
B.1 Configuring Media Streams ........................... 128
B.2 Setting SDP Values for Unicast ...................... 130
B.3 Multicast Operation ................................. 131
B.4 Delayed Media Streams ............................... 132
B.5 Putting Media Streams on Hold ....................... 132
B.6 Subject and SDP "s=" Line ........................... 132
B.7 The SDP "o=" Line ................................... 133
C Summary of Augmented BNF ............................ 133
C.1 Basic Rules ......................................... 135
D Using SRV DNS Records ............................... 137
E IANA Considerations ................................. 139
F Changes in Version -12 .............................. 139
G Acknowledgments ..................................... 140
H Authors' Addresses .................................. 140
I Bibliography ........................................ 141
 End of changes. 175 change blocks. 
474 lines changed or deleted 664 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/