Network Working Group

Request for Comments: 3261

Obsoletes: 2543
Category: Standards Track
J. Rosenberg
dynamicsoft
H. Schulzrinne
Columbia U.
G. Camarillo
Ericsson
A. Johnston
WorldCom
J. Peterson
Neustar
R. Sparks
dynamicsoft
M. Handley
ICIR
E. Schooler
AT&T
June 2002
Status of this Memo
SIP: Session Initiation Protocol
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes Session Initiation Protocol (SIP), an
application-layer control (signaling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include Internet telephone calls, multimedia
distribution, and multimedia conferences.
SIP invitations used to create sessions carry session descriptions
that allow participants to agree on a set of compatible media types.
SIP makes use of elements called proxy servers to help route requests
to the user's current location, authenticate and authorize users for
services, implement provider call-routing policies, and provide
features to users. SIP also provides a registration function that
allows users to upload their current locations for use by proxy
servers. SIP runs on top of several different transport protocols.
Rosenberg, et. al.
Standards Track
[Page 1]
RFC 3261
SIP: Session Initiation Protocol
June 2002
Table of Contents
1
Introduction
8
2
Overview of SIP Functionality
9
3
Terminology
10
4
Overview of Operation
10
5
Structure of the Protocol
18
6
Definitions
20
7
SIP Messages
26
7.1
Requests
27
7.2
Responses
28
7.3
Header Fields
29
7.3.1
Header Field Format
30
7.3.2
Header Field Classification
32
7.3.3
Compact Form
32
7.4
Bodies
33
7.4.1
Message Body Type
33
7.4.2
Message Body Length
33
7.5
Framing SIP Messages
34
8
General User Agent Behavior
34
8.1
UAC Behavior
35
8.1.1
Generating the Request
35
8.1.1.1
Request-URI
35
8.1.1.2
To
36
8.1.1.3
From
37
8.1.1.4
Call-ID
37
8.1.1.5
CSeq
38
8.1.1.6
Max-Forwards
38
8.1.1.7
Via
39
8.1.1.8
Contact
40
8.1.1.9
Supported and Require
40
8.1.1.10
Additional Message Components
41
8.1.2
Sending the Request
41
8.1.3
Processing Responses
42
8.1.3.1
Transaction Layer Errors
42
8.1.3.2
Unrecognized Responses
42
8.1.3.3
Vias
43
8.1.3.4
Processing 3xx Responses
43
8.1.3.5
Processing 4xx Responses
45
8.2
UAS Behavior
46
8.2.1
Method Inspection
46
8.2.2
Header Inspection
46
8.2.2.1
To and Request-URI
46
8.2.2.2
Merged Requests
47
8.2.2.3
8.2.3
Require
Content Processing
47
48
8.2.4
8.2.5
Applying Extensions
Processing the Request
49
49
Rosenberg, et. al.
Standards Track
[Page 2]
RFC 3261
SIP: Session Initiation Protocol
June 2002
8.2.6
Generating the Response
49
8.2.6.1
Sending a Provisional Response
49
8.2.6.2
Headers and Tags
50
8.2.7
Stateless UAS Behavior
50
8.3
Redirect Servers
51
9
Canceling a Request
53
9.1
Client Behavior
53
9.2
Server Behavior
55
10
Registrations
56
10.1
Overview
56
10.2
Constructing the REGISTER Request
57
10.2.1
Adding Bindings
59
10.2.1.1
Setting the Expiration Interval of Contact Addresses
60
10.2.1.2
Preferences among Contact Addresses
61
10.2.2
Removing Bindings
61
10.2.3
Fetching Bindings
61
10.2.4
Refreshing Bindings
61
10.2.5
Setting the Internal Clock
62
10.2.6
Discovering a Registrar
62
10.2.7
Transmitting a Request
62
10.2.8
Error Responses
63
10.3
Processing REGISTER Requests
63
11
Querying for Capabilities
66
11.1
Construction of OPTIONS Request
67
11.2
Processing of OPTIONS Request
68
12
Dialogs
69
12.1
Creation of a Dialog
70
12.1.1
UAS behavior
70
12.1.2
UAC Behavior
71
12.2
Requests within a Dialog
72
12.2.1
UAC Behavior
73
12.2.1.1
Generating the Request
73
12.2.1.2
Processing the Responses
75
12.2.2
UAS Behavior
76
12.3
13
13.1
Overview
13.2
13.2.1
13.2.2
13.2.2.1
1xx Responses
13.2.2.2
3xx Responses
Termination of a Dialog
Initiating a Session
UAC Processing
Creating the Initial INVITE
Processing INVITE Responses
13.2.2.3 4xx, 5xx and 6xx Responses
13.2.2.4 2xx Responses
77
77
77
78
78
81
81
81
81
82
13.3
UAS Processing
13.3.1
Processing of the INVITE
13.3.1.1
Progress
83
83
84
13.3.1.2 The INVITE is Redirected
84
Rosenberg, et. al.
Standards Track
[Page 3]
RFC 3261
SIP: Session Initiation Protocol
June 2002
13.3.1.3
The INVITE is Rejected
85
13.3.1.4
The INVITE is Accepted
85
14
Modifying an Existing Session
86
14.1
UAC Behavior
86
14.2
UAS Behavior
88
15
Terminating a Session
89
15.1
Terminating a Session with a BYE Request
90
15.1.1
UAC Behavior
90
15.1.2
UAS Behavior
91
16
Proxy Behavior
91
16.1
Overview
91
16.2
Stateful Proxy
92
16.3
Request Validation
94
16.4
Route Information Preprocessing
96
16.5
Determining Request Targets
97
16.6
Request Forwarding
99
16.7
Response Processing
107
16.8
Processing Timer C
114
16.9
Handling Transport Errors
115
16.10
CANCEL Processing
115
16.11
Stateless Proxy
116
16.12
Summary of Proxy Route Processing
118
16.12.1
Examples
118
16.12.1.1
Basic SIP Trapezoid
118
16.12.1.2
16.12.1.3
Traversing a Strict-Routing Proxy
Rewriting Record-Route Header Field Values
120
121
17
Transactions
122
17.1
Client Transaction
124
17.1.1
INVITE Client Transaction
125
17.1.1.1
Overview of INVITE Transaction
125
17.1.1.2
Formal Description
125
17.1.1.3
Construction of the ACK Request
129
17.1.2
Non-INVITE Client Transaction
130
17.1.2.1
Overview of the non-INVITE Transaction
130
17.1.2.2
Formal Description
131
17.1.3
Matching Responses to Client Transactions
132
17.1.4
Handling Transport Errors
133
17.2
Server Transaction
134
17.2.1
INVITE Server Transaction
134
17.2.2
Non-INVITE Server Transaction
137
17.2.3
Matching Requests to Server Transactions
138
17.2.4
Handling Transport Errors
141
18
Transport
141
18.1
Clients
142
18.1.1
Sending Requests
142
18.1.2
Receiving Responses
144
18.2
Servers
145
18.2.1
Receiving Requests
145
Rosenberg, et. al.
Standards Track
[Page 4]
RFC 3261
SIP: Session Initiation Protocol
June 2002
18.2.2
Sending Responses
146
18.3
Framing
147
18.4
Error Handling
147
19
Common Message Components
147
19.1
SIP and SIPS Uniform Resource Indicators
148
19.1.1
SIP and SIPS URI Components
148
19.1.2
Character Escaping Requirements
152
19.1.3
Example SIP and SIPS URIS
153
19.1.4
URI Comparison
153
19.1.5
Forming Requests from a URI
156
19.1.6
Relating SIP URIS and tel URLS
157
19.2
Option Tags
158
19.3
Tags
159
20
Header Fields
159
20.1
Accept
161
20.2
Accept-Encoding
163
20.3
Accept-Language
164
20.4
Alert-Info
164
20.5
Allow
165
20.6
Authentication-Info
165
20.7
Authorization
165
20.8
Call-ID
166
20.9
Call-Info
166
20.10
Contact
167
20.11
Content-Disposition
168
20.12
Content-Encoding
169
20.13
Content-Language
169
20.14
Content-Length
169
20.15
Content-Type
170
20.16
CSeq
170
20.17
Date
170
20.18
Error-Info
171
20.19
Expires
171
20.20
From
172
20.21
In-Reply-To
172
20.22
Max-Forwards
173
20.23
Min-Expires
173
20.24
MIME-Version
173
20.25
Organization
174
20.26
Priority
174
20.27
Proxy-Authenticate
174
20.28
Proxy-Authorization
175
20.29
Proxy-Require
175
20.30
Record-Route
175
20.31
Reply-To
176
20.32
Require
176
20.33
Retry-After
176
20.34
Route
177
Rosenberg, et. al.
Standards Track
[Page 5]
RFC 3261
SIP: Session Initiation Protocol
June 2002
20.35
Server
177
20.36
Subject
177
20.37
Supported
178
20.38
Timestamp
178
20.39
To
178
20.40
Unsupported
179
20.41
User-Agent
179
20.42
Via
179
20.43
Warning
180
20.44
WWW-Authenticate
182
21
Response Codes
182
21.1
Provisional 1xx
182
21.1.1
100 Trying
183
21.1.2
180 Ringing
183
21.1.3
181 Call Is Being Forwarded
183
21.1.4
182 Queued
183
21.1.5
183 Session Progress
183
21.2
Successful 2xx
183
21.2.1
200 OK
183
21.3
Redirection 3xx
184
21.3.1
300 Multiple Choices
184
21.3.2
301 Moved Permanently
184
21.3.3
302 Moved Temporarily
184
21.3.4
305 Use Proxy
185
21.3.5
380 Alternative Service
185
21.4
Request Failure 4xx
185
21.4.1
400 Bad Request
185
21.4.2
401 Unauthorized
185
21.4.3
402 Payment Required
186
21.4.4
403 Forbidden
186
21.4.5
404 Not Found
186
21.4.6
405 Method Not Allowed
186
21.4.7
406 Not Acceptable
186
21.4.8
407 Proxy Authentication Required
186
21.4.9
408 Request Timeout
186
21.4.10
410 Gone
187
21.4.11
413 Request Entity Too Large
187
21.4.12 414 Request-URI Too Long
187
21.4.13
415 Unsupported Media Type
187
21.4.14 416 Unsupported URI Scheme
187
21.4.15
420 Bad Extension
187
21.4.16 421 Extension Required
188
21.4.17
423 Interval Too Brief
188
21.4.18
480 Temporarily Unavailable
188
21.4.19 481 Call/Transaction Does Not Exist
188
21.4.20
482 Loop Detected
188
21.4.21 483 Too Many Hops
189
21.4.22 484 Address Incomplete
189
Rosenberg, et. al.
Standards Track
[Page 6]
RFC 3261
SIP: Session Initiation Protocol
June 2002
21.4.23
485 Ambiguous
189
21.4.24 486 Busy Here
189
21.4.25 487 Request Terminated
190
21.4.26 488 Not Acceptable Here
190
21.4.27
491 Request Pending
190
21.4.28
493 Undecipherable
190
21.5
Server Failure 5xx
190
21.5.1
500 Server Internal Error
190
21.5.2
501 Not Implemented
191
21.5.3
502 Bad Gateway
191
21.5.4
503 Service Unavailable
191
21.5.5
504 Server Time-out
191
21.5.6
505 Version Not Supported
192
21.5.7
513 Message Too Large
192
21.6
Global Failures 6xx
192
21.6.1
600 Busy Everywhere
192
21.6.2
603 Decline
192
21.6.3
21.6.4
22
22.1
22.2
22.3
22.4
23
604 Does Not Exist Anywhere
606 Not Acceptable
Usage of HTTP Authentication
Framework
User-to-User Authentication
Proxy-to-User Authentication
The Digest Authentication Scheme
S/MIME
192
192
193
193
195
197
199
201
23.1
S/MIME Certificates
201
23.2
S/MIME Key Exchange
202
23.3
Securing MIME bodies
205
23.4
SIP Header Privacy and Integrity using S/MIME:
Tunneling SIP
207
23.4.1
Integrity and Confidentiality Properties of SIP
Headers
207
23.4.1.1
Integrity
207
23.4.1.2
Confidentiality
208
23.4.2
Tunneling Integrity and Authentication
209
23.4.3
Tunneling Encryption
211
24
Examples
213
24.1
Registration
213
24.2
Session Setup
214
25
Augmented BNF for the SIP Protocol
219
25.1
Basic Rules
219
26
Security Considerations: Threat Model and Security
Usage Recommendations
232
26.1
Attacks and Threat Models
233
26.1.1
Registration Hijacking
233
26.1.2
Impersonating a Server
234
26.1.3
Tampering with Message Bodies
235
26.1.4
Tearing Down Sessions
235
Rosenberg, et. al.
Standards Track
[Page 7]
RFC 3261
SIP: Session Initiation Protocol
June 2002
26.1.5
26.2
Denial of Service and Amplification
Security Mechanisms
236
237
26.2.1
26.2.2
Transport and Network Layer Security
SIPS URI Scheme
238
239
26.2.3
HTTP Authentication
240
26.2.4
S/MIME
240
26.3
Implementing Security Mechanisms
241
26.3.1
Requirements for Implementers of SIP
241
26.3.2
Security Solutions
242
26.3.2.1
Registration
242
26.3.2.2
Interdomain Requests
243
26.3.2.3
Peer-to-Peer Requests
245
26.3.2.4
DoS Protection
246
26.4
Limitations
247
26.4.1
HTTP Digest
247
26.4.2
S/MIME
248
26.4.3
TLS
249
26.4.4
SIPS URIS
249
26.5
Privacy
251
27
IANA Considerations
252
27.1
Option Tags
252
27.2
Warn-Codes
252
27.3
Header Field Names
253
27.4
Method and Response Codes
253
27.5
The "message/sip" MIME type.
254
27.6
New Content-Disposition Parameter Registrations
255
28
Changes From RFC 2543
255
28.1
Major Functional Changes
255
28.2
Minor Functional Changes
260
29
Normative References
261
30
Informative References
262
A
Table of Timer Values
265
Acknowledgments
266
Authors' Addresses
267
269
Full Copyright Statement
1 Introduction
There are many applications of the Internet that require the creation
and management of a session, where a session is considered an
exchange of data between an association of participants. The
implementation of these applications is complicated by the practices
of participants: users may move between endpoints, they may be
addressable by multiple names, and they may communicate in several
different media sometimes simultaneously. Numerous protocols have
been authored that carry various forms of real-time multimedia
session data such as voice, video, or text messages. The Session
Initiation Protocol (SIP) works in concert with these protocols by
Rosenberg, et. al.
Standards Track
[Page 8]
RFC 3261
SIP: Session Initiation Protocol
June 2002
enabling Internet endpoints (called user agents) to discover one
another and to agree on a characterization of a session they would
like to share. For locating prospective session participants, and
for other functions, SIP enables the creation of an infrastructure of
network hosts (called proxy servers) to which user agents can send
registrations, invitations to sessions, and other requests. SIP is
an agile, general-purpose tool for creating, modifying, and
terminating sessions that works independently of underlying transport
protocols and without dependency on the type of session that is being
established.
2 Overview of SIP Functionality
SIP is an application-layer control protocol that can establish,
modify, and terminate multimedia sessions (conferences) such as
Internet telephony calls. SIP can also invite participants to
already existing sessions, such as multicast conferences. Media can
be added to (and removed from) an existing session. SIP
transparently supports name mapping and redirection services, which
supports personal mobility [27] users can maintain a single
externally visible identifier regardless of their network location.
SIP supports five facets of establishing and terminating multimedia
communications:
User location: determination of the end system to be used for
communication;
User availability: determination of the willingness of the called
party to engage in communications;
User capabilities: determination of the media and media parameters
to be used;
Session setup: "ringing", establishment of session parameters at
both called and calling party;
Session management: including transfer and termination of
sessions, modifying session parameters, and invoking
services.
SIP is not a vertically integrated communications system. SIP is
rather a component that can be used with other IETF protocols to
build a complete multimedia architecture. Typically, these
architectures will include protocols such as the Real-time Transport
Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and
providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC
2326 [29]) for controlling delivery of streaming media, the Media
Rosenberg, et. al.
Standards Track
[Page 9]
RFC 3261
SIP: Session Initiation Protocol
June 2002
Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling
gateways to the Public Switched Telephone Network (PSTN), and the
Session Description Protocol (SDP) (RFC 2327 [1]) for describing
multimedia sessions. Therefore, SIP should be used in conjunction
with other protocols in order to provide complete services to the
users. However, the basic functionality and operation of SIP does
not depend on any of these protocols.
SIP does not provide services. Rather, SIP provides primitives that
can be used to implement different services. For example, SIP can
locate a user and deliver an opaque object to his current location.
If this primitive is used to deliver a session description written in
SDP, for instance, the endpoints can agree on the parameters of a
session. If the same primitive is used to deliver a photo of the
caller as well as the session description, a "caller ID" service can
be easily implemented. As this example shows, a single primitive is
typically used to provide several different services.
SIP does not offer conference control services such as floor control
or voting and does not prescribe how a conference is to be managed.
SIP can be used to initiate a session that uses some other conference
control protocol. Since SIP messages and the sessions they establish
can pass through entirely different networks, SIP cannot, and does
not, provide any kind of network resource reservation capabilities.
The nature of the services provided make security particularly
important. To that end, SIP provides a suite of security services,
which include denial-of-service prevention, authentication (both user
to user and proxy to user), integrity protection, and encryption and
privacy services.
SIP works with both IPv4 and IPv6.
3 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [2] and indicate requirement levels for
compliant SIP implementations.
4 Overview of Operation
This section introduces the basic operations of SIP using simple
examples. This section is tutorial in nature and does not contain
any normative statements.
Rosenberg, et. al.
Standards Track
[Page 10]
RFC 3261
SIP: Session Initiation Protocol
June 2002
The first example shows the basic functions of SIP: location of an
end point, signal of a desire to communicate, negotiation of session
parameters to establish the session, and teardown of the session once
established.
Figure 1 shows a typical example of a SIP message exchange between
two users, Alice and Bob. (Each message is labeled with the letter
"F" and a number for reference by the text.) In this example, Alice
uses a SIP application on her PC (referred to as a softphone) to call
Bob on his SIP phone over the Internet. Also shown are two SIP proxy
servers that act on behalf of Alice and Bob to facilitate the session
establishment. This typical arrangement is often referred to as the
"SIP trapezoid" as shown by the geometric shape of the dotted lines
in Figure 1.
Alice "calls" Bob using his SIP identity, a type of Uniform Resource
Identifier (URI) called a SIP URI. SIP URIs are defined in Section
19.1. It has a similar form to an email address, typically
containing a username and a host name. In this case, it is
sip:[email protected], where biloxi.com is the domain of Bob's SIP
service provider. Alice has a SIP URI of sip:[email protected].
Alice might have typed in Bob's URI or perhaps clicked on a hyperlink
or an entry in an address book. SIP also provides a secure URI,
called a SIPS URI. An example would be sips:[email protected]. A call
made to a SIPS URI guarantees that secure, encrypted transport
(namely TLS) is used to carry all SIP messages from the caller to the
domain of the callee. From there, the request is sent securely to
the callee, but with security mechanisms that depend on the policy of
the domain of the callee.
SIP is based on an HTTP-like request/response transaction model.
Each transaction consists of a request that invokes a particular
method, or function, on the server and at least one response. In
this example, the transaction begins with Alice's softphone sending
an INVITE request addressed to Bob's SIP URI. INVITE is an example
of a SIP method that specifies the action that the requestor (Alice)
wants the server (Bob) to take. The INVITE request contains a number
of header fields. Header fields are named attributes that provide
additional information about a message. The ones present in an
INVITE include a unique identifier for the call, the destination
address, Alice's address, and information about the type of session
that Alice wishes to establish with Bob. The INVITE (message F1 in
Figure 1) might look like this:
Rosenberg, et. al.
Standards Track
[Page 11]
RFC 3261
SIP: Session Initiation Protocol
atlanta.com
proxy
Alice's
softphone
INVITE F1
--->
100 Trying F3
INVITE F2
biloxi.com
proxy
June 2002
Bob's
SIP Phone
---->
100 Trying F5
<
INVITE F4
180 Ringing F6
180 Ringing F7
<---
180 Ringing F8
-->
200 OK F9
<
200 OK F10
<----
200 OK F11
<-
<-
ACK F12
Media Session
BYE F13
200 OK F14
>
Figure 1: SIP session setup example with SIP trapezoid
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
The first line of the text-encoded message contains the method name
(INVITE). The lines that follow are a list of header fields. This
example contains a minimum required set. The header fields are
briefly described below:
Rosenberg, et. al.
Standards Track
[Page 12]
RFC 3261
SIP: Session Initiation Protocol
June 2002
Via contains the address (pc33.atlanta.com) at which Alice is
expecting to receive responses to this request. It also contains a
branch parameter that identifies this transaction.
To contains a display name (Bob) and a SIP or SIPS URI
(sip:[email protected]) towards which the request was originally
directed. Display names are described in RFC 2822 [3].
From also contains a display name (Alice) and a SIP or SIPS URI
(sip:[email protected]) that indicate the originator of the request.
This header field also has a tag parameter containing a random string
(1928301774) that was added to the URI by the softphone. It is used
for identification purposes.
Call-ID contains a globally unique identifier for this call,
generated by the combination of a random string and the softphone's
host name or IP address. The combination of the To tag, From tag,
and Call-ID completely defines a peer-to-peer SIP relationship
between Alice and Bob and is referred to as a dialog.
The
CSeq or Command Sequence contains an integer and a method name.
CSeq number is incremented for each new request within a dialog and
is a traditional sequence number.
Contact contains a SIP or SIPS URI that represents a direct route to
contact Alice, usually composed of a username at a fully qualified
domain name (FQDN). While an FQDN is preferred, many end systems do
not have registered domain names, so IP addresses are permitted.
While the Via header field tells other elements where to send the
response, the Contact header field tells other elements where to send
future requests.
Max-Forwards serves to limit the number of hops a request can make on
the way to its destination. It consists of an integer that is
decremented by one at each hop.
Content-Type contains a description of the message body (not shown).
Content-Length contains an octet (byte) count of the message body.
The complete set of SIP header fields is defined in Section 20.
The details of the session, such as the type of media, codec, or
sampling rate, are not described using SIP. Rather, the body of a
SIP message contains a description of the session, encoded in some
other protocol format. One such format is the Session Description
Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the
Rosenberg, et. al.
Standards Track
[Page 13]
RFC 3261
SIP: Session Initiation Protocol
June 2002
example) is carried by the SIP message in a way that is analogous to
a document attachment being carried by an email message, or a web
page being carried in an HTTP message.
Since the softphone does not know the location of Bob or the SIP
server in the biloxi.com domain, the softphone sends the INVITE to
the SIP server that serves Alice's domain, atlanta.com. The address
of the atlanta.com SIP server could have been configured in Alice's
softphone, or it could have been discovered by DHCP, for example.
The atlanta.com SIP server is a type of SIP server known as a proxy
server. A proxy server receives SIP requests and forwards them on