Network Working Group J. Rosenberg | |
Request for Comments: 3261 dynamicsoft | |
Obsoletes: 2543 H. Schulzrinne | |
Category: Standards Track Columbia U. | |
G. Camarillo | |
Ericsson | |
A. Johnston | |
WorldCom | |
J. Peterson | |
Neustar | |
R. Sparks | |
dynamicsoft | |
M. Handley | |
ICIR | |
E. Schooler | |
AT&T | |
June 2002 | |
SIP: Session Initiation Protocol | |
Status of this Memo | |
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 Require ............................................. 47 | |
8.2.3 Content Processing .................................. 48 | |
8.2.4 Applying Extensions ................................. 49 | |
8.2.5 Processing the Request .............................. 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 Termination of a Dialog ............................. 77 | |
13 Initiating a Session ................................ 77 | |
13.1 Overview ............................................ 77 | |
13.2 UAC Processing ...................................... 78 | |
13.2.1 Creating the Initial INVITE ......................... 78 | |
13.2.2 Processing INVITE Responses ......................... 81 | |
13.2.2.1 1xx Responses ....................................... 81 | |
13.2.2.2 3xx Responses ....................................... 81 | |
13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81 | |
13.2.2.4 2xx Responses ....................................... 82 | |
13.3 UAS Processing ...................................... 83 | |
13.3.1 Processing of the INVITE ............................ 83 | |
13.3.1.1 Progress ............................................ 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 Traversing a Strict-Routing Proxy ................... 120 | |
16.12.1.3 Rewriting Record-Route Header Field Values .......... 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 604 Does Not Exist Anywhere ......................... 192 | |
21.6.4 606 Not Acceptable .................................. 192 | |
22 Usage of HTTP Authentication ........................ 193 | |
22.1 Framework ........................................... 193 | |
22.2 User-to-User Authentication ......................... 195 | |
22.3 Proxy-to-User Authentication ........................ 197 | |
22.4 The Digest Authentication Scheme .................... 199 | |
23 S/MIME .............................................. 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 Denial of Service and Amplification ................. 236 | |
26.2 Security Mechanisms ................................. 237 | |
26.2.1 Transport and Network Layer Security ................ 238 | |
26.2.2 SIPS URI Scheme ..................................... 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 | |
Full Copyright Statement ....................................... 269 | |
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:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP | |
service provider. Alice has a SIP URI of sip:alice@atlanta.com. | |
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:bob@biloxi.com. 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 June 2002 | |
atlanta.com . . . biloxi.com | |
. proxy proxy . | |
. . | |
Alice's . . . . . . . . . . . . . . . . . . . . Bob's | |
softphone SIP Phone | |
| | | | | |
| INVITE F1 | | | | |
|--------------->| INVITE F2 | | | |
| 100 Trying F3 |--------------->| INVITE F4 | | |
|<---------------| 100 Trying F5 |--------------->| | |
| |<-------------- | 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:bob@biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds | |
Max-Forwards: 70 | |
To: Bob <sip:bob@biloxi.com> | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710@pc33.atlanta.com | |
CSeq: 314159 INVITE | |
Contact: <sip:alice@pc33.atlanta.com> | |
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:bob@biloxi.com) 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:alice@atlanta.com) 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. | |
CSeq or Command Sequence contains an integer and a method name. The | |
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 | |
behalf of the requestor. In this example, the proxy server receives | |
the INVITE request and sends a 100 (Trying) response back to Alice's | |
softphone. The 100 (Trying) response indicates that the INVITE has | |
been received and that the proxy is working on her behalf to route | |
the INVITE to the destination. Responses in SIP use a three-digit | |
code followed by a descriptive phrase. This response contains the | |
same To, From, Call-ID, CSeq and branch parameter in the Via as the | |
INVITE, which allows Alice's softphone to correlate this response to | |
the sent INVITE. The atlanta.com proxy server locates the proxy | |
server at biloxi.com, possibly by performing a particular type of DNS | |
(Domain Name Service) lookup to find the SIP server that serves the | |
biloxi.com domain. This is described in [4]. As a result, it | |
obtains the IP address of the biloxi.com proxy server and forwards, | |
or proxies, the INVITE request there. Before forwarding the request, | |
the atlanta.com proxy server adds an additional Via header field | |
value that contains its own address (the INVITE already contains | |
Alice's address in the first Via). The biloxi.com proxy server | |
receives the INVITE and responds with a 100 (Trying) response back to | |
the atlanta.com proxy server to indicate that it has received the | |
INVITE and is processing the request. The proxy server consults a | |
database, generically called a location service, that contains the | |
current IP address of Bob. (We shall see in the next section how | |
this database can be populated.) The biloxi.com proxy server adds | |
another Via header field value with its own address to the INVITE and | |
proxies it to Bob's SIP phone. | |
Bob's SIP phone receives the INVITE and alerts Bob to the incoming | |
call from Alice so that Bob can decide whether to answer the call, | |
that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 | |
(Ringing) response, which is routed back through the two proxies in | |
the reverse direction. Each proxy uses the Via header field to | |
determine where to send the response and removes its own address from | |
the top. As a result, although DNS and location service lookups were | |
required to route the initial INVITE, the 180 (Ringing) response can | |
be returned to the caller without lookups or without state being | |
Rosenberg, et. al. Standards Track [Page 14] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
maintained in the proxies. This also has the desirable property that | |
each proxy that sees the INVITE will also see all responses to the | |
INVITE. | |
When Alice's softphone receives the 180 (Ringing) response, it passes | |
this information to Alice, perhaps using an audio ringback tone or by | |
displaying a message on Alice's screen. | |
In this example, Bob decides to answer the call. When he picks up | |
the handset, his SIP phone sends a 200 (OK) response to indicate that | |
the call has been answered. The 200 (OK) contains a message body | |
with the SDP media description of the type of session that Bob is | |
willing to establish with Alice. As a result, there is a two-phase | |
exchange of SDP messages: Alice sent one to Bob, and Bob sent one | |
back to Alice. This two-phase exchange provides basic negotiation | |
capabilities and is based on a simple offer/answer model of SDP | |
exchange. If Bob did not wish to answer the call or was busy on | |
another call, an error response would have been sent instead of the | |
200 (OK), which would have resulted in no media session being | |
established. The complete list of SIP response codes is in Section | |
21. The 200 (OK) (message F9 in Figure 1) might look like this as | |
Bob sends it out: | |
SIP/2.0 200 OK | |
Via: SIP/2.0/UDP server10.biloxi.com | |
;branch=z9hG4bKnashds8;received=192.0.2.3 | |
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com | |
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 | |
Via: SIP/2.0/UDP pc33.atlanta.com | |
;branch=z9hG4bK776asdhds ;received=192.0.2.1 | |
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710@pc33.atlanta.com | |
CSeq: 314159 INVITE | |
Contact: <sip:bob@192.0.2.4> | |
Content-Type: application/sdp | |
Content-Length: 131 | |
(Bob's SDP not shown) | |
The first line of the response contains the response code (200) and | |
the reason phrase (OK). The remaining lines contain header fields. | |
The Via, To, From, Call-ID, and CSeq header fields are copied from | |
the INVITE request. (There are three Via header field values - one | |
added by Alice's SIP phone, one added by the atlanta.com proxy, and | |
one added by the biloxi.com proxy.) Bob's SIP phone has added a tag | |
parameter to the To header field. This tag will be incorporated by | |
both endpoints into the dialog and will be included in all future | |
Rosenberg, et. al. Standards Track [Page 15] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
requests and responses in this call. The Contact header field | |
contains a URI at which Bob can be directly reached at his SIP phone. | |
The Content-Type and Content-Length refer to the message body (not | |
shown) that contains Bob's SDP media information. | |
In addition to DNS and location service lookups shown in this | |
example, proxy servers can make flexible "routing decisions" to | |
decide where to send a request. For example, if Bob's SIP phone | |
returned a 486 (Busy Here) response, the biloxi.com proxy server | |
could proxy the INVITE to Bob's voicemail server. A proxy server can | |
also send an INVITE to a number of locations at the same time. This | |
type of parallel search is known as forking. | |
In this case, the 200 (OK) is routed back through the two proxies and | |
is received by Alice's softphone, which then stops the ringback tone | |
and indicates that the call has been answered. Finally, Alice's | |
softphone sends an acknowledgement message, ACK, to Bob's SIP phone | |
to confirm the reception of the final response (200 (OK)). In this | |
example, the ACK is sent directly from Alice's softphone to Bob's SIP | |
phone, bypassing the two proxies. This occurs because the endpoints | |
have learned each other's address from the Contact header fields | |
through the INVITE/200 (OK) exchange, which was not known when the | |
initial INVITE was sent. The lookups performed by the two proxies | |
are no longer needed, so the proxies drop out of the call flow. This | |
completes the INVITE/200/ACK three-way handshake used to establish | |
SIP sessions. Full details on session setup are in Section 13. | |
Alice and Bob's media session has now begun, and they send media | |
packets using the format to which they agreed in the exchange of SDP. | |
In general, the end-to-end media packets take a different path from | |
the SIP signaling messages. | |
During the session, either Alice or Bob may decide to change the | |
characteristics of the media session. This is accomplished by | |
sending a re-INVITE containing a new media description. This re- | |
INVITE references the existing dialog so that the other party knows | |
that it is to modify an existing session instead of establishing a | |
new session. The other party sends a 200 (OK) to accept the change. | |
The requestor responds to the 200 (OK) with an ACK. If the other | |
party does not accept the change, he sends an error response such as | |
488 (Not Acceptable Here), which also receives an ACK. However, the | |
failure of the re-INVITE does not cause the existing call to fail - | |
the session continues using the previously negotiated | |
characteristics. Full details on session modification are in Section | |
14. | |
Rosenberg, et. al. Standards Track [Page 16] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
At the end of the call, Bob disconnects (hangs up) first and | |
generates a BYE message. This BYE is routed directly to Alice's | |
softphone, again bypassing the proxies. Alice confirms receipt of | |
the BYE with a 200 (OK) response, which terminates the session and | |
the BYE transaction. No ACK is sent - an ACK is only sent in | |
response to a response to an INVITE request. The reasons for this | |
special handling for INVITE will be discussed later, but relate to | |
the reliability mechanisms in SIP, the length of time it can take for | |
a ringing phone to be answered, and forking. For this reason, | |
request handling in SIP is often classified as either INVITE or non- | |
INVITE, referring to all other methods besides INVITE. Full details | |
on session termination are in Section 15. | |
Section 24.2 describes the messages shown in Figure 1 in full. | |
In some cases, it may be useful for proxies in the SIP signaling path | |
to see all the messaging between the endpoints for the duration of | |
the session. For example, if the biloxi.com proxy server wished to | |
remain in the SIP messaging path beyond the initial INVITE, it would | |
add to the INVITE a required routing header field known as Record- | |
Route that contained a URI resolving to the hostname or IP address of | |
the proxy. This information would be received by both Bob's SIP | |
phone and (due to the Record-Route header field being passed back in | |
the 200 (OK)) Alice's softphone and stored for the duration of the | |
dialog. The biloxi.com proxy server would then receive and proxy the | |
ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently | |
decide to receive subsequent messages, and those messages will pass | |
through all proxies that elect to receive it. This capability is | |
frequently used for proxies that are providing mid-call features. | |
Registration is another common operation in SIP. Registration is one | |
way that the biloxi.com server can learn the current location of Bob. | |
Upon initialization, and at periodic intervals, Bob's SIP phone sends | |
REGISTER messages to a server in the biloxi.com domain known as a SIP | |
registrar. The REGISTER messages associate Bob's SIP or SIPS URI | |
(sip:bob@biloxi.com) with the machine into which he is currently | |
logged (conveyed as a SIP or SIPS URI in the Contact header field). | |
The registrar writes this association, also called a binding, to a | |
database, called the location service, where it can be used by the | |
proxy in the biloxi.com domain. Often, a registrar server for a | |
domain is co-located with the proxy for that domain. It is an | |
important concept that the distinction between types of SIP servers | |
is logical, not physical. | |
Bob is not limited to registering from a single device. For example, | |
both his SIP phone at home and the one in the office could send | |
registrations. This information is stored together in the location | |
Rosenberg, et. al. Standards Track [Page 17] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
service and allows a proxy to perform various types of searches to | |
locate Bob. Similarly, more than one user can be registered on a | |
single device at the same time. | |
The location service is just an abstract concept. It generally | |
contains information that allows a proxy to input a URI and receive a | |
set of zero or more URIs that tell the proxy where to send the | |
request. Registrations are one way to create this information, but | |
not the only way. Arbitrary mapping functions can be configured at | |
the discretion of the administrator. | |
Finally, it is important to note that in SIP, registration is used | |
for routing incoming SIP requests and has no role in authorizing | |
outgoing requests. Authorization and authentication are handled in | |
SIP either on a request-by-request basis with a challenge/response | |
mechanism, or by using a lower layer scheme as discussed in Section | |
26. | |
The complete set of SIP message details for this registration example | |
is in Section 24.1. | |
Additional operations in SIP, such as querying for the capabilities | |
of a SIP server or client using OPTIONS, or canceling a pending | |
request using CANCEL, will be introduced in later sections. | |
5 Structure of the Protocol | |
SIP is structured as a layered protocol, which means that its | |
behavior is described in terms of a set of fairly independent | |
processing stages with only a loose coupling between each stage. The | |
protocol behavior is described as layers for the purpose of | |
presentation, allowing the description of functions common across | |
elements in a single section. It does not dictate an implementation | |
in any way. When we say that an element "contains" a layer, we mean | |
it is compliant to the set of rules defined by that layer. | |
Not every element specified by the protocol contains every layer. | |
Furthermore, the elements specified by SIP are logical elements, not | |
physical ones. A physical realization can choose to act as different | |
logical elements, perhaps even on a transaction-by-transaction basis. | |
The lowest layer of SIP is its syntax and encoding. Its encoding is | |
specified using an augmented Backus-Naur Form grammar (BNF). The | |
complete BNF is specified in Section 25; an overview of a SIP | |
message's structure can be found in Section 7. | |
Rosenberg, et. al. Standards Track [Page 18] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The second layer is the transport layer. It defines how a client | |
sends requests and receives responses and how a server receives | |
requests and sends responses over the network. All SIP elements | |
contain a transport layer. The transport layer is described in | |
Section 18. | |
The third layer is the transaction layer. Transactions are a | |
fundamental component of SIP. A transaction is a request sent by a | |
client transaction (using the transport layer) to a server | |
transaction, along with all responses to that request sent from the | |
server transaction back to the client. The transaction layer handles | |
application-layer retransmissions, matching of responses to requests, | |
and application-layer timeouts. Any task that a user agent client | |
(UAC) accomplishes takes place using a series of transactions. | |
Discussion of transactions can be found in Section 17. User agents | |
contain a transaction layer, as do stateful proxies. Stateless | |
proxies do not contain a transaction layer. The transaction layer | |
has a client component (referred to as a client transaction) and a | |
server component (referred to as a server transaction), each of which | |
are represented by a finite state machine that is constructed to | |
process a particular request. | |
The layer above the transaction layer is called the transaction user | |
(TU). Each of the SIP entities, except the stateless proxy, is a | |
transaction user. When a TU wishes to send a request, it creates a | |
client transaction instance and passes it the request along with the | |
destination IP address, port, and transport to which to send the | |
request. A TU that creates a client transaction can also cancel it. | |
When a client cancels a transaction, it requests that the server stop | |
further processing, revert to the state that existed before the | |
transaction was initiated, and generate a specific error response to | |
that transaction. This is done with a CANCEL request, which | |
constitutes its own transaction, but references the transaction to be | |
cancelled (Section 9). | |
The SIP elements, that is, user agent clients and servers, stateless | |
and stateful proxies and registrars, contain a core that | |
distinguishes them from each other. Cores, except for the stateless | |
proxy, are transaction users. While the behavior of the UAC and UAS | |
cores depends on the method, there are some common rules for all | |
methods (Section 8). For a UAC, these rules govern the construction | |
of a request; for a UAS, they govern the processing of a request and | |
generating a response. Since registrations play an important role in | |
SIP, a UAS that handles a REGISTER is given the special name | |
registrar. Section 10 describes UAC and UAS core behavior for the | |
REGISTER method. Section 11 describes UAC and UAS core behavior for | |
the OPTIONS method, used for determining the capabilities of a UA. | |
Rosenberg, et. al. Standards Track [Page 19] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Certain other requests are sent within a dialog. A dialog is a | |
peer-to-peer SIP relationship between two user agents that persists | |
for some time. The dialog facilitates sequencing of messages and | |
proper routing of requests between the user agents. The INVITE | |
method is the only way defined in this specification to establish a | |
dialog. When a UAC sends a request that is within the context of a | |
dialog, it follows the common UAC rules as discussed in Section 8 but | |
also the rules for mid-dialog requests. Section 12 discusses dialogs | |
and presents the procedures for their construction and maintenance, | |
in addition to construction of requests within a dialog. | |
The most important method in SIP is the INVITE method, which is used | |
to establish a session between participants. A session is a | |
collection of participants, and streams of media between them, for | |
the purposes of communication. Section 13 discusses how sessions are | |
initiated, resulting in one or more SIP dialogs. Section 14 | |
discusses how characteristics of that session are modified through | |
the use of an INVITE request within a dialog. Finally, section 15 | |
discusses how a session is terminated. | |
The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal | |
entirely with the UA core (Section 9 describes cancellation, which | |
applies to both UA core and proxy core). Section 16 discusses the | |
proxy element, which facilitates routing of messages between user | |
agents. | |
6 Definitions | |
The following terms have special significance for SIP. | |
Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI | |
that points to a domain with a location service that can map | |
the URI to another URI where the user might be available. | |
Typically, the location service is populated through | |
registrations. An AOR is frequently thought of as the "public | |
address" of the user. | |
Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a | |
logical entity that receives a request and processes it as a | |
user agent server (UAS). In order to determine how the request | |
should be answered, it acts as a user agent client (UAC) and | |
generates requests. Unlike a proxy server, it maintains dialog | |
state and must participate in all requests sent on the dialogs | |
it has established. Since it is a concatenation of a UAC and | |
UAS, no explicit definitions are needed for its behavior. | |
Rosenberg, et. al. Standards Track [Page 20] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Call: A call is an informal term that refers to some communication | |
between peers, generally set up for the purposes of a | |
multimedia conversation. | |
Call Leg: Another name for a dialog [31]; no longer used in this | |
specification. | |
Call Stateful: A proxy is call stateful if it retains state for a | |
dialog from the initiating INVITE to the terminating BYE | |
request. A call stateful proxy is always transaction stateful, | |
but the converse is not necessarily true. | |
Client: A client is any network element that sends SIP requests | |
and receives SIP responses. Clients may or may not interact | |
directly with a human user. User agent clients and proxies are | |
clients. | |
Conference: A multimedia session (see below) that contains | |
multiple participants. | |
Core: Core designates the functions specific to a particular type | |
of SIP entity, i.e., specific to either a stateful or stateless | |
proxy, a user agent or registrar. All cores, except those for | |
the stateless proxy, are transaction users. | |
Dialog: A dialog is a peer-to-peer SIP relationship between two | |
UAs that persists for some time. A dialog is established by | |
SIP messages, such as a 2xx response to an INVITE request. A | |
dialog is identified by a call identifier, local tag, and a | |
remote tag. A dialog was formerly known as a call leg in RFC | |
2543. | |
Downstream: A direction of message forwarding within a transaction | |
that refers to the direction that requests flow from the user | |
agent client to user agent server. | |
Final Response: A response that terminates a SIP transaction, as | |
opposed to a provisional response that does not. All 2xx, 3xx, | |
4xx, 5xx and 6xx responses are final. | |
Header: A header is a component of a SIP message that conveys | |
information about the message. It is structured as a sequence | |
of header fields. | |
Header Field: A header field is a component of the SIP message | |
header. A header field can appear as one or more header field | |
rows. Header field rows consist of a header field name and zero | |
or more header field values. Multiple header field values on a | |
Rosenberg, et. al. Standards Track [Page 21] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
given header field row are separated by commas. Some header | |
fields can only have a single header field value, and as a | |
result, always appear as a single header field row. | |
Header Field Value: A header field value is a single value; a | |
header field consists of zero or more header field values. | |
Home Domain: The domain providing service to a SIP user. | |
Typically, this is the domain present in the URI in the | |
address-of-record of a registration. | |
Informational Response: Same as a provisional response. | |
Initiator, Calling Party, Caller: The party initiating a session | |
(and dialog) with an INVITE request. A caller retains this | |
role from the time it sends the initial INVITE that established | |
a dialog until the termination of that dialog. | |
Invitation: An INVITE request. | |
Invitee, Invited User, Called Party, Callee: The party that | |
receives an INVITE request for the purpose of establishing a | |
new session. A callee retains this role from the time it | |
receives the INVITE until the termination of the dialog | |
established by that INVITE. | |
Location Service: A location service is used by a SIP redirect or | |
proxy server to obtain information about a callee's possible | |
location(s). It contains a list of bindings of address-of- | |
record keys to zero or more contact addresses. The bindings | |
can be created and removed in many ways; this specification | |
defines a REGISTER method that updates the bindings. | |
Loop: A request that arrives at a proxy, is forwarded, and later | |
arrives back at the same proxy. When it arrives the second | |
time, its Request-URI is identical to the first time, and other | |
header fields that affect proxy operation are unchanged, so | |
that the proxy would make the same processing decision on the | |
request it made the first time. Looped requests are errors, | |
and the procedures for detecting them and handling them are | |
described by the protocol. | |
Loose Routing: A proxy is said to be loose routing if it follows | |
the procedures defined in this specification for processing of | |
the Route header field. These procedures separate the | |
destination of the request (present in the Request-URI) from | |
Rosenberg, et. al. Standards Track [Page 22] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
the set of proxies that need to be visited along the way | |
(present in the Route header field). A proxy compliant to | |
these mechanisms is also known as a loose router. | |
Message: Data sent between SIP elements as part of the protocol. | |
SIP messages are either requests or responses. | |
Method: The method is the primary function that a request is meant | |
to invoke on a server. The method is carried in the request | |
message itself. Example methods are INVITE and BYE. | |
Outbound Proxy: A proxy that receives requests from a client, even | |
though it may not be the server resolved by the Request-URI. | |
Typically, a UA is manually configured with an outbound proxy, | |
or can learn about one through auto-configuration protocols. | |
Parallel Search: In a parallel search, a proxy issues several | |
requests to possible user locations upon receiving an incoming | |
request. Rather than issuing one request and then waiting for | |
the final response before issuing the next request as in a | |
sequential search, a parallel search issues requests without | |
waiting for the result of previous requests. | |
Provisional Response: A response used by the server to indicate | |
progress, but that does not terminate a SIP transaction. 1xx | |
responses are provisional, other responses are considered | |
final. | |
Proxy, Proxy Server: An intermediary entity that acts as both a | |
server and a client for the purpose of making requests on | |
behalf of other clients. A proxy server primarily plays the | |
role of routing, which means its job is to ensure that a | |
request is sent to another entity "closer" to the targeted | |
user. Proxies are also useful for enforcing policy (for | |
example, making sure a user is allowed to make a call). A | |
proxy interprets, and, if necessary, rewrites specific parts of | |
a request message before forwarding it. | |
Recursion: A client recurses on a 3xx response when it generates a | |
new request to one or more of the URIs in the Contact header | |
field in the response. | |
Redirect Server: A redirect server is a user agent server that | |
generates 3xx responses to requests it receives, directing the | |
client to contact an alternate set of URIs. | |
Rosenberg, et. al. Standards Track [Page 23] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Registrar: A registrar is a server that accepts REGISTER requests | |
and places the information it receives in those requests into | |
the location service for the domain it handles. | |
Regular Transaction: A regular transaction is any transaction with | |
a method other than INVITE, ACK, or CANCEL. | |
Request: A SIP message sent from a client to a server, for the | |
purpose of invoking a particular operation. | |
Response: A SIP message sent from a server to a client, for | |
indicating the status of a request sent from the client to the | |
server. | |
Ringback: Ringback is the signaling tone produced by the calling | |
party's application indicating that a called party is being | |
alerted (ringing). | |
Route Set: A route set is a collection of ordered SIP or SIPS URI | |
which represent a list of proxies that must be traversed when | |
sending a particular request. A route set can be learned, | |
through headers like Record-Route, or it can be configured. | |
Server: A server is a network element that receives requests in | |
order to service them and sends back responses to those | |
requests. Examples of servers are proxies, user agent servers, | |
redirect servers, and registrars. | |
Sequential Search: In a sequential search, a proxy server attempts | |
each contact address in sequence, proceeding to the next one | |
only after the previous has generated a final response. A 2xx | |
or 6xx class final response always terminates a sequential | |
search. | |
Session: From the SDP specification: "A multimedia session is a | |
set of multimedia senders and receivers and the data streams | |
flowing from senders to receivers. A multimedia conference is | |
an example of a multimedia session." (RFC 2327 [1]) (A session | |
as defined for SDP can comprise one or more RTP sessions.) As | |
defined, a callee can be invited several times, by different | |
calls, to the same session. If SDP is used, a session is | |
defined by the concatenation of the SDP user name, session id, | |
network type, address type, and address elements in the origin | |
field. | |
SIP Transaction: A SIP transaction occurs between a client and a | |
server and comprises all messages from the first request sent | |
from the client to the server up to a final (non-1xx) response | |
Rosenberg, et. al. Standards Track [Page 24] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
sent from the server to the client. If the request is INVITE | |
and the final response is a non-2xx, the transaction also | |
includes an ACK to the response. The ACK for a 2xx response to | |
an INVITE request is a separate transaction. | |
Spiral: A spiral is a SIP request that is routed to a proxy, | |
forwarded onwards, and arrives once again at that proxy, but | |
this time differs in a way that will result in a different | |
processing decision than the original request. Typically, this | |
means that the request's Request-URI differs from its previous | |
arrival. A spiral is not an error condition, unlike a loop. A | |
typical cause for this is call forwarding. A user calls | |
joe@example.com. The example.com proxy forwards it to Joe's | |
PC, which in turn, forwards it to bob@example.com. This | |
request is proxied back to the example.com proxy. However, | |
this is not a loop. Since the request is targeted at a | |
different user, it is considered a spiral, and is a valid | |
condition. | |
Stateful Proxy: A logical entity that maintains the client and | |
server transaction state machines defined by this specification | |
during the processing of a request, also known as a transaction | |
stateful proxy. The behavior of a stateful proxy is further | |
defined in Section 16. A (transaction) stateful proxy is not | |
the same as a call stateful proxy. | |
Stateless Proxy: A logical entity that does not maintain the | |
client or server transaction state machines defined in this | |
specification when it processes requests. A stateless proxy | |
forwards every request it receives downstream and every | |
response it receives upstream. | |
Strict Routing: A proxy is said to be strict routing if it follows | |
the Route processing rules of RFC 2543 and many prior work in | |
progress versions of this RFC. That rule caused proxies to | |
destroy the contents of the Request-URI when a Route header | |
field was present. Strict routing behavior is not used in this | |
specification, in favor of a loose routing behavior. Proxies | |
that perform strict routing are also known as strict routers. | |
Target Refresh Request: A target refresh request sent within a | |
dialog is defined as a request that can modify the remote | |
target of the dialog. | |
Transaction User (TU): The layer of protocol processing that | |
resides above the transaction layer. Transaction users include | |
the UAC core, UAS core, and proxy core. | |
Rosenberg, et. al. Standards Track [Page 25] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Upstream: A direction of message forwarding within a transaction | |
that refers to the direction that responses flow from the user | |
agent server back to the user agent client. | |
URL-encoded: A character string encoded according to RFC 2396, | |
Section 2.4 [5]. | |
User Agent Client (UAC): A user agent client is a logical entity | |
that creates a new request, and then uses the client | |
transaction state machinery to send it. The role of UAC lasts | |
only for the duration of that transaction. In other words, if | |
a piece of software initiates a request, it acts as a UAC for | |
the duration of that transaction. If it receives a request | |
later, it assumes the role of a user agent server for the | |
processing of that transaction. | |
UAC Core: The set of processing functions required of a UAC that | |
reside above the transaction and transport layers. | |
User Agent Server (UAS): A user agent server is a logical entity | |
that generates a response to a SIP request. The response | |
accepts, rejects, or redirects the request. This role lasts | |
only for the duration of that transaction. In other words, if | |
a piece of software responds to a request, it acts as a UAS for | |
the duration of that transaction. If it generates a request | |
later, it assumes the role of a user agent client for the | |
processing of that transaction. | |
UAS Core: The set of processing functions required at a UAS that | |
resides above the transaction and transport layers. | |
User Agent (UA): A logical entity that can act as both a user | |
agent client and user agent server. | |
The role of UAC and UAS, as well as proxy and redirect servers, are | |
defined on a transaction-by-transaction basis. For example, the user | |
agent initiating a call acts as a UAC when sending the initial INVITE | |
request and as a UAS when receiving a BYE request from the callee. | |
Similarly, the same software can act as a proxy server for one | |
request and as a redirect server for the next request. | |
Proxy, location, and registrar servers defined above are logical | |
entities; implementations MAY combine them into a single application. | |
7 SIP Messages | |
SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 | |
[7]). | |
Rosenberg, et. al. Standards Track [Page 26] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
A SIP message is either a request from a client to a server, or a | |
response from a server to a client. | |
Both Request (section 7.1) and Response (section 7.2) messages use | |
the basic format of RFC 2822 [3], even though the syntax differs in | |
character set and syntax specifics. (SIP allows header fields that | |
would not be valid RFC 2822 header fields, for example.) Both types | |
of messages consist of a start-line, one or more header fields, an | |
empty line indicating the end of the header fields, and an optional | |
message-body. | |
generic-message = start-line | |
*message-header | |
CRLF | |
[ message-body ] | |
start-line = Request-Line / Status-Line | |
The start-line, each message-header line, and the empty line MUST be | |
terminated by a carriage-return line-feed sequence (CRLF). Note that | |
the empty line MUST be present even if the message-body is not. | |
Except for the above difference in character sets, much of SIP's | |
message and header field syntax is identical to HTTP/1.1. Rather | |
than repeating the syntax and semantics here, we use [HX.Y] to refer | |
to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). | |
However, SIP is not an extension of HTTP. | |
7.1 Requests | |
SIP requests are distinguished by having a Request-Line for a start- | |
line. A Request-Line contains a method name, a Request-URI, and the | |
protocol version separated by a single space (SP) character. | |
The Request-Line ends with CRLF. No CR or LF are allowed except in | |
the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed | |
in any of the elements. | |
Request-Line = Method SP Request-URI SP SIP-Version CRLF | |
Method: This specification defines six methods: REGISTER for | |
registering contact information, INVITE, ACK, and CANCEL for | |
setting up sessions, BYE for terminating sessions, and | |
OPTIONS for querying servers about their capabilities. SIP | |
extensions, documented in standards track RFCs, may define | |
additional methods. | |
Rosenberg, et. al. Standards Track [Page 27] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Request-URI: The Request-URI is a SIP or SIPS URI as described in | |
Section 19.1 or a general URI (RFC 2396 [5]). It indicates | |
the user or service to which this request is being addressed. | |
The Request-URI MUST NOT contain unescaped spaces or control | |
characters and MUST NOT be enclosed in "<>". | |
SIP elements MAY support Request-URIs with schemes other than | |
"sip" and "sips", for example the "tel" URI scheme of RFC | |
2806 [9]. SIP elements MAY translate non-SIP URIs using any | |
mechanism at their disposal, resulting in SIP URI, SIPS URI, | |
or some other scheme. | |
SIP-Version: Both request and response messages include the | |
version of SIP in use, and follow [H3.1] (with HTTP replaced | |
by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version | |
ordering, compliance requirements, and upgrading of version | |
numbers. To be compliant with this specification, | |
applications sending SIP messages MUST include a SIP-Version | |
of "SIP/2.0". The SIP-Version string is case-insensitive, | |
but implementations MUST send upper-case. | |
Unlike HTTP/1.1, SIP treats the version number as a literal | |
string. In practice, this should make no difference. | |
7.2 Responses | |
SIP responses are distinguished from requests by having a Status-Line | |
as their start-line. A Status-Line consists of the protocol version | |
followed by a numeric Status-Code and its associated textual phrase, | |
with each element separated by a single SP character. | |
No CR or LF is allowed except in the final CRLF sequence. | |
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF | |
The Status-Code is a 3-digit integer result code that indicates the | |
outcome of an attempt to understand and satisfy a request. The | |
Reason-Phrase is intended to give a short textual description of the | |
Status-Code. The Status-Code is intended for use by automata, | |
whereas the Reason-Phrase is intended for the human user. A client | |
is not required to examine or display the Reason-Phrase. | |
While this specification suggests specific wording for the reason | |
phrase, implementations MAY choose other text, for example, in the | |
language indicated in the Accept-Language header field of the | |
request. | |
Rosenberg, et. al. Standards Track [Page 28] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The first digit of the Status-Code defines the class of response. | |
The last two digits do not have any categorization role. For this | |
reason, any response with a status code between 100 and 199 is | |
referred to as a "1xx response", any response with a status code | |
between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows | |
six values for the first digit: | |
1xx: Provisional -- request received, continuing to process the | |
request; | |
2xx: Success -- the action was successfully received, understood, | |
and accepted; | |
3xx: Redirection -- further action needs to be taken in order to | |
complete the request; | |
4xx: Client Error -- the request contains bad syntax or cannot be | |
fulfilled at this server; | |
5xx: Server Error -- the server failed to fulfill an apparently | |
valid request; | |
6xx: Global Failure -- the request cannot be fulfilled at any | |
server. | |
Section 21 defines these classes and describes the individual codes. | |
7.3 Header Fields | |
SIP header fields are similar to HTTP header fields in both syntax | |
and semantics. In particular, SIP header fields follow the [H4.2] | |
definitions of syntax for the message-header and the rules for | |
extending header fields over multiple lines. However, the latter is | |
specified in HTTP with implicit whitespace and folding. This | |
specification conforms to RFC 2234 [10] and uses only explicit | |
whitespace and folding as an integral part of the grammar. | |
[H4.2] also specifies that multiple header fields of the same field | |
name whose value is a comma-separated list can be combined into one | |
header field. That applies to SIP as well, but the specific rule is | |
different because of the different grammars. Specifically, any SIP | |
header whose grammar is of the form | |
header = "header-name" HCOLON header-value *(COMMA header-value) | |
allows for combining header fields of the same name into a comma- | |
separated list. The Contact header field allows a comma-separated | |
list unless the header field value is "*". | |
Rosenberg, et. al. Standards Track [Page 29] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
7.3.1 Header Field Format | |
Header fields follow the same generic header format as that given in | |
Section 2.2 of RFC 2822 [3]. Each header field consists of a field | |
name followed by a colon (":") and the field value. | |
field-name: field-value | |
The formal grammar for a message-header specified in Section 25 | |
allows for an arbitrary amount of whitespace on either side of the | |
colon; however, implementations should avoid spaces between the field | |
name and the colon and use a single space (SP) between the colon and | |
the field-value. | |
Subject: lunch | |
Subject : lunch | |
Subject :lunch | |
Subject: lunch | |
Thus, the above are all valid and equivalent, but the last is the | |
preferred form. | |
Header fields can be extended over multiple lines by preceding each | |
extra line with at least one SP or horizontal tab (HT). The line | |
break and the whitespace at the beginning of the next line are | |
treated as a single SP character. Thus, the following are | |
equivalent: | |
Subject: I know you're there, pick up the phone and talk to me! | |
Subject: I know you're there, | |
pick up the phone | |
and talk to me! | |
The relative order of header fields with different field names is not | |
significant. However, it is RECOMMENDED that header fields which are | |
needed for proxy processing (Via, Route, Record-Route, Proxy-Require, | |
Max-Forwards, and Proxy-Authorization, for example) appear towards | |
the top of the message to facilitate rapid parsing. The relative | |
order of header field rows with the same field name is important. | |
Multiple header field rows with the same field-name MAY be present in | |
a message if and only if the entire field-value for that header field | |
is defined as a comma-separated list (that is, if follows the grammar | |
defined in Section 7.3). It MUST be possible to combine the multiple | |
header field rows into one "field-name: field-value" pair, without | |
changing the semantics of the message, by appending each subsequent | |
field-value to the first, each separated by a comma. The exceptions | |
to this rule are the WWW-Authenticate, Authorization, Proxy- | |
Authenticate, and Proxy-Authorization header fields. Multiple header | |
Rosenberg, et. al. Standards Track [Page 30] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
field rows with these names MAY be present in a message, but since | |
their grammar does not follow the general form listed in Section 7.3, | |
they MUST NOT be combined into a single header field row. | |
Implementations MUST be able to process multiple header field rows | |
with the same name in any combination of the single-value-per-line or | |
comma-separated value forms. | |
The following groups of header field rows are valid and equivalent: | |
Route: <sip:alice@atlanta.com> | |
Subject: Lunch | |
Route: <sip:bob@biloxi.com> | |
Route: <sip:carol@chicago.com> | |
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com> | |
Route: <sip:carol@chicago.com> | |
Subject: Lunch | |
Subject: Lunch | |
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, | |
<sip:carol@chicago.com> | |
Each of the following blocks is valid but not equivalent to the | |
others: | |
Route: <sip:alice@atlanta.com> | |
Route: <sip:bob@biloxi.com> | |
Route: <sip:carol@chicago.com> | |
Route: <sip:bob@biloxi.com> | |
Route: <sip:alice@atlanta.com> | |
Route: <sip:carol@chicago.com> | |
Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, | |
<sip:bob@biloxi.com> | |
The format of a header field-value is defined per header-name. It | |
will always be either an opaque sequence of TEXT-UTF8 octets, or a | |
combination of whitespace, tokens, separators, and quoted strings. | |
Many existing header fields will adhere to the general form of a | |
value followed by a semi-colon separated sequence of parameter-name, | |
parameter-value pairs: | |
field-name: field-value *(;parameter-name=parameter-value) | |
Rosenberg, et. al. Standards Track [Page 31] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Even though an arbitrary number of parameter pairs may be attached to | |
a header field value, any given parameter-name MUST NOT appear more | |
than once. | |
When comparing header fields, field names are always case- | |
insensitive. Unless otherwise stated in the definition of a | |
particular header field, field values, parameter names, and parameter | |
values are case-insensitive. Tokens are always case-insensitive. | |
Unless specified otherwise, values expressed as quoted strings are | |
case-sensitive. For example, | |
Contact: <sip:alice@atlanta.com>;expires=3600 | |
is equivalent to | |
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600 | |
and | |
Content-Disposition: session;handling=optional | |
is equivalent to | |
content-disposition: Session;HANDLING=OPTIONAL | |
The following two header fields are not equivalent: | |
Warning: 370 devnull "Choose a bigger pipe" | |
Warning: 370 devnull "CHOOSE A BIGGER PIPE" | |
7.3.2 Header Field Classification | |
Some header fields only make sense in requests or responses. These | |
are called request header fields and response header fields, | |
respectively. If a header field appears in a message not matching | |
its category (such as a request header field in a response), it MUST | |
be ignored. Section 20 defines the classification of each header | |
field. | |
7.3.3 Compact Form | |
SIP provides a mechanism to represent common header field names in an | |
abbreviated form. This may be useful when messages would otherwise | |
become too large to be carried on the transport available to it | |
(exceeding the maximum transmission unit (MTU) when using UDP, for | |
example). These compact forms are defined in Section 20. A compact | |
form MAY be substituted for the longer form of a header field name at | |
any time without changing the semantics of the message. A header | |
Rosenberg, et. al. Standards Track [Page 32] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
field name MAY appear in both long and short forms within the same | |
message. Implementations MUST accept both the long and short forms | |
of each header name. | |
7.4 Bodies | |
Requests, including new requests defined in extensions to this | |
specification, MAY contain message bodies unless otherwise noted. | |
The interpretation of the body depends on the request method. | |
For response messages, the request method and the response status | |
code determine the type and interpretation of any message body. All | |
responses MAY include a body. | |
7.4.1 Message Body Type | |
The Internet media type of the message body MUST be given by the | |
Content-Type header field. If the body has undergone any encoding | |
such as compression, then this MUST be indicated by the Content- | |
Encoding header field; otherwise, Content-Encoding MUST be omitted. | |
If applicable, the character set of the message body is indicated as | |
part of the Content-Type header-field value. | |
The "multipart" MIME type defined in RFC 2046 [11] MAY be used within | |
the body of the message. Implementations that send requests | |
containing multipart message bodies MUST send a session description | |
as a non-multipart message body if the remote implementation requests | |
this through an Accept header field that does not contain multipart. | |
SIP messages MAY contain binary bodies or body parts. When no | |
explicit charset parameter is provided by the sender, media subtypes | |
of the "text" type are defined to have a default charset value of | |
"UTF-8". | |
7.4.2 Message Body Length | |
The body length in bytes is provided by the Content-Length header | |
field. Section 20.14 describes the necessary contents of this header | |
field in detail. | |
The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. | |
(Note: The chunked encoding modifies the body of a message in order | |
to transfer it as a series of chunks, each with its own size | |
indicator.) | |
Rosenberg, et. al. Standards Track [Page 33] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
7.5 Framing SIP Messages | |
Unlike HTTP, SIP implementations can use UDP or other unreliable | |
datagram protocols. Each such datagram carries one request or | |
response. See Section 18 on constraints on usage of unreliable | |
transports. | |
Implementations processing SIP messages over stream-oriented | |
transports MUST ignore any CRLF appearing before the start-line | |
[H4.1]. | |
The Content-Length header field value is used to locate the end of | |
each SIP message in a stream. It will always be present when SIP | |
messages are sent over stream-oriented transports. | |
8 General User Agent Behavior | |
A user agent represents an end system. It contains a user agent | |
client (UAC), which generates requests, and a user agent server | |
(UAS), which responds to them. A UAC is capable of generating a | |
request based on some external stimulus (the user clicking a button, | |
or a signal on a PSTN line) and processing a response. A UAS is | |
capable of receiving a request and generating a response based on | |
user input, external stimulus, the result of a program execution, or | |
some other mechanism. | |
When a UAC sends a request, the request passes through some number of | |
proxy servers, which forward the request towards the UAS. When the | |
UAS generates a response, the response is forwarded towards the UAC. | |
UAC and UAS procedures depend strongly on two factors. First, based | |
on whether the request or response is inside or outside of a dialog, | |
and second, based on the method of a request. Dialogs are discussed | |
thoroughly in Section 12; they represent a peer-to-peer relationship | |
between user agents and are established by specific SIP methods, such | |
as INVITE. | |
In this section, we discuss the method-independent rules for UAC and | |
UAS behavior when processing requests that are outside of a dialog. | |
This includes, of course, the requests which themselves establish a | |
dialog. | |
Security procedures for requests and responses outside of a dialog | |
are described in Section 26. Specifically, mechanisms exist for the | |
UAS and UAC to mutually authenticate. A limited set of privacy | |
features are also supported through encryption of bodies using | |
S/MIME. | |
Rosenberg, et. al. Standards Track [Page 34] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
8.1 UAC Behavior | |
This section covers UAC behavior outside of a dialog. | |
8.1.1 Generating the Request | |
A valid SIP request formulated by a UAC MUST, at a minimum, contain | |
the following header fields: To, From, CSeq, Call-ID, Max-Forwards, | |
and Via; all of these header fields are mandatory in all SIP | |
requests. These six header fields are the fundamental building | |
blocks of a SIP message, as they jointly provide for most of the | |
critical message routing services including the addressing of | |
messages, the routing of responses, limiting message propagation, | |
ordering of messages, and the unique identification of transactions. | |
These header fields are in addition to the mandatory request line, | |
which contains the method, Request-URI, and SIP version. | |
Examples of requests sent outside of a dialog include an INVITE to | |
establish a session (Section 13) and an OPTIONS to query for | |
capabilities (Section 11). | |
8.1.1.1 Request-URI | |
The initial Request-URI of the message SHOULD be set to the value of | |
the URI in the To field. One notable exception is the REGISTER | |
method; behavior for setting the Request-URI of REGISTER is given in | |
Section 10. It may also be undesirable for privacy reasons or | |
convenience to set these fields to the same value (especially if the | |
originating UA expects that the Request-URI will be changed during | |
transit). | |
In some special circumstances, the presence of a pre-existing route | |
set can affect the Request-URI of the message. A pre-existing route | |
set is an ordered set of URIs that identify a chain of servers, to | |
which a UAC will send outgoing requests that are outside of a dialog. | |
Commonly, they are configured on the UA by a user or service provider | |
manually, or through some other non-SIP mechanism. When a provider | |
wishes to configure a UA with an outbound proxy, it is RECOMMENDED | |
that this be done by providing it with a pre-existing route set with | |
a single URI, that of the outbound proxy. | |
When a pre-existing route set is present, the procedures for | |
populating the Request-URI and Route header field detailed in Section | |
12.2.1.1 MUST be followed (even though there is no dialog), using the | |
desired Request-URI as the remote target URI. | |
Rosenberg, et. al. Standards Track [Page 35] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
8.1.1.2 To | |
The To header field first and foremost specifies the desired | |
"logical" recipient of the request, or the address-of-record of the | |
user or resource that is the target of this request. This may or may | |
not be the ultimate recipient of the request. The To header field | |
MAY contain a SIP or SIPS URI, but it may also make use of other URI | |
schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. | |
All SIP implementations MUST support the SIP URI scheme. Any | |
implementation that supports TLS MUST support the SIPS URI scheme. | |
The To header field allows for a display name. | |
A UAC may learn how to populate the To header field for a particular | |
request in a number of ways. Usually the user will suggest the To | |
header field through a human interface, perhaps inputting the URI | |
manually or selecting it from some sort of address book. Frequently, | |
the user will not enter a complete URI, but rather a string of digits | |
or letters (for example, "bob"). It is at the discretion of the UA | |
to choose how to interpret this input. Using the string to form the | |
user part of a SIP URI implies that the UA wishes the name to be | |
resolved in the domain to the right-hand side (RHS) of the at-sign in | |
the SIP URI (for instance, sip:bob@example.com). Using the string to | |
form the user part of a SIPS URI implies that the UA wishes to | |
communicate securely, and that the name is to be resolved in the | |
domain to the RHS of the at-sign. The RHS will frequently be the | |
home domain of the requestor, which allows for the home domain to | |
process the outgoing request. This is useful for features like | |
"speed dial" that require interpretation of the user part in the home | |
domain. The tel URL may be used when the UA does not wish to specify | |
the domain that should interpret a telephone number that has been | |
input by the user. Rather, each domain through which the request | |
passes would be given that opportunity. As an example, a user in an | |
airport might log in and send requests through an outbound proxy in | |
the airport. If they enter "411" (this is the phone number for local | |
directory assistance in the United States), that needs to be | |
interpreted and processed by the outbound proxy in the airport, not | |
the user's home domain. In this case, tel:411 would be the right | |
choice. | |
A request outside of a dialog MUST NOT contain a To tag; the tag in | |
the To field of a request identifies the peer of the dialog. Since | |
no dialog is established, no tag is present. | |
For further information on the To header field, see Section 20.39. | |
The following is an example of a valid To header field: | |
To: Carol <sip:carol@chicago.com> | |
Rosenberg, et. al. Standards Track [Page 36] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
8.1.1.3 From | |
The From header field indicates the logical identity of the initiator | |
of the request, possibly the user's address-of-record. Like the To | |
header field, it contains a URI and optionally a display name. It is | |
used by SIP elements to determine which processing rules to apply to | |
a request (for example, automatic call rejection). As such, it is | |
very important that the From URI not contain IP addresses or the FQDN | |
of the host on which the UA is running, since these are not logical | |
names. | |
The From header field allows for a display name. A UAC SHOULD use | |
the display name "Anonymous", along with a syntactically correct, but | |
otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the | |
identity of the client is to remain hidden. | |
Usually, the value that populates the From header field in requests | |
generated by a particular UA is pre-provisioned by the user or by the | |
administrators of the user's local domain. If a particular UA is | |
used by multiple users, it might have switchable profiles that | |
include a URI corresponding to the identity of the profiled user. | |
Recipients of requests can authenticate the originator of a request | |
in order to ascertain that they are who their From header field | |
claims they are (see Section 22 for more on authentication). | |
The From field MUST contain a new "tag" parameter, chosen by the UAC. | |
See Section 19.3 for details on choosing a tag. | |
For further information on the From header field, see Section 20.20. | |
Examples: | |
From: "Bob" <sips:bob@biloxi.com> ;tag=a48s | |
From: sip:+12125551212@phone2net.com;tag=887s | |
From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 | |
8.1.1.4 Call-ID | |
The Call-ID header field acts as a unique identifier to group | |
together a series of messages. It MUST be the same for all requests | |
and responses sent by either UA in a dialog. It SHOULD be the same | |
in each registration from a UA. | |
In a new request created by a UAC outside of any dialog, the Call-ID | |
header field MUST be selected by the UAC as a globally unique | |
identifier over space and time unless overridden by method-specific | |
behavior. All SIP UAs must have a means to guarantee that the Call- | |
ID header fields they produce will not be inadvertently generated by | |
any other UA. Note that when requests are retried after certain | |
Rosenberg, et. al. Standards Track [Page 37] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
failure responses that solicit an amendment to a request (for | |
example, a challenge for authentication), these retried requests are | |
not considered new requests, and therefore do not need new Call-ID | |
header fields; see Section 8.1.3.5. | |
Use of cryptographically random identifiers (RFC 1750 [12]) in the | |
generation of Call-IDs is RECOMMENDED. Implementations MAY use the | |
form "localid@host". Call-IDs are case-sensitive and are simply | |
compared byte-by-byte. | |
Using cryptographically random identifiers provides some | |
protection against session hijacking and reduces the likelihood of | |
unintentional Call-ID collisions. | |
No provisioning or human interface is required for the selection of | |
the Call-ID header field value for a request. | |
For further information on the Call-ID header field, see Section | |
20.8. | |
Example: | |
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com | |
8.1.1.5 CSeq | |
The CSeq header field serves as a way to identify and order | |
transactions. It consists of a sequence number and a method. The | |
method MUST match that of the request. For non-REGISTER requests | |
outside of a dialog, the sequence number value is arbitrary. The | |
sequence number value MUST be expressible as a 32-bit unsigned | |
integer and MUST be less than 2**31. As long as it follows the above | |
guidelines, a client may use any mechanism it would like to select | |
CSeq header field values. | |
Section 12.2.1.1 discusses construction of the CSeq for requests | |
within a dialog. | |
Example: | |
CSeq: 4711 INVITE | |
Rosenberg, et. al. Standards Track [Page 38] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
8.1.1.6 Max-Forwards | |
The Max-Forwards header field serves to limit the number of hops a | |
request can transit on the way to its destination. It consists of an | |
integer that is decremented by one at each hop. If the Max-Forwards | |
value reaches 0 before the request reaches its destination, it will | |
be rejected with a 483(Too Many Hops) error response. | |
A UAC MUST insert a Max-Forwards header field into each request it | |
originates with a value that SHOULD be 70. This number was chosen to | |
be sufficiently large to guarantee that a request would not be | |
dropped in any SIP network when there were no loops, but not so large | |
as to consume proxy resources when a loop does occur. Lower values | |
should be used with caution and only in networks where topologies are | |
known by the UA. | |
8.1.1.7 Via | |
The Via header field indicates the transport used for the transaction | |
and identifies the location where the response is to be sent. A Via | |
header field value is added only after the transport that will be | |
used to reach the next hop has been selected (which may involve the | |
usage of the procedures in [4]). | |
When the UAC creates a request, it MUST insert a Via into that | |
request. The protocol name and protocol version in the header field | |
MUST be SIP and 2.0, respectively. The Via header field value MUST | |
contain a branch parameter. This parameter is used to identify the | |
transaction created by that request. This parameter is used by both | |
the client and the server. | |
The branch parameter value MUST be unique across space and time for | |
all requests sent by the UA. The exceptions to this rule are CANCEL | |
and ACK for non-2xx responses. As discussed below, a CANCEL request | |
will have the same value of the branch parameter as the request it | |
cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx | |
response will also have the same branch ID as the INVITE whose | |
response it acknowledges. | |
The uniqueness property of the branch ID parameter, to facilitate | |
its use as a transaction ID, was not part of RFC 2543. | |
The branch ID inserted by an element compliant with this | |
specification MUST always begin with the characters "z9hG4bK". These | |
7 characters are used as a magic cookie (7 is deemed sufficient to | |
ensure that an older RFC 2543 implementation would not pick such a | |
value), so that servers receiving the request can determine that the | |
branch ID was constructed in the fashion described by this | |
Rosenberg, et. al. Standards Track [Page 39] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
specification (that is, globally unique). Beyond this requirement, | |
the precise format of the branch token is implementation-defined. | |
The Via header maddr, ttl, and sent-by components will be set when | |
the request is processed by the transport layer (Section 18). | |
Via processing for proxies is described in Section 16.6 Item 8 and | |
Section 16.7 Item 3. | |
8.1.1.8 Contact | |
The Contact header field provides a SIP or SIPS URI that can be used | |
to contact that specific instance of the UA for subsequent requests. | |
The Contact header field MUST be present and contain exactly one SIP | |
or SIPS URI in any request that can result in the establishment of a | |
dialog. For the methods defined in this specification, that includes | |
only the INVITE request. For these requests, the scope of the | |
Contact is global. That is, the Contact header field value contains | |
the URI at which the UA would like to receive requests, and this URI | |
MUST be valid even if used in subsequent requests outside of any | |
dialogs. | |
If the Request-URI or top Route header field value contains a SIPS | |
URI, the Contact header field MUST contain a SIPS URI as well. | |
For further information on the Contact header field, see Section | |
20.10. | |
8.1.1.9 Supported and Require | |
If the UAC supports extensions to SIP that can be applied by the | |
server to the response, the UAC SHOULD include a Supported header | |
field in the request listing the option tags (Section 19.2) for those | |
extensions. | |
The option tags listed MUST only refer to extensions defined in | |
standards-track RFCs. This is to prevent servers from insisting that | |
clients implement non-standard, vendor-defined features in order to | |
receive service. Extensions defined by experimental and | |
informational RFCs are explicitly excluded from usage with the | |
Supported header field in a request, since they too are often used to | |
document vendor-defined extensions. | |
If the UAC wishes to insist that a UAS understand an extension that | |
the UAC will apply to the request in order to process the request, it | |
MUST insert a Require header field into the request listing the | |
option tag for that extension. If the UAC wishes to apply an | |
extension to the request and insist that any proxies that are | |
Rosenberg, et. al. Standards Track [Page 40] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
traversed understand that extension, it MUST insert a Proxy-Require | |
header field into the request listing the option tag for that | |
extension. | |
As with the Supported header field, the option tags in the Require | |
and Proxy-Require header fields MUST only refer to extensions defined | |
in standards-track RFCs. | |
8.1.1.10 Additional Message Components | |
After a new request has been created, and the header fields described | |
above have been properly constructed, any additional optional header | |
fields are added, as are any header fields specific to the method. | |
SIP requests MAY contain a MIME-encoded message-body. Regardless of | |
the type of body that a request contains, certain header fields must | |
be formulated to characterize the contents of the body. For further | |
information on these header fields, see Sections 20.11 through 20.15. | |
8.1.2 Sending the Request | |
The destination for the request is then computed. Unless there is | |
local policy specifying otherwise, the destination MUST be determined | |
by applying the DNS procedures described in [4] as follows. If the | |
first element in the route set indicated a strict router (resulting | |
in forming the request as described in Section 12.2.1.1), the | |
procedures MUST be applied to the Request-URI of the request. | |
Otherwise, the procedures are applied to the first Route header field | |
value in the request (if one exists), or to the request's Request-URI | |
if there is no Route header field present. These procedures yield an | |
ordered set of address, port, and transports to attempt. Independent | |
of which URI is used as input to the procedures of [4], if the | |
Request-URI specifies a SIPS resource, the UAC MUST follow the | |
procedures of [4] as if the input URI were a SIPS URI. | |
Local policy MAY specify an alternate set of destinations to attempt. | |
If the Request-URI contains a SIPS URI, any alternate destinations | |
MUST be contacted with TLS. Beyond that, there are no restrictions | |
on the alternate destinations if the request contains no Route header | |
field. This provides a simple alternative to a pre-existing route | |
set as a way to specify an outbound proxy. However, that approach | |
for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing | |
route set with a single URI SHOULD be used instead. If the request | |
contains a Route header field, the request SHOULD be sent to the | |
locations derived from its topmost value, but MAY be sent to any | |
server that the UA is certain will honor the Route and Request-URI | |
policies specified in this document (as opposed to those in RFC | |
2543). In particular, a UAC configured with an outbound proxy SHOULD | |
Rosenberg, et. al. Standards Track [Page 41] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
attempt to send the request to the location indicated in the first | |
Route header field value instead of adopting the policy of sending | |
all messages to the outbound proxy. | |
This ensures that outbound proxies that do not add Record-Route | |
header field values will drop out of the path of subsequent | |
requests. It allows endpoints that cannot resolve the first Route | |
URI to delegate that task to an outbound proxy. | |
The UAC SHOULD follow the procedures defined in [4] for stateful | |
elements, trying each address until a server is contacted. Each try | |
constitutes a new transaction, and therefore each carries a different | |
topmost Via header field value with a new branch parameter. | |
Furthermore, the transport value in the Via header field is set to | |
whatever transport was determined for the target server. | |
8.1.3 Processing Responses | |
Responses are first processed by the transport layer and then passed | |
up to the transaction layer. The transaction layer performs its | |
processing and then passes the response up to the TU. The majority | |
of response processing in the TU is method specific. However, there | |
are some general behaviors independent of the method. | |
8.1.3.1 Transaction Layer Errors | |
In some cases, the response returned by the transaction layer will | |
not be a SIP message, but rather a transaction layer error. When a | |
timeout error is received from the transaction layer, it MUST be | |
treated as if a 408 (Request Timeout) status code has been received. | |
If a fatal transport error is reported by the transport layer | |
(generally, due to fatal ICMP errors in UDP or connection failures in | |
TCP), the condition MUST be treated as a 503 (Service Unavailable) | |
status code. | |
8.1.3.2 Unrecognized Responses | |
A UAC MUST treat any final response it does not recognize as being | |
equivalent to the x00 response code of that class, and MUST be able | |
to process the x00 response code for all classes. For example, if a | |
UAC receives an unrecognized response code of 431, it can safely | |
assume that there was something wrong with its request and treat the | |
response as if it had received a 400 (Bad Request) response code. A | |
UAC MUST treat any provisional response different than 100 that it | |
does not recognize as 183 (Session Progress). A UAC MUST be able to | |
process 100 and 183 responses. | |
Rosenberg, et. al. Standards Track [Page 42] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
8.1.3.3 Vias | |
If more than one Via header field value is present in a response, the | |
UAC SHOULD discard the message. | |
The presence of additional Via header field values that precede | |
the originator of the request suggests that the message was | |
misrouted or possibly corrupted. | |
8.1.3.4 Processing 3xx Responses | |
Upon receipt of a redirection response (for example, a 301 response | |
status code), clients SHOULD use the URI(s) in the Contact header | |
field to formulate one or more new requests based on the redirected | |
request. This process is similar to that of a proxy recursing on a | |
3xx class response as detailed in Sections 16.5 and 16.6. A client | |
starts with an initial target set containing exactly one URI, the | |
Request-URI of the original request. If a client wishes to formulate | |
new requests based on a 3xx class response to that request, it places | |
the URIs to try into the target set. Subject to the restrictions in | |
this specification, a client can choose which Contact URIs it places | |
into the target set. As with proxy recursion, a client processing | |
3xx class responses MUST NOT add any given URI to the target set more | |
than once. If the original request had a SIPS URI in the Request- | |
URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD | |
inform the user of the redirection to an insecure URI. | |
Any new request may receive 3xx responses themselves containing | |
the original URI as a contact. Two locations can be configured to | |
redirect to each other. Placing any given URI in the target set | |
only once prevents infinite redirection loops. | |
As the target set grows, the client MAY generate new requests to the | |
URIs in any order. A common mechanism is to order the set by the "q" | |
parameter value from the Contact header field value. Requests to the | |
URIs MAY be generated serially or in parallel. One approach is to | |
process groups of decreasing q-values serially and process the URIs | |
in each q-value group in parallel. Another is to perform only serial | |
processing in decreasing q-value order, arbitrarily choosing between | |
contacts of equal q-value. | |
If contacting an address in the list results in a failure, as defined | |
in the next paragraph, the element moves to the next address in the | |
list, until the list is exhausted. If the list is exhausted, then | |
the request has failed. | |
Rosenberg, et. al. Standards Track [Page 43] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Failures SHOULD be detected through failure response codes (codes | |
greater than 399); for network errors the client transaction will | |
report any transport layer failures to the transaction user. Note | |
that some response codes (detailed in 8.1.3.5) indicate that the | |
request can be retried; requests that are reattempted should not be | |
considered failures. | |
When a failure for a particular contact address is received, the | |
client SHOULD try the next contact address. This will involve | |
creating a new client transaction to deliver a new request. | |
In order to create a request based on a contact address in a 3xx | |
response, a UAC MUST copy the entire URI from the target set into the | |
Request-URI, except for the "method-param" and "header" URI | |
parameters (see Section 19.1.1 for a definition of these parameters). | |
It uses the "header" parameters to create header field values for the | |
new request, overwriting header field values associated with the | |
redirected request in accordance with the guidelines in Section | |
19.1.5. | |
Note that in some instances, header fields that have been | |
communicated in the contact address may instead append to existing | |
request header fields in the original redirected request. As a | |
general rule, if the header field can accept a comma-separated list | |
of values, then the new header field value MAY be appended to any | |
existing values in the original redirected request. If the header | |
field does not accept multiple values, the value in the original | |
redirected request MAY be overwritten by the header field value | |
communicated in the contact address. For example, if a contact | |
address is returned with the following value: | |
sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> | |
Then any Subject header field in the original redirected request is | |
overwritten, but the HTTP URL is merely appended to any existing | |
Call-Info header field values. | |
It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID | |
used in the original redirected request, but the UAC MAY also choose | |
to update the Call-ID header field value for new requests, for | |
example. | |
Finally, once the new request has been constructed, it is sent using | |
a new client transaction, and therefore MUST have a new branch ID in | |
the top Via field as discussed in Section 8.1.1.7. | |
Rosenberg, et. al. Standards Track [Page 44] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
In all other respects, requests sent upon receipt of a redirect | |
response SHOULD re-use the header fields and bodies of the original | |
request. | |
In some instances, Contact header field values may be cached at UAC | |
temporarily or permanently depending on the status code received and | |
the presence of an expiration interval; see Sections 21.3.2 and | |
21.3.3. | |
8.1.3.5 Processing 4xx Responses | |
Certain 4xx response codes require specific UA processing, | |
independent of the method. | |
If a 401 (Unauthorized) or 407 (Proxy Authentication Required) | |
response is received, the UAC SHOULD follow the authorization | |
procedures of Section 22.2 and Section 22.3 to retry the request with | |
credentials. | |
If a 413 (Request Entity Too Large) response is received (Section | |
21.4.11), the request contained a body that was longer than the UAS | |
was willing to accept. If possible, the UAC SHOULD retry the | |
request, either omitting the body or using one of a smaller length. | |
If a 415 (Unsupported Media Type) response is received (Section | |
21.4.13), the request contained media types not supported by the UAS. | |
The UAC SHOULD retry sending the request, this time only using | |
content with types listed in the Accept header field in the response, | |
with encodings listed in the Accept-Encoding header field in the | |
response, and with languages listed in the Accept-Language in the | |
response. | |
If a 416 (Unsupported URI Scheme) response is received (Section | |
21.4.14), the Request-URI used a URI scheme not supported by the | |
server. The client SHOULD retry the request, this time, using a SIP | |
URI. | |
If a 420 (Bad Extension) response is received (Section 21.4.15), the | |
request contained a Require or Proxy-Require header field listing an | |
option-tag for a feature not supported by a proxy or UAS. The UAC | |
SHOULD retry the request, this time omitting any extensions listed in | |
the Unsupported header field in the response. | |
In all of the above cases, the request is retried by creating a new | |
request with the appropriate modifications. This new request | |
constitutes a new transaction and SHOULD have the same value of the | |
Call-ID, To, and From of the previous request, but the CSeq should | |
contain a new sequence number that is one higher than the previous. | |
Rosenberg, et. al. Standards Track [Page 45] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
With other 4xx responses, including those yet to be defined, a retry | |
may or may not be possible depending on the method and the use case. | |
8.2 UAS Behavior | |
When a request outside of a dialog is processed by a UAS, there is a | |
set of processing rules that are followed, independent of the method. | |
Section 12 gives guidance on how a UAS can tell whether a request is | |
inside or outside of a dialog. | |
Note that request processing is atomic. If a request is accepted, | |
all state changes associated with it MUST be performed. If it is | |
rejected, all state changes MUST NOT be performed. | |
UASs SHOULD process the requests in the order of the steps that | |
follow in this section (that is, starting with authentication, then | |
inspecting the method, the header fields, and so on throughout the | |
remainder of this section). | |
8.2.1 Method Inspection | |
Once a request is authenticated (or authentication is skipped), the | |
UAS MUST inspect the method of the request. If the UAS recognizes | |
but does not support the method of a request, it MUST generate a 405 | |
(Method Not Allowed) response. Procedures for generating responses | |
are described in Section 8.2.6. The UAS MUST also add an Allow | |
header field to the 405 (Method Not Allowed) response. The Allow | |
header field MUST list the set of methods supported by the UAS | |
generating the message. The Allow header field is presented in | |
Section 20.5. | |
If the method is one supported by the server, processing continues. | |
8.2.2 Header Inspection | |
If a UAS does not understand a header field in a request (that is, | |
the header field is not defined in this specification or in any | |
supported extension), the server MUST ignore that header field and | |
continue processing the message. A UAS SHOULD ignore any malformed | |
header fields that are not necessary for processing requests. | |
8.2.2.1 To and Request-URI | |
The To header field identifies the original recipient of the request | |
designated by the user identified in the From field. The original | |
recipient may or may not be the UAS processing the request, due to | |
call forwarding or other proxy operations. A UAS MAY apply any | |
policy it wishes to determine whether to accept requests when the To | |
Rosenberg, et. al. Standards Track [Page 46] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
header field is not the identity of the UAS. However, it is | |
RECOMMENDED that a UAS accept requests even if they do not recognize | |
the URI scheme (for example, a tel: URI) in the To header field, or | |
if the To header field does not address a known or current user of | |
this UAS. If, on the other hand, the UAS decides to reject the | |
request, it SHOULD generate a response with a 403 (Forbidden) status | |
code and pass it to the server transaction for transmission. | |
However, the Request-URI identifies the UAS that is to process the | |
request. If the Request-URI uses a scheme not supported by the UAS, | |
it SHOULD reject the request with a 416 (Unsupported URI Scheme) | |
response. If the Request-URI does not identify an address that the | |
UAS is willing to accept requests for, it SHOULD reject the request | |
with a 404 (Not Found) response. Typically, a UA that uses the | |
REGISTER method to bind its address-of-record to a specific contact | |
address will see requests whose Request-URI equals that contact | |
address. Other potential sources of received Request-URIs include | |
the Contact header fields of requests and responses sent by the UA | |
that establish or refresh dialogs. | |
8.2.2.2 Merged Requests | |
If the request has no tag in the To header field, the UAS core MUST | |
check the request against ongoing transactions. If the From tag, | |
Call-ID, and CSeq exactly match those associated with an ongoing | |
transaction, but the request does not match that transaction (based | |
on the matching rules in Section 17.2.3), the UAS core SHOULD | |
generate a 482 (Loop Detected) response and pass it to the server | |
transaction. | |
The same request has arrived at the UAS more than once, following | |
different paths, most likely due to forking. The UAS processes | |
the first such request received and responds with a 482 (Loop | |
Detected) to the rest of them. | |
8.2.2.3 Require | |
Assuming the UAS decides that it is the proper element to process the | |
request, it examines the Require header field, if present. | |
The Require header field is used by a UAC to tell a UAS about SIP | |
extensions that the UAC expects the UAS to support in order to | |
process the request properly. Its format is described in Section | |
20.32. If a UAS does not understand an option-tag listed in a | |
Require header field, it MUST respond by generating a response with | |
status code 420 (Bad Extension). The UAS MUST add an Unsupported | |
header field, and list in it those options it does not understand | |
amongst those in the Require header field of the request. | |
Rosenberg, et. al. Standards Track [Page 47] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL | |
request, or in an ACK request sent for a non-2xx response. These | |
header fields MUST be ignored if they are present in these requests. | |
An ACK request for a 2xx response MUST contain only those Require and | |
Proxy-Require values that were present in the initial request. | |
Example: | |
UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 | |
Require: 100rel | |
UAS->UAC: SIP/2.0 420 Bad Extension | |
Unsupported: 100rel | |
This behavior ensures that the client-server interaction will | |
proceed without delay when all options are understood by both | |
sides, and only slow down if options are not understood (as in the | |
example above). For a well-matched client-server pair, the | |
interaction proceeds quickly, saving a round-trip often required | |
by negotiation mechanisms. In addition, it also removes ambiguity | |
when the client requires features that the server does not | |
understand. Some features, such as call handling fields, are only | |
of interest to end systems. | |
8.2.3 Content Processing | |
Assuming the UAS understands any extensions required by the client, | |
the UAS examines the body of the message, and the header fields that | |
describe it. If there are any bodies whose type (indicated by the | |
Content-Type), language (indicated by the Content-Language) or | |
encoding (indicated by the Content-Encoding) are not understood, and | |
that body part is not optional (as indicated by the Content- | |
Disposition header field), the UAS MUST reject the request with a 415 | |
(Unsupported Media Type) response. The response MUST contain an | |
Accept header field listing the types of all bodies it understands, | |
in the event the request contained bodies of types not supported by | |
the UAS. If the request contained content encodings not understood | |
by the UAS, the response MUST contain an Accept-Encoding header field | |
listing the encodings understood by the UAS. If the request | |
contained content with languages not understood by the UAS, the | |
response MUST contain an Accept-Language header field indicating the | |
languages understood by the UAS. Beyond these checks, body handling | |
depends on the method and type. For further information on the | |
processing of content-specific header fields, see Section 7.4 as well | |
as Section 20.11 through 20.15. | |
Rosenberg, et. al. Standards Track [Page 48] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
8.2.4 Applying Extensions | |
A UAS that wishes to apply some extension when generating the | |
response MUST NOT do so unless support for that extension is | |
indicated in the Supported header field in the request. If the | |
desired extension is not supported, the server SHOULD rely only on | |
baseline SIP and any other extensions supported by the client. In | |
rare circumstances, where the server cannot process the request | |
without the extension, the server MAY send a 421 (Extension Required) | |
response. This response indicates that the proper response cannot be | |
generated without support of a specific extension. The needed | |
extension(s) MUST be included in a Require header field in the | |
response. This behavior is NOT RECOMMENDED, as it will generally | |
break interoperability. | |
Any extensions applied to a non-421 response MUST be listed in a | |
Require header field included in the response. Of course, the server | |
MUST NOT apply extensions not listed in the Supported header field in | |
the request. As a result of this, the Require header field in a | |
response will only ever contain option tags defined in standards- | |
track RFCs. | |
8.2.5 Processing the Request | |
Assuming all of the checks in the previous subsections are passed, | |
the UAS processing becomes method-specific. Section 10 covers the | |
REGISTER request, Section 11 covers the OPTIONS request, Section 13 | |
covers the INVITE request, and Section 15 covers the BYE request. | |
8.2.6 Generating the Response | |
When a UAS wishes to construct a response to a request, it follows | |
the general procedures detailed in the following subsections. | |
Additional behaviors specific to the response code in question, which | |
are not detailed in this section, may also be required. | |
Once all procedures associated with the creation of a response have | |
been completed, the UAS hands the response back to the server | |
transaction from which it received the request. | |
8.2.6.1 Sending a Provisional Response | |
One largely non-method-specific guideline for the generation of | |
responses is that UASs SHOULD NOT issue a provisional response for a | |
non-INVITE request. Rather, UASs SHOULD generate a final response to | |
a non-INVITE request as soon as possible. | |
Rosenberg, et. al. Standards Track [Page 49] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
When a 100 (Trying) response is generated, any Timestamp header field | |
present in the request MUST be copied into this 100 (Trying) | |
response. If there is a delay in generating the response, the UAS | |
SHOULD add a delay value into the Timestamp value in the response. | |
This value MUST contain the difference between the time of sending of | |
the response and receipt of the request, measured in seconds. | |
8.2.6.2 Headers and Tags | |
The From field of the response MUST equal the From header field of | |
the request. The Call-ID header field of the response MUST equal the | |
Call-ID header field of the request. The CSeq header field of the | |
response MUST equal the CSeq field of the request. The Via header | |
field values in the response MUST equal the Via header field values | |
in the request and MUST maintain the same ordering. | |
If a request contained a To tag in the request, the To header field | |
in the response MUST equal that of the request. However, if the To | |
header field in the request did not contain a tag, the URI in the To | |
header field in the response MUST equal the URI in the To header | |
field; additionally, the UAS MUST add a tag to the To header field in | |
the response (with the exception of the 100 (Trying) response, in | |
which a tag MAY be present). This serves to identify the UAS that is | |
responding, possibly resulting in a component of a dialog ID. The | |
same tag MUST be used for all responses to that request, both final | |
and provisional (again excepting the 100 (Trying)). Procedures for | |
the generation of tags are defined in Section 19.3. | |
8.2.7 Stateless UAS Behavior | |
A stateless UAS is a UAS that does not maintain transaction state. | |
It replies to requests normally, but discards any state that would | |
ordinarily be retained by a UAS after a response has been sent. If a | |
stateless UAS receives a retransmission of a request, it regenerates | |
the response and resends it, just as if it were replying to the first | |
instance of the request. A UAS cannot be stateless unless the request | |
processing for that method would always result in the same response | |
if the requests are identical. This rules out stateless registrars, | |
for example. Stateless UASs do not use a transaction layer; they | |
receive requests directly from the transport layer and send responses | |
directly to the transport layer. | |
The stateless UAS role is needed primarily to handle unauthenticated | |
requests for which a challenge response is issued. If | |
unauthenticated requests were handled statefully, then malicious | |
floods of unauthenticated requests could create massive amounts of | |
Rosenberg, et. al. Standards Track [Page 50] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
transaction state that might slow or completely halt call processing | |
in a UAS, effectively creating a denial of service condition; for | |
more information see Section 26.1.5. | |
The most important behaviors of a stateless UAS are the following: | |
o A stateless UAS MUST NOT send provisional (1xx) responses. | |
o A stateless UAS MUST NOT retransmit responses. | |
o A stateless UAS MUST ignore ACK requests. | |
o A stateless UAS MUST ignore CANCEL requests. | |
o To header tags MUST be generated for responses in a stateless | |
manner - in a manner that will generate the same tag for the | |
same request consistently. For information on tag construction | |
see Section 19.3. | |
In all other respects, a stateless UAS behaves in the same manner as | |
a stateful UAS. A UAS can operate in either a stateful or stateless | |
mode for each new request. | |
8.3 Redirect Servers | |
In some architectures it may be desirable to reduce the processing | |
load on proxy servers that are responsible for routing requests, and | |
improve signaling path robustness, by relying on redirection. | |
Redirection allows servers to push routing information for a request | |
back in a response to the client, thereby taking themselves out of | |
the loop of further messaging for this transaction while still aiding | |
in locating the target of the request. When the originator of the | |
request receives the redirection, it will send a new request based on | |
the URI(s) it has received. By propagating URIs from the core of the | |
network to its edges, redirection allows for considerable network | |
scalability. | |
A redirect server is logically constituted of a server transaction | |
layer and a transaction user that has access to a location service of | |
some kind (see Section 10 for more on registrars and location | |
services). This location service is effectively a database | |
containing mappings between a single URI and a set of one or more | |
alternative locations at which the target of that URI can be found. | |
A redirect server does not issue any SIP requests of its own. After | |
receiving a request other than CANCEL, the server either refuses the | |
request or gathers the list of alternative locations from the | |
Rosenberg, et. al. Standards Track [Page 51] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
location service and returns a final response of class 3xx. For | |
well-formed CANCEL requests, it SHOULD return a 2xx response. This | |
response ends the SIP transaction. The redirect server maintains | |
transaction state for an entire SIP transaction. It is the | |
responsibility of clients to detect forwarding loops between redirect | |
servers. | |
When a redirect server returns a 3xx response to a request, it | |
populates the list of (one or more) alternative locations into the | |
Contact header field. An "expires" parameter to the Contact header | |
field values may also be supplied to indicate the lifetime of the | |
Contact data. | |
The Contact header field contains URIs giving the new locations or | |
user names to try, or may simply specify additional transport | |
parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) | |
response may also give the same location and username that was | |
targeted by the initial request but specify additional transport | |
parameters such as a different server or multicast address to try, or | |
a change of SIP transport from UDP to TCP or vice versa. | |
However, redirect servers MUST NOT redirect a request to a URI equal | |
to the one in the Request-URI; instead, provided that the URI does | |
not point to itself, the server MAY proxy the request to the | |
destination URI, or MAY reject it with a 404. | |
If a client is using an outbound proxy, and that proxy actually | |
redirects requests, a potential arises for infinite redirection | |
loops. | |
Note that a Contact header field value MAY also refer to a different | |
resource than the one originally called. For example, a SIP call | |
connected to PSTN gateway may need to deliver a special informational | |
announcement such as "The number you have dialed has been changed." | |
A Contact response header field can contain any suitable URI | |
indicating where the called party can be reached, not limited to SIP | |
URIs. For example, it could contain URIs for phones, fax, or irc (if | |
they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 | |
discusses implications and limitations of redirecting a SIPS URI to a | |
non-SIPS URI. | |
The "expires" parameter of a Contact header field value indicates how | |
long the URI is valid. The value of the parameter is a number | |
indicating seconds. If this parameter is not provided, the value of | |
the Expires header field determines how long the URI is valid. | |
Malformed values SHOULD be treated as equivalent to 3600. | |
Rosenberg, et. al. Standards Track [Page 52] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
This provides a modest level of backwards compatibility with RFC | |
2543, which allowed absolute times in this header field. If an | |
absolute time is received, it will be treated as malformed, and | |
then default to 3600. | |
Redirect servers MUST ignore features that are not understood | |
(including unrecognized header fields, any unknown option tags in | |
Require, or even method names) and proceed with the redirection of | |
the request in question. | |
9 Canceling a Request | |
The previous section has discussed general UA behavior for generating | |
requests and processing responses for requests of all methods. In | |
this section, we discuss a general purpose method, called CANCEL. | |
The CANCEL request, as the name implies, is used to cancel a previous | |
request sent by a client. Specifically, it asks the UAS to cease | |
processing the request and to generate an error response to that | |
request. CANCEL has no effect on a request to which a UAS has | |
already given a final response. Because of this, it is most useful | |
to CANCEL requests to which it can take a server long time to | |
respond. For this reason, CANCEL is best for INVITE requests, which | |
can take a long time to generate a response. In that usage, a UAS | |
that receives a CANCEL request for an INVITE, but has not yet sent a | |
final response, would "stop ringing", and then respond to the INVITE | |
with a specific error response (a 487). | |
CANCEL requests can be constructed and sent by both proxies and user | |
agent clients. Section 15 discusses under what conditions a UAC | |
would CANCEL an INVITE request, and Section 16.10 discusses proxy | |
usage of CANCEL. | |
A stateful proxy responds to a CANCEL, rather than simply forwarding | |
a response it would receive from a downstream element. For that | |
reason, CANCEL is referred to as a "hop-by-hop" request, since it is | |
responded to at each stateful proxy hop. | |
9.1 Client Behavior | |
A CANCEL request SHOULD NOT be sent to cancel a request other than | |
INVITE. | |
Since requests other than INVITE are responded to immediately, | |
sending a CANCEL for a non-INVITE request would always create a | |
race condition. | |
Rosenberg, et. al. Standards Track [Page 53] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The following procedures are used to construct a CANCEL request. The | |
Request-URI, Call-ID, To, the numeric part of CSeq, and From header | |
fields in the CANCEL request MUST be identical to those in the | |
request being cancelled, including tags. A CANCEL constructed by a | |
client MUST have only a single Via header field value matching the | |
top Via value in the request being cancelled. Using the same values | |
for these header fields allows the CANCEL to be matched with the | |
request it cancels (Section 9.2 indicates how such matching occurs). | |
However, the method part of the CSeq header field MUST have a value | |
of CANCEL. This allows it to be identified and processed as a | |
transaction in its own right (See Section 17). | |
If the request being cancelled contains a Route header field, the | |
CANCEL request MUST include that Route header field's values. | |
This is needed so that stateless proxies are able to route CANCEL | |
requests properly. | |
The CANCEL request MUST NOT contain any Require or Proxy-Require | |
header fields. | |
Once the CANCEL is constructed, the client SHOULD check whether it | |
has received any response (provisional or final) for the request | |
being cancelled (herein referred to as the "original request"). | |
If no provisional response has been received, the CANCEL request MUST | |
NOT be sent; rather, the client MUST wait for the arrival of a | |
provisional response before sending the request. If the original | |
request has generated a final response, the CANCEL SHOULD NOT be | |
sent, as it is an effective no-op, since CANCEL has no effect on | |
requests that have already generated a final response. When the | |
client decides to send the CANCEL, it creates a client transaction | |
for the CANCEL and passes it the CANCEL request along with the | |
destination address, port, and transport. The destination address, | |
port, and transport for the CANCEL MUST be identical to those used to | |
send the original request. | |
If it was allowed to send the CANCEL before receiving a response | |
for the previous request, the server could receive the CANCEL | |
before the original request. | |
Note that both the transaction corresponding to the original request | |
and the CANCEL transaction will complete independently. However, a | |
UAC canceling a request cannot rely on receiving a 487 (Request | |
Terminated) response for the original request, as an RFC 2543- | |
compliant UAS will not generate such a response. If there is no | |
final response for the original request in 64*T1 seconds (T1 is | |
Rosenberg, et. al. Standards Track [Page 54] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
defined in Section 17.1.1.1), the client SHOULD then consider the | |
original transaction cancelled and SHOULD destroy the client | |
transaction handling the original request. | |
9.2 Server Behavior | |
The CANCEL method requests that the TU at the server side cancel a | |
pending transaction. The TU determines the transaction to be | |
cancelled by taking the CANCEL request, and then assuming that the | |
request method is anything but CANCEL or ACK and applying the | |
transaction matching procedures of Section 17.2.3. The matching | |
transaction is the one to be cancelled. | |
The processing of a CANCEL request at a server depends on the type of | |
server. A stateless proxy will forward it, a stateful proxy might | |
respond to it and generate some CANCEL requests of its own, and a UAS | |
will respond to it. See Section 16.10 for proxy treatment of CANCEL. | |
A UAS first processes the CANCEL request according to the general UAS | |
processing described in Section 8.2. However, since CANCEL requests | |
are hop-by-hop and cannot be resubmitted, they cannot be challenged | |
by the server in order to get proper credentials in an Authorization | |
header field. Note also that CANCEL requests do not contain a | |
Require header field. | |
If the UAS did not find a matching transaction for the CANCEL | |
according to the procedure above, it SHOULD respond to the CANCEL | |
with a 481 (Call Leg/Transaction Does Not Exist). If the transaction | |
for the original request still exists, the behavior of the UAS on | |
receiving a CANCEL request depends on whether it has already sent a | |
final response for the original request. If it has, the CANCEL | |
request has no effect on the processing of the original request, no | |
effect on any session state, and no effect on the responses generated | |
for the original request. If the UAS has not issued a final response | |
for the original request, its behavior depends on the method of the | |
original request. If the original request was an INVITE, the UAS | |
SHOULD immediately respond to the INVITE with a 487 (Request | |
Terminated). A CANCEL request has no impact on the processing of | |
transactions with any other method defined in this specification. | |
Regardless of the method of the original request, as long as the | |
CANCEL matched an existing transaction, the UAS answers the CANCEL | |
request itself with a 200 (OK) response. This response is | |
constructed following the procedures described in Section 8.2.6 | |
noting that the To tag of the response to the CANCEL and the To tag | |
in the response to the original request SHOULD be the same. The | |
response to CANCEL is passed to the server transaction for | |
transmission. | |
Rosenberg, et. al. Standards Track [Page 55] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
10 Registrations | |
10.1 Overview | |
SIP offers a discovery capability. If a user wants to initiate a | |
session with another user, SIP must discover the current host(s) at | |
which the destination user is reachable. This discovery process is | |
frequently accomplished by SIP network elements such as proxy servers | |
and redirect servers which are responsible for receiving a request, | |
determining where to send it based on knowledge of the location of | |
the user, and then sending it there. To do this, SIP network | |
elements consult an abstract service known as a location service, | |
which provides address bindings for a particular domain. These | |
address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, | |
for example, to one or more URIs that are somehow "closer" to the | |
desired user, sip:bob@engineering.biloxi.com, for example. | |
Ultimately, a proxy will consult a location service that maps a | |
received URI to the user agent(s) at which the desired recipient is | |
currently residing. | |
Registration creates bindings in a location service for a particular | |
domain that associates an address-of-record URI with one or more | |
contact addresses. Thus, when a proxy for that domain receives a | |
request whose Request-URI matches the address-of-record, the proxy | |
will forward the request to the contact addresses registered to that | |
address-of-record. Generally, it only makes sense to register an | |
address-of-record at a domain's location service when requests for | |
that address-of-record would be routed to that domain. In most | |
cases, this means that the domain of the registration will need to | |
match the domain in the URI of the address-of-record. | |
There are many ways by which the contents of the location service can | |
be established. One way is administratively. In the above example, | |
Bob is known to be a member of the engineering department through | |
access to a corporate database. However, SIP provides a mechanism | |
for a UA to create a binding explicitly. This mechanism is known as | |
registration. | |
Registration entails sending a REGISTER request to a special type of | |
UAS known as a registrar. A registrar acts as the front end to the | |
location service for a domain, reading and writing mappings based on | |
the contents of REGISTER requests. This location service is then | |
typically consulted by a proxy server that is responsible for routing | |
requests for that domain. | |
An illustration of the overall registration process is given in | |
Figure 2. Note that the registrar and proxy server are logical roles | |
that can be played by a single device in a network; for purposes of | |
Rosenberg, et. al. Standards Track [Page 56] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
clarity the two are separated in this illustration. Also note that | |
UAs may send requests through a proxy server in order to reach a | |
registrar if the two are separate elements. | |
SIP does not mandate a particular mechanism for implementing the | |
location service. The only requirement is that a registrar for some | |
domain MUST be able to read and write data to the location service, | |
and a proxy or a redirect server for that domain MUST be capable of | |
reading that same data. A registrar MAY be co-located with a | |
particular SIP proxy server for the same domain. | |
10.2 Constructing the REGISTER Request | |
REGISTER requests add, remove, and query bindings. A REGISTER | |
request can add a new binding between an address-of-record and one or | |
more contact addresses. Registration on behalf of a particular | |
address-of-record can be performed by a suitably authorized third | |
party. A client can also remove previous bindings or query to | |
determine which bindings are currently in place for an address-of- | |
record. | |
Except as noted, the construction of the REGISTER request and the | |
behavior of clients sending a REGISTER request is identical to the | |
general UAC behavior described in Section 8.1 and Section 17.1. | |
A REGISTER request does not establish a dialog. A UAC MAY include a | |
Route header field in a REGISTER request based on a pre-existing | |
route set as described in Section 8.1. The Record-Route header field | |
has no meaning in REGISTER requests or responses, and MUST be ignored | |
if present. In particular, the UAC MUST NOT create a new route set | |
based on the presence or absence of a Record-Route header field in | |
any response to a REGISTER request. | |
The following header fields, except Contact, MUST be included in a | |
REGISTER request. A Contact header field MAY be included: | |
Request-URI: The Request-URI names the domain of the location | |
service for which the registration is meant (for example, | |
"sip:chicago.com"). The "userinfo" and "@" components of the | |
SIP URI MUST NOT be present. | |
To: The To header field contains the address of record whose | |
registration is to be created, queried, or modified. The To | |
header field and the Request-URI field typically differ, as | |
the former contains a user name. This address-of-record MUST | |
be a SIP URI or SIPS URI. | |
Rosenberg, et. al. Standards Track [Page 57] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
From: The From header field contains the address-of-record of the | |
person responsible for the registration. The value is the | |
same as the To header field unless the request is a third- | |
party registration. | |
Call-ID: All registrations from a UAC SHOULD use the same Call-ID | |
header field value for registrations sent to a particular | |
registrar. | |
If the same client were to use different Call-ID values, a | |
registrar could not detect whether a delayed REGISTER request | |
might have arrived out of order. | |
CSeq: The CSeq value guarantees proper ordering of REGISTER | |
requests. A UA MUST increment the CSeq value by one for each | |
REGISTER request with the same Call-ID. | |
Contact: REGISTER requests MAY contain a Contact header field with | |
zero or more values containing address bindings. | |
UAs MUST NOT send a new registration (that is, containing new Contact | |
header field values, as opposed to a retransmission) until they have | |
received a final response from the registrar for the previous one or | |
the previous REGISTER request has timed out. | |
Rosenberg, et. al. Standards Track [Page 58] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
bob | |
+----+ | |
| UA | | |
| | | |
+----+ | |
| | |
|3)INVITE | |
| carol@chicago.com | |
chicago.com +--------+ V | |
+---------+ 2)Store|Location|4)Query +-----+ | |
|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com | |
+---------+ +--------+=======>+-----+ | |
A 5)Resp | | |
| | | |
| | | |
1)REGISTER| | | |
| | | |
+----+ | | |
| UA |<-------------------------------+ | |
cube2214a| | 6)INVITE | |
+----+ carol@cube2214a.chicago.com | |
carol | |
Figure 2: REGISTER example | |
The following Contact header parameters have a special meaning in | |
REGISTER requests: | |
action: The "action" parameter from RFC 2543 has been deprecated. | |
UACs SHOULD NOT use the "action" parameter. | |
expires: The "expires" parameter indicates how long the UA would | |
like the binding to be valid. The value is a number | |
indicating seconds. If this parameter is not provided, the | |
value of the Expires header field is used instead. | |
Implementations MAY treat values larger than 2**32-1 | |
(4294967295 seconds or 136 years) as equivalent to 2**32-1. | |
Malformed values SHOULD be treated as equivalent to 3600. | |
10.2.1 Adding Bindings | |
The REGISTER request sent to a registrar includes the contact | |
address(es) to which SIP requests for the address-of-record should be | |
forwarded. The address-of-record is included in the To header field | |
of the REGISTER request. | |
Rosenberg, et. al. Standards Track [Page 59] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The Contact header field values of the request typically consist of | |
SIP or SIPS URIs that identify particular SIP endpoints (for example, | |
"sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme. | |
A SIP UA can choose to register telephone numbers (with the tel URL, | |
RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) | |
as Contacts for an address-of-record, for example. | |
For example, Carol, with address-of-record "sip:carol@chicago.com", | |
would register with the SIP registrar of the domain chicago.com. Her | |
registrations would then be used by a proxy server in the chicago.com | |
domain to route requests for Carol's address-of-record to her SIP | |
endpoint. | |
Once a client has established bindings at a registrar, it MAY send | |
subsequent registrations containing new bindings or modifications to | |
existing bindings as necessary. The 2xx response to the REGISTER | |
request will contain, in a Contact header field, a complete list of | |
bindings that have been registered for this address-of-record at this | |
registrar. | |
If the address-of-record in the To header field of a REGISTER request | |
is a SIPS URI, then any Contact header field values in the request | |
SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs | |
under a SIPS address-of-record when the security of the resource | |
represented by the contact address is guaranteed by other means. | |
This may be applicable to URIs that invoke protocols other than SIP, | |
or SIP devices secured by protocols other than TLS. | |
Registrations do not need to update all bindings. Typically, a UA | |
only updates its own contact addresses. | |
10.2.1.1 Setting the Expiration Interval of Contact Addresses | |
When a client sends a REGISTER request, it MAY suggest an expiration | |
interval that indicates how long the client would like the | |
registration to be valid. (As described in Section 10.3, the | |
registrar selects the actual time interval based on its local | |
policy.) | |
There are two ways in which a client can suggest an expiration | |
interval for a binding: through an Expires header field or an | |
"expires" Contact header parameter. The latter allows expiration | |
intervals to be suggested on a per-binding basis when more than one | |
binding is given in a single REGISTER request, whereas the former | |
suggests an expiration interval for all Contact header field values | |
that do not contain the "expires" parameter. | |
Rosenberg, et. al. Standards Track [Page 60] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
If neither mechanism for expressing a suggested expiration time is | |
present in a REGISTER, the client is indicating its desire for the | |
server to choose. | |
10.2.1.2 Preferences among Contact Addresses | |
If more than one Contact is sent in a REGISTER request, the | |
registering UA intends to associate all of the URIs in these Contact | |
header field values with the address-of-record present in the To | |
field. This list can be prioritized with the "q" parameter in the | |
Contact header field. The "q" parameter indicates a relative | |
preference for the particular Contact header field value compared to | |
other bindings for this address-of-record. Section 16.6 describes | |
how a proxy server uses this preference indication. | |
10.2.2 Removing Bindings | |
Registrations are soft state and expire unless refreshed, but can | |
also be explicitly removed. A client can attempt to influence the | |
expiration interval selected by the registrar as described in Section | |
10.2.1. A UA requests the immediate removal of a binding by | |
specifying an expiration interval of "0" for that contact address in | |
a REGISTER request. UAs SHOULD support this mechanism so that | |
bindings can be removed before their expiration interval has passed. | |
The REGISTER-specific Contact header field value of "*" applies to | |
all registrations, but it MUST NOT be used unless the Expires header | |
field is present with a value of "0". | |
Use of the "*" Contact header field value allows a registering UA | |
to remove all bindings associated with an address-of-record | |
without knowing their precise values. | |
10.2.3 Fetching Bindings | |
A success response to any REGISTER request contains the complete list | |
of existing bindings, regardless of whether the request contained a | |
Contact header field. If no Contact header field is present in a | |
REGISTER request, the list of bindings is left unchanged. | |
10.2.4 Refreshing Bindings | |
Each UA is responsible for refreshing the bindings that it has | |
previously established. A UA SHOULD NOT refresh bindings set up by | |
other UAs. | |
Rosenberg, et. al. Standards Track [Page 61] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The 200 (OK) response from the registrar contains a list of Contact | |
fields enumerating all current bindings. The UA compares each | |
contact address to see if it created the contact address, using | |
comparison rules in Section 19.1.4. If so, it updates the expiration | |
time interval according to the expires parameter or, if absent, the | |
Expires field value. The UA then issues a REGISTER request for each | |
of its bindings before the expiration interval has elapsed. It MAY | |
combine several updates into one REGISTER request. | |
A UA SHOULD use the same Call-ID for all registrations during a | |
single boot cycle. Registration refreshes SHOULD be sent to the same | |
network address as the original registration, unless redirected. | |
10.2.5 Setting the Internal Clock | |
If the response for a REGISTER request contains a Date header field, | |
the client MAY use this header field to learn the current time in | |
order to set any internal clocks. | |
10.2.6 Discovering a Registrar | |
UAs can use three ways to determine the address to which to send | |
registrations: by configuration, using the address-of-record, and | |
multicast. A UA can be configured, in ways beyond the scope of this | |
specification, with a registrar address. If there is no configured | |
registrar address, the UA SHOULD use the host part of the address- | |
of-record as the Request-URI and address the request there, using the | |
normal SIP server location mechanisms [4]. For example, the UA for | |
the user "sip:carol@chicago.com" addresses the REGISTER request to | |
"sip:chicago.com". | |
Finally, a UA can be configured to use multicast. Multicast | |
registrations are addressed to the well-known "all SIP servers" | |
multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well- | |
known IPv6 multicast address has been allocated; such an allocation | |
will be documented separately when needed. SIP UAs MAY listen to | |
that address and use it to become aware of the location of other | |
local users (see [33]); however, they do not respond to the request. | |
Multicast registration may be inappropriate in some environments, | |
for example, if multiple businesses share the same local area | |
network. | |
10.2.7 Transmitting a Request | |
Once the REGISTER method has been constructed, and the destination of | |
the message identified, UACs follow the procedures described in | |
Section 8.1.2 to hand off the REGISTER to the transaction layer. | |
Rosenberg, et. al. Standards Track [Page 62] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
If the transaction layer returns a timeout error because the REGISTER | |
yielded no response, the UAC SHOULD NOT immediately re-attempt a | |
registration to the same registrar. | |
An immediate re-attempt is likely to also timeout. Waiting some | |
reasonable time interval for the conditions causing the timeout to | |
be corrected reduces unnecessary load on the network. No specific | |
interval is mandated. | |
10.2.8 Error Responses | |
If a UA receives a 423 (Interval Too Brief) response, it MAY retry | |
the registration after making the expiration interval of all contact | |
addresses in the REGISTER request equal to or greater than the | |
expiration interval within the Min-Expires header field of the 423 | |
(Interval Too Brief) response. | |
10.3 Processing REGISTER Requests | |
A registrar is a UAS that responds to REGISTER requests and maintains | |
a list of bindings that are accessible to proxy servers and redirect | |
servers within its administrative domain. A registrar handles | |
requests according to Section 8.2 and Section 17.2, but it accepts | |
only REGISTER requests. A registrar MUST not generate 6xx responses. | |
A registrar MAY redirect REGISTER requests as appropriate. One | |
common usage would be for a registrar listening on a multicast | |
interface to redirect multicast REGISTER requests to its own unicast | |
interface with a 302 (Moved Temporarily) response. | |
Registrars MUST ignore the Record-Route header field if it is | |
included in a REGISTER request. Registrars MUST NOT include a | |
Record-Route header field in any response to a REGISTER request. | |
A registrar might receive a request that traversed a proxy which | |
treats REGISTER as an unknown request and which added a Record- | |
Route header field value. | |
A registrar has to know (for example, through configuration) the set | |
of domain(s) for which it maintains bindings. REGISTER requests MUST | |
be processed by a registrar in the order that they are received. | |
REGISTER requests MUST also be processed atomically, meaning that a | |
particular REGISTER request is either processed completely or not at | |
all. Each REGISTER message MUST be processed independently of any | |
other registration or binding changes. | |
Rosenberg, et. al. Standards Track [Page 63] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
When receiving a REGISTER request, a registrar follows these steps: | |
1. The registrar inspects the Request-URI to determine whether it | |
has access to bindings for the domain identified in the | |
Request-URI. If not, and if the server also acts as a proxy | |
server, the server SHOULD forward the request to the addressed | |
domain, following the general behavior for proxying messages | |
described in Section 16. | |
2. To guarantee that the registrar supports any necessary | |
extensions, the registrar MUST process the Require header field | |
values as described for UASs in Section 8.2.2. | |
3. A registrar SHOULD authenticate the UAC. Mechanisms for the | |
authentication of SIP user agents are described in Section 22. | |
Registration behavior in no way overrides the generic | |
authentication framework for SIP. If no authentication | |
mechanism is available, the registrar MAY take the From address | |
as the asserted identity of the originator of the request. | |
4. The registrar SHOULD determine if the authenticated user is | |
authorized to modify registrations for this address-of-record. | |
For example, a registrar might consult an authorization | |
database that maps user names to a list of addresses-of-record | |
for which that user has authorization to modify bindings. If | |
the authenticated user is not authorized to modify bindings, | |
the registrar MUST return a 403 (Forbidden) and skip the | |
remaining steps. | |
In architectures that support third-party registration, one | |
entity may be responsible for updating the registrations | |
associated with multiple addresses-of-record. | |
5. The registrar extracts the address-of-record from the To header | |
field of the request. If the address-of-record is not valid | |
for the domain in the Request-URI, the registrar MUST send a | |
404 (Not Found) response and skip the remaining steps. The URI | |
MUST then be converted to a canonical form. To do that, all | |
URI parameters MUST be removed (including the user-param), and | |
any escaped characters MUST be converted to their unescaped | |
form. The result serves as an index into the list of bindings. | |
Rosenberg, et. al. Standards Track [Page 64] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
6. The registrar checks whether the request contains the Contact | |
header field. If not, it skips to the last step. If the | |
Contact header field is present, the registrar checks if there | |
is one Contact field value that contains the special value "*" | |
and an Expires field. If the request has additional Contact | |
fields or an expiration time other than zero, the request is | |
invalid, and the server MUST return a 400 (Invalid Request) and | |
skip the remaining steps. If not, the registrar checks whether | |
the Call-ID agrees with the value stored for each binding. If | |
not, it MUST remove the binding. If it does agree, it MUST | |
remove the binding only if the CSeq in the request is higher | |
than the value stored for that binding. Otherwise, the update | |
MUST be aborted and the request fails. | |
7. The registrar now processes each contact address in the Contact | |
header field in turn. For each address, it determines the | |
expiration interval as follows: | |
- If the field value has an "expires" parameter, that value | |
MUST be taken as the requested expiration. | |
- If there is no such parameter, but the request has an | |
Expires header field, that value MUST be taken as the | |
requested expiration. | |
- If there is neither, a locally-configured default value MUST | |
be taken as the requested expiration. | |
The registrar MAY choose an expiration less than the requested | |
expiration interval. If and only if the requested expiration | |
interval is greater than zero AND smaller than one hour AND | |
less than a registrar-configured minimum, the registrar MAY | |
reject the registration with a response of 423 (Interval Too | |
Brief). This response MUST contain a Min-Expires header field | |
that states the minimum expiration interval the registrar is | |
willing to honor. It then skips the remaining steps. | |
Allowing the registrar to set the registration interval | |
protects it against excessively frequent registration refreshes | |
while limiting the state that it needs to maintain and | |
decreasing the likelihood of registrations going stale. The | |
expiration interval of a registration is frequently used in the | |
creation of services. An example is a follow-me service, where | |
the user may only be available at a terminal for a brief | |
period. Therefore, registrars should accept brief | |
registrations; a request should only be rejected if the | |
interval is so short that the refreshes would degrade registrar | |
performance. | |
Rosenberg, et. al. Standards Track [Page 65] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
For each address, the registrar then searches the list of | |
current bindings using the URI comparison rules. If the | |
binding does not exist, it is tentatively added. If the | |
binding does exist, the registrar checks the Call-ID value. If | |
the Call-ID value in the existing binding differs from the | |
Call-ID value in the request, the binding MUST be removed if | |
the expiration time is zero and updated otherwise. If they are | |
the same, the registrar compares the CSeq value. If the value | |
is higher than that of the existing binding, it MUST update or | |
remove the binding as above. If not, the update MUST be | |
aborted and the request fails. | |
This algorithm ensures that out-of-order requests from the same | |
UA are ignored. | |
Each binding record records the Call-ID and CSeq values from | |
the request. | |
The binding updates MUST be committed (that is, made visible to | |
the proxy or redirect server) if and only if all binding | |
updates and additions succeed. If any one of them fails (for | |
example, because the back-end database commit failed), the | |
request MUST fail with a 500 (Server Error) response and all | |
tentative binding updates MUST be removed. | |
8. The registrar returns a 200 (OK) response. The response MUST | |
contain Contact header field values enumerating all current | |
bindings. Each Contact value MUST feature an "expires" | |
parameter indicating its expiration interval chosen by the | |
registrar. The response SHOULD include a Date header field. | |
11 Querying for Capabilities | |
The SIP method OPTIONS allows a UA to query another UA or a proxy | |
server as to its capabilities. This allows a client to discover | |
information about the supported methods, content types, extensions, | |
codecs, etc. without "ringing" the other party. For example, before | |
a client inserts a Require header field into an INVITE listing an | |
option that it is not certain the destination UAS supports, the | |
client can query the destination UAS with an OPTIONS to see if this | |
option is returned in a Supported header field. All UAs MUST support | |
the OPTIONS method. | |
The target of the OPTIONS request is identified by the Request-URI, | |
which could identify another UA or a SIP server. If the OPTIONS is | |
addressed to a proxy server, the Request-URI is set without a user | |
part, similar to the way a Request-URI is set for a REGISTER request. | |
Rosenberg, et. al. Standards Track [Page 66] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Alternatively, a server receiving an OPTIONS request with a Max- | |
Forwards header field value of 0 MAY respond to the request | |
regardless of the Request-URI. | |
This behavior is common with HTTP/1.1. This behavior can be used | |
as a "traceroute" functionality to check the capabilities of | |
individual hop servers by sending a series of OPTIONS requests | |
with incremented Max-Forwards values. | |
As is the case for general UA behavior, the transaction layer can | |
return a timeout error if the OPTIONS yields no response. This may | |
indicate that the target is unreachable and hence unavailable. | |
An OPTIONS request MAY be sent as part of an established dialog to | |
query the peer on capabilities that may be utilized later in the | |
dialog. | |
11.1 Construction of OPTIONS Request | |
An OPTIONS request is constructed using the standard rules for a SIP | |
request as discussed in Section 8.1.1. | |
A Contact header field MAY be present in an OPTIONS. | |
An Accept header field SHOULD be included to indicate the type of | |
message body the UAC wishes to receive in the response. Typically, | |
this is set to a format that is used to describe the media | |
capabilities of a UA, such as SDP (application/sdp). | |
The response to an OPTIONS request is assumed to be scoped to the | |
Request-URI in the original request. However, only when an OPTIONS | |
is sent as part of an established dialog is it guaranteed that future | |
requests will be received by the server that generated the OPTIONS | |
response. | |
Example OPTIONS request: | |
OPTIONS sip:carol@chicago.com SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 | |
Max-Forwards: 70 | |
To: <sip:carol@chicago.com> | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 63104 OPTIONS | |
Contact: <sip:alice@pc33.atlanta.com> | |
Accept: application/sdp | |
Content-Length: 0 | |
Rosenberg, et. al. Standards Track [Page 67] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
11.2 Processing of OPTIONS Request | |
The response to an OPTIONS is constructed using the standard rules | |
for a SIP response as discussed in Section 8.2.6. The response code | |
chosen MUST be the same that would have been chosen had the request | |
been an INVITE. That is, a 200 (OK) would be returned if the UAS is | |
ready to accept a call, a 486 (Busy Here) would be returned if the | |
UAS is busy, etc. This allows an OPTIONS request to be used to | |
determine the basic state of a UAS, which can be an indication of | |
whether the UAS will accept an INVITE request. | |
An OPTIONS request received within a dialog generates a 200 (OK) | |
response that is identical to one constructed outside a dialog and | |
does not have any impact on the dialog. | |
This use of OPTIONS has limitations due to the differences in proxy | |
handling of OPTIONS and INVITE requests. While a forked INVITE can | |
result in multiple 200 (OK) responses being returned, a forked | |
OPTIONS will only result in a single 200 (OK) response, since it is | |
treated by proxies using the non-INVITE handling. See Section 16.7 | |
for the normative details. | |
If the response to an OPTIONS is generated by a proxy server, the | |
proxy returns a 200 (OK), listing the capabilities of the server. | |
The response does not contain a message body. | |
Allow, Accept, Accept-Encoding, Accept-Language, and Supported header | |
fields SHOULD be present in a 200 (OK) response to an OPTIONS | |
request. If the response is generated by a proxy, the Allow header | |
field SHOULD be omitted as it is ambiguous since a proxy is method | |
agnostic. Contact header fields MAY be present in a 200 (OK) | |
response and have the same semantics as in a 3xx response. That is, | |
they may list a set of alternative names and methods of reaching the | |
user. A Warning header field MAY be present. | |
A message body MAY be sent, the type of which is determined by the | |
Accept header field in the OPTIONS request (application/sdp is the | |
default if the Accept header field is not present). If the types | |
include one that can describe media capabilities, the UAS SHOULD | |
include a body in the response for that purpose. Details on the | |
construction of such a body in the case of application/sdp are | |
described in [13]. | |
Rosenberg, et. al. Standards Track [Page 68] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Example OPTIONS response generated by a UAS (corresponding to the | |
request in Section 11.1): | |
SIP/2.0 200 OK | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 | |
;received=192.0.2.4 | |
To: <sip:carol@chicago.com>;tag=93810874 | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 63104 OPTIONS | |
Contact: <sip:carol@chicago.com> | |
Contact: <mailto:carol@chicago.com> | |
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE | |
Accept: application/sdp | |
Accept-Encoding: gzip | |
Accept-Language: en | |
Supported: foo | |
Content-Type: application/sdp | |
Content-Length: 274 | |
(SDP not shown) | |
12 Dialogs | |
A key concept for a user agent is that of a dialog. A dialog | |
represents a peer-to-peer SIP relationship between two user agents | |
that persists for some time. The dialog facilitates sequencing of | |
messages between the user agents and proper routing of requests | |
between both of them. The dialog represents a context in which to | |
interpret SIP messages. Section 8 discussed method independent UA | |
processing for requests and responses outside of a dialog. This | |
section discusses how those requests and responses are used to | |
construct a dialog, and then how subsequent requests and responses | |
are sent within a dialog. | |
A dialog is identified at each UA with a dialog ID, which consists of | |
a Call-ID value, a local tag and a remote tag. The dialog ID at each | |
UA involved in the dialog is not the same. Specifically, the local | |
tag at one UA is identical to the remote tag at the peer UA. The | |
tags are opaque tokens that facilitate the generation of unique | |
dialog IDs. | |
A dialog ID is also associated with all responses and with any | |
request that contains a tag in the To field. The rules for computing | |
the dialog ID of a message depend on whether the SIP element is a UAC | |
or UAS. For a UAC, the Call-ID value of the dialog ID is set to the | |
Call-ID of the message, the remote tag is set to the tag in the To | |
field of the message, and the local tag is set to the tag in the From | |
Rosenberg, et. al. Standards Track [Page 69] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
field of the message (these rules apply to both requests and | |
responses). As one would expect for a UAS, the Call-ID value of the | |
dialog ID is set to the Call-ID of the message, the remote tag is set | |
to the tag in the From field of the message, and the local tag is set | |
to the tag in the To field of the message. | |
A dialog contains certain pieces of state needed for further message | |
transmissions within the dialog. This state consists of the dialog | |
ID, a local sequence number (used to order requests from the UA to | |
its peer), a remote sequence number (used to order requests from its | |
peer to the UA), a local URI, a remote URI, remote target, a boolean | |
flag called "secure", and a route set, which is an ordered list of | |
URIs. The route set is the list of servers that need to be traversed | |
to send a request to the peer. A dialog can also be in the "early" | |
state, which occurs when it is created with a provisional response, | |
and then transition to the "confirmed" state when a 2xx final | |
response arrives. For other responses, or if no response arrives at | |
all on that dialog, the early dialog terminates. | |
12.1 Creation of a Dialog | |
Dialogs are created through the generation of non-failure responses | |
to requests with specific methods. Within this specification, only | |
2xx and 101-199 responses with a To tag, where the request was | |
INVITE, will establish a dialog. A dialog established by a non-final | |
response to a request is in the "early" state and it is called an | |
early dialog. Extensions MAY define other means for creating | |
dialogs. Section 13 gives more details that are specific to the | |
INVITE method. Here, we describe the process for creation of dialog | |
state that is not dependent on the method. | |
UAs MUST assign values to the dialog ID components as described | |
below. | |
12.1.1 UAS behavior | |
When a UAS responds to a request with a response that establishes a | |
dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route | |
header field values from the request into the response (including the | |
URIs, URI parameters, and any Record-Route header field parameters, | |
whether they are known or unknown to the UAS) and MUST maintain the | |
order of those values. The UAS MUST add a Contact header field to | |
the response. The Contact header field contains an address where the | |
UAS would like to be contacted for subsequent requests in the dialog | |
(which includes the ACK for a 2xx response in the case of an INVITE). | |
Generally, the host portion of this URI is the IP address or FQDN of | |
the host. The URI provided in the Contact header field MUST be a SIP | |
or SIPS URI. If the request that initiated the dialog contained a | |
Rosenberg, et. al. Standards Track [Page 70] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
SIPS URI in the Request-URI or in the top Record-Route header field | |
value, if there was any, or the Contact header field if there was no | |
Record-Route header field, the Contact header field in the response | |
MUST be a SIPS URI. The URI SHOULD have global scope (that is, the | |
same URI can be used in messages outside this dialog). The same way, | |
the scope of the URI in the Contact header field of the INVITE is not | |
limited to this dialog either. It can therefore be used in messages | |
to the UAC even outside this dialog. | |
The UAS then constructs the state of the dialog. This state MUST be | |
maintained for the duration of the dialog. | |
If the request arrived over TLS, and the Request-URI contained a SIPS | |
URI, the "secure" flag is set to TRUE. | |
The route set MUST be set to the list of URIs in the Record-Route | |
header field from the request, taken in order and preserving all URI | |
parameters. If no Record-Route header field is present in the | |
request, the route set MUST be set to the empty set. This route set, | |
even if empty, overrides any pre-existing route set for future | |
requests in this dialog. The remote target MUST be set to the URI | |
from the Contact header field of the request. | |
The remote sequence number MUST be set to the value of the sequence | |
number in the CSeq header field of the request. The local sequence | |
number MUST be empty. The call identifier component of the dialog ID | |
MUST be set to the value of the Call-ID in the request. The local | |
tag component of the dialog ID MUST be set to the tag in the To field | |
in the response to the request (which always includes a tag), and the | |
remote tag component of the dialog ID MUST be set to the tag from the | |
From field in the request. A UAS MUST be prepared to receive a | |
request without a tag in the From field, in which case the tag is | |
considered to have a value of null. | |
This is to maintain backwards compatibility with RFC 2543, which | |
did not mandate From tags. | |
The remote URI MUST be set to the URI in the From field, and the | |
local URI MUST be set to the URI in the To field. | |
12.1.2 UAC Behavior | |
When a UAC sends a request that can establish a dialog (such as an | |
INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., | |
the same SIP URI can be used in messages outside this dialog) in the | |
Contact header field of the request. If the request has a Request- | |
URI or a topmost Route header field value with a SIPS URI, the | |
Contact header field MUST contain a SIPS URI. | |
Rosenberg, et. al. Standards Track [Page 71] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
When a UAC receives a response that establishes a dialog, it | |
constructs the state of the dialog. This state MUST be maintained | |
for the duration of the dialog. | |
If the request was sent over TLS, and the Request-URI contained a | |
SIPS URI, the "secure" flag is set to TRUE. | |
The route set MUST be set to the list of URIs in the Record-Route | |
header field from the response, taken in reverse order and preserving | |
all URI parameters. If no Record-Route header field is present in | |
the response, the route set MUST be set to the empty set. This route | |
set, even if empty, overrides any pre-existing route set for future | |
requests in this dialog. The remote target MUST be set to the URI | |
from the Contact header field of the response. | |
The local sequence number MUST be set to the value of the sequence | |
number in the CSeq header field of the request. The remote sequence | |
number MUST be empty (it is established when the remote UA sends a | |
request within the dialog). The call identifier component of the | |
dialog ID MUST be set to the value of the Call-ID in the request. | |
The local tag component of the dialog ID MUST be set to the tag in | |
the From field in the request, and the remote tag component of the | |
dialog ID MUST be set to the tag in the To field of the response. A | |
UAC MUST be prepared to receive a response without a tag in the To | |
field, in which case the tag is considered to have a value of null. | |
This is to maintain backwards compatibility with RFC 2543, which | |
did not mandate To tags. | |
The remote URI MUST be set to the URI in the To field, and the local | |
URI MUST be set to the URI in the From field. | |
12.2 Requests within a Dialog | |
Once a dialog has been established between two UAs, either of them | |
MAY initiate new transactions as needed within the dialog. The UA | |
sending the request will take the UAC role for the transaction. The | |
UA receiving the request will take the UAS role. Note that these may | |
be different roles than the UAs held during the transaction that | |
established the dialog. | |
Requests within a dialog MAY contain Record-Route and Contact header | |
fields. However, these requests do not cause the dialog's route set | |
to be modified, although they may modify the remote target URI. | |
Specifically, requests that are not target refresh requests do not | |
modify the dialog's remote target URI, and requests that are target | |
refresh requests do. For dialogs that have been established with an | |
Rosenberg, et. al. Standards Track [Page 72] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
INVITE, the only target refresh request defined is re-INVITE (see | |
Section 14). Other extensions may define different target refresh | |
requests for dialogs established in other ways. | |
Note that an ACK is NOT a target refresh request. | |
Target refresh requests only update the dialog's remote target URI, | |
and not the route set formed from the Record-Route. Updating the | |
latter would introduce severe backwards compatibility problems with | |
RFC 2543-compliant systems. | |
12.2.1 UAC Behavior | |
12.2.1.1 Generating the Request | |
A request within a dialog is constructed by using many of the | |
components of the state stored as part of the dialog. | |
The URI in the To field of the request MUST be set to the remote URI | |
from the dialog state. The tag in the To header field of the request | |
MUST be set to the remote tag of the dialog ID. The From URI of the | |
request MUST be set to the local URI from the dialog state. The tag | |
in the From header field of the request MUST be set to the local tag | |
of the dialog ID. If the value of the remote or local tags is null, | |
the tag parameter MUST be omitted from the To or From header fields, | |
respectively. | |
Usage of the URI from the To and From fields in the original | |
request within subsequent requests is done for backwards | |
compatibility with RFC 2543, which used the URI for dialog | |
identification. In this specification, only the tags are used for | |
dialog identification. It is expected that mandatory reflection | |
of the original To and From URI in mid-dialog requests will be | |
deprecated in a subsequent revision of this specification. | |
The Call-ID of the request MUST be set to the Call-ID of the dialog. | |
Requests within a dialog MUST contain strictly monotonically | |
increasing and contiguous CSeq sequence numbers (increasing-by-one) | |
in each direction (excepting ACK and CANCEL of course, whose numbers | |
equal the requests being acknowledged or cancelled). Therefore, if | |
the local sequence number is not empty, the value of the local | |
sequence number MUST be incremented by one, and this value MUST be | |
placed into the CSeq header field. If the local sequence number is | |
empty, an initial value MUST be chosen using the guidelines of | |
Section 8.1.1.5. The method field in the CSeq header field value | |
MUST match the method of the request. | |
Rosenberg, et. al. Standards Track [Page 73] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
With a length of 32 bits, a client could generate, within a single | |
call, one request a second for about 136 years before needing to | |
wrap around. The initial value of the sequence number is chosen | |
so that subsequent requests within the same call will not wrap | |
around. A non-zero initial value allows clients to use a time- | |
based initial sequence number. A client could, for example, | |
choose the 31 most significant bits of a 32-bit second clock as an | |
initial sequence number. | |
The UAC uses the remote target and route set to build the Request-URI | |
and Route header field of the request. | |
If the route set is empty, the UAC MUST place the remote target URI | |
into the Request-URI. The UAC MUST NOT add a Route header field to | |
the request. | |
If the route set is not empty, and the first URI in the route set | |
contains the lr parameter (see Section 19.1.1), the UAC MUST place | |
the remote target URI into the Request-URI and MUST include a Route | |
header field containing the route set values in order, including all | |
parameters. | |
If the route set is not empty, and its first URI does not contain the | |
lr parameter, the UAC MUST place the first URI from the route set | |
into the Request-URI, stripping any parameters that are not allowed | |
in a Request-URI. The UAC MUST add a Route header field containing | |
the remainder of the route set values in order, including all | |
parameters. The UAC MUST then place the remote target URI into the | |
Route header field as the last value. | |
For example, if the remote target is sip:user@remoteua and the route | |
set contains: | |
<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4> | |
The request will be formed with the following Request-URI and Route | |
header field: | |
METHOD sip:proxy1 | |
Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua> | |
If the first URI of the route set does not contain the lr | |
parameter, the proxy indicated does not understand the routing | |
mechanisms described in this document and will act as specified in | |
RFC 2543, replacing the Request-URI with the first Route header | |
field value it receives while forwarding the message. Placing the | |
Request-URI at the end of the Route header field preserves the | |
Rosenberg, et. al. Standards Track [Page 74] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
information in that Request-URI across the strict router (it will | |
be returned to the Request-URI when the request reaches a loose- | |
router). | |
A UAC SHOULD include a Contact header field in any target refresh | |
requests within a dialog, and unless there is a need to change it, | |
the URI SHOULD be the same as used in previous requests within the | |
dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. | |
As discussed in Section 12.2.2, a Contact header field in a target | |
refresh request updates the remote target URI. This allows a UA to | |
provide a new contact address, should its address change during the | |
duration of the dialog. | |
However, requests that are not target refresh requests do not affect | |
the remote target URI for the dialog. | |
The rest of the request is formed as described in Section 8.1.1. | |
Once the request has been constructed, the address of the server is | |
computed and the request is sent, using the same procedures for | |
requests outside of a dialog (Section 8.1.2). | |
The procedures in Section 8.1.2 will normally result in the | |
request being sent to the address indicated by the topmost Route | |
header field value or the Request-URI if no Route header field is | |
present. Subject to certain restrictions, they allow the request | |
to be sent to an alternate address (such as a default outbound | |
proxy not represented in the route set). | |
12.2.1.2 Processing the Responses | |
The UAC will receive responses to the request from the transaction | |
layer. If the client transaction returns a timeout, this is treated | |
as a 408 (Request Timeout) response. | |
The behavior of a UAC that receives a 3xx response for a request sent | |
within a dialog is the same as if the request had been sent outside a | |
dialog. This behavior is described in Section 8.1.3.4. | |
Note, however, that when the UAC tries alternative locations, it | |
still uses the route set for the dialog to build the Route header | |
of the request. | |
When a UAC receives a 2xx response to a target refresh request, it | |
MUST replace the dialog's remote target URI with the URI from the | |
Contact header field in that response, if present. | |
Rosenberg, et. al. Standards Track [Page 75] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
If the response for a request within a dialog is a 481 | |
(Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC | |
SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if | |
no response at all is received for the request (the client | |
transaction would inform the TU about the timeout.) | |
For INVITE initiated dialogs, terminating the dialog consists of | |
sending a BYE. | |
12.2.2 UAS Behavior | |
Requests sent within a dialog, as any other requests, are atomic. If | |
a particular request is accepted by the UAS, all the state changes | |
associated with it are performed. If the request is rejected, none | |
of the state changes are performed. | |
Note that some requests, such as INVITEs, affect several pieces of | |
state. | |
The UAS will receive the request from the transaction layer. If the | |
request has a tag in the To header field, the UAS core computes the | |
dialog identifier corresponding to the request and compares it with | |
existing dialogs. If there is a match, this is a mid-dialog request. | |
In that case, the UAS first applies the same processing rules for | |
requests outside of a dialog, discussed in Section 8.2. | |
If the request has a tag in the To header field, but the dialog | |
identifier does not match any existing dialogs, the UAS may have | |
crashed and restarted, or it may have received a request for a | |
different (possibly failed) UAS (the UASs can construct the To tags | |
so that a UAS can identify that the tag was for a UAS for which it is | |
providing recovery). Another possibility is that the incoming | |
request has been simply misrouted. Based on the To tag, the UAS MAY | |
either accept or reject the request. Accepting the request for | |
acceptable To tags provides robustness, so that dialogs can persist | |
even through crashes. UAs wishing to support this capability must | |
take into consideration some issues such as choosing monotonically | |
increasing CSeq sequence numbers even across reboots, reconstructing | |
the route set, and accepting out-of-range RTP timestamps and sequence | |
numbers. | |
If the UAS wishes to reject the request because it does not wish to | |
recreate the dialog, it MUST respond to the request with a 481 | |
(Call/Transaction Does Not Exist) status code and pass that to the | |
server transaction. | |
Rosenberg, et. al. Standards Track [Page 76] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Requests that do not change in any way the state of a dialog may be | |
received within a dialog (for example, an OPTIONS request). They are | |
processed as if they had been received outside the dialog. | |
If the remote sequence number is empty, it MUST be set to the value | |
of the sequence number in the CSeq header field value in the request. | |
If the remote sequence number was not empty, but the sequence number | |
of the request is lower than the remote sequence number, the request | |
is out of order and MUST be rejected with a 500 (Server Internal | |
Error) response. If the remote sequence number was not empty, and | |
the sequence number of the request is greater than the remote | |
sequence number, the request is in order. It is possible for the | |
CSeq sequence number to be higher than the remote sequence number by | |
more than one. This is not an error condition, and a UAS SHOULD be | |
prepared to receive and process requests with CSeq values more than | |
one higher than the previous received request. The UAS MUST then set | |
the remote sequence number to the value of the sequence number in the | |
CSeq header field value in the request. | |
If a proxy challenges a request generated by the UAC, the UAC has | |
to resubmit the request with credentials. The resubmitted request | |
will have a new CSeq number. The UAS will never see the first | |
request, and thus, it will notice a gap in the CSeq number space. | |
Such a gap does not represent any error condition. | |
When a UAS receives a target refresh request, it MUST replace the | |
dialog's remote target URI with the URI from the Contact header field | |
in that request, if present. | |
12.3 Termination of a Dialog | |
Independent of the method, if a request outside of a dialog generates | |
a non-2xx final response, any early dialogs created through | |
provisional responses to that request are terminated. The mechanism | |
for terminating confirmed dialogs is method specific. In this | |
specification, the BYE method terminates a session and the dialog | |
associated with it. See Section 15 for details. | |
13 Initiating a Session | |
13.1 Overview | |
When a user agent client desires to initiate a session (for example, | |
audio, video, or a game), it formulates an INVITE request. The | |
INVITE request asks a server to establish a session. This request | |
may be forwarded by proxies, eventually arriving at one or more UAS | |
that can potentially accept the invitation. These UASs will | |
frequently need to query the user about whether to accept the | |
Rosenberg, et. al. Standards Track [Page 77] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
invitation. After some time, those UASs can accept the invitation | |
(meaning the session is to be established) by sending a 2xx response. | |
If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is | |
sent, depending on the reason for the rejection. Before sending a | |
final response, the UAS can also send provisional responses (1xx) to | |
advise the UAC of progress in contacting the called user. | |
After possibly receiving one or more provisional responses, the UAC | |
will get one or more 2xx responses or one non-2xx final response. | |
Because of the protracted amount of time it can take to receive final | |
responses to INVITE, the reliability mechanisms for INVITE | |
transactions differ from those of other requests (like OPTIONS). | |
Once it receives a final response, the UAC needs to send an ACK for | |
every final response it receives. The procedure for sending this ACK | |
depends on the type of response. For final responses between 300 and | |
699, the ACK processing is done in the transaction layer and follows | |
one set of rules (See Section 17). For 2xx responses, the ACK is | |
generated by the UAC core. | |
A 2xx response to an INVITE establishes a session, and it also | |
creates a dialog between the UA that issued the INVITE and the UA | |
that generated the 2xx response. Therefore, when multiple 2xx | |
responses are received from different remote UAs (because the INVITE | |
forked), each 2xx establishes a different dialog. All these dialogs | |
are part of the same call. | |
This section provides details on the establishment of a session using | |
INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and | |
BYE. | |
13.2 UAC Processing | |
13.2.1 Creating the Initial INVITE | |
Since the initial INVITE represents a request outside of a dialog, | |
its construction follows the procedures of Section 8.1.1. Additional | |
processing is required for the specific case of INVITE. | |
An Allow header field (Section 20.5) SHOULD be present in the INVITE. | |
It indicates what methods can be invoked within a dialog, on the UA | |
sending the INVITE, for the duration of the dialog. For example, a | |
UA capable of receiving INFO requests within a dialog [34] SHOULD | |
include an Allow header field listing the INFO method. | |
A Supported header field (Section 20.37) SHOULD be present in the | |
INVITE. It enumerates all the extensions understood by the UAC. | |
Rosenberg, et. al. Standards Track [Page 78] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
An Accept (Section 20.1) header field MAY be present in the INVITE. | |
It indicates which Content-Types are acceptable to the UA, in both | |
the response received by it, and in any subsequent requests sent to | |
it within dialogs established by the INVITE. The Accept header field | |
is especially useful for indicating support of various session | |
description formats. | |
The UAC MAY add an Expires header field (Section 20.19) to limit the | |
validity of the invitation. If the time indicated in the Expires | |
header field is reached and no final answer for the INVITE has been | |
received, the UAC core SHOULD generate a CANCEL request for the | |
INVITE, as per Section 9. | |
A UAC MAY also find it useful to add, among others, Subject (Section | |
20.36), Organization (Section 20.25) and User-Agent (Section 20.41) | |
header fields. They all contain information related to the INVITE. | |
The UAC MAY choose to add a message body to the INVITE. Section | |
8.1.1.10 deals with how to construct the header fields -- Content- | |
Type among others -- needed to describe the message body. | |
There are special rules for message bodies that contain a session | |
description - their corresponding Content-Disposition is "session". | |
SIP uses an offer/answer model where one UA sends a session | |
description, called the offer, which contains a proposed description | |
of the session. The offer indicates the desired communications means | |
(audio, video, games), parameters of those means (such as codec | |
types) and addresses for receiving media from the answerer. The | |
other UA responds with another session description, called the | |
answer, which indicates which communications means are accepted, the | |
parameters that apply to those means, and addresses for receiving | |
media from the offerer. An offer/answer exchange is within the | |
context of a dialog, so that if a SIP INVITE results in multiple | |
dialogs, each is a separate offer/answer exchange. The offer/answer | |
model defines restrictions on when offers and answers can be made | |
(for example, you cannot make a new offer while one is in progress). | |
This results in restrictions on where the offers and answers can | |
appear in SIP messages. In this specification, offers and answers | |
can only appear in INVITE requests and responses, and ACK. The usage | |
of offers and answers is further restricted. For the initial INVITE | |
transaction, the rules are: | |
o The initial offer MUST be in either an INVITE or, if not there, | |
in the first reliable non-failure message from the UAS back to | |
the UAC. In this specification, that is the final 2xx | |
response. | |
Rosenberg, et. al. Standards Track [Page 79] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o If the initial offer is in an INVITE, the answer MUST be in a | |
reliable non-failure message from UAS back to UAC which is | |
correlated to that INVITE. For this specification, that is | |
only the final 2xx response to that INVITE. That same exact | |
answer MAY also be placed in any provisional responses sent | |
prior to the answer. The UAC MUST treat the first session | |
description it receives as the answer, and MUST ignore any | |
session descriptions in subsequent responses to the initial | |
INVITE. | |
o If the initial offer is in the first reliable non-failure | |
message from the UAS back to UAC, the answer MUST be in the | |
acknowledgement for that message (in this specification, ACK | |
for a 2xx response). | |
o After having sent or received an answer to the first offer, the | |
UAC MAY generate subsequent offers in requests based on rules | |
specified for that method, but only if it has received answers | |
to any previous offers, and has not sent any offers to which it | |
hasn't gotten an answer. | |
o Once the UAS has sent or received an answer to the initial | |
offer, it MUST NOT generate subsequent offers in any responses | |
to the initial INVITE. This means that a UAS based on this | |
specification alone can never generate subsequent offers until | |
completion of the initial transaction. | |
Concretely, the above rules specify two exchanges for UAs compliant | |
to this specification alone - the offer is in the INVITE, and the | |
answer in the 2xx (and possibly in a 1xx as well, with the same | |
value), or the offer is in the 2xx, and the answer is in the ACK. | |
All user agents that support INVITE MUST support these two exchanges. | |
The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be | |
supported by all user agents as a means to describe sessions, and its | |
usage for constructing offers and answers MUST follow the procedures | |
defined in [13]. | |
The restrictions of the offer-answer model just described only apply | |
to bodies whose Content-Disposition header field value is "session". | |
Therefore, it is possible that both the INVITE and the ACK contain a | |
body message (for example, the INVITE carries a photo (Content- | |
Disposition: render) and the ACK a session description (Content- | |
Disposition: session)). | |
If the Content-Disposition header field is missing, bodies of | |
Content-Type application/sdp imply the disposition "session", while | |
other content types imply "render". | |
Rosenberg, et. al. Standards Track [Page 80] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Once the INVITE has been created, the UAC follows the procedures | |
defined for sending requests outside of a dialog (Section 8). This | |
results in the construction of a client transaction that will | |
ultimately send the request and deliver responses to the UAC. | |
13.2.2 Processing INVITE Responses | |
Once the INVITE has been passed to the INVITE client transaction, the | |
UAC waits for responses for the INVITE. If the INVITE client | |
transaction returns a timeout rather than a response the TU acts as | |
if a 408 (Request Timeout) response had been received, as described | |
in Section 8.1.3. | |
13.2.2.1 1xx Responses | |
Zero, one or multiple provisional responses may arrive before one or | |
more final responses are received. Provisional responses for an | |
INVITE request can create "early dialogs". If a provisional response | |
has a tag in the To field, and if the dialog ID of the response does | |
not match an existing dialog, one is constructed using the procedures | |
defined in Section 12.1.2. | |
The early dialog will only be needed if the UAC needs to send a | |
request to its peer within the dialog before the initial INVITE | |
transaction completes. Header fields present in a provisional | |
response are applicable as long as the dialog is in the early state | |
(for example, an Allow header field in a provisional response | |
contains the methods that can be used in the dialog while this is in | |
the early state). | |
13.2.2.2 3xx Responses | |
A 3xx response may contain one or more Contact header field values | |
providing new addresses where the callee might be reachable. | |
Depending on the status code of the 3xx response (see Section 21.3), | |
the UAC MAY choose to try those new addresses. | |
13.2.2.3 4xx, 5xx and 6xx Responses | |
A single non-2xx final response may be received for the INVITE. 4xx, | |
5xx and 6xx responses may contain a Contact header field value | |
indicating the location where additional information about the error | |
can be found. Subsequent final responses (which would only arrive | |
under error conditions) MUST be ignored. | |
All early dialogs are considered terminated upon reception of the | |
non-2xx final response. | |
Rosenberg, et. al. Standards Track [Page 81] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
After having received the non-2xx final response the UAC core | |
considers the INVITE transaction completed. The INVITE client | |
transaction handles the generation of ACKs for the response (see | |
Section 17). | |
13.2.2.4 2xx Responses | |
Multiple 2xx responses may arrive at the UAC for a single INVITE | |
request due to a forking proxy. Each response is distinguished by | |
the tag parameter in the To header field, and each represents a | |
distinct dialog, with a distinct dialog identifier. | |
If the dialog identifier in the 2xx response matches the dialog | |
identifier of an existing dialog, the dialog MUST be transitioned to | |
the "confirmed" state, and the route set for the dialog MUST be | |
recomputed based on the 2xx response using the procedures of Section | |
12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be | |
constructed using the procedures of Section 12.1.2. | |
Note that the only piece of state that is recomputed is the route | |
set. Other pieces of state such as the highest sequence numbers | |
(remote and local) sent within the dialog are not recomputed. The | |
route set only is recomputed for backwards compatibility. RFC | |
2543 did not mandate mirroring of the Record-Route header field in | |
a 1xx, only 2xx. However, we cannot update the entire state of | |
the dialog, since mid-dialog requests may have been sent within | |
the early dialog, modifying the sequence numbers, for example. | |
The UAC core MUST generate an ACK request for each 2xx received from | |
the transaction layer. The header fields of the ACK are constructed | |
in the same way as for any request sent within a dialog (see Section | |
12) with the exception of the CSeq and the header fields related to | |
authentication. The sequence number of the CSeq header field MUST be | |
the same as the INVITE being acknowledged, but the CSeq method MUST | |
be ACK. The ACK MUST contain the same credentials as the INVITE. If | |
the 2xx contains an offer (based on the rules above), the ACK MUST | |
carry an answer in its body. If the offer in the 2xx response is not | |
acceptable, the UAC core MUST generate a valid answer in the ACK and | |
then send a BYE immediately. | |
Once the ACK has been constructed, the procedures of [4] are used to | |
determine the destination address, port and transport. However, the | |
request is passed to the transport layer directly for transmission, | |
rather than a client transaction. This is because the UAC core | |
handles retransmissions of the ACK, not the transaction layer. The | |
ACK MUST be passed to the client transport every time a | |
retransmission of the 2xx final response that triggered the ACK | |
arrives. | |
Rosenberg, et. al. Standards Track [Page 82] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The UAC core considers the INVITE transaction completed 64*T1 seconds | |
after the reception of the first 2xx response. At this point all the | |
early dialogs that have not transitioned to established dialogs are | |
terminated. Once the INVITE transaction is considered completed by | |
the UAC core, no more new 2xx responses are expected to arrive. | |
If, after acknowledging any 2xx response to an INVITE, the UAC does | |
not want to continue with that dialog, then the UAC MUST terminate | |
the dialog by sending a BYE request as described in Section 15. | |
13.3 UAS Processing | |
13.3.1 Processing of the INVITE | |
The UAS core will receive INVITE requests from the transaction layer. | |
It first performs the request processing procedures of Section 8.2, | |
which are applied for both requests inside and outside of a dialog. | |
Assuming these processing states are completed without generating a | |
response, the UAS core performs the additional processing steps: | |
1. If the request is an INVITE that contains an Expires header | |
field, the UAS core sets a timer for the number of seconds | |
indicated in the header field value. When the timer fires, the | |
invitation is considered to be expired. If the invitation | |
expires before the UAS has generated a final response, a 487 | |
(Request Terminated) response SHOULD be generated. | |
2. If the request is a mid-dialog request, the method-independent | |
processing described in Section 12.2.2 is first applied. It | |
might also modify the session; Section 14 provides details. | |
3. If the request has a tag in the To header field but the dialog | |
identifier does not match any of the existing dialogs, the UAS | |
may have crashed and restarted, or may have received a request | |
for a different (possibly failed) UAS. Section 12.2.2 provides | |
guidelines to achieve a robust behavior under such a situation. | |
Processing from here forward assumes that the INVITE is outside of a | |
dialog, and is thus for the purposes of establishing a new session. | |
The INVITE may contain a session description, in which case the UAS | |
is being presented with an offer for that session. It is possible | |
that the user is already a participant in that session, even though | |
the INVITE is outside of a dialog. This can happen when a user is | |
invited to the same multicast conference by multiple other | |
participants. If desired, the UAS MAY use identifiers within the | |
session description to detect this duplication. For example, SDP | |
Rosenberg, et. al. Standards Track [Page 83] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
contains a session id and version number in the origin (o) field. If | |
the user is already a member of the session, and the session | |
parameters contained in the session description have not changed, the | |
UAS MAY silently accept the INVITE (that is, send a 2xx response | |
without prompting the user). | |
If the INVITE does not contain a session description, the UAS is | |
being asked to participate in a session, and the UAC has asked that | |
the UAS provide the offer of the session. It MUST provide the offer | |
in its first non-failure reliable message back to the UAC. In this | |
specification, that is a 2xx response to the INVITE. | |
The UAS can indicate progress, accept, redirect, or reject the | |
invitation. In all of these cases, it formulates a response using | |
the procedures described in Section 8.2.6. | |
13.3.1.1 Progress | |
If the UAS is not able to answer the invitation immediately, it can | |
choose to indicate some kind of progress to the UAC (for example, an | |
indication that a phone is ringing). This is accomplished with a | |
provisional response between 101 and 199. These provisional | |
responses establish early dialogs and therefore follow the procedures | |
of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY | |
send as many provisional responses as it likes. Each of these MUST | |
indicate the same dialog ID. However, these will not be delivered | |
reliably. | |
If the UAS desires an extended period of time to answer the INVITE, | |
it will need to ask for an "extension" in order to prevent proxies | |
from canceling the transaction. A proxy has the option of canceling | |
a transaction when there is a gap of 3 minutes between responses in a | |
transaction. To prevent cancellation, the UAS MUST send a non-100 | |
provisional response at every minute, to handle the possibility of | |
lost provisional responses. | |
An INVITE transaction can go on for extended durations when the | |
user is placed on hold, or when interworking with PSTN systems | |
which allow communications to take place without answering the | |
call. The latter is common in Interactive Voice Response (IVR) | |
systems. | |
13.3.1.2 The INVITE is Redirected | |
If the UAS decides to redirect the call, a 3xx response is sent. A | |
300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved | |
Temporarily) response SHOULD contain a Contact header field | |
Rosenberg, et. al. Standards Track [Page 84] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
containing one or more URIs of new addresses to be tried. The | |
response is passed to the INVITE server transaction, which will deal | |
with its retransmissions. | |
13.3.1.3 The INVITE is Rejected | |
A common scenario occurs when the callee is currently not willing or | |
able to take additional calls at this end system. A 486 (Busy Here) | |
SHOULD be returned in such a scenario. If the UAS knows that no | |
other end system will be able to accept this call, a 600 (Busy | |
Everywhere) response SHOULD be sent instead. However, it is unlikely | |
that a UAS will be able to know this in general, and thus this | |
response will not usually be used. The response is passed to the | |
INVITE server transaction, which will deal with its retransmissions. | |
A UAS rejecting an offer contained in an INVITE SHOULD return a 488 | |
(Not Acceptable Here) response. Such a response SHOULD include a | |
Warning header field value explaining why the offer was rejected. | |
13.3.1.4 The INVITE is Accepted | |
The UAS core generates a 2xx response. This response establishes a | |
dialog, and therefore follows the procedures of Section 12.1.1 in | |
addition to those of Section 8.2.6. | |
A 2xx response to an INVITE SHOULD contain the Allow header field and | |
the Supported header field, and MAY contain the Accept header field. | |
Including these header fields allows the UAC to determine the | |
features and extensions supported by the UAS for the duration of the | |
call, without probing. | |
If the INVITE request contained an offer, and the UAS had not yet | |
sent an answer, the 2xx MUST contain an answer. If the INVITE did | |
not contain an offer, the 2xx MUST contain an offer if the UAS had | |
not yet sent an offer. | |
Once the response has been constructed, it is passed to the INVITE | |
server transaction. Note, however, that the INVITE server | |
transaction will be destroyed as soon as it receives this final | |
response and passes it to the transport. Therefore, it is necessary | |
to periodically pass the response directly to the transport until the | |
ACK arrives. The 2xx response is passed to the transport with an | |
interval that starts at T1 seconds and doubles for each | |
retransmission until it reaches T2 seconds (T1 and T2 are defined in | |
Section 17). Response retransmissions cease when an ACK request for | |
the response is received. This is independent of whatever transport | |
protocols are used to send the response. | |
Rosenberg, et. al. Standards Track [Page 85] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Since 2xx is retransmitted end-to-end, there may be hops between | |
UAS and UAC that are UDP. To ensure reliable delivery across | |
these hops, the response is retransmitted periodically even if the | |
transport at the UAS is reliable. | |
If the server retransmits the 2xx response for 64*T1 seconds without | |
receiving an ACK, the dialog is confirmed, but the session SHOULD be | |
terminated. This is accomplished with a BYE, as described in Section | |
15. | |
14 Modifying an Existing Session | |
A successful INVITE request (see Section 13) establishes both a | |
dialog between two user agents and a session using the offer-answer | |
model. Section 12 explains how to modify an existing dialog using a | |
target refresh request (for example, changing the remote target URI | |
of the dialog). This section describes how to modify the actual | |
session. This modification can involve changing addresses or ports, | |
adding a media stream, deleting a media stream, and so on. This is | |
accomplished by sending a new INVITE request within the same dialog | |
that established the session. An INVITE request sent within an | |
existing dialog is known as a re-INVITE. | |
Note that a single re-INVITE can modify the dialog and the | |
parameters of the session at the same time. | |
Either the caller or callee can modify an existing session. | |
The behavior of a UA on detection of media failure is a matter of | |
local policy. However, automated generation of re-INVITE or BYE is | |
NOT RECOMMENDED to avoid flooding the network with traffic when there | |
is congestion. In any case, if these messages are sent | |
automatically, they SHOULD be sent after some randomized interval. | |
Note that the paragraph above refers to automatically generated | |
BYEs and re-INVITEs. If the user hangs up upon media failure, the | |
UA would send a BYE request as usual. | |
14.1 UAC Behavior | |
The same offer-answer model that applies to session descriptions in | |
INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC | |
that wants to add a media stream, for example, will create a new | |
offer that contains this media stream, and send that in an INVITE | |
request to its peer. It is important to note that the full | |
description of the session, not just the change, is sent. This | |
supports stateless session processing in various elements, and | |
supports failover and recovery capabilities. Of course, a UAC MAY | |
Rosenberg, et. al. Standards Track [Page 86] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
send a re-INVITE with no session description, in which case the first | |
reliable non-failure response to the re-INVITE will contain the offer | |
(in this specification, that is a 2xx response). | |
If the session description format has the capability for version | |
numbers, the offerer SHOULD indicate that the version of the session | |
description has changed. | |
The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set | |
following the same rules as for regular requests within an existing | |
dialog, described in Section 12. | |
A UAC MAY choose not to add an Alert-Info header field or a body with | |
Content-Disposition "alert" to re-INVITEs because UASs do not | |
typically alert the user upon reception of a re-INVITE. | |
Unlike an INVITE, which can fork, a re-INVITE will never fork, and | |
therefore, only ever generate a single final response. The reason a | |
re-INVITE will never fork is that the Request-URI identifies the | |
target as the UA instance it established the dialog with, rather than | |
identifying an address-of-record for the user. | |
Note that a UAC MUST NOT initiate a new INVITE transaction within a | |
dialog while another INVITE transaction is in progress in either | |
direction. | |
1. If there is an ongoing INVITE client transaction, the TU MUST | |
wait until the transaction reaches the completed or terminated | |
state before initiating the new INVITE. | |
2. If there is an ongoing INVITE server transaction, the TU MUST | |
wait until the transaction reaches the confirmed or terminated | |
state before initiating the new INVITE. | |
However, a UA MAY initiate a regular transaction while an INVITE | |
transaction is in progress. A UA MAY also initiate an INVITE | |
transaction while a regular transaction is in progress. | |
If a UA receives a non-2xx final response to a re-INVITE, the session | |
parameters MUST remain unchanged, as if no re-INVITE had been issued. | |
Note that, as stated in Section 12.2.1.2, if the non-2xx final | |
response is a 481 (Call/Transaction Does Not Exist), or a 408 | |
(Request Timeout), or no response at all is received for the re- | |
INVITE (that is, a timeout is returned by the INVITE client | |
transaction), the UAC will terminate the dialog. | |
Rosenberg, et. al. Standards Track [Page 87] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
If a UAC receives a 491 response to a re-INVITE, it SHOULD start a | |
timer with a value T chosen as follows: | |
1. If the UAC is the owner of the Call-ID of the dialog ID | |
(meaning it generated the value), T has a randomly chosen value | |
between 2.1 and 4 seconds in units of 10 ms. | |
2. If the UAC is not the owner of the Call-ID of the dialog ID, T | |
has a randomly chosen value of between 0 and 2 seconds in units | |
of 10 ms. | |
When the timer fires, the UAC SHOULD attempt the re-INVITE once more, | |
if it still desires for that session modification to take place. For | |
example, if the call was already hung up with a BYE, the re-INVITE | |
would not take place. | |
The rules for transmitting a re-INVITE and for generating an ACK for | |
a 2xx response to re-INVITE are the same as for the initial INVITE | |
(Section 13.2.1). | |
14.2 UAS Behavior | |
Section 13.3.1 describes the procedure for distinguishing incoming | |
re-INVITEs from incoming initial INVITEs and handling a re-INVITE for | |
an existing dialog. | |
A UAS that receives a second INVITE before it sends the final | |
response to a first INVITE with a lower CSeq sequence number on the | |
same dialog MUST return a 500 (Server Internal Error) response to the | |
second INVITE and MUST include a Retry-After header field with a | |
randomly chosen value of between 0 and 10 seconds. | |
A UAS that receives an INVITE on a dialog while an INVITE it had sent | |
on that dialog is in progress MUST return a 491 (Request Pending) | |
response to the received INVITE. | |
If a UA receives a re-INVITE for an existing dialog, it MUST check | |
any version identifiers in the session description or, if there are | |
no version identifiers, the content of the session description to see | |
if it has changed. If the session description has changed, the UAS | |
MUST adjust the session parameters accordingly, possibly after asking | |
the user for confirmation. | |
Versioning of the session description can be used to accommodate | |
the capabilities of new arrivals to a conference, add or delete | |
media, or change from a unicast to a multicast conference. | |
Rosenberg, et. al. Standards Track [Page 88] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
If the new session description is not acceptable, the UAS can reject | |
it by returning a 488 (Not Acceptable Here) response for the re- | |
INVITE. This response SHOULD include a Warning header field. | |
If a UAS generates a 2xx response and never receives an ACK, it | |
SHOULD generate a BYE to terminate the dialog. | |
A UAS MAY choose not to generate 180 (Ringing) responses for a re- | |
INVITE because UACs do not typically render this information to the | |
user. For the same reason, UASs MAY choose not to use an Alert-Info | |
header field or a body with Content-Disposition "alert" in responses | |
to a re-INVITE. | |
A UAS providing an offer in a 2xx (because the INVITE did not contain | |
an offer) SHOULD construct the offer as if the UAS were making a | |
brand new call, subject to the constraints of sending an offer that | |
updates an existing session, as described in [13] in the case of SDP. | |
Specifically, this means that it SHOULD include as many media formats | |
and media types that the UA is willing to support. The UAS MUST | |
ensure that the session description overlaps with its previous | |
session description in media formats, transports, or other parameters | |
that require support from the peer. This is to avoid the need for | |
the peer to reject the session description. If, however, it is | |
unacceptable to the UAC, the UAC SHOULD generate an answer with a | |
valid session description, and then send a BYE to terminate the | |
session. | |
15 Terminating a Session | |
This section describes the procedures for terminating a session | |
established by SIP. The state of the session and the state of the | |
dialog are very closely related. When a session is initiated with an | |
INVITE, each 1xx or 2xx response from a distinct UAS creates a | |
dialog, and if that response completes the offer/answer exchange, it | |
also creates a session. As a result, each session is "associated" | |
with a single dialog - the one which resulted in its creation. If an | |
initial INVITE generates a non-2xx final response, that terminates | |
all sessions (if any) and all dialogs (if any) that were created | |
through responses to the request. By virtue of completing the | |
transaction, a non-2xx final response also prevents further sessions | |
from being created as a result of the INVITE. The BYE request is | |
used to terminate a specific session or attempted session. In this | |
case, the specific session is the one with the peer UA on the other | |
side of the dialog. When a BYE is received on a dialog, any session | |
associated with that dialog SHOULD terminate. A UA MUST NOT send a | |
BYE outside of a dialog. The caller's UA MAY send a BYE for either | |
confirmed or early dialogs, and the callee's UA MAY send a BYE on | |
confirmed dialogs, but MUST NOT send a BYE on early dialogs. | |
Rosenberg, et. al. Standards Track [Page 89] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
However, the callee's UA MUST NOT send a BYE on a confirmed dialog | |
until it has received an ACK for its 2xx response or until the server | |
transaction times out. If no SIP extensions have defined other | |
application layer states associated with the dialog, the BYE also | |
terminates the dialog. | |
The impact of a non-2xx final response to INVITE on dialogs and | |
sessions makes the use of CANCEL attractive. The CANCEL attempts to | |
force a non-2xx response to the INVITE (in particular, a 487). | |
Therefore, if a UAC wishes to give up on its call attempt entirely, | |
it can send a CANCEL. If the INVITE results in 2xx final response(s) | |
to the INVITE, this means that a UAS accepted the invitation while | |
the CANCEL was in progress. The UAC MAY continue with the sessions | |
established by any 2xx responses, or MAY terminate them with BYE. | |
The notion of "hanging up" is not well defined within SIP. It is | |
specific to a particular, albeit common, user interface. | |
Typically, when the user hangs up, it indicates a desire to | |
terminate the attempt to establish a session, and to terminate any | |
sessions already created. For the caller's UA, this would imply a | |
CANCEL request if the initial INVITE has not generated a final | |
response, and a BYE to all confirmed dialogs after a final | |
response. For the callee's UA, it would typically imply a BYE; | |
presumably, when the user picked up the phone, a 2xx was | |
generated, and so hanging up would result in a BYE after the ACK | |
is received. This does not mean a user cannot hang up before | |
receipt of the ACK, it just means that the software in his phone | |
needs to maintain state for a short while in order to clean up | |
properly. If the particular UI allows for the user to reject a | |
call before its answered, a 403 (Forbidden) is a good way to | |
express that. As per the rules above, a BYE can't be sent. | |
15.1 Terminating a Session with a BYE Request | |
15.1.1 UAC Behavior | |
A BYE request is constructed as would any other request within a | |
dialog, as described in Section 12. | |
Once the BYE is constructed, the UAC core creates a new non-INVITE | |
client transaction, and passes it the BYE request. The UAC MUST | |
consider the session terminated (and therefore stop sending or | |
listening for media) as soon as the BYE request is passed to the | |
client transaction. If the response for the BYE is a 481 | |
(Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no | |
Rosenberg, et. al. Standards Track [Page 90] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
response at all is received for the BYE (that is, a timeout is | |
returned by the client transaction), the UAC MUST consider the | |
session and the dialog terminated. | |
15.1.2 UAS Behavior | |
A UAS first processes the BYE request according to the general UAS | |
processing described in Section 8.2. A UAS core receiving a BYE | |
request checks if it matches an existing dialog. If the BYE does not | |
match an existing dialog, the UAS core SHOULD generate a 481 | |
(Call/Transaction Does Not Exist) response and pass that to the | |
server transaction. | |
This rule means that a BYE sent without tags by a UAC will be | |
rejected. This is a change from RFC 2543, which allowed BYE | |
without tags. | |
A UAS core receiving a BYE request for an existing dialog MUST follow | |
the procedures of Section 12.2.2 to process the request. Once done, | |
the UAS SHOULD terminate the session (and therefore stop sending and | |
listening for media). The only case where it can elect not to are | |
multicast sessions, where participation is possible even if the other | |
participant in the dialog has terminated its involvement in the | |
session. Whether or not it ends its participation on the session, | |
the UAS core MUST generate a 2xx response to the BYE, and MUST pass | |
that to the server transaction for transmission. | |
The UAS MUST still respond to any pending requests received for that | |
dialog. It is RECOMMENDED that a 487 (Request Terminated) response | |
be generated to those pending requests. | |
16 Proxy Behavior | |
16.1 Overview | |
SIP proxies are elements that route SIP requests to user agent | |
servers and SIP responses to user agent clients. A request may | |
traverse several proxies on its way to a UAS. Each will make routing | |
decisions, modifying the request before forwarding it to the next | |
element. Responses will route through the same set of proxies | |
traversed by the request in the reverse order. | |
Being a proxy is a logical role for a SIP element. When a request | |
arrives, an element that can play the role of a proxy first decides | |
if it needs to respond to the request on its own. For instance, the | |
request may be malformed or the element may need credentials from the | |
client before acting as a proxy. The element MAY respond with any | |
Rosenberg, et. al. Standards Track [Page 91] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
appropriate error code. When responding directly to a request, the | |
element is playing the role of a UAS and MUST behave as described in | |
Section 8.2. | |
A proxy can operate in either a stateful or stateless mode for each | |
new request. When stateless, a proxy acts as a simple forwarding | |
element. It forwards each request downstream to a single element | |
determined by making a targeting and routing decision based on the | |
request. It simply forwards every response it receives upstream. A | |
stateless proxy discards information about a message once the message | |
has been forwarded. A stateful proxy remembers information | |
(specifically, transaction state) about each incoming request and any | |
requests it sends as a result of processing the incoming request. It | |
uses this information to affect the processing of future messages | |
associated with that request. A stateful proxy MAY choose to "fork" | |
a request, routing it to multiple destinations. Any request that is | |
forwarded to more than one location MUST be handled statefully. | |
In some circumstances, a proxy MAY forward requests using stateful | |
transports (such as TCP) without being transaction-stateful. For | |
instance, a proxy MAY forward a request from one TCP connection to | |
another transaction statelessly as long as it places enough | |
information in the message to be able to forward the response down | |
the same connection the request arrived on. Requests forwarded | |
between different types of transports where the proxy's TU must take | |
an active role in ensuring reliable delivery on one of the transports | |
MUST be forwarded transaction statefully. | |
A stateful proxy MAY transition to stateless operation at any time | |
during the processing of a request, so long as it did not do anything | |
that would otherwise prevent it from being stateless initially | |
(forking, for example, or generation of a 100 response). When | |
performing such a transition, all state is simply discarded. The | |
proxy SHOULD NOT initiate a CANCEL request. | |
Much of the processing involved when acting statelessly or statefully | |
for a request is identical. The next several subsections are written | |
from the point of view of a stateful proxy. The last section calls | |
out those places where a stateless proxy behaves differently. | |
16.2 Stateful Proxy | |
When stateful, a proxy is purely a SIP transaction processing engine. | |
Its behavior is modeled here in terms of the server and client | |
transactions defined in Section 17. A stateful proxy has a server | |
transaction associated with one or more client transactions by a | |
higher layer proxy processing component (see figure 3), known as a | |
proxy core. An incoming request is processed by a server | |
Rosenberg, et. al. Standards Track [Page 92] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
transaction. Requests from the server transaction are passed to a | |
proxy core. The proxy core determines where to route the request, | |
choosing one or more next-hop locations. An outgoing request for | |
each next-hop location is processed by its own associated client | |
transaction. The proxy core collects the responses from the client | |
transactions and uses them to send responses to the server | |
transaction. | |
A stateful proxy creates a new server transaction for each new | |
request received. Any retransmissions of the request will then be | |
handled by that server transaction per Section 17. The proxy core | |
MUST behave as a UAS with respect to sending an immediate provisional | |
on that server transaction (such as 100 Trying) as described in | |
Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 | |
(Trying) responses to non-INVITE requests. | |
This is a model of proxy behavior, not of software. An | |
implementation is free to take any approach that replicates the | |
external behavior this model defines. | |
For all new requests, including any with unknown methods, an element | |
intending to proxy the request MUST: | |
1. Validate the request (Section 16.3) | |
2. Preprocess routing information (Section 16.4) | |
3. Determine target(s) for the request (Section 16.5) | |
+--------------------+ | |
| | +---+ | |
| | | C | | |
| | | T | | |
| | +---+ | |
+---+ | Proxy | +---+ CT = Client Transaction | |
| S | | "Higher" Layer | | C | | |
| T | | | | T | ST = Server Transaction | |
+---+ | | +---+ | |
| | +---+ | |
| | | C | | |
| | | T | | |
| | +---+ | |
+--------------------+ | |
Figure 3: Stateful Proxy Model | |
Rosenberg, et. al. Standards Track [Page 93] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
4. Forward the request to each target (Section 16.6) | |
5. Process all responses (Section 16.7) | |
16.3 Request Validation | |
Before an element can proxy a request, it MUST verify the message's | |
validity. A valid message must pass the following checks: | |
1. Reasonable Syntax | |
2. URI scheme | |
3. Max-Forwards | |
4. (Optional) Loop Detection | |
5. Proxy-Require | |
6. Proxy-Authorization | |
If any of these checks fail, the element MUST behave as a user agent | |
server (see Section 8.2) and respond with an error code. | |
Notice that a proxy is not required to detect merged requests and | |
MUST NOT treat merged requests as an error condition. The endpoints | |
receiving the requests will resolve the merge as described in Section | |
8.2.2.2. | |
1. Reasonable syntax check | |
The request MUST be well-formed enough to be handled with a server | |
transaction. Any components involved in the remainder of these | |
Request Validation steps or the Request Forwarding section MUST be | |
well-formed. Any other components, well-formed or not, SHOULD be | |
ignored and remain unchanged when the message is forwarded. For | |
instance, an element would not reject a request because of a | |
malformed Date header field. Likewise, a proxy would not remove a | |
malformed Date header field before forwarding a request. | |
This protocol is designed to be extended. Future extensions may | |
define new methods and header fields at any time. An element MUST | |
NOT refuse to proxy a request because it contains a method or | |
header field it does not know about. | |
Rosenberg, et. al. Standards Track [Page 94] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
2. URI scheme check | |
If the Request-URI has a URI whose scheme is not understood by the | |
proxy, the proxy SHOULD reject the request with a 416 (Unsupported | |
URI Scheme) response. | |
3. Max-Forwards check | |
The Max-Forwards header field (Section 20.22) is used to limit the | |
number of elements a SIP request can traverse. | |
If the request does not contain a Max-Forwards header field, this | |
check is passed. | |
If the request contains a Max-Forwards header field with a field | |
value greater than zero, the check is passed. | |
If the request contains a Max-Forwards header field with a field | |
value of zero (0), the element MUST NOT forward the request. If | |
the request was for OPTIONS, the element MAY act as the final | |
recipient and respond per Section 11. Otherwise, the element MUST | |
return a 483 (Too many hops) response. | |
4. Optional Loop Detection check | |
An element MAY check for forwarding loops before forwarding a | |
request. If the request contains a Via header field with a sent- | |
by value that equals a value placed into previous requests by the | |
proxy, the request has been forwarded by this element before. The | |
request has either looped or is legitimately spiraling through the | |
element. To determine if the request has looped, the element MAY | |
perform the branch parameter calculation described in Step 8 of | |
Section 16.6 on this message and compare it to the parameter | |
received in that Via header field. If the parameters match, the | |
request has looped. If they differ, the request is spiraling, and | |
processing continues. If a loop is detected, the element MAY | |
return a 482 (Loop Detected) response. | |
5. Proxy-Require check | |
Future extensions to this protocol may introduce features that | |
require special handling by proxies. Endpoints will include a | |
Proxy-Require header field in requests that use these features, | |
telling the proxy not to process the request unless the feature is | |
understood. | |
Rosenberg, et. al. Standards Track [Page 95] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
If the request contains a Proxy-Require header field (Section | |
20.29) with one or more option-tags this element does not | |
understand, the element MUST return a 420 (Bad Extension) | |
response. The response MUST include an Unsupported (Section | |
20.40) header field listing those option-tags the element did not | |
understand. | |
6. Proxy-Authorization check | |
If an element requires credentials before forwarding a request, | |
the request MUST be inspected as described in Section 22.3. That | |
section also defines what the element must do if the inspection | |
fails. | |
16.4 Route Information Preprocessing | |
The proxy MUST inspect the Request-URI of the request. If the | |
Request-URI of the request contains a value this proxy previously | |
placed into a Record-Route header field (see Section 16.6 item 4), | |
the proxy MUST replace the Request-URI in the request with the last | |
value from the Route header field, and remove that value from the | |
Route header field. The proxy MUST then proceed as if it received | |
this modified request. | |
This will only happen when the element sending the request to the | |
proxy (which may have been an endpoint) is a strict router. This | |
rewrite on receive is necessary to enable backwards compatibility | |
with those elements. It also allows elements following this | |
specification to preserve the Request-URI through strict-routing | |
proxies (see Section 12.2.1.1). | |
This requirement does not obligate a proxy to keep state in order | |
to detect URIs it previously placed in Record-Route header fields. | |
Instead, a proxy need only place enough information in those URIs | |
to recognize them as values it provided when they later appear. | |
If the Request-URI contains a maddr parameter, the proxy MUST check | |
to see if its value is in the set of addresses or domains the proxy | |
is configured to be responsible for. If the Request-URI has a maddr | |
parameter with a value the proxy is responsible for, and the request | |
was received using the port and transport indicated (explicitly or by | |
default) in the Request-URI, the proxy MUST strip the maddr and any | |
non-default port or transport parameter and continue processing as if | |
those values had not been present in the request. | |
Rosenberg, et. al. Standards Track [Page 96] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
A request may arrive with a maddr matching the proxy, but on a | |
port or transport different from that indicated in the URI. Such | |
a request needs to be forwarded to the proxy using the indicated | |
port and transport. | |
If the first value in the Route header field indicates this proxy, | |
the proxy MUST remove that value from the request. | |
16.5 Determining Request Targets | |
Next, the proxy calculates the target(s) of the request. The set of | |
targets will either be predetermined by the contents of the request | |
or will be obtained from an abstract location service. Each target | |
in the set is represented as a URI. | |
If the Request-URI of the request contains an maddr parameter, the | |
Request-URI MUST be placed into the target set as the only target | |
URI, and the proxy MUST proceed to Section 16.6. | |
If the domain of the Request-URI indicates a domain this element is | |
not responsible for, the Request-URI MUST be placed into the target | |
set as the only target, and the element MUST proceed to the task of | |
Request Forwarding (Section 16.6). | |
There are many circumstances in which a proxy might receive a | |
request for a domain it is not responsible for. A firewall proxy | |
handling outgoing calls (the way HTTP proxies handle outgoing | |
requests) is an example of where this is likely to occur. | |
If the target set for the request has not been predetermined as | |
described above, this implies that the element is responsible for the | |
domain in the Request-URI, and the element MAY use whatever mechanism | |
it desires to determine where to send the request. Any of these | |
mechanisms can be modeled as accessing an abstract Location Service. | |
This may consist of obtaining information from a location service | |
created by a SIP Registrar, reading a database, consulting a presence | |
server, utilizing other protocols, or simply performing an | |
algorithmic substitution on the Request-URI. When accessing the | |
location service constructed by a registrar, the Request-URI MUST | |
first be canonicalized as described in Section 10.3 before being used | |
as an index. The output of these mechanisms is used to construct the | |
target set. | |
If the Request-URI does not provide sufficient information for the | |
proxy to determine the target set, it SHOULD return a 485 (Ambiguous) | |
response. This response SHOULD contain a Contact header field | |
containing URIs of new addresses to be tried. For example, an INVITE | |
Rosenberg, et. al. Standards Track [Page 97] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
to sip:John.Smith@company.com may be ambiguous at a proxy whose | |
location service has multiple John Smiths listed. See Section | |
21.4.23 for details. | |
Any information in or about the request or the current environment of | |
the element MAY be used in the construction of the target set. For | |
instance, different sets may be constructed depending on contents or | |
the presence of header fields and bodies, the time of day of the | |
request's arrival, the interface on which the request arrived, | |
failure of previous requests, or even the element's current level of | |
utilization. | |
As potential targets are located through these services, their URIs | |
are added to the target set. Targets can only be placed in the | |
target set once. If a target URI is already present in the set | |
(based on the definition of equality for the URI type), it MUST NOT | |
be added again. | |
A proxy MUST NOT add additional targets to the target set if the | |
Request-URI of the original request does not indicate a resource this | |
proxy is responsible for. | |
A proxy can only change the Request-URI of a request during | |
forwarding if it is responsible for that URI. If the proxy is not | |
responsible for that URI, it will not recurse on 3xx or 416 | |
responses as described below. | |
If the Request-URI of the original request indicates a resource this | |
proxy is responsible for, the proxy MAY continue to add targets to | |
the set after beginning Request Forwarding. It MAY use any | |
information obtained during that processing to determine new targets. | |
For instance, a proxy may choose to incorporate contacts obtained in | |
a redirect response (3xx) into the target set. If a proxy uses a | |
dynamic source of information while building the target set (for | |
instance, if it consults a SIP Registrar), it SHOULD monitor that | |
source for the duration of processing the request. New locations | |
SHOULD be added to the target set as they become available. As | |
above, any given URI MUST NOT be added to the set more than once. | |
Allowing a URI to be added to the set only once reduces | |
unnecessary network traffic, and in the case of incorporating | |
contacts from redirect requests prevents infinite recursion. | |
For example, a trivial location service is a "no-op", where the | |
target URI is equal to the incoming request URI. The request is sent | |
to a specific next hop proxy for further processing. During request | |
Rosenberg, et. al. Standards Track [Page 98] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
forwarding of Section 16.6, Item 6, the identity of that next hop, | |
expressed as a SIP or SIPS URI, is inserted as the top-most Route | |
header field value into the request. | |
If the Request-URI indicates a resource at this proxy that does not | |
exist, the proxy MUST return a 404 (Not Found) response. | |
If the target set remains empty after applying all of the above, the | |
proxy MUST return an error response, which SHOULD be the 480 | |
(Temporarily Unavailable) response. | |
16.6 Request Forwarding | |
As soon as the target set is non-empty, a proxy MAY begin forwarding | |
the request. A stateful proxy MAY process the set in any order. It | |
MAY process multiple targets serially, allowing each client | |
transaction to complete before starting the next. It MAY start | |
client transactions with every target in parallel. It also MAY | |
arbitrarily divide the set into groups, processing the groups | |
serially and processing the targets in each group in parallel. | |
A common ordering mechanism is to use the qvalue parameter of targets | |
obtained from Contact header fields (see Section 20.10). Targets are | |
processed from highest qvalue to lowest. Targets with equal qvalues | |
may be processed in parallel. | |
A stateful proxy must have a mechanism to maintain the target set as | |
responses are received and associate the responses to each forwarded | |
request with the original request. For the purposes of this model, | |
this mechanism is a "response context" created by the proxy layer | |
before forwarding the first request. | |
For each target, the proxy forwards the request following these | |
steps: | |
1. Make a copy of the received request | |
2. Update the Request-URI | |
3. Update the Max-Forwards header field | |
4. Optionally add a Record-route header field value | |
5. Optionally add additional header fields | |
6. Postprocess routing information | |
7. Determine the next-hop address, port, and transport | |
Rosenberg, et. al. Standards Track [Page 99] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
8. Add a Via header field value | |
9. Add a Content-Length header field if necessary | |
10. Forward the new request | |
11. Set timer C | |
Each of these steps is detailed below: | |
1. Copy request | |
The proxy starts with a copy of the received request. The copy | |
MUST initially contain all of the header fields from the | |
received request. Fields not detailed in the processing | |
described below MUST NOT be removed. The copy SHOULD maintain | |
the ordering of the header fields as in the received request. | |
The proxy MUST NOT reorder field values with a common field | |
name (See Section 7.3.1). The proxy MUST NOT add to, modify, | |
or remove the message body. | |
An actual implementation need not perform a copy; the primary | |
requirement is that the processing for each next hop begin with | |
the same request. | |
2. Request-URI | |
The Request-URI in the copy's start line MUST be replaced with | |
the URI for this target. If the URI contains any parameters | |
not allowed in a Request-URI, they MUST be removed. | |
This is the essence of a proxy's role. This is the mechanism | |
through which a proxy routes a request toward its destination. | |
In some circumstances, the received Request-URI is placed into | |
the target set without being modified. For that target, the | |
replacement above is effectively a no-op. | |
3. Max-Forwards | |
If the copy contains a Max-Forwards header field, the proxy | |
MUST decrement its value by one (1). | |
If the copy does not contain a Max-Forwards header field, the | |
proxy MUST add one with a field value, which SHOULD be 70. | |
Some existing UAs will not provide a Max-Forwards header field | |
in a request. | |
Rosenberg, et. al. Standards Track [Page 100] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
4. Record-Route | |
If this proxy wishes to remain on the path of future requests | |
in a dialog created by this request (assuming the request | |
creates a dialog), it MUST insert a Record-Route header field | |
value into the copy before any existing Record-Route header | |
field values, even if a Route header field is already present. | |
Requests establishing a dialog may contain a preloaded Route | |
header field. | |
If this request is already part of a dialog, the proxy SHOULD | |
insert a Record-Route header field value if it wishes to remain | |
on the path of future requests in the dialog. In normal | |
endpoint operation as described in Section 12, these Record- | |
Route header field values will not have any effect on the route | |
sets used by the endpoints. | |
The proxy will remain on the path if it chooses to not insert a | |
Record-Route header field value into requests that are already | |
part of a dialog. However, it would be removed from the path | |
when an endpoint that has failed reconstitutes the dialog. | |
A proxy MAY insert a Record-Route header field value into any | |
request. If the request does not initiate a dialog, the | |
endpoints will ignore the value. See Section 12 for details on | |
how endpoints use the Record-Route header field values to | |
construct Route header fields. | |
Each proxy in the path of a request chooses whether to add a | |
Record-Route header field value independently - the presence of | |
a Record-Route header field in a request does not obligate this | |
proxy to add a value. | |
The URI placed in the Record-Route header field value MUST be a | |
SIP or SIPS URI. This URI MUST contain an lr parameter (see | |
Section 19.1.1). This URI MAY be different for each | |
destination the request is forwarded to. The URI SHOULD NOT | |
contain the transport parameter unless the proxy has knowledge | |
(such as in a private network) that the next downstream element | |
that will be in the path of subsequent requests supports that | |
transport. | |
The URI this proxy provides will be used by some other element | |
to make a routing decision. This proxy, in general, has no way | |
of knowing the capabilities of that element, so it must | |
restrict itself to the mandatory elements of a SIP | |
implementation: SIP URIs and either the TCP or UDP transports. | |
Rosenberg, et. al. Standards Track [Page 101] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The URI placed in the Record-Route header field MUST resolve to | |
the element inserting it (or a suitable stand-in) when the | |
server location procedures of [4] are applied to it, so that | |
subsequent requests reach the same SIP element. If the | |
Request-URI contains a SIPS URI, or the topmost Route header | |
field value (after the post processing of bullet 6) contains a | |
SIPS URI, the URI placed into the Record-Route header field | |
MUST be a SIPS URI. Furthermore, if the request was not | |
received over TLS, the proxy MUST insert a Record-Route header | |
field. In a similar fashion, a proxy that receives a request | |
over TLS, but generates a request without a SIPS URI in the | |
Request-URI or topmost Route header field value (after the post | |
processing of bullet 6), MUST insert a Record-Route header | |
field that is not a SIPS URI. | |
A proxy at a security perimeter must remain on the perimeter | |
throughout the dialog. | |
If the URI placed in the Record-Route header field needs to be | |
rewritten when it passes back through in a response, the URI | |
MUST be distinct enough to locate at that time. (The request | |
may spiral through this proxy, resulting in more than one | |
Record-Route header field value being added). Item 8 of | |
Section 16.7 recommends a mechanism to make the URI | |
sufficiently distinct. | |
The proxy MAY include parameters in the Record-Route header | |
field value. These will be echoed in some responses to the | |
request such as the 200 (OK) responses to INVITE. Such | |
parameters may be useful for keeping state in the message | |
rather than the proxy. | |
If a proxy needs to be in the path of any type of dialog (such | |
as one straddling a firewall), it SHOULD add a Record-Route | |
header field value to every request with a method it does not | |
understand since that method may have dialog semantics. | |
The URI a proxy places into a Record-Route header field is only | |
valid for the lifetime of any dialog created by the transaction | |
in which it occurs. A dialog-stateful proxy, for example, MAY | |
refuse to accept future requests with that value in the | |
Request-URI after the dialog has terminated. Non-dialog- | |
stateful proxies, of course, have no concept of when the dialog | |
has terminated, but they MAY encode enough information in the | |
value to compare it against the dialog identifier of future | |
requests and MAY reject requests not matching that information. | |
Endpoints MUST NOT use a URI obtained from a Record-Route | |
header field outside the dialog in which it was provided. See | |
Rosenberg, et. al. Standards Track [Page 102] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Section 12 for more information on an endpoint's use of | |
Record-Route header fields. | |
Record-routing may be required by certain services where the | |
proxy needs to observe all messages in a dialog. However, it | |
slows down processing and impairs scalability and thus proxies | |
should only record-route if required for a particular service. | |
The Record-Route process is designed to work for any SIP | |
request that initiates a dialog. INVITE is the only such | |
request in this specification, but extensions to the protocol | |
MAY define others. | |
5. Add Additional Header Fields | |
The proxy MAY add any other appropriate header fields to the | |
copy at this point. | |
6. Postprocess routing information | |
A proxy MAY have a local policy that mandates that a request | |
visit a specific set of proxies before being delivered to the | |
destination. A proxy MUST ensure that all such proxies are | |
loose routers. Generally, this can only be known with | |
certainty if the proxies are within the same administrative | |
domain. This set of proxies is represented by a set of URIs | |
(each of which contains the lr parameter). This set MUST be | |
pushed into the Route header field of the copy ahead of any | |
existing values, if present. If the Route header field is | |
absent, it MUST be added, containing that list of URIs. | |
If the proxy has a local policy that mandates that the request | |
visit one specific proxy, an alternative to pushing a Route | |
value into the Route header field is to bypass the forwarding | |
logic of item 10 below, and instead just send the request to | |
the address, port, and transport for that specific proxy. If | |
the request has a Route header field, this alternative MUST NOT | |
be used unless it is known that next hop proxy is a loose | |
router. Otherwise, this approach MAY be used, but the Route | |
insertion mechanism above is preferred for its robustness, | |
flexibility, generality and consistency of operation. | |
Furthermore, if the Request-URI contains a SIPS URI, TLS MUST | |
be used to communicate with that proxy. | |
If the copy contains a Route header field, the proxy MUST | |
inspect the URI in its first value. If that URI does not | |
contain an lr parameter, the proxy MUST modify the copy as | |
follows: | |
Rosenberg, et. al. Standards Track [Page 103] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
- The proxy MUST place the Request-URI into the Route header | |
field as the last value. | |
- The proxy MUST then place the first Route header field value | |
into the Request-URI and remove that value from the Route | |
header field. | |
Appending the Request-URI to the Route header field is part of | |
a mechanism used to pass the information in that Request-URI | |
through strict-routing elements. "Popping" the first Route | |
header field value into the Request-URI formats the message the | |
way a strict-routing element expects to receive it (with its | |
own URI in the Request-URI and the next location to visit in | |
the first Route header field value). | |
7. Determine Next-Hop Address, Port, and Transport | |
The proxy MAY have a local policy to send the request to a | |
specific IP address, port, and transport, independent of the | |
values of the Route and Request-URI. Such a policy MUST NOT be | |
used if the proxy is not certain that the IP address, port, and | |
transport correspond to a server that is a loose router. | |
However, this mechanism for sending the request through a | |
specific next hop is NOT RECOMMENDED; instead a Route header | |
field should be used for that purpose as described above. | |
In the absence of such an overriding mechanism, the proxy | |
applies the procedures listed in [4] as follows to determine | |
where to send the request. If the proxy has reformatted the | |
request to send to a strict-routing element as described in | |
step 6 above, the proxy MUST apply those procedures to the | |
Request-URI of the request. Otherwise, the proxy MUST apply | |
the procedures to the first value in the Route header field, if | |
present, else the Request-URI. The procedures will produce an | |
ordered set of (address, port, transport) tuples. | |
Independently of which URI is being used as input to the | |
procedures of [4], if the Request-URI specifies a SIPS | |
resource, the proxy MUST follow the procedures of [4] as if the | |
input URI were a SIPS URI. | |
As described in [4], the proxy MUST attempt to deliver the | |
message to the first tuple in that set, and proceed through the | |
set in order until the delivery attempt succeeds. | |
For each tuple attempted, the proxy MUST format the message as | |
appropriate for the tuple and send the request using a new | |
client transaction as detailed in steps 8 through 10. | |
Rosenberg, et. al. Standards Track [Page 104] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Since each attempt uses a new client transaction, it represents | |
a new branch. Thus, the branch parameter provided with the Via | |
header field inserted in step 8 MUST be different for each | |
attempt. | |
If the client transaction reports failure to send the request | |
or a timeout from its state machine, the proxy continues to the | |
next address in that ordered set. If the ordered set is | |
exhausted, the request cannot be forwarded to this element in | |
the target set. The proxy does not need to place anything in | |
the response context, but otherwise acts as if this element of | |
the target set returned a 408 (Request Timeout) final response. | |
8. Add a Via header field value | |
The proxy MUST insert a Via header field value into the copy | |
before the existing Via header field values. The construction | |
of this value follows the same guidelines of Section 8.1.1.7. | |
This implies that the proxy will compute its own branch | |
parameter, which will be globally unique for that branch, and | |
contain the requisite magic cookie. Note that this implies that | |
the branch parameter will be different for different instances | |
of a spiraled or looped request through a proxy. | |
Proxies choosing to detect loops have an additional constraint | |
in the value they use for construction of the branch parameter. | |
A proxy choosing to detect loops SHOULD create a branch | |
parameter separable into two parts by the implementation. The | |
first part MUST satisfy the constraints of Section 8.1.1.7 as | |
described above. The second is used to perform loop detection | |
and distinguish loops from spirals. | |
Loop detection is performed by verifying that, when a request | |
returns to a proxy, those fields having an impact on the | |
processing of the request have not changed. The value placed | |
in this part of the branch parameter SHOULD reflect all of | |
those fields (including any Route, Proxy-Require and Proxy- | |
Authorization header fields). This is to ensure that if the | |
request is routed back to the proxy and one of those fields | |
changes, it is treated as a spiral and not a loop (see Section | |
16.3). A common way to create this value is to compute a | |
cryptographic hash of the To tag, From tag, Call-ID header | |
field, the Request-URI of the request received (before | |
translation), the topmost Via header, and the sequence number | |
from the CSeq header field, in addition to any Proxy-Require | |
and Proxy-Authorization header fields that may be present. The | |
Rosenberg, et. al. Standards Track [Page 105] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
algorithm used to compute the hash is implementation-dependent, | |
but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a | |
reasonable choice. (Base64 is not permissible for a token.) | |
If a proxy wishes to detect loops, the "branch" parameter it | |
supplies MUST depend on all information affecting processing of | |
a request, including the incoming Request-URI and any header | |
fields affecting the request's admission or routing. This is | |
necessary to distinguish looped requests from requests whose | |
routing parameters have changed before returning to this | |
server. | |
The request method MUST NOT be included in the calculation of | |
the branch parameter. In particular, CANCEL and ACK requests | |
(for non-2xx responses) MUST have the same branch value as the | |
corresponding request they cancel or acknowledge. The branch | |
parameter is used in correlating those requests at the server | |
handling them (see Sections 17.2.3 and 9.2). | |
9. Add a Content-Length header field if necessary | |
If the request will be sent to the next hop using a stream- | |
based transport and the copy contains no Content-Length header | |
field, the proxy MUST insert one with the correct value for the | |
body of the request (see Section 20.14). | |
10. Forward Request | |
A stateful proxy MUST create a new client transaction for this | |
request as described in Section 17.1 and instructs the | |
transaction to send the request using the address, port and | |
transport determined in step 7. | |
11. Set timer C | |
In order to handle the case where an INVITE request never | |
generates a final response, the TU uses a timer which is called | |
timer C. Timer C MUST be set for each client transaction when | |
an INVITE request is proxied. The timer MUST be larger than 3 | |
minutes. Section 16.7 bullet 2 discusses how this timer is | |
updated with provisional responses, and Section 16.8 discusses | |
processing when it fires. | |
Rosenberg, et. al. Standards Track [Page 106] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
16.7 Response Processing | |
When a response is received by an element, it first tries to locate a | |
client transaction (Section 17.1.3) matching the response. If none | |
is found, the element MUST process the response (even if it is an | |
informational response) as a stateless proxy (described below). If a | |
match is found, the response is handed to the client transaction. | |
Forwarding responses for which a client transaction (or more | |
generally any knowledge of having sent an associated request) is | |
not found improves robustness. In particular, it ensures that | |
"late" 2xx responses to INVITE requests are forwarded properly. | |
As client transactions pass responses to the proxy layer, the | |
following processing MUST take place: | |
1. Find the appropriate response context | |
2. Update timer C for provisional responses | |
3. Remove the topmost Via | |
4. Add the response to the response context | |
5. Check to see if this response should be forwarded immediately | |
6. When necessary, choose the best final response from the | |
response context | |
If no final response has been forwarded after every client | |
transaction associated with the response context has been terminated, | |
the proxy must choose and forward the "best" response from those it | |
has seen so far. | |
The following processing MUST be performed on each response that is | |
forwarded. It is likely that more than one response to each request | |
will be forwarded: at least each provisional and one final response. | |
7. Aggregate authorization header field values if necessary | |
8. Optionally rewrite Record-Route header field values | |
9. Forward the response | |
10. Generate any necessary CANCEL requests | |
Rosenberg, et. al. Standards Track [Page 107] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Each of the above steps are detailed below: | |
1. Find Context | |
The proxy locates the "response context" it created before | |
forwarding the original request using the key described in | |
Section 16.6. The remaining processing steps take place in | |
this context. | |
2. Update timer C for provisional responses | |
For an INVITE transaction, if the response is a provisional | |
response with status codes 101 to 199 inclusive (i.e., anything | |
but 100), the proxy MUST reset timer C for that client | |
transaction. The timer MAY be reset to a different value, but | |
this value MUST be greater than 3 minutes. | |
3. Via | |
The proxy removes the topmost Via header field value from the | |
response. | |
If no Via header field values remain in the response, the | |
response was meant for this element and MUST NOT be forwarded. | |
The remainder of the processing described in this section is | |
not performed on this message, the UAC processing rules | |
described in Section 8.1.3 are followed instead (transport | |
layer processing has already occurred). | |
This will happen, for instance, when the element generates | |
CANCEL requests as described in Section 10. | |
4. Add response to context | |
Final responses received are stored in the response context | |
until a final response is generated on the server transaction | |
associated with this context. The response may be a candidate | |
for the best final response to be returned on that server | |
transaction. Information from this response may be needed in | |
forming the best response, even if this response is not chosen. | |
If the proxy chooses to recurse on any contacts in a 3xx | |
response by adding them to the target set, it MUST remove them | |
from the response before adding the response to the response | |
context. However, a proxy SHOULD NOT recurse to a non-SIPS URI | |
if the Request-URI of the original request was a SIPS URI. If | |
Rosenberg, et. al. Standards Track [Page 108] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
the proxy recurses on all of the contacts in a 3xx response, | |
the proxy SHOULD NOT add the resulting contactless response to | |
the response context. | |
Removing the contact before adding the response to the response | |
context prevents the next element upstream from retrying a | |
location this proxy has already attempted. | |
3xx responses may contain a mixture of SIP, SIPS, and non-SIP | |
URIs. A proxy may choose to recurse on the SIP and SIPS URIs | |
and place the remainder into the response context to be | |
returned, potentially in the final response. | |
If a proxy receives a 416 (Unsupported URI Scheme) response to | |
a request whose Request-URI scheme was not SIP, but the scheme | |
in the original received request was SIP or SIPS (that is, the | |
proxy changed the scheme from SIP or SIPS to something else | |
when it proxied a request), the proxy SHOULD add a new URI to | |
the target set. This URI SHOULD be a SIP URI version of the | |
non-SIP URI that was just tried. In the case of the tel URL, | |
this is accomplished by placing the telephone-subscriber part | |
of the tel URL into the user part of the SIP URI, and setting | |
the hostpart to the domain where the prior request was sent. | |
See Section 19.1.6 for more detail on forming SIP URIs from tel | |
URLs. | |
As with a 3xx response, if a proxy "recurses" on the 416 by | |
trying a SIP or SIPS URI instead, the 416 response SHOULD NOT | |
be added to the response context. | |
5. Check response for forwarding | |
Until a final response has been sent on the server transaction, | |
the following responses MUST be forwarded immediately: | |
- Any provisional response other than 100 (Trying) | |
- Any 2xx response | |
If a 6xx response is received, it is not immediately forwarded, | |
but the stateful proxy SHOULD cancel all client pending | |
transactions as described in Section 10, and it MUST NOT create | |
any new branches in this context. | |
This is a change from RFC 2543, which mandated that the proxy | |
was to forward the 6xx response immediately. For an INVITE | |
transaction, this approach had the problem that a 2xx response | |
could arrive on another branch, in which case the proxy would | |
Rosenberg, et. al. Standards Track [Page 109] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
have to forward the 2xx. The result was that the UAC could | |
receive a 6xx response followed by a 2xx response, which should | |
never be allowed to happen. Under the new rules, upon | |
receiving a 6xx, a proxy will issue a CANCEL request, which | |
will generally result in 487 responses from all outstanding | |
client transactions, and then at that point the 6xx is | |
forwarded upstream. | |
After a final response has been sent on the server transaction, | |
the following responses MUST be forwarded immediately: | |
- Any 2xx response to an INVITE request | |
A stateful proxy MUST NOT immediately forward any other | |
responses. In particular, a stateful proxy MUST NOT forward | |
any 100 (Trying) response. Those responses that are candidates | |
for forwarding later as the "best" response have been gathered | |
as described in step "Add Response to Context". | |
Any response chosen for immediate forwarding MUST be processed | |
as described in steps "Aggregate Authorization Header Field | |
Values" through "Record-Route". | |
This step, combined with the next, ensures that a stateful | |
proxy will forward exactly one final response to a non-INVITE | |
request, and either exactly one non-2xx response or one or more | |
2xx responses to an INVITE request. | |
6. Choosing the best response | |
A stateful proxy MUST send a final response to a response | |
context's server transaction if no final responses have been | |
immediately forwarded by the above rules and all client | |
transactions in this response context have been terminated. | |
The stateful proxy MUST choose the "best" final response among | |
those received and stored in the response context. | |
If there are no final responses in the context, the proxy MUST | |
send a 408 (Request Timeout) response to the server | |
transaction. | |
Otherwise, the proxy MUST forward a response from the responses | |
stored in the response context. It MUST choose from the 6xx | |
class responses if any exist in the context. If no 6xx class | |
responses are present, the proxy SHOULD choose from the lowest | |
response class stored in the response context. The proxy MAY | |
select any response within that chosen class. The proxy SHOULD | |
Rosenberg, et. al. Standards Track [Page 110] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
give preference to responses that provide information affecting | |
resubmission of this request, such as 401, 407, 415, 420, and | |
484 if the 4xx class is chosen. | |
A proxy which receives a 503 (Service Unavailable) response | |
SHOULD NOT forward it upstream unless it can determine that any | |
subsequent requests it might proxy will also generate a 503. | |
In other words, forwarding a 503 means that the proxy knows it | |
cannot service any requests, not just the one for the Request- | |
URI in the request which generated the 503. If the only | |
response that was received is a 503, the proxy SHOULD generate | |
a 500 response and forward that upstream. | |
The forwarded response MUST be processed as described in steps | |
"Aggregate Authorization Header Field Values" through "Record- | |
Route". | |
For example, if a proxy forwarded a request to 4 locations, and | |
received 503, 407, 501, and 404 responses, it may choose to | |
forward the 407 (Proxy Authentication Required) response. | |
1xx and 2xx responses may be involved in the establishment of | |
dialogs. When a request does not contain a To tag, the To tag | |
in the response is used by the UAC to distinguish multiple | |
responses to a dialog creating request. A proxy MUST NOT | |
insert a tag into the To header field of a 1xx or 2xx response | |
if the request did not contain one. A proxy MUST NOT modify | |
the tag in the To header field of a 1xx or 2xx response. | |
Since a proxy may not insert a tag into the To header field of | |
a 1xx response to a request that did not contain one, it cannot | |
issue non-100 provisional responses on its own. However, it | |
can branch the request to a UAS sharing the same element as the | |
proxy. This UAS can return its own provisional responses, | |
entering into an early dialog with the initiator of the | |
request. The UAS does not have to be a discreet process from | |
the proxy. It could be a virtual UAS implemented in the same | |
code space as the proxy. | |
3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx | |
response, the element is effectively acting as a UAS, issuing | |
its own response, usually based on the responses received from | |
downstream elements. An element SHOULD preserve the To tag | |
when simply forwarding a 3-6xx response to a request that did | |
not contain a To tag. | |
A proxy MUST NOT modify the To tag in any forwarded response to | |
a request that contains a To tag. | |
Rosenberg, et. al. Standards Track [Page 111] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
While it makes no difference to the upstream elements if the | |
proxy replaced the To tag in a forwarded 3-6xx response, | |
preserving the original tag may assist with debugging. | |
When the proxy is aggregating information from several | |
responses, choosing a To tag from among them is arbitrary, and | |
generating a new To tag may make debugging easier. This | |
happens, for instance, when combining 401 (Unauthorized) and | |
407 (Proxy Authentication Required) challenges, or combining | |
Contact values from unencrypted and unauthenticated 3xx | |
responses. | |
7. Aggregate Authorization Header Field Values | |
If the selected response is a 401 (Unauthorized) or 407 (Proxy | |
Authentication Required), the proxy MUST collect any WWW- | |
Authenticate and Proxy-Authenticate header field values from | |
all other 401 (Unauthorized) and 407 (Proxy Authentication | |
Required) responses received so far in this response context | |
and add them to this response without modification before | |
forwarding. The resulting 401 (Unauthorized) or 407 (Proxy | |
Authentication Required) response could have several WWW- | |
Authenticate AND Proxy-Authenticate header field values. | |
This is necessary because any or all of the destinations the | |
request was forwarded to may have requested credentials. The | |
client needs to receive all of those challenges and supply | |
credentials for each of them when it retries the request. | |
Motivation for this behavior is provided in Section 26. | |
8. Record-Route | |
If the selected response contains a Record-Route header field | |
value originally provided by this proxy, the proxy MAY choose | |
to rewrite the value before forwarding the response. This | |
allows the proxy to provide different URIs for itself to the | |
next upstream and downstream elements. A proxy may choose to | |
use this mechanism for any reason. For instance, it is useful | |
for multi-homed hosts. | |
If the proxy received the request over TLS, and sent it out | |
over a non-TLS connection, the proxy MUST rewrite the URI in | |
the Record-Route header field to be a SIPS URI. If the proxy | |
received the request over a non-TLS connection, and sent it out | |
over TLS, the proxy MUST rewrite the URI in the Record-Route | |
header field to be a SIP URI. | |
Rosenberg, et. al. Standards Track [Page 112] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The new URI provided by the proxy MUST satisfy the same | |
constraints on URIs placed in Record-Route header fields in | |
requests (see Step 4 of Section 16.6) with the following | |
modifications: | |
The URI SHOULD NOT contain the transport parameter unless the | |
proxy has knowledge that the next upstream (as opposed to | |
downstream) element that will be in the path of subsequent | |
requests supports that transport. | |
When a proxy does decide to modify the Record-Route header | |
field in the response, one of the operations it performs is | |
locating the Record-Route value that it had inserted. If the | |
request spiraled, and the proxy inserted a Record-Route value | |
in each iteration of the spiral, locating the correct value in | |
the response (which must be the proper iteration in the reverse | |
direction) is tricky. The rules above recommend that a proxy | |
wishing to rewrite Record-Route header field values insert | |
sufficiently distinct URIs into the Record-Route header field | |
so that the right one may be selected for rewriting. A | |
RECOMMENDED mechanism to achieve this is for the proxy to | |
append a unique identifier for the proxy instance to the user | |
portion of the URI. | |
When the response arrives, the proxy modifies the first | |
Record-Route whose identifier matches the proxy instance. The | |
modification results in a URI without this piece of data | |
appended to the user portion of the URI. Upon the next | |
iteration, the same algorithm (find the topmost Record-Route | |
header field value with the parameter) will correctly extract | |
the next Record-Route header field value inserted by that | |
proxy. | |
Not every response to a request to which a proxy adds a | |
Record-Route header field value will contain a Record-Route | |
header field. If the response does contain a Record-Route | |
header field, it will contain the value the proxy added. | |
9. Forward response | |
After performing the processing described in steps "Aggregate | |
Authorization Header Field Values" through "Record-Route", the | |
proxy MAY perform any feature specific manipulations on the | |
selected response. The proxy MUST NOT add to, modify, or | |
remove the message body. Unless otherwise specified, the proxy | |
MUST NOT remove any header field values other than the Via | |
header field value discussed in Section 16.7 Item 3. In | |
particular, the proxy MUST NOT remove any "received" parameter | |
Rosenberg, et. al. Standards Track [Page 113] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
it may have added to the next Via header field value while | |
processing the request associated with this response. The | |
proxy MUST pass the response to the server transaction | |
associated with the response context. This will result in the | |
response being sent to the location now indicated in the | |
topmost Via header field value. If the server transaction is | |
no longer available to handle the transmission, the element | |
MUST forward the response statelessly by sending it to the | |
server transport. The server transaction might indicate | |
failure to send the response or signal a timeout in its state | |
machine. These errors would be logged for diagnostic purposes | |
as appropriate, but the protocol requires no remedial action | |
from the proxy. | |
The proxy MUST maintain the response context until all of its | |
associated transactions have been terminated, even after | |
forwarding a final response. | |
10. Generate CANCELs | |
If the forwarded response was a final response, the proxy MUST | |
generate a CANCEL request for all pending client transactions | |
associated with this response context. A proxy SHOULD also | |
generate a CANCEL request for all pending client transactions | |
associated with this response context when it receives a 6xx | |
response. A pending client transaction is one that has | |
received a provisional response, but no final response (it is | |
in the proceeding state) and has not had an associated CANCEL | |
generated for it. Generating CANCEL requests is described in | |
Section 9.1. | |
The requirement to CANCEL pending client transactions upon | |
forwarding a final response does not guarantee that an endpoint | |
will not receive multiple 200 (OK) responses to an INVITE. 200 | |
(OK) responses on more than one branch may be generated before | |
the CANCEL requests can be sent and processed. Further, it is | |
reasonable to expect that a future extension may override this | |
requirement to issue CANCEL requests. | |
16.8 Processing Timer C | |
If timer C should fire, the proxy MUST either reset the timer with | |
any value it chooses, or terminate the client transaction. If the | |
client transaction has received a provisional response, the proxy | |
MUST generate a CANCEL request matching that transaction. If the | |
client transaction has not received a provisional response, the proxy | |
MUST behave as if the transaction received a 408 (Request Timeout) | |
response. | |
Rosenberg, et. al. Standards Track [Page 114] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Allowing the proxy to reset the timer allows the proxy to dynamically | |
extend the transaction's lifetime based on current conditions (such | |
as utilization) when the timer fires. | |
16.9 Handling Transport Errors | |
If the transport layer notifies a proxy of an error when it tries to | |
forward a request (see Section 18.4), the proxy MUST behave as if the | |
forwarded request received a 503 (Service Unavailable) response. | |
If the proxy is notified of an error when forwarding a response, it | |
drops the response. The proxy SHOULD NOT cancel any outstanding | |
client transactions associated with this response context due to this | |
notification. | |
If a proxy cancels its outstanding client transactions, a single | |
malicious or misbehaving client can cause all transactions to fail | |
through its Via header field. | |
16.10 CANCEL Processing | |
A stateful proxy MAY generate a CANCEL to any other request it has | |
generated at any time (subject to receiving a provisional response to | |
that request as described in section 9.1). A proxy MUST cancel any | |
pending client transactions associated with a response context when | |
it receives a matching CANCEL request. | |
A stateful proxy MAY generate CANCEL requests for pending INVITE | |
client transactions based on the period specified in the INVITE's | |
Expires header field elapsing. However, this is generally | |
unnecessary since the endpoints involved will take care of signaling | |
the end of the transaction. | |
While a CANCEL request is handled in a stateful proxy by its own | |
server transaction, a new response context is not created for it. | |
Instead, the proxy layer searches its existing response contexts for | |
the server transaction handling the request associated with this | |
CANCEL. If a matching response context is found, the element MUST | |
immediately return a 200 (OK) response to the CANCEL request. In | |
this case, the element is acting as a user agent server as defined in | |
Section 8.2. Furthermore, the element MUST generate CANCEL requests | |
for all pending client transactions in the context as described in | |
Section 16.7 step 10. | |
If a response context is not found, the element does not have any | |
knowledge of the request to apply the CANCEL to. It MUST statelessly | |
forward the CANCEL request (it may have statelessly forwarded the | |
associated request previously). | |
Rosenberg, et. al. Standards Track [Page 115] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
16.11 Stateless Proxy | |
When acting statelessly, a proxy is a simple message forwarder. Much | |
of the processing performed when acting statelessly is the same as | |
when behaving statefully. The differences are detailed here. | |
A stateless proxy does not have any notion of a transaction, or of | |
the response context used to describe stateful proxy behavior. | |
Instead, the stateless proxy takes messages, both requests and | |
responses, directly from the transport layer (See section 18). As a | |
result, stateless proxies do not retransmit messages on their own. | |
They do, however, forward all retransmissions they receive (they do | |
not have the ability to distinguish a retransmission from the | |
original message). Furthermore, when handling a request statelessly, | |
an element MUST NOT generate its own 100 (Trying) or any other | |
provisional response. | |
A stateless proxy MUST validate a request as described in Section | |
16.3 | |
A stateless proxy MUST follow the request processing steps described | |
in Sections 16.4 through 16.5 with the following exception: | |
o A stateless proxy MUST choose one and only one target from the | |
target set. This choice MUST only rely on fields in the | |
message and time-invariant properties of the server. In | |
particular, a retransmitted request MUST be forwarded to the | |
same destination each time it is processed. Furthermore, | |
CANCEL and non-Routed ACK requests MUST generate the same | |
choice as their associated INVITE. | |
A stateless proxy MUST follow the request processing steps described | |
in Section 16.6 with the following exceptions: | |
o The requirement for unique branch IDs across space and time | |
applies to stateless proxies as well. However, a stateless | |
proxy cannot simply use a random number generator to compute | |
the first component of the branch ID, as described in Section | |
16.6 bullet 8. This is because retransmissions of a request | |
need to have the same value, and a stateless proxy cannot tell | |
a retransmission from the original request. Therefore, the | |
component of the branch parameter that makes it unique MUST be | |
the same each time a retransmitted request is forwarded. Thus | |
for a stateless proxy, the branch parameter MUST be computed as | |
a combinatoric function of message parameters which are | |
invariant on retransmission. | |
Rosenberg, et. al. Standards Track [Page 116] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The stateless proxy MAY use any technique it likes to guarantee | |
uniqueness of its branch IDs across transactions. However, the | |
following procedure is RECOMMENDED. The proxy examines the | |
branch ID in the topmost Via header field of the received | |
request. If it begins with the magic cookie, the first | |
component of the branch ID of the outgoing request is computed | |
as a hash of the received branch ID. Otherwise, the first | |
component of the branch ID is computed as a hash of the topmost | |
Via, the tag in the To header field, the tag in the From header | |
field, the Call-ID header field, the CSeq number (but not | |
method), and the Request-URI from the received request. One of | |
these fields will always vary across two different | |
transactions. | |
o All other message transformations specified in Section 16.6 | |
MUST result in the same transformation of a retransmitted | |
request. In particular, if the proxy inserts a Record-Route | |
value or pushes URIs into the Route header field, it MUST place | |
the same values in retransmissions of the request. As for the | |
Via branch parameter, this implies that the transformations | |
MUST be based on time-invariant configuration or | |
retransmission-invariant properties of the request. | |
o A stateless proxy determines where to forward the request as | |
described for stateful proxies in Section 16.6 Item 10. The | |
request is sent directly to the transport layer instead of | |
through a client transaction. | |
Since a stateless proxy must forward retransmitted requests to | |
the same destination and add identical branch parameters to | |
each of them, it can only use information from the message | |
itself and time-invariant configuration data for those | |
calculations. If the configuration state is not time-invariant | |
(for example, if a routing table is updated) any requests that | |
could be affected by the change may not be forwarded | |
statelessly during an interval equal to the transaction timeout | |
window before or after the change. The method of processing | |
the affected requests in that interval is an implementation | |
decision. A common solution is to forward them transaction | |
statefully. | |
Stateless proxies MUST NOT perform special processing for CANCEL | |
requests. They are processed by the above rules as any other | |
requests. In particular, a stateless proxy applies the same Route | |
header field processing to CANCEL requests that it applies to any | |
other request. | |
Rosenberg, et. al. Standards Track [Page 117] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Response processing as described in Section 16.7 does not apply to a | |
proxy behaving statelessly. When a response arrives at a stateless | |
proxy, the proxy MUST inspect the sent-by value in the first | |
(topmost) Via header field value. If that address matches the proxy, | |
(it equals a value this proxy has inserted into previous requests) | |
the proxy MUST remove that header field value from the response and | |
forward the result to the location indicated in the next Via header | |
field value. The proxy MUST NOT add to, modify, or remove the | |
message body. Unless specified otherwise, the proxy MUST NOT remove | |
any other header field values. If the address does not match the | |
proxy, the message MUST be silently discarded. | |
16.12 Summary of Proxy Route Processing | |
In the absence of local policy to the contrary, the processing a | |
proxy performs on a request containing a Route header field can be | |
summarized in the following steps. | |
1. The proxy will inspect the Request-URI. If it indicates a | |
resource owned by this proxy, the proxy will replace it with | |
the results of running a location service. Otherwise, the | |
proxy will not change the Request-URI. | |
2. The proxy will inspect the URI in the topmost Route header | |
field value. If it indicates this proxy, the proxy removes it | |
from the Route header field (this route node has been | |
reached). | |
3. The proxy will forward the request to the resource indicated | |
by the URI in the topmost Route header field value or in the | |
Request-URI if no Route header field is present. The proxy | |
determines the address, port and transport to use when | |
forwarding the request by applying the procedures in [4] to | |
that URI. | |
If no strict-routing elements are encountered on the path of the | |
request, the Request-URI will always indicate the target of the | |
request. | |
16.12.1 Examples | |
16.12.1.1 Basic SIP Trapezoid | |
This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with | |
both proxies record-routing. Here is the flow. | |
Rosenberg, et. al. Standards Track [Page 118] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
U1 sends: | |
INVITE sip:callee@domain.com SIP/2.0 | |
Contact: sip:caller@u1.example.com | |
to P1. P1 is an outbound proxy. P1 is not responsible for | |
domain.com, so it looks it up in DNS and sends it there. It also | |
adds a Record-Route header field value: | |
INVITE sip:callee@domain.com SIP/2.0 | |
Contact: sip:caller@u1.example.com | |
Record-Route: <sip:p1.example.com;lr> | |
P2 gets this. It is responsible for domain.com so it runs a location | |
service and rewrites the Request-URI. It also adds a Record-Route | |
header field value. There is no Route header field, so it resolves | |
the new Request-URI to determine where to send the request: | |
INVITE sip:callee@u2.domain.com SIP/2.0 | |
Contact: sip:caller@u1.example.com | |
Record-Route: <sip:p2.domain.com;lr> | |
Record-Route: <sip:p1.example.com;lr> | |
The callee at u2.domain.com gets this and responds with a 200 OK: | |
SIP/2.0 200 OK | |
Contact: sip:callee@u2.domain.com | |
Record-Route: <sip:p2.domain.com;lr> | |
Record-Route: <sip:p1.example.com;lr> | |
The callee at u2 also sets its dialog state's remote target URI to | |
sip:caller@u1.example.com and its route set to: | |
(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>) | |
This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its | |
dialog state's remote target URI to sip:callee@u2.domain.com and its | |
route set to: | |
(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>) | |
Since all the route set elements contain the lr parameter, U1 | |
constructs the following BYE request: | |
BYE sip:callee@u2.domain.com SIP/2.0 | |
Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr> | |
Rosenberg, et. al. Standards Track [Page 119] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
As any other element (including proxies) would do, it resolves the | |
URI in the topmost Route header field value using DNS to determine | |
where to send the request. This goes to P1. P1 notices that it is | |
not responsible for the resource indicated in the Request-URI so it | |
doesn't change it. It does see that it is the first value in the | |
Route header field, so it removes that value, and forwards the | |
request to P2: | |
BYE sip:callee@u2.domain.com SIP/2.0 | |
Route: <sip:p2.domain.com;lr> | |
P2 also notices it is not responsible for the resource indicated by | |
the Request-URI (it is responsible for domain.com, not | |
u2.domain.com), so it doesn't change it. It does see itself in the | |
first Route header field value, so it removes it and forwards the | |
following to u2.domain.com based on a DNS lookup against the | |
Request-URI: | |
BYE sip:callee@u2.domain.com SIP/2.0 | |
16.12.1.2 Traversing a Strict-Routing Proxy | |
In this scenario, a dialog is established across four proxies, each | |
of which adds Record-Route header field values. The third proxy | |
implements the strict-routing procedures specified in RFC 2543 and | |
many works in progress. | |
U1->P1->P2->P3->P4->U2 | |
The INVITE arriving at U2 contains: | |
INVITE sip:callee@u2.domain.com SIP/2.0 | |
Contact: sip:caller@u1.example.com | |
Record-Route: <sip:p4.domain.com;lr> | |
Record-Route: <sip:p3.middle.com> | |
Record-Route: <sip:p2.example.com;lr> | |
Record-Route: <sip:p1.example.com;lr> | |
Which U2 responds to with a 200 OK. Later, U2 sends the following | |
BYE request to P4 based on the first Route header field value. | |
BYE sip:caller@u1.example.com SIP/2.0 | |
Route: <sip:p4.domain.com;lr> | |
Route: <sip:p3.middle.com> | |
Route: <sip:p2.example.com;lr> | |
Route: <sip:p1.example.com;lr> | |
Rosenberg, et. al. Standards Track [Page 120] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
P4 is not responsible for the resource indicated in the Request-URI | |
so it will leave it alone. It notices that it is the element in the | |
first Route header field value so it removes it. It then prepares to | |
send the request based on the now first Route header field value of | |
sip:p3.middle.com, but it notices that this URI does not contain the | |
lr parameter, so before sending, it reformats the request to be: | |
BYE sip:p3.middle.com SIP/2.0 | |
Route: <sip:p2.example.com;lr> | |
Route: <sip:p1.example.com;lr> | |
Route: <sip:caller@u1.example.com> | |
P3 is a strict router, so it forwards the following to P2: | |
BYE sip:p2.example.com;lr SIP/2.0 | |
Route: <sip:p1.example.com;lr> | |
Route: <sip:caller@u1.example.com> | |
P2 sees the request-URI is a value it placed into a Record-Route | |
header field, so before further processing, it rewrites the request | |
to be: | |
BYE sip:caller@u1.example.com SIP/2.0 | |
Route: <sip:p1.example.com;lr> | |
P2 is not responsible for u1.example.com, so it sends the request to | |
P1 based on the resolution of the Route header field value. | |
P1 notices itself in the topmost Route header field value, so it | |
removes it, resulting in: | |
BYE sip:caller@u1.example.com SIP/2.0 | |
Since P1 is not responsible for u1.example.com and there is no Route | |
header field, P1 will forward the request to u1.example.com based on | |
the Request-URI. | |
16.12.1.3 Rewriting Record-Route Header Field Values | |
In this scenario, U1 and U2 are in different private namespaces and | |
they enter a dialog through a proxy P1, which acts as a gateway | |
between the namespaces. | |
U1->P1->U2 | |
Rosenberg, et. al. Standards Track [Page 121] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
U1 sends: | |
INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 | |
Contact: <sip:caller@u1.leftprivatespace.com> | |
P1 uses its location service and sends the following to U2: | |
INVITE sip:callee@rightprivatespace.com SIP/2.0 | |
Contact: <sip:caller@u1.leftprivatespace.com> | |
Record-Route: <sip:gateway.rightprivatespace.com;lr> | |
U2 sends this 200 (OK) back to P1: | |
SIP/2.0 200 OK | |
Contact: <sip:callee@u2.rightprivatespace.com> | |
Record-Route: <sip:gateway.rightprivatespace.com;lr> | |
P1 rewrites its Record-Route header parameter to provide a value that | |
U1 will find useful, and sends the following to U1: | |
SIP/2.0 200 OK | |
Contact: <sip:callee@u2.rightprivatespace.com> | |
Record-Route: <sip:gateway.leftprivatespace.com;lr> | |
Later, U1 sends the following BYE request to P1: | |
BYE sip:callee@u2.rightprivatespace.com SIP/2.0 | |
Route: <sip:gateway.leftprivatespace.com;lr> | |
which P1 forwards to U2 as: | |
BYE sip:callee@u2.rightprivatespace.com SIP/2.0 | |
17 Transactions | |
SIP is a transactional protocol: interactions between components take | |
place in a series of independent message exchanges. Specifically, a | |
SIP transaction consists of a single request and any responses to | |
that request, which include zero or more provisional responses and | |
one or more final responses. In the case of a transaction where the | |
request was an INVITE (known as an INVITE transaction), the | |
transaction also includes the ACK only if the final response was not | |
a 2xx response. If the response was a 2xx, the ACK is not considered | |
part of the transaction. | |
The reason for this separation is rooted in the importance of | |
delivering all 200 (OK) responses to an INVITE to the UAC. To | |
deliver them all to the UAC, the UAS alone takes responsibility | |
Rosenberg, et. al. Standards Track [Page 122] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
for retransmitting them (see Section 13.3.1.4), and the UAC alone | |
takes responsibility for acknowledging them with ACK (see Section | |
13.2.2.4). Since this ACK is retransmitted only by the UAC, it is | |
effectively considered its own transaction. | |
Transactions have a client side and a server side. The client side | |
is known as a client transaction and the server side as a server | |
transaction. The client transaction sends the request, and the | |
server transaction sends the response. The client and server | |
transactions are logical functions that are embedded in any number of | |
elements. Specifically, they exist within user agents and stateful | |
proxy servers. Consider the example in Section 4. In this example, | |
the UAC executes the client transaction, and its outbound proxy | |
executes the server transaction. The outbound proxy also executes a | |
client transaction, which sends the request to a server transaction | |
in the inbound proxy. That proxy also executes a client transaction, | |
which in turn sends the request to a server transaction in the UAS. | |
This is shown in Figure 4. | |
+---------+ +---------+ +---------+ +---------+ | |
| +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | | |
| |C||------->||S| |C||------->||S| |C||------->||S| | | |
| |l|| ||e| |l|| ||e| |l|| ||e| | | |
| |i|| ||r| |i|| ||r| |i|| ||r| | | |
| |e|| ||v| |e|| ||v| |e|| ||v| | | |
| |n|| ||e| |n|| ||e| |n|| ||e| | | |
| |t|| ||r| |t|| ||r| |t|| ||r| | | |
| | || || | | || || | | || || | | | |
| |T|| ||T| |T|| ||T| |T|| ||T| | | |
| |r|| ||r| |r|| ||r| |r|| ||r| | | |
| |a|| ||a| |a|| ||a| |a|| ||a| | | |
| |n|| ||n| |n|| ||n| |n|| ||n| | | |
| |s||Response||s| |s||Response||s| |s||Response||s| | | |
| +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | | |
+---------+ +---------+ +---------+ +---------+ | |
UAC Outbound Inbound UAS | |
Proxy Proxy | |
Figure 4: Transaction relationships | |
A stateless proxy does not contain a client or server transaction. | |
The transaction exists between the UA or stateful proxy on one side, | |
and the UA or stateful proxy on the other side. As far as SIP | |
transactions are concerned, stateless proxies are effectively | |
transparent. The purpose of the client transaction is to receive a | |
request from the element in which the client is embedded (call this | |
element the "Transaction User" or TU; it can be a UA or a stateful | |
proxy), and reliably deliver the request to a server transaction. | |
Rosenberg, et. al. Standards Track [Page 123] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The client transaction is also responsible for receiving responses | |
and delivering them to the TU, filtering out any response | |
retransmissions or disallowed responses (such as a response to ACK). | |
Additionally, in the case of an INVITE request, the client | |
transaction is responsible for generating the ACK request for any | |
final response accepting a 2xx response. | |
Similarly, the purpose of the server transaction is to receive | |
requests from the transport layer and deliver them to the TU. The | |
server transaction filters any request retransmissions from the | |
network. The server transaction accepts responses from the TU and | |
delivers them to the transport layer for transmission over the | |
network. In the case of an INVITE transaction, it absorbs the ACK | |
request for any final response excepting a 2xx response. | |
The 2xx response and its ACK receive special treatment. This | |
response is retransmitted only by a UAS, and its ACK generated only | |
by the UAC. This end-to-end treatment is needed so that a caller | |
knows the entire set of users that have accepted the call. Because | |
of this special handling, retransmissions of the 2xx response are | |
handled by the UA core, not the transaction layer. Similarly, | |
generation of the ACK for the 2xx is handled by the UA core. Each | |
proxy along the path merely forwards each 2xx response to INVITE and | |
its corresponding ACK. | |
17.1 Client Transaction | |
The client transaction provides its functionality through the | |
maintenance of a state machine. | |
The TU communicates with the client transaction through a simple | |
interface. When the TU wishes to initiate a new transaction, it | |
creates a client transaction and passes it the SIP request to send | |
and an IP address, port, and transport to which to send it. The | |
client transaction begins execution of its state machine. Valid | |
responses are passed up to the TU from the client transaction. | |
There are two types of client transaction state machines, depending | |
on the method of the request passed by the TU. One handles client | |
transactions for INVITE requests. This type of machine is referred | |
to as an INVITE client transaction. Another type handles client | |
transactions for all requests except INVITE and ACK. This is | |
referred to as a non-INVITE client transaction. There is no client | |
transaction for ACK. If the TU wishes to send an ACK, it passes one | |
directly to the transport layer for transmission. | |
Rosenberg, et. al. Standards Track [Page 124] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The INVITE transaction is different from those of other methods | |
because of its extended duration. Normally, human input is required | |
in order to respond to an INVITE. The long delays expected for | |
sending a response argue for a three-way handshake. On the other | |
hand, requests of other methods are expected to complete rapidly. | |
Because of the non-INVITE transaction's reliance on a two-way | |
handshake, TUs SHOULD respond immediately to non-INVITE requests. | |
17.1.1 INVITE Client Transaction | |
17.1.1.1 Overview of INVITE Transaction | |
The INVITE transaction consists of a three-way handshake. The client | |
transaction sends an INVITE, the server transaction sends responses, | |
and the client transaction sends an ACK. For unreliable transports | |
(such as UDP), the client transaction retransmits requests at an | |
interval that starts at T1 seconds and doubles after every | |
retransmission. T1 is an estimate of the round-trip time (RTT), and | |
it defaults to 500 ms. Nearly all of the transaction timers | |
described here scale with T1, and changing T1 adjusts their values. | |
The request is not retransmitted over reliable transports. After | |
receiving a 1xx response, any retransmissions cease altogether, and | |
the client waits for further responses. The server transaction can | |
send additional 1xx responses, which are not transmitted reliably by | |
the server transaction. Eventually, the server transaction decides | |
to send a final response. For unreliable transports, that response | |
is retransmitted periodically, and for reliable transports, it is | |
sent once. For each final response that is received at the client | |
transaction, the client transaction sends an ACK, the purpose of | |
which is to quench retransmissions of the response. | |
17.1.1.2 Formal Description | |
The state machine for the INVITE client transaction is shown in | |
Figure 5. The initial state, "calling", MUST be entered when the TU | |
initiates a new client transaction with an INVITE request. The | |
client transaction MUST pass the request to the transport layer for | |
transmission (see Section 18). If an unreliable transport is being | |
used, the client transaction MUST start timer A with a value of T1. | |
If a reliable transport is being used, the client transaction SHOULD | |
NOT start timer A (Timer A controls request retransmissions). For | |
any transport, the client transaction MUST start timer B with a value | |
of 64*T1 seconds (Timer B controls transaction timeouts). | |
When timer A fires, the client transaction MUST retransmit the | |
request by passing it to the transport layer, and MUST reset the | |
timer with a value of 2*T1. The formal definition of retransmit | |
Rosenberg, et. al. Standards Track [Page 125] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
within the context of the transaction layer is to take the message | |
previously sent to the transport layer and pass it to the transport | |
layer once more. | |
When timer A fires 2*T1 seconds later, the request MUST be | |
retransmitted again (assuming the client transaction is still in this | |
state). This process MUST continue so that the request is | |
retransmitted with intervals that double after each transmission. | |
These retransmissions SHOULD only be done while the client | |
transaction is in the "calling" state. | |
The default value for T1 is 500 ms. T1 is an estimate of the RTT | |
between the client and server transactions. Elements MAY (though it | |
is NOT RECOMMENDED) use smaller values of T1 within closed, private | |
networks that do not permit general Internet connection. T1 MAY be | |
chosen larger, and this is RECOMMENDED if it is known in advance | |
(such as on high latency access links) that the RTT is larger. | |
Whatever the value of T1, the exponential backoffs on retransmissions | |
described in this section MUST be used. | |
If the client transaction is still in the "Calling" state when timer | |
B fires, the client transaction SHOULD inform the TU that a timeout | |
has occurred. The client transaction MUST NOT generate an ACK. The | |
value of 64*T1 is equal to the amount of time required to send seven | |
requests in the case of an unreliable transport. | |
If the client transaction receives a provisional response while in | |
the "Calling" state, it transitions to the "Proceeding" state. In the | |
"Proceeding" state, the client transaction SHOULD NOT retransmit the | |
request any longer. Furthermore, the provisional response MUST be | |
passed to the TU. Any further provisional responses MUST be passed | |
up to the TU while in the "Proceeding" state. | |
When in either the "Calling" or "Proceeding" states, reception of a | |
response with status code from 300-699 MUST cause the client | |
transaction to transition to "Completed". The client transaction | |
MUST pass the received response up to the TU, and the client | |
transaction MUST generate an ACK request, even if the transport is | |
reliable (guidelines for constructing the ACK from the response are | |
given in Section 17.1.1.3) and then pass the ACK to the transport | |
layer for transmission. The ACK MUST be sent to the same address, | |
port, and transport to which the original request was sent. The | |
client transaction SHOULD start timer D when it enters the | |
"Completed" state, with a value of at least 32 seconds for unreliable | |
transports, and a value of zero seconds for reliable transports. | |
Timer D reflects the amount of time that the server transaction can | |
remain in the "Completed" state when unreliable transports are used. | |
This is equal to Timer H in the INVITE server transaction, whose | |
Rosenberg, et. al. Standards Track [Page 126] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
default is 64*T1. However, the client transaction does not know the | |
value of T1 in use by the server transaction, so an absolute minimum | |
of 32s is used instead of basing Timer D on T1. | |
Any retransmissions of the final response that are received while in | |
the "Completed" state MUST cause the ACK to be re-passed to the | |
transport layer for retransmission, but the newly received response | |
MUST NOT be passed up to the TU. A retransmission of the response is | |
defined as any response which would match the same client transaction | |
based on the rules of Section 17.1.3. | |
Rosenberg, et. al. Standards Track [Page 127] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
|INVITE from TU | |
Timer A fires |INVITE sent | |
Reset A, V Timer B fires | |
INVITE sent +-----------+ or Transport Err. | |
+---------| |---------------+inform TU | |
| | Calling | | | |
+-------->| |-------------->| | |
+-----------+ 2xx | | |
| | 2xx to TU | | |
| |1xx | | |
300-699 +---------------+ |1xx to TU | | |
ACK sent | | | | |
resp. to TU | 1xx V | | |
| 1xx to TU -----------+ | | |
| +---------| | | | |
| | |Proceeding |-------------->| | |
| +-------->| | 2xx | | |
| +-----------+ 2xx to TU | | |
| 300-699 | | | |
| ACK sent, | | | |
| resp. to TU| | | |
| | | NOTE: | |
| 300-699 V | | |
| ACK sent +-----------+Transport Err. | transitions | |
| +---------| |Inform TU | labeled with | |
| | | Completed |-------------->| the event | |
| +-------->| | | over the action | |
| +-----------+ | to take | |
| ^ | | | |
| | | Timer D fires | | |
+--------------+ | - | | |
| | | |
V | | |
+-----------+ | | |
| | | | |
| Terminated|<--------------+ | |
| | | |
+-----------+ | |
Figure 5: INVITE client transaction | |
If timer D fires while the client transaction is in the "Completed" | |
state, the client transaction MUST move to the terminated state. | |
When in either the "Calling" or "Proceeding" states, reception of a | |
2xx response MUST cause the client transaction to enter the | |
"Terminated" state, and the response MUST be passed up to the TU. | |
The handling of this response depends on whether the TU is a proxy | |
Rosenberg, et. al. Standards Track [Page 128] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
core or a UAC core. A UAC core will handle generation of the ACK for | |
this response, while a proxy core will always forward the 200 (OK) | |
upstream. The differing treatment of 200 (OK) between proxy and UAC | |
is the reason that handling of it does not take place in the | |
transaction layer. | |
The client transaction MUST be destroyed the instant it enters the | |
"Terminated" state. This is actually necessary to guarantee correct | |
operation. The reason is that 2xx responses to an INVITE are treated | |
differently; each one is forwarded by proxies, and the ACK handling | |
in a UAC is different. Thus, each 2xx needs to be passed to a proxy | |
core (so that it can be forwarded) and to a UAC core (so it can be | |
acknowledged). No transaction layer processing takes place. | |
Whenever a response is received by the transport, if the transport | |
layer finds no matching client transaction (using the rules of | |
Section 17.1.3), the response is passed directly to the core. Since | |
the matching client transaction is destroyed by the first 2xx, | |
subsequent 2xx will find no match and therefore be passed to the | |
core. | |
17.1.1.3 Construction of the ACK Request | |
This section specifies the construction of ACK requests sent within | |
the client transaction. A UAC core that generates an ACK for 2xx | |
MUST instead follow the rules described in Section 13. | |
The ACK request constructed by the client transaction MUST contain | |
values for the Call-ID, From, and Request-URI that are equal to the | |
values of those header fields in the request passed to the transport | |
by the client transaction (call this the "original request"). The To | |
header field in the ACK MUST equal the To header field in the | |
response being acknowledged, and therefore will usually differ from | |
the To header field in the original request by the addition of the | |
tag parameter. The ACK MUST contain a single Via header field, and | |
this MUST be equal to the top Via header field of the original | |
request. The CSeq header field in the ACK MUST contain the same | |
value for the sequence number as was present in the original request, | |
but the method parameter MUST be equal to "ACK". | |
Rosenberg, et. al. Standards Track [Page 129] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
If the INVITE request whose response is being acknowledged had Route | |
header fields, those header fields MUST appear in the ACK. This is | |
to ensure that the ACK can be routed properly through any downstream | |
stateless proxies. | |
Although any request MAY contain a body, a body in an ACK is special | |
since the request cannot be rejected if the body is not understood. | |
Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, | |
but if done, the body types are restricted to any that appeared in | |
the INVITE, assuming that the response to the INVITE was not 415. If | |
it was, the body in the ACK MAY be any type listed in the Accept | |
header field in the 415. | |
For example, consider the following request: | |
INVITE sip:bob@biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff | |
To: Bob <sip:bob@biloxi.com> | |
From: Alice <sip:alice@atlanta.com>;tag=88sja8x | |
Max-Forwards: 70 | |
Call-ID: 987asjd97y7atg | |
CSeq: 986759 INVITE | |
The ACK request for a non-2xx final response to this request would | |
look like this: | |
ACK sip:bob@biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff | |
To: Bob <sip:bob@biloxi.com>;tag=99sa0xk | |
From: Alice <sip:alice@atlanta.com>;tag=88sja8x | |
Max-Forwards: 70 | |
Call-ID: 987asjd97y7atg | |
CSeq: 986759 ACK | |
17.1.2 Non-INVITE Client Transaction | |
17.1.2.1 Overview of the non-INVITE Transaction | |
Non-INVITE transactions do not make use of ACK. They are simple | |
request-response interactions. For unreliable transports, requests | |
are retransmitted at an interval which starts at T1 and doubles until | |
it hits T2. If a provisional response is received, retransmissions | |
continue for unreliable transports, but at an interval of T2. The | |
server transaction retransmits the last response it sent, which can | |
be a provisional or final response, only when a retransmission of the | |
request is received. This is why request retransmissions need to | |
continue even after a provisional response; they are to ensure | |
reliable delivery of the final response. | |
Rosenberg, et. al. Standards Track [Page 130] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Unlike an INVITE transaction, a non-INVITE transaction has no special | |
handling for the 2xx response. The result is that only a single 2xx | |
response to a non-INVITE is ever delivered to a UAC. | |
17.1.2.2 Formal Description | |
The state machine for the non-INVITE client transaction is shown in | |
Figure 6. It is very similar to the state machine for INVITE. | |
The "Trying" state is entered when the TU initiates a new client | |
transaction with a request. When entering this state, the client | |
transaction SHOULD set timer F to fire in 64*T1 seconds. The request | |
MUST be passed to the transport layer for transmission. If an | |
unreliable transport is in use, the client transaction MUST set timer | |
E to fire in T1 seconds. If timer E fires while still in this state, | |
the timer is reset, but this time with a value of MIN(2*T1, T2). | |
When the timer fires again, it is reset to a MIN(4*T1, T2). This | |
process continues so that retransmissions occur with an exponentially | |
increasing interval that caps at T2. The default value of T2 is 4s, | |
and it represents the amount of time a non-INVITE server transaction | |
will take to respond to a request, if it does not respond | |
immediately. For the default values of T1 and T2, this results in | |
intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. | |
If Timer F fires while the client transaction is still in the | |
"Trying" state, the client transaction SHOULD inform the TU about the | |
timeout, and then it SHOULD enter the "Terminated" state. If a | |
provisional response is received while in the "Trying" state, the | |
response MUST be passed to the TU, and then the client transaction | |
SHOULD move to the "Proceeding" state. If a final response (status | |
codes 200-699) is received while in the "Trying" state, the response | |
MUST be passed to the TU, and the client transaction MUST transition | |
to the "Completed" state. | |
If Timer E fires while in the "Proceeding" state, the request MUST be | |
passed to the transport layer for retransmission, and Timer E MUST be | |
reset with a value of T2 seconds. If timer F fires while in the | |
"Proceeding" state, the TU MUST be informed of a timeout, and the | |
client transaction MUST transition to the terminated state. If a | |
final response (status codes 200-699) is received while in the | |
"Proceeding" state, the response MUST be passed to the TU, and the | |
client transaction MUST transition to the "Completed" state. | |
Once the client transaction enters the "Completed" state, it MUST set | |
Timer K to fire in T4 seconds for unreliable transports, and zero | |
seconds for reliable transports. The "Completed" state exists to | |
buffer any additional response retransmissions that may be received | |
(which is why the client transaction remains there only for | |
Rosenberg, et. al. Standards Track [Page 131] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
unreliable transports). T4 represents the amount of time the network | |
will take to clear messages between client and server transactions. | |
The default value of T4 is 5s. A response is a retransmission when | |
it matches the same transaction, using the rules specified in Section | |
17.1.3. If Timer K fires while in this state, the client transaction | |
MUST transition to the "Terminated" state. | |
Once the transaction is in the terminated state, it MUST be destroyed | |
immediately. | |
17.1.3 Matching Responses to Client Transactions | |
When the transport layer in the client receives a response, it has to | |
determine which client transaction will handle the response, so that | |
the processing of Sections 17.1.1 and 17.1.2 can take place. The | |
branch parameter in the top Via header field is used for this | |
purpose. A response matches a client transaction under two | |
conditions: | |
1. If the response has the same value of the branch parameter in | |
the top Via header field as the branch parameter in the top | |
Via header field of the request that created the transaction. | |
2. If the method parameter in the CSeq header field matches the | |
method of the request that created the transaction. The | |
method is needed since a CANCEL request constitutes a | |
different transaction, but shares the same value of the branch | |
parameter. | |
If a request is sent via multicast, it is possible that it will | |
generate multiple responses from different servers. These responses | |
will all have the same branch parameter in the topmost Via, but vary | |
in the To tag. The first response received, based on the rules | |
above, will be used, and others will be viewed as retransmissions. | |
That is not an error; multicast SIP provides only a rudimentary | |
"single-hop-discovery-like" service that is limited to processing a | |
single response. See Section 18.1.1 for details. | |
Rosenberg, et. al. Standards Track [Page 132] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
17.1.4 Handling Transport Errors | |
|Request from TU | |
|send request | |
Timer E V | |
send request +-----------+ | |
+---------| |-------------------+ | |
| | Trying | Timer F | | |
+-------->| | or Transport Err.| | |
+-----------+ inform TU | | |
200-699 | | | | |
resp. to TU | |1xx | | |
+---------------+ |resp. to TU | | |
| | | | |
| Timer E V Timer F | | |
| send req +-----------+ or Transport Err. | | |
| +---------| | inform TU | | |
| | |Proceeding |------------------>| | |
| +-------->| |-----+ | | |
| +-----------+ |1xx | | |
| | ^ |resp to TU | | |
| 200-699 | +--------+ | | |
| resp. to TU | | | |
| | | | |
| V | | |
| +-----------+ | | |
| | | | | |
| | Completed | | | |
| | | | | |
| +-----------+ | | |
| ^ | | | |
| | | Timer K | | |
+--------------+ | - | | |
| | | |
V | | |
NOTE: +-----------+ | | |
| | | | |
transitions | Terminated|<------------------+ | |
labeled with | | | |
the event +-----------+ | |
over the action | |
to take | |
Figure 6: non-INVITE client transaction | |
When the client transaction sends a request to the transport layer to | |
be sent, the following procedures are followed if the transport layer | |
indicates a failure. | |
Rosenberg, et. al. Standards Track [Page 133] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The client transaction SHOULD inform the TU that a transport failure | |
has occurred, and the client transaction SHOULD transition directly | |
to the "Terminated" state. The TU will handle the failover | |
mechanisms described in [4]. | |
17.2 Server Transaction | |
The server transaction is responsible for the delivery of requests to | |
the TU and the reliable transmission of responses. It accomplishes | |
this through a state machine. Server transactions are created by the | |
core when a request is received, and transaction handling is desired | |
for that request (this is not always the case). | |
As with the client transactions, the state machine depends on whether | |
the received request is an INVITE request. | |
17.2.1 INVITE Server Transaction | |
The state diagram for the INVITE server transaction is shown in | |
Figure 7. | |
When a server transaction is constructed for a request, it enters the | |
"Proceeding" state. The server transaction MUST generate a 100 | |
(Trying) response unless it knows that the TU will generate a | |
provisional or final response within 200 ms, in which case it MAY | |
generate a 100 (Trying) response. This provisional response is | |
needed to quench request retransmissions rapidly in order to avoid | |
network congestion. The 100 (Trying) response is constructed | |
according to the procedures in Section 8.2.6, except that the | |
insertion of tags in the To header field of the response (when none | |
was present in the request) is downgraded from MAY to SHOULD NOT. | |
The request MUST be passed to the TU. | |
The TU passes any number of provisional responses to the server | |
transaction. So long as the server transaction is in the | |
"Proceeding" state, each of these MUST be passed to the transport | |
layer for transmission. They are not sent reliably by the | |
transaction layer (they are not retransmitted by it) and do not cause | |
a change in the state of the server transaction. If a request | |
retransmission is received while in the "Proceeding" state, the most | |
recent provisional response that was received from the TU MUST be | |
passed to the transport layer for retransmission. A request is a | |
retransmission if it matches the same server transaction based on the | |
rules of Section 17.2.3. | |
If, while in the "Proceeding" state, the TU passes a 2xx response to | |
the server transaction, the server transaction MUST pass this | |
response to the transport layer for transmission. It is not | |
Rosenberg, et. al. Standards Track [Page 134] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
retransmitted by the server transaction; retransmissions of 2xx | |
responses are handled by the TU. The server transaction MUST then | |
transition to the "Terminated" state. | |
While in the "Proceeding" state, if the TU passes a response with | |
status code from 300 to 699 to the server transaction, the response | |
MUST be passed to the transport layer for transmission, and the state | |
machine MUST enter the "Completed" state. For unreliable transports, | |
timer G is set to fire in T1 seconds, and is not set to fire for | |
reliable transports. | |
This is a change from RFC 2543, where responses were always | |
retransmitted, even over reliable transports. | |
When the "Completed" state is entered, timer H MUST be set to fire in | |
64*T1 seconds for all transports. Timer H determines when the server | |
transaction abandons retransmitting the response. Its value is | |
chosen to equal Timer B, the amount of time a client transaction will | |
continue to retry sending a request. If timer G fires, the response | |
is passed to the transport layer once more for retransmission, and | |
timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when | |
timer G fires, the response is passed to the transport again for | |
transmission, and timer G is reset with a value that doubles, unless | |
that value exceeds T2, in which case it is reset with the value of | |
T2. This is identical to the retransmit behavior for requests in the | |
"Trying" state of the non-INVITE client transaction. Furthermore, | |
while in the "Completed" state, if a request retransmission is | |
received, the server SHOULD pass the response to the transport for | |
retransmission. | |
If an ACK is received while the server transaction is in the | |
"Completed" state, the server transaction MUST transition to the | |
"Confirmed" state. As Timer G is ignored in this state, any | |
retransmissions of the response will cease. | |
If timer H fires while in the "Completed" state, it implies that the | |
ACK was never received. In this case, the server transaction MUST | |
transition to the "Terminated" state, and MUST indicate to the TU | |
that a transaction failure has occurred. | |
Rosenberg, et. al. Standards Track [Page 135] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
|INVITE | |
|pass INV to TU | |
INVITE V send 100 if TU won't in 200ms | |
send response+-----------+ | |
+--------| |--------+101-199 from TU | |
| | Proceeding| |send response | |
+------->| |<-------+ | |
| | Transport Err. | |
| | Inform TU | |
| |--------------->+ | |
+-----------+ | | |
300-699 from TU | |2xx from TU | | |
send response | |send response | | |
| +------------------>+ | |
| | | |
INVITE V Timer G fires | | |
send response+-----------+ send response | | |
+--------| |--------+ | | |
| | Completed | | | | |
+------->| |<-------+ | | |
+-----------+ | | |
| | | | |
ACK | | | | |
- | +------------------>+ | |
| Timer H fires | | |
V or Transport Err.| | |
+-----------+ Inform TU | | |
| | | | |
| Confirmed | | | |
| | | | |
+-----------+ | | |
| | | |
|Timer I fires | | |
|- | | |
| | | |
V | | |
+-----------+ | | |
| | | | |
| Terminated|<---------------+ | |
| | | |
+-----------+ | |
Figure 7: INVITE server transaction | |
Rosenberg, et. al. Standards Track [Page 136] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The purpose of the "Confirmed" state is to absorb any additional ACK | |
messages that arrive, triggered from retransmissions of the final | |
response. When this state is entered, timer I is set to fire in T4 | |
seconds for unreliable transports, and zero seconds for reliable | |
transports. Once timer I fires, the server MUST transition to the | |
"Terminated" state. | |
Once the transaction is in the "Terminated" state, it MUST be | |
destroyed immediately. As with client transactions, this is needed | |
to ensure reliability of the 2xx responses to INVITE. | |
17.2.2 Non-INVITE Server Transaction | |
The state machine for the non-INVITE server transaction is shown in | |
Figure 8. | |
The state machine is initialized in the "Trying" state and is passed | |
a request other than INVITE or ACK when initialized. This request is | |
passed up to the TU. Once in the "Trying" state, any further request | |
retransmissions are discarded. A request is a retransmission if it | |
matches the same server transaction, using the rules specified in | |
Section 17.2.3. | |
While in the "Trying" state, if the TU passes a provisional response | |
to the server transaction, the server transaction MUST enter the | |
"Proceeding" state. The response MUST be passed to the transport | |
layer for transmission. Any further provisional responses that are | |
received from the TU while in the "Proceeding" state MUST be passed | |
to the transport layer for transmission. If a retransmission of the | |
request is received while in the "Proceeding" state, the most | |
recently sent provisional response MUST be passed to the transport | |
layer for retransmission. If the TU passes a final response (status | |
codes 200-699) to the server while in the "Proceeding" state, the | |
transaction MUST enter the "Completed" state, and the response MUST | |
be passed to the transport layer for transmission. | |
When the server transaction enters the "Completed" state, it MUST set | |
Timer J to fire in 64*T1 seconds for unreliable transports, and zero | |
seconds for reliable transports. While in the "Completed" state, the | |
server transaction MUST pass the final response to the transport | |
layer for retransmission whenever a retransmission of the request is | |
received. Any other final responses passed by the TU to the server | |
transaction MUST be discarded while in the "Completed" state. The | |
server transaction remains in this state until Timer J fires, at | |
which point it MUST transition to the "Terminated" state. | |
The server transaction MUST be destroyed the instant it enters the | |
"Terminated" state. | |
Rosenberg, et. al. Standards Track [Page 137] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
17.2.3 Matching Requests to Server Transactions | |
When a request is received from the network by the server, it has to | |
be matched to an existing transaction. This is accomplished in the | |
following manner. | |
The branch parameter in the topmost Via header field of the request | |
is examined. If it is present and begins with the magic cookie | |
"z9hG4bK", the request was generated by a client transaction | |
compliant to this specification. Therefore, the branch parameter | |
will be unique across all transactions sent by that client. The | |
request matches a transaction if: | |
1. the branch parameter in the request is equal to the one in the | |
top Via header field of the request that created the | |
transaction, and | |
2. the sent-by value in the top Via of the request is equal to the | |
one in the request that created the transaction, and | |
3. the method of the request matches the one that created the | |
transaction, except for ACK, where the method of the request | |
that created the transaction is INVITE. | |
This matching rule applies to both INVITE and non-INVITE transactions | |
alike. | |
The sent-by value is used as part of the matching process because | |
there could be accidental or malicious duplication of branch | |
parameters from different clients. | |
If the branch parameter in the top Via header field is not present, | |
or does not contain the magic cookie, the following procedures are | |
used. These exist to handle backwards compatibility with RFC 2543 | |
compliant implementations. | |
The INVITE request matches a transaction if the Request-URI, To tag, | |
From tag, Call-ID, CSeq, and top Via header field match those of the | |
INVITE request which created the transaction. In this case, the | |
INVITE is a retransmission of the original one that created the | |
transaction. The ACK request matches a transaction if the Request- | |
URI, From tag, Call-ID, CSeq number (not the method), and top Via | |
header field match those of the INVITE request which created the | |
transaction, and the To tag of the ACK matches the To tag of the | |
response sent by the server transaction. Matching is done based on | |
the matching rules defined for each of those header fields. | |
Inclusion of the tag in the To header field in the ACK matching | |
process helps disambiguate ACK for 2xx from ACK for other responses | |
Rosenberg, et. al. Standards Track [Page 138] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
at a proxy, which may have forwarded both responses (This can occur | |
in unusual conditions. Specifically, when a proxy forked a request, | |
and then crashes, the responses may be delivered to another proxy, | |
which might end up forwarding multiple responses upstream). An ACK | |
request that matches an INVITE transaction matched by a previous ACK | |
is considered a retransmission of that previous ACK. | |
Rosenberg, et. al. Standards Track [Page 139] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
|Request received | |
|pass to TU | |
V | |
+-----------+ | |
| | | |
| Trying |-------------+ | |
| | | | |
+-----------+ |200-699 from TU | |
| |send response | |
|1xx from TU | | |
|send response | | |
| | | |
Request V 1xx from TU | | |
send response+-----------+send response| | |
+--------| |--------+ | | |
| | Proceeding| | | | |
+------->| |<-------+ | | |
+<--------------| | | | |
|Trnsprt Err +-----------+ | | |
|Inform TU | | | |
| | | | |
| |200-699 from TU | | |
| |send response | | |
| Request V | | |
| send response+-----------+ | | |
| +--------| | | | |
| | | Completed |<------------+ | |
| +------->| | | |
+<--------------| | | |
|Trnsprt Err +-----------+ | |
|Inform TU | | |
| |Timer J fires | |
| |- | |
| | | |
| V | |
| +-----------+ | |
| | | | |
+-------------->| Terminated| | |
| | | |
+-----------+ | |
Figure 8: non-INVITE server transaction | |
For all other request methods, a request is matched to a transaction | |
if the Request-URI, To tag, From tag, Call-ID, CSeq (including the | |
method), and top Via header field match those of the request that | |
created the transaction. Matching is done based on the matching | |
Rosenberg, et. al. Standards Track [Page 140] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
rules defined for each of those header fields. When a non-INVITE | |
request matches an existing transaction, it is a retransmission of | |
the request that created that transaction. | |
Because the matching rules include the Request-URI, the server cannot | |
match a response to a transaction. When the TU passes a response to | |
the server transaction, it must pass it to the specific server | |
transaction for which the response is targeted. | |
17.2.4 Handling Transport Errors | |
When the server transaction sends a response to the transport layer | |
to be sent, the following procedures are followed if the transport | |
layer indicates a failure. | |
First, the procedures in [4] are followed, which attempt to deliver | |
the response to a backup. If those should all fail, based on the | |
definition of failure in [4], the server transaction SHOULD inform | |
the TU that a failure has occurred, and SHOULD transition to the | |
terminated state. | |
18 Transport | |
The transport layer is responsible for the actual transmission of | |
requests and responses over network transports. This includes | |
determination of the connection to use for a request or response in | |
the case of connection-oriented transports. | |
The transport layer is responsible for managing persistent | |
connections for transport protocols like TCP and SCTP, or TLS over | |
those, including ones opened to the transport layer. This includes | |
connections opened by the client or server transports, so that | |
connections are shared between client and server transport functions. | |
These connections are indexed by the tuple formed from the address, | |
port, and transport protocol at the far end of the connection. When | |
a connection is opened by the transport layer, this index is set to | |
the destination IP, port and transport. When the connection is | |
accepted by the transport layer, this index is set to the source IP | |
address, port number, and transport. Note that, because the source | |
port is often ephemeral, but it cannot be known whether it is | |
ephemeral or selected through procedures in [4], connections accepted | |
by the transport layer will frequently not be reused. The result is | |
that two proxies in a "peering" relationship using a connection- | |
oriented transport frequently will have two connections in use, one | |
for transactions initiated in each direction. | |
Rosenberg, et. al. Standards Track [Page 141] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
It is RECOMMENDED that connections be kept open for some | |
implementation-defined duration after the last message was sent or | |
received over that connection. This duration SHOULD at least equal | |
the longest amount of time the element would need in order to bring a | |
transaction from instantiation to the terminated state. This is to | |
make it likely that transactions are completed over the same | |
connection on which they are initiated (for example, request, | |
response, and in the case of INVITE, ACK for non-2xx responses). | |
This usually means at least 64*T1 (see Section 17.1.1.1 for a | |
definition of T1). However, it could be larger in an element that | |
has a TU using a large value for timer C (bullet 11 of Section 16.6), | |
for example. | |
All SIP elements MUST implement UDP and TCP. SIP elements MAY | |
implement other protocols. | |
Making TCP mandatory for the UA is a substantial change from RFC | |
2543. It has arisen out of the need to handle larger messages, | |
which MUST use TCP, as discussed below. Thus, even if an element | |
never sends large messages, it may receive one and needs to be | |
able to handle them. | |
18.1 Clients | |
18.1.1 Sending Requests | |
The client side of the transport layer is responsible for sending the | |
request and receiving responses. The user of the transport layer | |
passes the client transport the request, an IP address, port, | |
transport, and possibly TTL for multicast destinations. | |
If a request is within 200 bytes of the path MTU, or if it is larger | |
than 1300 bytes and the path MTU is unknown, the request MUST be sent | |
using an RFC 2914 [43] congestion controlled transport protocol, such | |
as TCP. If this causes a change in the transport protocol from the | |
one indicated in the top Via, the value in the top Via MUST be | |
changed. This prevents fragmentation of messages over UDP and | |
provides congestion control for larger messages. However, | |
implementations MUST be able to handle messages up to the maximum | |
datagram packet size. For UDP, this size is 65,535 bytes, including | |
IP and UDP headers. | |
The 200 byte "buffer" between the message size and the MTU | |
accommodates the fact that the response in SIP can be larger than | |
the request. This happens due to the addition of Record-Route | |
header field values to the responses to INVITE, for example. With | |
the extra buffer, the response can be about 170 bytes larger than | |
the request, and still not be fragmented on IPv4 (about 30 bytes | |
Rosenberg, et. al. Standards Track [Page 142] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when | |
path MTU is not known, based on the assumption of a 1500 byte | |
Ethernet MTU. | |
If an element sends a request over TCP because of these message size | |
constraints, and that request would have otherwise been sent over | |
UDP, if the attempt to establish the connection generates either an | |
ICMP Protocol Not Supported, or results in a TCP reset, the element | |
SHOULD retry the request, using UDP. This is only to provide | |
backwards compatibility with RFC 2543 compliant implementations that | |
do not support TCP. It is anticipated that this behavior will be | |
deprecated in a future revision of this specification. | |
A client that sends a request to a multicast address MUST add the | |
"maddr" parameter to its Via header field value containing the | |
destination multicast address, and for IPv4, SHOULD add the "ttl" | |
parameter with a value of 1. Usage of IPv6 multicast is not defined | |
in this specification, and will be a subject of future | |
standardization when the need arises. | |
These rules result in a purposeful limitation of multicast in SIP. | |
Its primary function is to provide a "single-hop-discovery-like" | |
service, delivering a request to a group of homogeneous servers, | |
where it is only required to process the response from any one of | |
them. This functionality is most useful for registrations. In fact, | |
based on the transaction processing rules in Section 17.1.3, the | |
client transaction will accept the first response, and view any | |
others as retransmissions because they all contain the same Via | |
branch identifier. | |
Before a request is sent, the client transport MUST insert a value of | |
the "sent-by" field into the Via header field. This field contains | |
an IP address or host name, and port. The usage of an FQDN is | |
RECOMMENDED. This field is used for sending responses under certain | |
conditions, described below. If the port is absent, the default | |
value depends on the transport. It is 5060 for UDP, TCP and SCTP, | |
5061 for TLS. | |
For reliable transports, the response is normally sent on the | |
connection on which the request was received. Therefore, the client | |
transport MUST be prepared to receive the response on the same | |
connection used to send the request. Under error conditions, the | |
server may attempt to open a new connection to send the response. To | |
handle this case, the transport layer MUST also be prepared to | |
receive an incoming connection on the source IP address from which | |
the request was sent and port number in the "sent-by" field. It also | |
Rosenberg, et. al. Standards Track [Page 143] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
MUST be prepared to receive incoming connections on any address and | |
port that would be selected by a server based on the procedures | |
described in Section 5 of [4]. | |
For unreliable unicast transports, the client transport MUST be | |
prepared to receive responses on the source IP address from which the | |
request is sent (as responses are sent back to the source address) | |
and the port number in the "sent-by" field. Furthermore, as with | |
reliable transports, in certain cases the response will be sent | |
elsewhere. The client MUST be prepared to receive responses on any | |
address and port that would be selected by a server based on the | |
procedures described in Section 5 of [4]. | |
For multicast, the client transport MUST be prepared to receive | |
responses on the same multicast group and port to which the request | |
is sent (that is, it needs to be a member of the multicast group it | |
sent the request to.) | |
If a request is destined to an IP address, port, and transport to | |
which an existing connection is open, it is RECOMMENDED that this | |
connection be used to send the request, but another connection MAY be | |
opened and used. | |
If a request is sent using multicast, it is sent to the group | |
address, port, and TTL provided by the transport user. If a request | |
is sent using unicast unreliable transports, it is sent to the IP | |
address and port provided by the transport user. | |
18.1.2 Receiving Responses | |
When a response is received, the client transport examines the top | |
Via header field value. If the value of the "sent-by" parameter in | |
that header field value does not correspond to a value that the | |
client transport is configured to insert into requests, the response | |
MUST be silently discarded. | |
If there are any client transactions in existence, the client | |
transport uses the matching procedures of Section 17.1.3 to attempt | |
to match the response to an existing transaction. If there is a | |
match, the response MUST be passed to that transaction. Otherwise, | |
the response MUST be passed to the core (whether it be stateless | |
proxy, stateful proxy, or UA) for further processing. Handling of | |
these "stray" responses is dependent on the core (a proxy will | |
forward them, while a UA will discard, for example). | |
Rosenberg, et. al. Standards Track [Page 144] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
18.2 Servers | |
18.2.1 Receiving Requests | |
A server SHOULD be prepared to receive requests on any IP address, | |
port and transport combination that can be the result of a DNS lookup | |
on a SIP or SIPS URI [4] that is handed out for the purposes of | |
communicating with that server. In this context, "handing out" | |
includes placing a URI in a Contact header field in a REGISTER | |
request or a redirect response, or in a Record-Route header field in | |
a request or response. A URI can also be "handed out" by placing it | |
on a web page or business card. It is also RECOMMENDED that a server | |
listen for requests on the default SIP ports (5060 for TCP and UDP, | |
5061 for TLS over TCP) on all public interfaces. The typical | |
exception would be private networks, or when multiple server | |
instances are running on the same host. For any port and interface | |
that a server listens on for UDP, it MUST listen on that same port | |
and interface for TCP. This is because a message may need to be sent | |
using TCP, rather than UDP, if it is too large. As a result, the | |
converse is not true. A server need not listen for UDP on a | |
particular address and port just because it is listening on that same | |
address and port for TCP. There may, of course, be other reasons why | |
a server needs to listen for UDP on a particular address and port. | |
When the server transport receives a request over any transport, it | |
MUST examine the value of the "sent-by" parameter in the top Via | |
header field value. If the host portion of the "sent-by" parameter | |
contains a domain name, or if it contains an IP address that differs | |
from the packet source address, the server MUST add a "received" | |
parameter to that Via header field value. This parameter MUST | |
contain the source address from which the packet was received. This | |
is to assist the server transport layer in sending the response, | |
since it must be sent to the source IP address from which the request | |
came. | |
Consider a request received by the server transport which looks like, | |
in part: | |
INVITE sip:bob@Biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP bobspc.biloxi.com:5060 | |
The request is received with a source IP address of 192.0.2.4. | |
Before passing the request up, the transport adds a "received" | |
parameter, so that the request would look like, in part: | |
INVITE sip:bob@Biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4 | |
Rosenberg, et. al. Standards Track [Page 145] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Next, the server transport attempts to match the request to a server | |
transaction. It does so using the matching rules described in | |
Section 17.2.3. If a matching server transaction is found, the | |
request is passed to that transaction for processing. If no match is | |
found, the request is passed to the core, which may decide to | |
construct a new server transaction for that request. Note that when | |
a UAS core sends a 2xx response to INVITE, the server transaction is | |
destroyed. This means that when the ACK arrives, there will be no | |
matching server transaction, and based on this rule, the ACK is | |
passed to the UAS core, where it is processed. | |
18.2.2 Sending Responses | |
The server transport uses the value of the top Via header field in | |
order to determine where to send a response. It MUST follow the | |
following process: | |
o If the "sent-protocol" is a reliable transport protocol such as | |
TCP or SCTP, or TLS over those, the response MUST be sent using | |
the existing connection to the source of the original request | |
that created the transaction, if that connection is still open. | |
This requires the server transport to maintain an association | |
between server transactions and transport connections. If that | |
connection is no longer open, the server SHOULD open a | |
connection to the IP address in the "received" parameter, if | |
present, using the port in the "sent-by" value, or the default | |
port for that transport, if no port is specified. If that | |
connection attempt fails, the server SHOULD use the procedures | |
in [4] for servers in order to determine the IP address and | |
port to open the connection and send the response to. | |
o Otherwise, if the Via header field value contains a "maddr" | |
parameter, the response MUST be forwarded to the address listed | |
there, using the port indicated in "sent-by", or port 5060 if | |
none is present. If the address is a multicast address, the | |
response SHOULD be sent using the TTL indicated in the "ttl" | |
parameter, or with a TTL of 1 if that parameter is not present. | |
o Otherwise (for unreliable unicast transports), if the top Via | |
has a "received" parameter, the response MUST be sent to the | |
address in the "received" parameter, using the port indicated | |
in the "sent-by" value, or using port 5060 if none is specified | |
explicitly. If this fails, for example, elicits an ICMP "port | |
unreachable" response, the procedures of Section 5 of [4] | |
SHOULD be used to determine where to send the response. | |
Rosenberg, et. al. Standards Track [Page 146] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o Otherwise, if it is not receiver-tagged, the response MUST be | |
sent to the address indicated by the "sent-by" value, using the | |
procedures in Section 5 of [4]. | |
18.3 Framing | |
In the case of message-oriented transports (such as UDP), if the | |
message has a Content-Length header field, the message body is | |
assumed to contain that many bytes. If there are additional bytes in | |
the transport packet beyond the end of the body, they MUST be | |
discarded. If the transport packet ends before the end of the | |
message body, this is considered an error. If the message is a | |
response, it MUST be discarded. If the message is a request, the | |
element SHOULD generate a 400 (Bad Request) response. If the message | |
has no Content-Length header field, the message body is assumed to | |
end at the end of the transport packet. | |
In the case of stream-oriented transports such as TCP, the Content- | |
Length header field indicates the size of the body. The Content- | |
Length header field MUST be used with stream oriented transports. | |
18.4 Error Handling | |
Error handling is independent of whether the message was a request or | |
response. | |
If the transport user asks for a message to be sent over an | |
unreliable transport, and the result is an ICMP error, the behavior | |
depends on the type of ICMP error. Host, network, port or protocol | |
unreachable errors, or parameter problem errors SHOULD cause the | |
transport layer to inform the transport user of a failure in sending. | |
Source quench and TTL exceeded ICMP errors SHOULD be ignored. | |
If the transport user asks for a request to be sent over a reliable | |
transport, and the result is a connection failure, the transport | |
layer SHOULD inform the transport user of a failure in sending. | |
19 Common Message Components | |
There are certain components of SIP messages that appear in various | |
places within SIP messages (and sometimes, outside of them) that | |
merit separate discussion. | |
Rosenberg, et. al. Standards Track [Page 147] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
19.1 SIP and SIPS Uniform Resource Indicators | |
A SIP or SIPS URI identifies a communications resource. Like all | |
URIs, SIP and SIPS URIs may be placed in web pages, email messages, | |
or printed literature. They contain sufficient information to | |
initiate and maintain a communication session with the resource. | |
Examples of communications resources include the following: | |
o a user of an online service | |
o an appearance on a multi-line phone | |
o a mailbox on a messaging system | |
o a PSTN number at a gateway service | |
o a group (such as "sales" or "helpdesk") in an organization | |
A SIPS URI specifies that the resource be contacted securely. This | |
means, in particular, that TLS is to be used between the UAC and the | |
domain that owns the URI. From there, secure communications are used | |
to reach the user, where the specific security mechanism depends on | |
the policy of the domain. Any resource described by a SIP URI can be | |
"upgraded" to a SIPS URI by just changing the scheme, if it is | |
desired to communicate with that resource securely. | |
19.1.1 SIP and SIPS URI Components | |
The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5]. | |
They use a form similar to the mailto URL, allowing the specification | |
of SIP request-header fields and the SIP message-body. This makes it | |
possible to specify the subject, media type, or urgency of sessions | |
initiated by using a URI on a web page or in an email message. The | |
formal syntax for a SIP or SIPS URI is presented in Section 25. Its | |
general form, in the case of a SIP URI, is: | |
sip:user:password@host:port;uri-parameters?headers | |
The format for a SIPS URI is the same, except that the scheme is | |
"sips" instead of sip. These tokens, and some of the tokens in their | |
expansions, have the following meanings: | |
user: The identifier of a particular resource at the host being | |
addressed. The term "host" in this context frequently refers | |
to a domain. The "userinfo" of a URI consists of this user | |
field, the password field, and the @ sign following them. The | |
userinfo part of a URI is optional and MAY be absent when the | |
Rosenberg, et. al. Standards Track [Page 148] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
destination host does not have a notion of users or when the | |
host itself is the resource being identified. If the @ sign is | |
present in a SIP or SIPS URI, the user field MUST NOT be empty. | |
If the host being addressed can process telephone numbers, for | |
instance, an Internet telephony gateway, a telephone- | |
subscriber field defined in RFC 2806 [9] MAY be used to | |
populate the user field. There are special escaping rules for | |
encoding telephone-subscriber fields in SIP and SIPS URIs | |
described in Section 19.1.2. | |
password: A password associated with the user. While the SIP and | |
SIPS URI syntax allows this field to be present, its use is NOT | |
RECOMMENDED, because the passing of authentication information | |
in clear text (such as URIs) has proven to be a security risk | |
in almost every case where it has been used. For instance, | |
transporting a PIN number in this field exposes the PIN. | |
Note that the password field is just an extension of the user | |
portion. Implementations not wishing to give special | |
significance to the password portion of the field MAY simply | |
treat "user:password" as a single string. | |
host: The host providing the SIP resource. The host part contains | |
either a fully-qualified domain name or numeric IPv4 or IPv6 | |
address. Using the fully-qualified domain name form is | |
RECOMMENDED whenever possible. | |
port: The port number where the request is to be sent. | |
URI parameters: Parameters affecting a request constructed from | |
the URI. | |
URI parameters are added after the hostport component and are | |
separated by semi-colons. | |
URI parameters take the form: | |
parameter-name "=" parameter-value | |
Even though an arbitrary number of URI parameters may be | |
included in a URI, any given parameter-name MUST NOT appear | |
more than once. | |
This extensible mechanism includes the transport, maddr, ttl, | |
user, method and lr parameters. | |
Rosenberg, et. al. Standards Track [Page 149] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The transport parameter determines the transport mechanism to | |
be used for sending SIP messages, as specified in [4]. SIP can | |
use any network transport protocol. Parameter names are | |
defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP | |
(RFC 2960 [16]). For a SIPS URI, the transport parameter MUST | |
indicate a reliable transport. | |
The maddr parameter indicates the server address to be | |
contacted for this user, overriding any address derived from | |
the host field. When an maddr parameter is present, the port | |
and transport components of the URI apply to the address | |
indicated in the maddr parameter value. [4] describes the | |
proper interpretation of the transport, maddr, and hostport in | |
order to obtain the destination address, port, and transport | |
for sending a request. | |
The maddr field has been used as a simple form of loose source | |
routing. It allows a URI to specify a proxy that must be | |
traversed en-route to the destination. Continuing to use the | |
maddr parameter this way is strongly discouraged (the | |
mechanisms that enable it are deprecated). Implementations | |
should instead use the Route mechanism described in this | |
document, establishing a pre-existing route set if necessary | |
(see Section 8.1.1.1). This provides a full URI to describe | |
the node to be traversed. | |
The ttl parameter determines the time-to-live value of the UDP | |
multicast packet and MUST only be used if maddr is a multicast | |
address and the transport protocol is UDP. For example, to | |
specify a call to alice@atlanta.com using multicast to | |
239.255.255.1 with a ttl of 15, the following URI would be | |
used: | |
sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 | |
The set of valid telephone-subscriber strings is a subset of | |
valid user strings. The user URI parameter exists to | |
distinguish telephone numbers from user names that happen to | |
look like telephone numbers. If the user string contains a | |
telephone number formatted as a telephone-subscriber, the user | |
parameter value "phone" SHOULD be present. Even without this | |
parameter, recipients of SIP and SIPS URIs MAY interpret the | |
pre-@ part as a telephone number if local restrictions on the | |
name space for user name allow it. | |
The method of the SIP request constructed from the URI can be | |
specified with the method parameter. | |
Rosenberg, et. al. Standards Track [Page 150] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The lr parameter, when present, indicates that the element | |
responsible for this resource implements the routing mechanisms | |
specified in this document. This parameter will be used in the | |
URIs proxies place into Record-Route header field values, and | |
may appear in the URIs in a pre-existing route set. | |
This parameter is used to achieve backwards compatibility with | |
systems implementing the strict-routing mechanisms of RFC 2543 | |
and the rfc2543bis drafts up to bis-05. An element preparing | |
to send a request based on a URI not containing this parameter | |
can assume the receiving element implements strict-routing and | |
reformat the message to preserve the information in the | |
Request-URI. | |
Since the uri-parameter mechanism is extensible, SIP elements | |
MUST silently ignore any uri-parameters that they do not | |
understand. | |
Headers: Header fields to be included in a request constructed | |
from the URI. | |
Headers fields in the SIP request can be specified with the "?" | |
mechanism within a URI. The header names and values are | |
encoded in ampersand separated hname = hvalue pairs. The | |
special hname "body" indicates that the associated hvalue is | |
the message-body of the SIP request. | |
Table 1 summarizes the use of SIP and SIPS URI components based on | |
the context in which the URI appears. The external column describes | |
URIs appearing anywhere outside of a SIP message, for instance on a | |
web page or business card. Entries marked "m" are mandatory, those | |
marked "o" are optional, and those marked "-" are not allowed. | |
Elements processing URIs SHOULD ignore any disallowed components if | |
they are present. The second column indicates the default value of | |
an optional element if it is not present. "--" indicates that the | |
element is either not optional, or has no default value. | |
URIs in Contact header fields have different restrictions depending | |
on the context in which the header field appears. One set applies to | |
messages that establish and maintain dialogs (INVITE and its 200 (OK) | |
response). The other applies to registration and redirection | |
messages (REGISTER, its 200 (OK) response, and 3xx class responses to | |
any method). | |
Rosenberg, et. al. Standards Track [Page 151] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
19.1.2 Character Escaping Requirements | |
dialog | |
reg./redir. Contact/ | |
default Req.-URI To From Contact R-R/Route external | |
user -- o o o o o o | |
password -- o o o o o o | |
host -- m m m m m m | |
port (1) o - - o o o | |
user-param ip o o o o o o | |
method INVITE - - - - - o | |
maddr-param -- o - - o o o | |
ttl-param 1 o - - o - o | |
transp.-param (2) o - - o o o | |
lr-param -- o - - - o o | |
other-param -- o o o o o o | |
headers -- - - - o - o | |
(1): The default port value is transport and scheme dependent. The | |
default is 5060 for sip: using UDP, TCP, or SCTP. The default is | |
5061 for sip: using TLS over TCP and sips: over TCP. | |
(2): The default transport is scheme dependent. For sip:, it is UDP. | |
For sips:, it is TCP. | |
Table 1: Use and default values of URI components for SIP header | |
field values, Request-URI and references | |
SIP follows the requirements and guidelines of RFC 2396 [5] when | |
defining the set of characters that must be escaped in a SIP URI, and | |
uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]: | |
The set of characters actually reserved within any given URI | |
component is defined by that component. In general, a character | |
is reserved if the semantics of the URI changes if the character | |
is replaced with its escaped US-ASCII encoding [5]. Excluded US- | |
ASCII characters (RFC 2396 [5]), such as space and control | |
characters and characters used as URI delimiters, also MUST be | |
escaped. URIs MUST NOT contain unescaped space and control | |
characters. | |
For each component, the set of valid BNF expansions defines exactly | |
which characters may appear unescaped. All other characters MUST be | |
escaped. | |
For example, "@" is not in the set of characters in the user | |
component, so the user "j@s0n" must have at least the @ sign encoded, | |
as in "j%40s0n". | |
Rosenberg, et. al. Standards Track [Page 152] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Expanding the hname and hvalue tokens in Section 25 show that all URI | |
reserved characters in header field names and values MUST be escaped. | |
The telephone-subscriber subset of the user component has special | |
escaping considerations. The set of characters not reserved in the | |
RFC 2806 [9] description of telephone-subscriber contains a number of | |
characters in various syntax elements that need to be escaped when | |
used in SIP URIs. Any characters occurring in a telephone-subscriber | |
that do not appear in an expansion of the BNF for the user rule MUST | |
be escaped. | |
Note that character escaping is not allowed in the host component of | |
a SIP or SIPS URI (the % character is not valid in its expansion). | |
This is likely to change in the future as requirements for | |
Internationalized Domain Names are finalized. Current | |
implementations MUST NOT attempt to improve robustness by treating | |
received escaped characters in the host component as literally | |
equivalent to their unescaped counterpart. The behavior required to | |
meet the requirements of IDN may be significantly different. | |
19.1.3 Example SIP and SIPS URIs | |
sip:alice@atlanta.com | |
sip:alice:secretword@atlanta.com;transport=tcp | |
sips:alice@atlanta.com?subject=project%20x&priority=urgent | |
sip:+1-212-555-1212:1234@gateway.com;user=phone | |
sips:1212@gateway.com | |
sip:alice@192.0.2.4 | |
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com | |
sip:alice;day=tuesday@atlanta.com | |
The last sample URI above has a user field value of | |
"alice;day=tuesday". The escaping rules defined above allow a | |
semicolon to appear unescaped in this field. For the purposes of | |
this protocol, the field is opaque. The structure of that value is | |
only useful to the SIP element responsible for the resource. | |
19.1.4 URI Comparison | |
Some operations in this specification require determining whether two | |
SIP or SIPS URIs are equivalent. In this specification, registrars | |
need to compare bindings in Contact URIs in REGISTER requests (see | |
Section 10.3.). SIP and SIPS URIs are compared for equality | |
according to the following rules: | |
o A SIP and SIPS URI are never equivalent. | |
Rosenberg, et. al. Standards Track [Page 153] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o Comparison of the userinfo of SIP and SIPS URIs is case- | |
sensitive. This includes userinfo containing passwords or | |
formatted as telephone-subscribers. Comparison of all other | |
components of the URI is case-insensitive unless explicitly | |
defined otherwise. | |
o The ordering of parameters and header fields is not significant | |
in comparing SIP and SIPS URIs. | |
o Characters other than those in the "reserved" set (see RFC 2396 | |
[5]) are equivalent to their ""%" HEX HEX" encoding. | |
o An IP address that is the result of a DNS lookup of a host name | |
does not match that host name. | |
o For two URIs to be equal, the user, password, host, and port | |
components must match. | |
A URI omitting the user component will not match a URI that | |
includes one. A URI omitting the password component will not | |
match a URI that includes one. | |
A URI omitting any component with a default value will not | |
match a URI explicitly containing that component with its | |
default value. For instance, a URI omitting the optional port | |
component will not match a URI explicitly declaring port 5060. | |
The same is true for the transport-parameter, ttl-parameter, | |
user-parameter, and method components. | |
Defining sip:user@host to not be equivalent to | |
sip:user@host:5060 is a change from RFC 2543. When deriving | |
addresses from URIs, equivalent addresses are expected from | |
equivalent URIs. The URI sip:user@host:5060 will always | |
resolve to port 5060. The URI sip:user@host may resolve to | |
other ports through the DNS SRV mechanisms detailed in [4]. | |
o URI uri-parameter components are compared as follows: | |
- Any uri-parameter appearing in both URIs must match. | |
- A user, ttl, or method uri-parameter appearing in only one | |
URI never matches, even if it contains the default value. | |
- A URI that includes an maddr parameter will not match a URI | |
that contains no maddr parameter. | |
- All other uri-parameters appearing in only one URI are | |
ignored when comparing the URIs. | |
Rosenberg, et. al. Standards Track [Page 154] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o URI header components are never ignored. Any present header | |
component MUST be present in both URIs and match for the URIs | |
to match. The matching rules are defined for each header field | |
in Section 20. | |
The URIs within each of the following sets are equivalent: | |
sip:%61lice@atlanta.com;transport=TCP | |
sip:alice@AtLanTa.CoM;Transport=tcp | |
sip:carol@chicago.com | |
sip:carol@chicago.com;newparam=5 | |
sip:carol@chicago.com;security=on | |
sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com | |
sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com | |
sip:alice@atlanta.com?subject=project%20x&priority=urgent | |
sip:alice@atlanta.com?priority=urgent&subject=project%20x | |
The URIs within each of the following sets are not equivalent: | |
SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) | |
sip:alice@AtLanTa.CoM;Transport=UDP | |
sip:bob@biloxi.com (can resolve to different ports) | |
sip:bob@biloxi.com:5060 | |
sip:bob@biloxi.com (can resolve to different transports) | |
sip:bob@biloxi.com;transport=udp | |
sip:bob@biloxi.com (can resolve to different port and transports) | |
sip:bob@biloxi.com:6000;transport=tcp | |
sip:carol@chicago.com (different header component) | |
sip:carol@chicago.com?Subject=next%20meeting | |
sip:bob@phone21.boxesbybob.com (even though that's what | |
sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) | |
Note that equality is not transitive: | |
o sip:carol@chicago.com and sip:carol@chicago.com;security=on are | |
equivalent | |
o sip:carol@chicago.com and sip:carol@chicago.com;security=off | |
are equivalent | |
Rosenberg, et. al. Standards Track [Page 155] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o sip:carol@chicago.com;security=on and | |
sip:carol@chicago.com;security=off are not equivalent | |
19.1.5 Forming Requests from a URI | |
An implementation needs to take care when forming requests directly | |
from a URI. URIs from business cards, web pages, and even from | |
sources inside the protocol such as registered contacts may contain | |
inappropriate header fields or body parts. | |
An implementation MUST include any provided transport, maddr, ttl, or | |
user parameter in the Request-URI of the formed request. If the URI | |
contains a method parameter, its value MUST be used as the method of | |
the request. The method parameter MUST NOT be placed in the | |
Request-URI. Unknown URI parameters MUST be placed in the message's | |
Request-URI. | |
An implementation SHOULD treat the presence of any headers or body | |
parts in the URI as a desire to include them in the message, and | |
choose to honor the request on a per-component basis. | |
An implementation SHOULD NOT honor these obviously dangerous header | |
fields: From, Call-ID, CSeq, Via, and Record-Route. | |
An implementation SHOULD NOT honor any requested Route header field | |
values in order to not be used as an unwitting agent in malicious | |
attacks. | |
An implementation SHOULD NOT honor requests to include header fields | |
that may cause it to falsely advertise its location or capabilities. | |
These include: Accept, Accept-Encoding, Accept-Language, Allow, | |
Contact (in its dialog usage), Organization, Supported, and User- | |
Agent. | |
An implementation SHOULD verify the accuracy of any requested | |
descriptive header fields, including: Content-Disposition, Content- | |
Encoding, Content-Language, Content-Length, Content-Type, Date, | |
Mime-Version, and Timestamp. | |
If the request formed from constructing a message from a given URI is | |
not a valid SIP request, the URI is invalid. An implementation MUST | |
NOT proceed with transmitting the request. It should instead pursue | |
the course of action due an invalid URI in the context it occurs. | |
The constructed request can be invalid in many ways. These | |
include, but are not limited to, syntax error in header fields, | |
invalid combinations of URI parameters, or an incorrect | |
description of the message body. | |
Rosenberg, et. al. Standards Track [Page 156] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Sending a request formed from a given URI may require capabilities | |
unavailable to the implementation. The URI might indicate use of an | |
unimplemented transport or extension, for example. An implementation | |
SHOULD refuse to send these requests rather than modifying them to | |
match their capabilities. An implementation MUST NOT send a request | |
requiring an extension that it does not support. | |
For example, such a request can be formed through the presence of | |
a Require header parameter or a method URI parameter with an | |
unknown or explicitly unsupported value. | |
19.1.6 Relating SIP URIs and tel URLs | |
When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the | |
entire telephone-subscriber portion of the tel URL, including any | |
parameters, is placed into the userinfo part of the SIP or SIPS URI. | |
Thus, tel:+358-555-1234567;postd=pp22 becomes | |
sip:+358-555-1234567;postd=pp22@foo.com;user=phone | |
or | |
sips:+358-555-1234567;postd=pp22@foo.com;user=phone | |
not | |
sip:+358-555-1234567@foo.com;postd=pp22;user=phone | |
or | |
sips:+358-555-1234567@foo.com;postd=pp22;user=phone | |
In general, equivalent "tel" URLs converted to SIP or SIPS URIs in | |
this fashion may not produce equivalent SIP or SIPS URIs. The | |
userinfo of SIP and SIPS URIs are compared as a case-sensitive | |
string. Variance in case-insensitive portions of tel URLs and | |
reordering of tel URL parameters does not affect tel URL equivalence, | |
but does affect the equivalence of SIP URIs formed from them. | |
For example, | |
tel:+358-555-1234567;postd=pp22 | |
tel:+358-555-1234567;POSTD=PP22 | |
are equivalent, while | |
sip:+358-555-1234567;postd=pp22@foo.com;user=phone | |
sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone | |
Rosenberg, et. al. Standards Track [Page 157] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
are not. | |
Likewise, | |
tel:+358-555-1234567;postd=pp22;isub=1411 | |
tel:+358-555-1234567;isub=1411;postd=pp22 | |
are equivalent, while | |
sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone | |
sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone | |
are not. | |
To mitigate this problem, elements constructing telephone-subscriber | |
fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold | |
any case-insensitive portion of telephone-subscriber to lower case, | |
and order the telephone-subscriber parameters lexically by parameter | |
name, excepting isdn-subaddress and post-dial, which occur first and | |
in that order. (All components of a tel URL except for future- | |
extension parameters are defined to be compared case-insensitive.) | |
Following this suggestion, both | |
tel:+358-555-1234567;postd=pp22 | |
tel:+358-555-1234567;POSTD=PP22 | |
become | |
sip:+358-555-1234567;postd=pp22@foo.com;user=phone | |
and both | |
tel:+358-555-1234567;tsp=a.b;phone-context=5 | |
tel:+358-555-1234567;phone-context=5;tsp=a.b | |
become | |
sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone | |
19.2 Option Tags | |
Option tags are unique identifiers used to designate new options | |
(extensions) in SIP. These tags are used in Require (Section 20.32), | |
Proxy-Require (Section 20.29), Supported (Section 20.37) and | |
Unsupported (Section 20.40) header fields. Note that these options | |
appear as parameters in those header fields in an option-tag = token | |
form (see Section 25 for the definition of token). | |
Rosenberg, et. al. Standards Track [Page 158] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Option tags are defined in standards track RFCs. This is a change | |
from past practice, and is instituted to ensure continuing multi- | |
vendor interoperability (see discussion in Section 20.32 and Section | |
20.37). An IANA registry of option tags is used to ensure easy | |
reference. | |
19.3 Tags | |
The "tag" parameter is used in the To and From header fields of SIP | |
messages. It serves as a general mechanism to identify a dialog, | |
which is the combination of the Call-ID along with two tags, one from | |
each participant in the dialog. When a UA sends a request outside of | |
a dialog, it contains a From tag only, providing "half" of the dialog | |
ID. The dialog is completed from the response(s), each of which | |
contributes the second half in the To header field. The forking of | |
SIP requests means that multiple dialogs can be established from a | |
single request. This also explains the need for the two-sided dialog | |
identifier; without a contribution from the recipients, the | |
originator could not disambiguate the multiple dialogs established | |
from a single request. | |
When a tag is generated by a UA for insertion into a request or | |
response, it MUST be globally unique and cryptographically random | |
with at least 32 bits of randomness. A property of this selection | |
requirement is that a UA will place a different tag into the From | |
header of an INVITE than it would place into the To header of the | |
response to the same INVITE. This is needed in order for a UA to | |
invite itself to a session, a common case for "hairpinning" of calls | |
in PSTN gateways. Similarly, two INVITEs for different calls will | |
have different From tags, and two responses for different calls will | |
have different To tags. | |
Besides the requirement for global uniqueness, the algorithm for | |
generating a tag is implementation-specific. Tags are helpful in | |
fault tolerant systems, where a dialog is to be recovered on an | |
alternate server after a failure. A UAS can select the tag in such a | |
way that a backup can recognize a request as part of a dialog on the | |
failed server, and therefore determine that it should attempt to | |
recover the dialog and any other state associated with it. | |
20 Header Fields | |
The general syntax for header fields is covered in Section 7.3. This | |
section lists the full set of header fields along with notes on | |
syntax, meaning, and usage. Throughout this section, we use [HX.Y] | |
to refer to Section X.Y of the current HTTP/1.1 specification RFC | |
2616 [8]. Examples of each header field are given. | |
Rosenberg, et. al. Standards Track [Page 159] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Information about header fields in relation to methods and proxy | |
processing is summarized in Tables 2 and 3. | |
The "where" column describes the request and response types in which | |
the header field can be used. Values in this column are: | |
R: header field may only appear in requests; | |
r: header field may only appear in responses; | |
2xx, 4xx, etc.: A numerical value or range indicates response | |
codes with which the header field can be used; | |
c: header field is copied from the request to the response. | |
An empty entry in the "where" column indicates that the header | |
field may be present in all requests and responses. | |
The "proxy" column describes the operations a proxy may perform on a | |
header field: | |
a: A proxy can add or concatenate the header field if not present. | |
m: A proxy can modify an existing header field value. | |
d: A proxy can delete a header field value. | |
r: A proxy must be able to read the header field, and thus this | |
header field cannot be encrypted. | |
The next six columns relate to the presence of a header field in a | |
method: | |
c: Conditional; requirements on the header field depend on the | |
context of the message. | |
m: The header field is mandatory. | |
m*: The header field SHOULD be sent, but clients/servers need to | |
be prepared to receive messages without that header field. | |
o: The header field is optional. | |
t: The header field SHOULD be sent, but clients/servers need to be | |
prepared to receive messages without that header field. | |
If a stream-based protocol (such as TCP) is used as a | |
transport, then the header field MUST be sent. | |
Rosenberg, et. al. Standards Track [Page 160] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
*: The header field is required if the message body is not empty. | |
See Sections 20.14, 20.15 and 7.4 for details. | |
-: The header field is not applicable. | |
"Optional" means that an element MAY include the header field in a | |
request or response, and a UA MAY ignore the header field if present | |
in the request or response (The exception to this rule is the Require | |
header field discussed in 20.32). A "mandatory" header field MUST be | |
present in a request, and MUST be understood by the UAS receiving the | |
request. A mandatory response header field MUST be present in the | |
response, and the header field MUST be understood by the UAC | |
processing the response. "Not applicable" means that the header | |
field MUST NOT be present in a request. If one is placed in a | |
request by mistake, it MUST be ignored by the UAS receiving the | |
request. Similarly, a header field labeled "not applicable" for a | |
response means that the UAS MUST NOT place the header field in the | |
response, and the UAC MUST ignore the header field in the response. | |
A UA SHOULD ignore extension header parameters that are not | |
understood. | |
A compact form of some common header field names is also defined for | |
use when overall message size is an issue. | |
The Contact, From, and To header fields contain a URI. If the URI | |
contains a comma, question mark or semicolon, the URI MUST be | |
enclosed in angle brackets (< and >). Any URI parameters are | |
contained within these brackets. If the URI is not enclosed in angle | |
brackets, any semicolon-delimited parameters are header-parameters, | |
not URI parameters. | |
20.1 Accept | |
The Accept header field follows the syntax defined in [H14.1]. The | |
semantics are also identical, with the exception that if no Accept | |
header field is present, the server SHOULD assume a default value of | |
application/sdp. | |
An empty Accept header field means that no formats are acceptable. | |
Rosenberg, et. al. Standards Track [Page 161] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Example: | |
Header field where proxy ACK BYE CAN INV OPT REG | |
___________________________________________________________ | |
Accept R - o - o m* o | |
Accept 2xx - - - o m* o | |
Accept 415 - c - c c c | |
Accept-Encoding R - o - o o o | |
Accept-Encoding 2xx - - - o m* o | |
Accept-Encoding 415 - c - c c c | |
Accept-Language R - o - o o o | |
Accept-Language 2xx - - - o m* o | |
Accept-Language 415 - c - c c c | |
Alert-Info R ar - - - o - - | |
Alert-Info 180 ar - - - o - - | |
Allow R - o - o o o | |
Allow 2xx - o - m* m* o | |
Allow r - o - o o o | |
Allow 405 - m - m m m | |
Authentication-Info 2xx - o - o o o | |
Authorization R o o o o o o | |
Call-ID c r m m m m m m | |
Call-Info ar - - - o o o | |
Contact R o - - m o o | |
Contact 1xx - - - o - - | |
Contact 2xx - - - m o o | |
Contact 3xx d - o - o o o | |
Contact 485 - o - o o o | |
Content-Disposition o o - o o o | |
Content-Encoding o o - o o o | |
Content-Language o o - o o o | |
Content-Length ar t t t t t t | |
Content-Type * * - * * * | |
CSeq c r m m m m m m | |
Date a o o o o o o | |
Error-Info 300-699 a - o o o o o | |
Expires - - - o - o | |
From c r m m m m m m | |
In-Reply-To R - - - o - - | |
Max-Forwards R amr m m m m m m | |
Min-Expires 423 - - - - - m | |
MIME-Version o o - o o o | |
Organization ar - - - o o o | |
Table 2: Summary of header fields, A--O | |
Rosenberg, et. al. Standards Track [Page 162] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Header field where proxy ACK BYE CAN INV OPT REG | |
___________________________________________________________________ | |
Priority R ar - - - o - - | |
Proxy-Authenticate 407 ar - m - m m m | |
Proxy-Authenticate 401 ar - o o o o o | |
Proxy-Authorization R dr o o - o o o | |
Proxy-Require R ar - o - o o o | |
Record-Route R ar o o o o o - | |
Record-Route 2xx,18x mr - o o o o - | |
Reply-To - - - o - - | |
Require ar - c - c c c | |
Retry-After 404,413,480,486 - o o o o o | |
500,503 - o o o o o | |
600,603 - o o o o o | |
Route R adr c c c c c c | |
Server r - o o o o o | |
Subject R - - - o - - | |
Supported R - o o m* o o | |
Supported 2xx - o o m* m* o | |
Timestamp o o o o o o | |
To c(1) r m m m m m m | |
Unsupported 420 - m - m m m | |
User-Agent o o o o o o | |
Via R amr m m m m m m | |
Via rc dr m m m m m m | |
Warning r - o o o o o | |
WWW-Authenticate 401 ar - m - m m m | |
WWW-Authenticate 407 ar - o - o o o | |
Table 3: Summary of header fields, P--Z; (1): copied with possible | |
addition of tag | |
Accept: application/sdp;level=1, application/x-private, text/html | |
20.2 Accept-Encoding | |
The Accept-Encoding header field is similar to Accept, but restricts | |
the content-codings [H3.5] that are acceptable in the response. See | |
[H14.3]. The semantics in SIP are identical to those defined in | |
[H14.3]. | |
An empty Accept-Encoding header field is permissible. It is | |
equivalent to Accept-Encoding: identity, that is, only the identity | |
encoding, meaning no encoding, is permissible. | |
If no Accept-Encoding header field is present, the server SHOULD | |
assume a default value of identity. | |
Rosenberg, et. al. Standards Track [Page 163] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
This differs slightly from the HTTP definition, which indicates that | |
when not present, any encoding can be used, but the identity encoding | |
is preferred. | |
Example: | |
Accept-Encoding: gzip | |
20.3 Accept-Language | |
The Accept-Language header field is used in requests to indicate the | |
preferred languages for reason phrases, session descriptions, or | |
status responses carried as message bodies in the response. If no | |
Accept-Language header field is present, the server SHOULD assume all | |
languages are acceptable to the client. | |
The Accept-Language header field follows the syntax defined in | |
[H14.4]. The rules for ordering the languages based on the "q" | |
parameter apply to SIP as well. | |
Example: | |
Accept-Language: da, en-gb;q=0.8, en;q=0.7 | |
20.4 Alert-Info | |
When present in an INVITE request, the Alert-Info header field | |
specifies an alternative ring tone to the UAS. When present in a 180 | |
(Ringing) response, the Alert-Info header field specifies an | |
alternative ringback tone to the UAC. A typical usage is for a proxy | |
to insert this header field to provide a distinctive ring feature. | |
The Alert-Info header field can introduce security risks. These | |
risks and the ways to handle them are discussed in Section 20.9, | |
which discusses the Call-Info header field since the risks are | |
identical. | |
In addition, a user SHOULD be able to disable this feature | |
selectively. | |
This helps prevent disruptions that could result from the use of | |
this header field by untrusted elements. | |
Example: | |
Alert-Info: <http://www.example.com/sounds/moo.wav> | |
Rosenberg, et. al. Standards Track [Page 164] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
20.5 Allow | |
The Allow header field lists the set of methods supported by the UA | |
generating the message. | |
All methods, including ACK and CANCEL, understood by the UA MUST be | |
included in the list of methods in the Allow header field, when | |
present. The absence of an Allow header field MUST NOT be | |
interpreted to mean that the UA sending the message supports no | |
methods. Rather, it implies that the UA is not providing any | |
information on what methods it supports. | |
Supplying an Allow header field in responses to methods other than | |
OPTIONS reduces the number of messages needed. | |
Example: | |
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE | |
20.6 Authentication-Info | |
The Authentication-Info header field provides for mutual | |
authentication with HTTP Digest. A UAS MAY include this header field | |
in a 2xx response to a request that was successfully authenticated | |
using digest based on the Authorization header field. | |
Syntax and semantics follow those specified in RFC 2617 [17]. | |
Example: | |
Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c" | |
20.7 Authorization | |
The Authorization header field contains authentication credentials of | |
a UA. Section 22.2 overviews the use of the Authorization header | |
field, and Section 22.4 describes the syntax and semantics when used | |
with HTTP authentication. | |
This header field, along with Proxy-Authorization, breaks the general | |
rules about multiple header field values. Although not a comma- | |
separated list, this header field name may be present multiple times, | |
and MUST NOT be combined into a single header line using the usual | |
rules described in Section 7.3. | |
Rosenberg, et. al. Standards Track [Page 165] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
In the example below, there are no quotes around the Digest | |
parameter: | |
Authorization: Digest username="Alice", realm="atlanta.com", | |
nonce="84a4cc6f3082121f32b42a2187831a9e", | |
response="7587245234b3434cc3412213e5f113a5432" | |
20.8 Call-ID | |
The Call-ID header field uniquely identifies a particular invitation | |
or all registrations of a particular client. A single multimedia | |
conference can give rise to several calls with different Call-IDs, | |
for example, if a user invites a single individual several times to | |
the same (long-running) conference. Call-IDs are case-sensitive and | |
are simply compared byte-by-byte. | |
The compact form of the Call-ID header field is i. | |
Examples: | |
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com | |
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 | |
20.9 Call-Info | |
The Call-Info header field provides additional information about the | |
caller or callee, depending on whether it is found in a request or | |
response. The purpose of the URI is described by the "purpose" | |
parameter. The "icon" parameter designates an image suitable as an | |
iconic representation of the caller or callee. The "info" parameter | |
describes the caller or callee in general, for example, through a web | |
page. The "card" parameter provides a business card, for example, in | |
vCard [36] or LDIF [37] formats. Additional tokens can be registered | |
using IANA and the procedures in Section 27. | |
Use of the Call-Info header field can pose a security risk. If a | |
callee fetches the URIs provided by a malicious caller, the callee | |
may be at risk for displaying inappropriate or offensive content, | |
dangerous or illegal content, and so on. Therefore, it is | |
RECOMMENDED that a UA only render the information in the Call-Info | |
header field if it can verify the authenticity of the element that | |
originated the header field and trusts that element. This need not | |
be the peer UA; a proxy can insert this header field into requests. | |
Example: | |
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, | |
<http://www.example.com/alice/> ;purpose=info | |
Rosenberg, et. al. Standards Track [Page 166] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
20.10 Contact | |
A Contact header field value provides a URI whose meaning depends on | |
the type of request or response it is in. | |
A Contact header field value can contain a display name, a URI with | |
URI parameters, and header parameters. | |
This document defines the Contact parameters "q" and "expires". | |
These parameters are only used when the Contact is present in a | |
REGISTER request or response, or in a 3xx response. Additional | |
parameters may be defined in other specifications. | |
When the header field value contains a display name, the URI | |
including all URI parameters is enclosed in "<" and ">". If no "<" | |
and ">" are present, all parameters after the URI are header | |
parameters, not URI parameters. The display name can be tokens, or a | |
quoted string, if a larger character set is desired. | |
Even if the "display-name" is empty, the "name-addr" form MUST be | |
used if the "addr-spec" contains a comma, semicolon, or question | |
mark. There may or may not be LWS between the display-name and the | |
"<". | |
These rules for parsing a display name, URI and URI parameters, and | |
header parameters also apply for the header fields To and From. | |
The Contact header field has a role similar to the Location header | |
field in HTTP. However, the HTTP header field only allows one | |
address, unquoted. Since URIs can contain commas and semicolons | |
as reserved characters, they can be mistaken for header or | |
parameter delimiters, respectively. | |
The compact form of the Contact header field is m (for "moved"). | |
Examples: | |
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com> | |
;q=0.7; expires=3600, | |
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1 | |
m: <sips:bob@192.0.2.4>;expires=60 | |
Rosenberg, et. al. Standards Track [Page 167] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
20.11 Content-Disposition | |
The Content-Disposition header field describes how the message body | |
or, for multipart messages, a message body part is to be interpreted | |
by the UAC or UAS. This SIP header field extends the MIME Content- | |
Type (RFC 2183 [18]). | |
Several new "disposition-types" of the Content-Disposition header are | |
defined by SIP. The value "session" indicates that the body part | |
describes a session, for either calls or early (pre-call) media. The | |
value "render" indicates that the body part should be displayed or | |
otherwise rendered to the user. Note that the value "render" is used | |
rather than "inline" to avoid the connotation that the MIME body is | |
displayed as a part of the rendering of the entire message (since the | |
MIME bodies of SIP messages oftentimes are not displayed to users). | |
For backward-compatibility, if the Content-Disposition header field | |
is missing, the server SHOULD assume bodies of Content-Type | |
application/sdp are the disposition "session", while other content | |
types are "render". | |
The disposition type "icon" indicates that the body part contains an | |
image suitable as an iconic representation of the caller or callee | |
that could be rendered informationally by a user agent when a message | |
has been received, or persistently while a dialog takes place. The | |
value "alert" indicates that the body part contains information, such | |
as an audio clip, that should be rendered by the user agent in an | |
attempt to alert the user to the receipt of a request, generally a | |
request that initiates a dialog; this alerting body could for example | |
be rendered as a ring tone for a phone call after a 180 Ringing | |
provisional response has been sent. | |
Any MIME body with a "disposition-type" that renders content to the | |
user should only be processed when a message has been properly | |
authenticated. | |
The handling parameter, handling-param, describes how the UAS should | |
react if it receives a message body whose content type or disposition | |
type it does not understand. The parameter has defined values of | |
"optional" and "required". If the handling parameter is missing, the | |
value "required" SHOULD be assumed. The handling parameter is | |
described in RFC 3204 [19]. | |
If this header field is missing, the MIME type determines the default | |
content disposition. If there is none, "render" is assumed. | |
Example: | |
Content-Disposition: session | |
Rosenberg, et. al. Standards Track [Page 168] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
20.12 Content-Encoding | |
The Content-Encoding header field is used as a modifier to the | |
"media-type". When present, its value indicates what additional | |
content codings have been applied to the entity-body, and thus what | |
decoding mechanisms MUST be applied in order to obtain the media-type | |
referenced by the Content-Type header field. Content-Encoding is | |
primarily used to allow a body to be compressed without losing the | |
identity of its underlying media type. | |
If multiple encodings have been applied to an entity-body, the | |
content codings MUST be listed in the order in which they were | |
applied. | |
All content-coding values are case-insensitive. IANA acts as a | |
registry for content-coding value tokens. See [H3.5] for a | |
definition of the syntax for content-coding. | |
Clients MAY apply content encodings to the body in requests. A | |
server MAY apply content encodings to the bodies in responses. The | |
server MUST only use encodings listed in the Accept-Encoding header | |
field in the request. | |
The compact form of the Content-Encoding header field is e. | |
Examples: | |
Content-Encoding: gzip | |
e: tar | |
20.13 Content-Language | |
See [H14.12]. Example: | |
Content-Language: fr | |
20.14 Content-Length | |
The Content-Length header field indicates the size of the message- | |
body, in decimal number of octets, sent to the recipient. | |
Applications SHOULD use this field to indicate the size of the | |
message-body to be transferred, regardless of the media type of the | |
entity. If a stream-based protocol (such as TCP) is used as | |
transport, the header field MUST be used. | |
The size of the message-body does not include the CRLF separating | |
header fields and body. Any Content-Length greater than or equal to | |
zero is a valid value. If no body is present in a message, then the | |
Content-Length header field value MUST be set to zero. | |
Rosenberg, et. al. Standards Track [Page 169] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The ability to omit Content-Length simplifies the creation of | |
cgi-like scripts that dynamically generate responses. | |
The compact form of the header field is l. | |
Examples: | |
Content-Length: 349 | |
l: 173 | |
20.15 Content-Type | |
The Content-Type header field indicates the media type of the | |
message-body sent to the recipient. The "media-type" element is | |
defined in [H3.7]. The Content-Type header field MUST be present if | |
the body is not empty. If the body is empty, and a Content-Type | |
header field is present, it indicates that the body of the specific | |
type has zero length (for example, an empty audio file). | |
The compact form of the header field is c. | |
Examples: | |
Content-Type: application/sdp | |
c: text/html; charset=ISO-8859-4 | |
20.16 CSeq | |
A CSeq header field in a request contains a single decimal sequence | |
number and the request method. The sequence number MUST be | |
expressible as a 32-bit unsigned integer. The method part of CSeq is | |
case-sensitive. The CSeq header field serves to order transactions | |
within a dialog, to provide a means to uniquely identify | |
transactions, and to differentiate between new requests and request | |
retransmissions. Two CSeq header fields are considered equal if the | |
sequence number and the request method are identical. Example: | |
CSeq: 4711 INVITE | |
20.17 Date | |
The Date header field contains the date and time. Unlike HTTP/1.1, | |
SIP only supports the most recent RFC 1123 [20] format for dates. As | |
in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while | |
RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive. | |
The Date header field reflects the time when the request or response | |
is first sent. | |
Rosenberg, et. al. Standards Track [Page 170] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The Date header field can be used by simple end systems without a | |
battery-backed clock to acquire a notion of current time. | |
However, in its GMT form, it requires clients to know their offset | |
from GMT. | |
Example: | |
Date: Sat, 13 Nov 2010 23:29:00 GMT | |
20.18 Error-Info | |
The Error-Info header field provides a pointer to additional | |
information about the error status response. | |
SIP UACs have user interface capabilities ranging from pop-up | |
windows and audio on PC softclients to audio-only on "black" | |
phones or endpoints connected via gateways. Rather than forcing a | |
server generating an error to choose between sending an error | |
status code with a detailed reason phrase and playing an audio | |
recording, the Error-Info header field allows both to be sent. | |
The UAC then has the choice of which error indicator to render to | |
the caller. | |
A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if | |
it were a Contact in a redirect and generate a new INVITE, resulting | |
in a recorded announcement session being established. A non-SIP URI | |
MAY be rendered to the user. | |
Examples: | |
SIP/2.0 404 The number you have dialed is not in service | |
Error-Info: <sip:not-in-service-recording@atlanta.com> | |
20.19 Expires | |
The Expires header field gives the relative time after which the | |
message (or content) expires. | |
The precise meaning of this is method dependent. | |
The expiration time in an INVITE does not affect the duration of the | |
actual session that may result from the invitation. Session | |
description protocols may offer the ability to express time limits on | |
the session duration, however. | |
The value of this field is an integral number of seconds (in decimal) | |
between 0 and (2**32)-1, measured from the receipt of the request. | |
Rosenberg, et. al. Standards Track [Page 171] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Example: | |
Expires: 5 | |
20.20 From | |
The From header field indicates the initiator of the request. This | |
may be different from the initiator of the dialog. Requests sent by | |
the callee to the caller use the callee's address in the From header | |
field. | |
The optional "display-name" is meant to be rendered by a human user | |
interface. A system SHOULD use the display name "Anonymous" if the | |
identity of the client is to remain hidden. Even if the "display- | |
name" is empty, the "name-addr" form MUST be used if the "addr-spec" | |
contains a comma, question mark, or semicolon. Syntax issues are | |
discussed in Section 7.3.1. | |
Two From header fields are equivalent if their URIs match, and their | |
parameters match. Extension parameters in one header field, not | |
present in the other are ignored for the purposes of comparison. This | |
means that the display name and presence or absence of angle brackets | |
do not affect matching. | |
See Section 20.10 for the rules for parsing a display name, URI and | |
URI parameters, and header field parameters. | |
The compact form of the From header field is f. | |
Examples: | |
From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s | |
From: sip:+12125551212@server.phone2net.com;tag=887s | |
f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 | |
20.21 In-Reply-To | |
The In-Reply-To header field enumerates the Call-IDs that this call | |
references or returns. These Call-IDs may have been cached by the | |
client then included in this header field in a return call. | |
This allows automatic call distribution systems to route return | |
calls to the originator of the first call. This also allows | |
callees to filter calls, so that only return calls for calls they | |
originated will be accepted. This field is not a substitute for | |
request authentication. | |
Rosenberg, et. al. Standards Track [Page 172] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Example: | |
In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com | |
20.22 Max-Forwards | |
The Max-Forwards header field must be used with any SIP method to | |
limit the number of proxies or gateways that can forward the request | |
to the next downstream server. This can also be useful when the | |
client is attempting to trace a request chain that appears to be | |
failing or looping in mid-chain. | |
The Max-Forwards value is an integer in the range 0-255 indicating | |
the remaining number of times this request message is allowed to be | |
forwarded. This count is decremented by each server that forwards | |
the request. The recommended initial value is 70. | |
This header field should be inserted by elements that can not | |
otherwise guarantee loop detection. For example, a B2BUA should | |
insert a Max-Forwards header field. | |
Example: | |
Max-Forwards: 6 | |
20.23 Min-Expires | |
The Min-Expires header field conveys the minimum refresh interval | |
supported for soft-state elements managed by that server. This | |
includes Contact header fields that are stored by a registrar. The | |
header field contains a decimal integer number of seconds from 0 to | |
(2**32)-1. The use of the header field in a 423 (Interval Too Brief) | |
response is described in Sections 10.2.8, 10.3, and 21.4.17. | |
Example: | |
Min-Expires: 60 | |
20.24 MIME-Version | |
See [H19.4.1]. | |
Example: | |
MIME-Version: 1.0 | |
Rosenberg, et. al. Standards Track [Page 173] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
20.25 Organization | |
The Organization header field conveys the name of the organization to | |
which the SIP element issuing the request or response belongs. | |
The field MAY be used by client software to filter calls. | |
Example: | |
Organization: Boxes by Bob | |
20.26 Priority | |
The Priority header field indicates the urgency of the request as | |
perceived by the client. The Priority header field describes the | |
priority that the SIP request should have to the receiving human or | |
its agent. For example, it may be factored into decisions about call | |
routing and acceptance. For these decisions, a message containing no | |
Priority header field SHOULD be treated as if it specified a Priority | |
of "normal". The Priority header field does not influence the use of | |
communications resources such as packet forwarding priority in | |
routers or access to circuits in PSTN gateways. The header field can | |
have the values "non-urgent", "normal", "urgent", and "emergency", | |
but additional values can be defined elsewhere. It is RECOMMENDED | |
that the value of "emergency" only be used when life, limb, or | |
property are in imminent danger. Otherwise, there are no semantics | |
defined for this header field. | |
These are the values of RFC 2076 [38], with the addition of | |
"emergency". | |
Examples: | |
Subject: A tornado is heading our way! | |
Priority: emergency | |
or | |
Subject: Weekend plans | |
Priority: non-urgent | |
20.27 Proxy-Authenticate | |
A Proxy-Authenticate header field value contains an authentication | |
challenge. | |
The use of this header field is defined in [H14.33]. See Section | |
22.3 for further details on its usage. | |
Rosenberg, et. al. Standards Track [Page 174] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Example: | |
Proxy-Authenticate: Digest realm="atlanta.com", | |
domain="sip:ss1.carrier.com", qop="auth", | |
nonce="f84f1cec41e6cbe5aea9c8e88d359", | |
opaque="", stale=FALSE, algorithm=MD5 | |
20.28 Proxy-Authorization | |
The Proxy-Authorization header field allows the client to identify | |
itself (or its user) to a proxy that requires authentication. A | |
Proxy-Authorization field value consists of credentials containing | |
the authentication information of the user agent for the proxy and/or | |
realm of the resource being requested. | |
See Section 22.3 for a definition of the usage of this header field. | |
This header field, along with Authorization, breaks the general rules | |
about multiple header field names. Although not a comma-separated | |
list, this header field name may be present multiple times, and MUST | |
NOT be combined into a single header line using the usual rules | |
described in Section 7.3.1. | |
Example: | |
Proxy-Authorization: Digest username="Alice", realm="atlanta.com", | |
nonce="c60f3082ee1212b402a21831ae", | |
response="245f23415f11432b3434341c022" | |
20.29 Proxy-Require | |
The Proxy-Require header field is used to indicate proxy-sensitive | |
features that must be supported by the proxy. See Section 20.32 for | |
more details on the mechanics of this message and a usage example. | |
Example: | |
Proxy-Require: foo | |
20.30 Record-Route | |
The Record-Route header field is inserted by proxies in a request to | |
force future requests in the dialog to be routed through the proxy. | |
Examples of its use with the Route header field are described in | |
Sections 16.12.1. | |
Rosenberg, et. al. Standards Track [Page 175] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Example: | |
Record-Route: <sip:server10.biloxi.com;lr>, | |
<sip:bigbox3.site3.atlanta.com;lr> | |
20.31 Reply-To | |
The Reply-To header field contains a logical return URI that may be | |
different from the From header field. For example, the URI MAY be | |
used to return missed calls or unestablished sessions. If the user | |
wished to remain anonymous, the header field SHOULD either be omitted | |
from the request or populated in such a way that does not reveal any | |
private information. | |
Even if the "display-name" is empty, the "name-addr" form MUST be | |
used if the "addr-spec" contains a comma, question mark, or | |
semicolon. Syntax issues are discussed in Section 7.3.1. | |
Example: | |
Reply-To: Bob <sip:bob@biloxi.com> | |
20.32 Require | |
The Require header field is used by UACs to tell UASs about options | |
that the UAC expects the UAS to support in order to process the | |
request. Although an optional header field, the Require MUST NOT be | |
ignored if it is present. | |
The Require header field contains a list of option tags, described in | |
Section 19.2. Each option tag defines a SIP extension that MUST be | |
understood to process the request. Frequently, this is used to | |
indicate that a specific set of extension header fields need to be | |
understood. A UAC compliant to this specification MUST only include | |
option tags corresponding to standards-track RFCs. | |
Example: | |
Require: 100rel | |
20.33 Retry-After | |
The Retry-After header field can be used with a 500 (Server Internal | |
Error) or 503 (Service Unavailable) response to indicate how long the | |
service is expected to be unavailable to the requesting client and | |
with a 404 (Not Found), 413 (Request Entity Too Large), 480 | |
(Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 | |
Rosenberg, et. al. Standards Track [Page 176] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
(Decline) response to indicate when the called party anticipates | |
being available again. The value of this field is a positive integer | |
number of seconds (in decimal) after the time of the response. | |
An optional comment can be used to indicate additional information | |
about the time of callback. An optional "duration" parameter | |
indicates how long the called party will be reachable starting at the | |
initial time of availability. If no duration parameter is given, the | |
service is assumed to be available indefinitely. | |
Examples: | |
Retry-After: 18000;duration=3600 | |
Retry-After: 120 (I'm in a meeting) | |
20.34 Route | |
The Route header field is used to force routing for a request through | |
the listed set of proxies. Examples of the use of the Route header | |
field are in Section 16.12.1. | |
Example: | |
Route: <sip:bigbox3.site3.atlanta.com;lr>, | |
<sip:server10.biloxi.com;lr> | |
20.35 Server | |
The Server header field contains information about the software used | |
by the UAS to handle the request. | |
Revealing the specific software version of the server might allow the | |
server to become more vulnerable to attacks against software that is | |
known to contain security holes. Implementers SHOULD make the Server | |
header field a configurable option. | |
Example: | |
Server: HomeServer v2 | |
20.36 Subject | |
The Subject header field provides a summary or indicates the nature | |
of the call, allowing call filtering without having to parse the | |
session description. The session description does not have to use | |
the same subject indication as the invitation. | |
The compact form of the Subject header field is s. | |
Rosenberg, et. al. Standards Track [Page 177] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Example: | |
Subject: Need more boxes | |
s: Tech Support | |
20.37 Supported | |
The Supported header field enumerates all the extensions supported by | |
the UAC or UAS. | |
The Supported header field contains a list of option tags, described | |
in Section 19.2, that are understood by the UAC or UAS. A UA | |
compliant to this specification MUST only include option tags | |
corresponding to standards-track RFCs. If empty, it means that no | |
extensions are supported. | |
The compact form of the Supported header field is k. | |
Example: | |
Supported: 100rel | |
20.38 Timestamp | |
The Timestamp header field describes when the UAC sent the request to | |
the UAS. | |
See Section 8.2.6 for details on how to generate a response to a | |
request that contains the header field. Although there is no | |
normative behavior defined here that makes use of the header, it | |
allows for extensions or SIP applications to obtain RTT estimates. | |
Example: | |
Timestamp: 54 | |
20.39 To | |
The To header field specifies the logical recipient of the request. | |
The optional "display-name" is meant to be rendered by a human-user | |
interface. The "tag" parameter serves as a general mechanism for | |
dialog identification. | |
See Section 19.3 for details of the "tag" parameter. | |
Rosenberg, et. al. Standards Track [Page 178] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Comparison of To header fields for equality is identical to | |
comparison of From header fields. See Section 20.10 for the rules | |
for parsing a display name, URI and URI parameters, and header field | |
parameters. | |
The compact form of the To header field is t. | |
The following are examples of valid To header fields: | |
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447 | |
t: sip:+12125551212@server.phone2net.com | |
20.40 Unsupported | |
The Unsupported header field lists the features not supported by the | |
UAS. See Section 20.32 for motivation. | |
Example: | |
Unsupported: foo | |
20.41 User-Agent | |
The User-Agent header field contains information about the UAC | |
originating the request. The semantics of this header field are | |
defined in [H14.43]. | |
Revealing the specific software version of the user agent might allow | |
the user agent to become more vulnerable to attacks against software | |
that is known to contain security holes. Implementers SHOULD make | |
the User-Agent header field a configurable option. | |
Example: | |
User-Agent: Softphone Beta1.5 | |
20.42 Via | |
The Via header field indicates the path taken by the request so far | |
and indicates the path that should be followed in routing responses. | |
The branch ID parameter in the Via header field values serves as a | |
transaction identifier, and is used by proxies to detect loops. | |
A Via header field value contains the transport protocol used to send | |
the message, the client's host name or network address, and possibly | |
the port number at which it wishes to receive responses. A Via | |
header field value can also contain parameters such as "maddr", | |
"ttl", "received", and "branch", whose meaning and use are described | |
Rosenberg, et. al. Standards Track [Page 179] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
in other sections. For implementations compliant to this | |
specification, the value of the branch parameter MUST start with the | |
magic cookie "z9hG4bK", as discussed in Section 8.1.1.7. | |
Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". | |
"TLS" means TLS over TCP. When a request is sent to a SIPS URI, the | |
protocol still indicates "SIP", and the transport protocol is TLS. | |
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 | |
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 | |
;branch=z9hG4bK77asjd | |
The compact form of the Via header field is v. | |
In this example, the message originated from a multi-homed host with | |
two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong | |
as to which network interface would be used. Erlang.bell- | |
telephone.com noticed the mismatch and added a parameter to the | |
previous hop's Via header field value, containing the address that | |
the packet actually came from. | |
The host or network address and port number are not required to | |
follow the SIP URI syntax. Specifically, LWS on either side of the | |
":" or "/" is allowed, as shown here: | |
Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 | |
;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 | |
Even though this specification mandates that the branch parameter be | |
present in all requests, the BNF for the header field indicates that | |
it is optional. This allows interoperation with RFC 2543 elements, | |
which did not have to insert the branch parameter. | |
Two Via header fields are equal if their sent-protocol and sent-by | |
fields are equal, both have the same set of parameters, and the | |
values of all parameters are equal. | |
20.43 Warning | |
The Warning header field is used to carry additional information | |
about the status of a response. Warning header field values are sent | |
with responses and contain a three-digit warning code, host name, and | |
warning text. | |
The "warn-text" should be in a natural language that is most likely | |
to be intelligible to the human user receiving the response. This | |
decision can be based on any available knowledge, such as the | |
location of the user, the Accept-Language field in a request, or the | |
Rosenberg, et. al. Standards Track [Page 180] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Content-Language field in a response. The default language is i- | |
default [21]. | |
The currently-defined "warn-code"s are listed below, with a | |
recommended warn-text in English and a description of their meaning. | |
These warnings describe failures induced by the session description. | |
The first digit of warning codes beginning with "3" indicates | |
warnings specific to SIP. Warnings 300 through 329 are reserved for | |
indicating problems with keywords in the session description, 330 | |
through 339 are warnings related to basic network services requested | |
in the session description, 370 through 379 are warnings related to | |
quantitative QoS parameters requested in the session description, and | |
390 through 399 are miscellaneous warnings that do not fall into one | |
of the above categories. | |
300 Incompatible network protocol: One or more network protocols | |
contained in the session description are not available. | |
301 Incompatible network address formats: One or more network | |
address formats contained in the session description are not | |
available. | |
302 Incompatible transport protocol: One or more transport | |
protocols described in the session description are not | |
available. | |
303 Incompatible bandwidth units: One or more bandwidth | |
measurement units contained in the session description were | |
not understood. | |
304 Media type not available: One or more media types contained in | |
the session description are not available. | |
305 Incompatible media format: One or more media formats contained | |
in the session description are not available. | |
306 Attribute not understood: One or more of the media attributes | |
in the session description are not supported. | |
307 Session description parameter not understood: A parameter | |
other than those listed above was not understood. | |
330 Multicast not available: The site where the user is located | |
does not support multicast. | |
331 Unicast not available: The site where the user is located does | |
not support unicast communication (usually due to the presence | |
of a firewall). | |
Rosenberg, et. al. Standards Track [Page 181] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
370 Insufficient bandwidth: The bandwidth specified in the session | |
description or defined by the media exceeds that known to be | |
available. | |
399 Miscellaneous warning: The warning text can include arbitrary | |
information to be presented to a human user or logged. A | |
system receiving this warning MUST NOT take any automated | |
action. | |
1xx and 2xx have been taken by HTTP/1.1. | |
Additional "warn-code"s can be defined through IANA, as defined in | |
Section 27.2. | |
Examples: | |
Warning: 307 isi.edu "Session parameter 'foo' not understood" | |
Warning: 301 isi.edu "Incompatible network address type 'E.164'" | |
20.44 WWW-Authenticate | |
A WWW-Authenticate header field value contains an authentication | |
challenge. See Section 22.2 for further details on its usage. | |
Example: | |
WWW-Authenticate: Digest realm="atlanta.com", | |
domain="sip:boxesbybob.com", qop="auth", | |
nonce="f84f1cec41e6cbe5aea9c8e88d359", | |
opaque="", stale=FALSE, algorithm=MD5 | |
21 Response Codes | |
The response codes are consistent with, and extend, HTTP/1.1 response | |
codes. Not all HTTP/1.1 response codes are appropriate, and only | |
those that are appropriate are given here. Other HTTP/1.1 response | |
codes SHOULD NOT be used. Also, SIP defines a new class, 6xx. | |
21.1 Provisional 1xx | |
Provisional responses, also known as informational responses, | |
indicate that the server contacted is performing some further action | |
and does not yet have a definitive response. A server sends a 1xx | |
response if it expects to take more than 200 ms to obtain a final | |
response. Note that 1xx responses are not transmitted reliably. | |
They never cause the client to send an ACK. Provisional (1xx) | |
responses MAY contain message bodies, including session descriptions. | |
Rosenberg, et. al. Standards Track [Page 182] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
21.1.1 100 Trying | |
This response indicates that the request has been received by the | |
next-hop server and that some unspecified action is being taken on | |
behalf of this call (for example, a database is being consulted). | |
This response, like all other provisional responses, stops | |
retransmissions of an INVITE by a UAC. The 100 (Trying) response is | |
different from other provisional responses, in that it is never | |
forwarded upstream by a stateful proxy. | |
21.1.2 180 Ringing | |
The UA receiving the INVITE is trying to alert the user. This | |
response MAY be used to initiate local ringback. | |
21.1.3 181 Call Is Being Forwarded | |
A server MAY use this status code to indicate that the call is being | |
forwarded to a different set of destinations. | |
21.1.4 182 Queued | |
The called party is temporarily unavailable, but the server has | |
decided to queue the call rather than reject it. When the callee | |
becomes available, it will return the appropriate final status | |
response. The reason phrase MAY give further details about the | |
status of the call, for example, "5 calls queued; expected waiting | |
time is 15 minutes". The server MAY issue several 182 (Queued) | |
responses to update the caller about the status of the queued call. | |
21.1.5 183 Session Progress | |
The 183 (Session Progress) response is used to convey information | |
about the progress of the call that is not otherwise classified. The | |
Reason-Phrase, header fields, or message body MAY be used to convey | |
more details about the call progress. | |
21.2 Successful 2xx | |
The request was successful. | |
21.2.1 200 OK | |
The request has succeeded. The information returned with the | |
response depends on the method used in the request. | |
Rosenberg, et. al. Standards Track [Page 183] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
21.3 Redirection 3xx | |
3xx responses give information about the user's new location, or | |
about alternative services that might be able to satisfy the call. | |
21.3.1 300 Multiple Choices | |
The address in the request resolved to several choices, each with its | |
own specific location, and the user (or UA) can select a preferred | |
communication end point and redirect its request to that location. | |
The response MAY include a message body containing a list of resource | |
characteristics and location(s) from which the user or UA can choose | |
the one most appropriate, if allowed by the Accept request header | |
field. However, no MIME types have been defined for this message | |
body. | |
The choices SHOULD also be listed as Contact fields (Section 20.10). | |
Unlike HTTP, the SIP response MAY contain several Contact fields or a | |
list of addresses in a Contact field. UAs MAY use the Contact header | |
field value for automatic redirection or MAY ask the user to confirm | |
a choice. However, this specification does not define any standard | |
for such automatic selection. | |
This status response is appropriate if the callee can be reached | |
at several different locations and the server cannot or prefers | |
not to proxy the request. | |
21.3.2 301 Moved Permanently | |
The user can no longer be found at the address in the Request-URI, | |
and the requesting client SHOULD retry at the new address given by | |
the Contact header field (Section 20.10). The requestor SHOULD | |
update any local directories, address books, and user location caches | |
with this new value and redirect future requests to the address(es) | |
listed. | |
21.3.3 302 Moved Temporarily | |
The requesting client SHOULD retry the request at the new address(es) | |
given by the Contact header field (Section 20.10). The Request-URI | |
of the new request uses the value of the Contact header field in the | |
response. | |
Rosenberg, et. al. Standards Track [Page 184] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The duration of the validity of the Contact URI can be indicated | |
through an Expires (Section 20.19) header field or an expires | |
parameter in the Contact header field. Both proxies and UAs MAY | |
cache this URI for the duration of the expiration time. If there is | |
no explicit expiration time, the address is only valid once for | |
recursing, and MUST NOT be cached for future transactions. | |
If the URI cached from the Contact header field fails, the Request- | |
URI from the redirected request MAY be tried again a single time. | |
The temporary URI may have become out-of-date sooner than the | |
expiration time, and a new temporary URI may be available. | |
21.3.4 305 Use Proxy | |
The requested resource MUST be accessed through the proxy given by | |
the Contact field. The Contact field gives the URI of the proxy. | |
The recipient is expected to repeat this single request via the | |
proxy. 305 (Use Proxy) responses MUST only be generated by UASs. | |
21.3.5 380 Alternative Service | |
The call was not successful, but alternative services are possible. | |
The alternative services are described in the message body of the | |
response. Formats for such bodies are not defined here, and may be | |
the subject of future standardization. | |
21.4 Request Failure 4xx | |
4xx responses are definite failure responses from a particular | |
server. The client SHOULD NOT retry the same request without | |
modification (for example, adding appropriate authorization). | |
However, the same request to a different server might be successful. | |
21.4.1 400 Bad Request | |
The request could not be understood due to malformed syntax. The | |
Reason-Phrase SHOULD identify the syntax problem in more detail, for | |
example, "Missing Call-ID header field". | |
21.4.2 401 Unauthorized | |
The request requires user authentication. This response is issued by | |
UASs and registrars, while 407 (Proxy Authentication Required) is | |
used by proxy servers. | |
Rosenberg, et. al. Standards Track [Page 185] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
21.4.3 402 Payment Required | |
Reserved for future use. | |
21.4.4 403 Forbidden | |
The server understood the request, but is refusing to fulfill it. | |
Authorization will not help, and the request SHOULD NOT be repeated. | |
21.4.5 404 Not Found | |
The server has definitive information that the user does not exist at | |
the domain specified in the Request-URI. This status is also | |
returned if the domain in the Request-URI does not match any of the | |
domains handled by the recipient of the request. | |
21.4.6 405 Method Not Allowed | |
The method specified in the Request-Line is understood, but not | |
allowed for the address identified by the Request-URI. | |
The response MUST include an Allow header field containing a list of | |
valid methods for the indicated address. | |
21.4.7 406 Not Acceptable | |
The resource identified by the request is only capable of generating | |
response entities that have content characteristics not acceptable | |
according to the Accept header field sent in the request. | |
21.4.8 407 Proxy Authentication Required | |
This code is similar to 401 (Unauthorized), but indicates that the | |
client MUST first authenticate itself with the proxy. SIP access | |
authentication is explained in Sections 26 and 22.3. | |
This status code can be used for applications where access to the | |
communication channel (for example, a telephony gateway) rather than | |
the callee requires authentication. | |
21.4.9 408 Request Timeout | |
The server could not produce a response within a suitable amount of | |
time, for example, if it could not determine the location of the user | |
in time. The client MAY repeat the request without modifications at | |
any later time. | |
Rosenberg, et. al. Standards Track [Page 186] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
21.4.10 410 Gone | |
The requested resource is no longer available at the server and no | |
forwarding address is known. This condition is expected to be | |
considered permanent. If the server does not know, or has no | |
facility to determine, whether or not the condition is permanent, the | |
status code 404 (Not Found) SHOULD be used instead. | |
21.4.11 413 Request Entity Too Large | |
The server is refusing to process a request because the request | |
entity-body is larger than the server is willing or able to process. | |
The server MAY close the connection to prevent the client from | |
continuing the request. | |
If the condition is temporary, the server SHOULD include a Retry- | |
After header field to indicate that it is temporary and after what | |
time the client MAY try again. | |
21.4.12 414 Request-URI Too Long | |
The server is refusing to service the request because the Request-URI | |
is longer than the server is willing to interpret. | |
21.4.13 415 Unsupported Media Type | |
The server is refusing to service the request because the message | |
body of the request is in a format not supported by the server for | |
the requested method. The server MUST return a list of acceptable | |
formats using the Accept, Accept-Encoding, or Accept-Language header | |
field, depending on the specific problem with the content. UAC | |
processing of this response is described in Section 8.1.3.5. | |
21.4.14 416 Unsupported URI Scheme | |
The server cannot process the request because the scheme of the URI | |
in the Request-URI is unknown to the server. Client processing of | |
this response is described in Section 8.1.3.5. | |
21.4.15 420 Bad Extension | |
The server did not understand the protocol extension specified in a | |
Proxy-Require (Section 20.29) or Require (Section 20.32) header | |
field. The server MUST include a list of the unsupported extensions | |
in an Unsupported header field in the response. UAC processing of | |
this response is described in Section 8.1.3.5. | |
Rosenberg, et. al. Standards Track [Page 187] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
21.4.16 421 Extension Required | |
The UAS needs a particular extension to process the request, but this | |
extension is not listed in a Supported header field in the request. | |
Responses with this status code MUST contain a Require header field | |
listing the required extensions. | |
A UAS SHOULD NOT use this response unless it truly cannot provide any | |
useful service to the client. Instead, if a desirable extension is | |
not listed in the Supported header field, servers SHOULD process the | |
request using baseline SIP capabilities and any extensions supported | |
by the client. | |
21.4.17 423 Interval Too Brief | |
The server is rejecting the request because the expiration time of | |
the resource refreshed by the request is too short. This response | |
can be used by a registrar to reject a registration whose Contact | |
header field expiration time was too small. The use of this response | |
and the related Min-Expires header field are described in Sections | |
10.2.8, 10.3, and 20.23. | |
21.4.18 480 Temporarily Unavailable | |
The callee's end system was contacted successfully but the callee is | |
currently unavailable (for example, is not logged in, logged in but | |
in a state that precludes communication with the callee, or has | |
activated the "do not disturb" feature). The response MAY indicate a | |
better time to call in the Retry-After header field. The user could | |
also be available elsewhere (unbeknownst to this server). The reason | |
phrase SHOULD indicate a more precise cause as to why the callee is | |
unavailable. This value SHOULD be settable by the UA. Status 486 | |
(Busy Here) MAY be used to more precisely indicate a particular | |
reason for the call failure. | |
This status is also returned by a redirect or proxy server that | |
recognizes the user identified by the Request-URI, but does not | |
currently have a valid forwarding location for that user. | |
21.4.19 481 Call/Transaction Does Not Exist | |
This status indicates that the UAS received a request that does not | |
match any existing dialog or transaction. | |
21.4.20 482 Loop Detected | |
The server has detected a loop (Section 16.3 Item 4). | |
Rosenberg, et. al. Standards Track [Page 188] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
21.4.21 483 Too Many Hops | |
The server received a request that contains a Max-Forwards (Section | |
20.22) header field with the value zero. | |
21.4.22 484 Address Incomplete | |
The server received a request with a Request-URI that was incomplete. | |
Additional information SHOULD be provided in the reason phrase. | |
This status code allows overlapped dialing. With overlapped | |
dialing, the client does not know the length of the dialing | |
string. It sends strings of increasing lengths, prompting the | |
user for more input, until it no longer receives a 484 (Address | |
Incomplete) status response. | |
21.4.23 485 Ambiguous | |
The Request-URI was ambiguous. The response MAY contain a listing of | |
possible unambiguous addresses in Contact header fields. Revealing | |
alternatives can infringe on privacy of the user or the organization. | |
It MUST be possible to configure a server to respond with status 404 | |
(Not Found) or to suppress the listing of possible choices for | |
ambiguous Request-URIs. | |
Example response to a request with the Request-URI | |
sip:lee@example.com: | |
SIP/2.0 485 Ambiguous | |
Contact: Carol Lee <sip:carol.lee@example.com> | |
Contact: Ping Lee <sip:p.lee@example.com> | |
Contact: Lee M. Foote <sips:lee.foote@example.com> | |
Some email and voice mail systems provide this functionality. A | |
status code separate from 3xx is used since the semantics are | |
different: for 300, it is assumed that the same person or service | |
will be reached by the choices provided. While an automated | |
choice or sequential search makes sense for a 3xx response, user | |
intervention is required for a 485 (Ambiguous) response. | |
21.4.24 486 Busy Here | |
The callee's end system was contacted successfully, but the callee is | |
currently not willing or able to take additional calls at this end | |
system. The response MAY indicate a better time to call in the | |
Retry-After header field. The user could also be available | |
Rosenberg, et. al. Standards Track [Page 189] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
elsewhere, such as through a voice mail service. Status 600 (Busy | |
Everywhere) SHOULD be used if the client knows that no other end | |
system will be able to accept this call. | |
21.4.25 487 Request Terminated | |
The request was terminated by a BYE or CANCEL request. This response | |
is never returned for a CANCEL request itself. | |
21.4.26 488 Not Acceptable Here | |
The response has the same meaning as 606 (Not Acceptable), but only | |
applies to the specific resource addressed by the Request-URI and the | |
request may succeed elsewhere. | |
A message body containing a description of media capabilities MAY be | |
present in the response, which is formatted according to the Accept | |
header field in the INVITE (or application/sdp if not present), the | |
same as a message body in a 200 (OK) response to an OPTIONS request. | |
21.4.27 491 Request Pending | |
The request was received by a UAS that had a pending request within | |
the same dialog. Section 14.2 describes how such "glare" situations | |
are resolved. | |
21.4.28 493 Undecipherable | |
The request was received by a UAS that contained an encrypted MIME | |
body for which the recipient does not possess or will not provide an | |
appropriate decryption key. This response MAY have a single body | |
containing an appropriate public key that should be used to encrypt | |
MIME bodies sent to this UA. Details of the usage of this response | |
code can be found in Section 23.2. | |
21.5 Server Failure 5xx | |
5xx responses are failure responses given when a server itself has | |
erred. | |
21.5.1 500 Server Internal Error | |
The server encountered an unexpected condition that prevented it from | |
fulfilling the request. The client MAY display the specific error | |
condition and MAY retry the request after several seconds. | |
If the condition is temporary, the server MAY indicate when the | |
client may retry the request using the Retry-After header field. | |
Rosenberg, et. al. Standards Track [Page 190] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
21.5.2 501 Not Implemented | |
The server does not support the functionality required to fulfill the | |
request. This is the appropriate response when a UAS does not | |
recognize the request method and is not capable of supporting it for | |
any user. (Proxies forward all requests regardless of method.) | |
Note that a 405 (Method Not Allowed) is sent when the server | |
recognizes the request method, but that method is not allowed or | |
supported. | |
21.5.3 502 Bad Gateway | |
The server, while acting as a gateway or proxy, received an invalid | |
response from the downstream server it accessed in attempting to | |
fulfill the request. | |
21.5.4 503 Service Unavailable | |
The server is temporarily unable to process the request due to a | |
temporary overloading or maintenance of the server. The server MAY | |
indicate when the client should retry the request in a Retry-After | |
header field. If no Retry-After is given, the client MUST act as if | |
it had received a 500 (Server Internal Error) response. | |
A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD | |
attempt to forward the request to an alternate server. It SHOULD NOT | |
forward any other requests to that server for the duration specified | |
in the Retry-After header field, if present. | |
Servers MAY refuse the connection or drop the request instead of | |
responding with 503 (Service Unavailable). | |
21.5.5 504 Server Time-out | |
The server did not receive a timely response from an external server | |
it accessed in attempting to process the request. 408 (Request | |
Timeout) should be used instead if there was no response within the | |
period specified in the Expires header field from the upstream | |
server. | |
21.5.6 505 Version Not Supported | |
The server does not support, or refuses to support, the SIP protocol | |
version that was used in the request. The server is indicating that | |
it is unable or unwilling to complete the request using the same | |
major version as the client, other than with this error message. | |
Rosenberg, et. al. Standards Track [Page 191] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
21.5.7 513 Message Too Large | |
The server was unable to process the request since the message length | |
exceeded its capabilities. | |
21.6 Global Failures 6xx | |
6xx responses indicate that a server has definitive information about | |
a particular user, not just the particular instance indicated in the | |
Request-URI. | |
21.6.1 600 Busy Everywhere | |
The callee's end system was contacted successfully but the callee is | |
busy and does not wish to take the call at this time. The response | |
MAY indicate a better time to call in the Retry-After header field. | |
If the callee does not wish to reveal the reason for declining the | |
call, the callee uses status code 603 (Decline) instead. This status | |
response is returned only if the client knows that no other end point | |
(such as a voice mail system) will answer the request. Otherwise, | |
486 (Busy Here) should be returned. | |
21.6.2 603 Decline | |
The callee's machine was successfully contacted but the user | |
explicitly does not wish to or cannot participate. The response MAY | |
indicate a better time to call in the Retry-After header field. This | |
status response is returned only if the client knows that no other | |
end point will answer the request. | |
21.6.3 604 Does Not Exist Anywhere | |
The server has authoritative information that the user indicated in | |
the Request-URI does not exist anywhere. | |
21.6.4 606 Not Acceptable | |
The user's agent was contacted successfully but some aspects of the | |
session description such as the requested media, bandwidth, or | |
addressing style were not acceptable. | |
A 606 (Not Acceptable) response means that the user wishes to | |
communicate, but cannot adequately support the session described. | |
The 606 (Not Acceptable) response MAY contain a list of reasons in a | |
Warning header field describing why the session described cannot be | |
supported. Warning reason codes are listed in Section 20.43. | |
Rosenberg, et. al. Standards Track [Page 192] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
A message body containing a description of media capabilities MAY be | |
present in the response, which is formatted according to the Accept | |
header field in the INVITE (or application/sdp if not present), the | |
same as a message body in a 200 (OK) response to an OPTIONS request. | |
It is hoped that negotiation will not frequently be needed, and when | |
a new user is being invited to join an already existing conference, | |
negotiation may not be possible. It is up to the invitation | |
initiator to decide whether or not to act on a 606 (Not Acceptable) | |
response. | |
This status response is returned only if the client knows that no | |
other end point will answer the request. | |
22 Usage of HTTP Authentication | |
SIP provides a stateless, challenge-based mechanism for | |
authentication that is based on authentication in HTTP. Any time | |
that a proxy server or UA receives a request (with the exceptions | |
given in Section 22.1), it MAY challenge the initiator of the request | |
to provide assurance of its identity. Once the originator has been | |
identified, the recipient of the request SHOULD ascertain whether or | |
not this user is authorized to make the request in question. No | |
authorization systems are recommended or discussed in this document. | |
The "Digest" authentication mechanism described in this section | |
provides message authentication and replay protection only, without | |
message integrity or confidentiality. Protective measures above and | |
beyond those provided by Digest need to be taken to prevent active | |
attackers from modifying SIP requests and responses. | |
Note that due to its weak security, the usage of "Basic" | |
authentication has been deprecated. Servers MUST NOT accept | |
credentials using the "Basic" authorization scheme, and servers also | |
MUST NOT challenge with "Basic". This is a change from RFC 2543. | |
22.1 Framework | |
The framework for SIP authentication closely parallels that of HTTP | |
(RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, | |
challenge, realm, realm-value, and credentials is identical (although | |
the usage of "Basic" as a scheme is not permitted). In SIP, a UAS | |
uses the 401 (Unauthorized) response to challenge the identity of a | |
UAC. Additionally, registrars and redirect servers MAY make use of | |
401 (Unauthorized) responses for authentication, but proxies MUST | |
NOT, and instead MAY use the 407 (Proxy Authentication Required) | |
Rosenberg, et. al. Standards Track [Page 193] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
response. The requirements for inclusion of the Proxy-Authenticate, | |
Proxy-Authorization, WWW-Authenticate, and Authorization in the | |
various messages are identical to those described in RFC 2617 [17]. | |
Since SIP does not have the concept of a canonical root URL, the | |
notion of protection spaces is interpreted differently in SIP. The | |
realm string alone defines the protection domain. This is a change | |
from RFC 2543, in which the Request-URI and the realm together | |
defined the protection domain. | |
This previous definition of protection domain caused some amount | |
of confusion since the Request-URI sent by the UAC and the | |
Request-URI received by the challenging server might be different, | |
and indeed the final form of the Request-URI might not be known to | |
the UAC. Also, the previous definition depended on the presence | |
of a SIP URI in the Request-URI and seemed to rule out alternative | |
URI schemes (for example, the tel URL). | |
Operators of user agents or proxy servers that will authenticate | |
received requests MUST adhere to the following guidelines for | |
creation of a realm string for their server: | |
o Realm strings MUST be globally unique. It is RECOMMENDED that | |
a realm string contain a hostname or domain name, following the | |
recommendation in Section 3.2.1 of RFC 2617 [17]. | |
o Realm strings SHOULD present a human-readable identifier that | |
can be rendered to a user. | |
For example: | |
INVITE sip:bob@biloxi.com SIP/2.0 | |
Authorization: Digest realm="biloxi.com", <...> | |
Generally, SIP authentication is meaningful for a specific realm, a | |
protection domain. Thus, for Digest authentication, each such | |
protection domain has its own set of usernames and passwords. If a | |
server does not require authentication for a particular request, it | |
MAY accept a default username, "anonymous", which has no password | |
(password of ""). Similarly, UACs representing many users, such as | |
PSTN gateways, MAY have their own device-specific username and | |
password, rather than accounts for particular users, for their realm. | |
While a server can legitimately challenge most SIP requests, there | |
are two requests defined by this document that require special | |
handling for authentication: ACK and CANCEL. | |
Rosenberg, et. al. Standards Track [Page 194] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Under an authentication scheme that uses responses to carry values | |
used to compute nonces (such as Digest), some problems come up for | |
any requests that take no response, including ACK. For this reason, | |
any credentials in the INVITE that were accepted by a server MUST be | |
accepted by that server for the ACK. UACs creating an ACK message | |
will duplicate all of the Authorization and Proxy-Authorization | |
header field values that appeared in the INVITE to which the ACK | |
corresponds. Servers MUST NOT attempt to challenge an ACK. | |
Although the CANCEL method does take a response (a 2xx), servers MUST | |
NOT attempt to challenge CANCEL requests since these requests cannot | |
be resubmitted. Generally, a CANCEL request SHOULD be accepted by a | |
server if it comes from the same hop that sent the request being | |
canceled (provided that some sort of transport or network layer | |
security association, as described in Section 26.2.1, is in place). | |
When a UAC receives a challenge, it SHOULD render to the user the | |
contents of the "realm" parameter in the challenge (which appears in | |
either a WWW-Authenticate header field or Proxy-Authenticate header | |
field) if the UAC device does not already know of a credential for | |
the realm in question. A service provider that pre-configures UAs | |
with credentials for its realm should be aware that users will not | |
have the opportunity to present their own credentials for this realm | |
when challenged at a pre-configured device. | |
Finally, note that even if a UAC can locate credentials that are | |
associated with the proper realm, the potential exists that these | |
credentials may no longer be valid or that the challenging server | |
will not accept these credentials for whatever reason (especially | |
when "anonymous" with no password is submitted). In this instance a | |
server may repeat its challenge, or it may respond with a 403 | |
Forbidden. A UAC MUST NOT re-attempt requests with the credentials | |
that have just been rejected (though the request may be retried if | |
the nonce was stale). | |
22.2 User-to-User Authentication | |
When a UAS receives a request from a UAC, the UAS MAY authenticate | |
the originator before the request is processed. If no credentials | |
(in the Authorization header field) are provided in the request, the | |
UAS can challenge the originator to provide credentials by rejecting | |
the request with a 401 (Unauthorized) status code. | |
The WWW-Authenticate response-header field MUST be included in 401 | |
(Unauthorized) response messages. The field value consists of at | |
least one challenge that indicates the authentication scheme(s) and | |
parameters applicable to the realm. | |
Rosenberg, et. al. Standards Track [Page 195] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
An example of the WWW-Authenticate header field in a 401 challenge | |
is: | |
WWW-Authenticate: Digest | |
realm="biloxi.com", | |
qop="auth,auth-int", | |
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", | |
opaque="5ccc069c403ebaf9f0171e9517f40e41" | |
When the originating UAC receives the 401 (Unauthorized), it SHOULD, | |
if it is able, re-originate the request with the proper credentials. | |
The UAC may require input from the originating user before | |
proceeding. Once authentication credentials have been supplied | |
(either directly by the user, or discovered in an internal keyring), | |
UAs SHOULD cache the credentials for a given value of the To header | |
field and "realm" and attempt to re-use these values on the next | |
request for that destination. UAs MAY cache credentials in any way | |
they would like. | |
If no credentials for a realm can be located, UACs MAY attempt to | |
retry the request with a username of "anonymous" and no password (a | |
password of ""). | |
Once credentials have been located, any UA that wishes to | |
authenticate itself with a UAS or registrar -- usually, but not | |
necessarily, after receiving a 401 (Unauthorized) response -- MAY do | |
so by including an Authorization header field with the request. The | |
Authorization field value consists of credentials containing the | |
authentication information of the UA for the realm of the resource | |
being requested as well as parameters required in support of | |
authentication and replay protection. | |
An example of the Authorization header field is: | |
Authorization: Digest username="bob", | |
realm="biloxi.com", | |
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", | |
uri="sip:bob@biloxi.com", | |
qop=auth, | |
nc=00000001, | |
cnonce="0a4f113b", | |
response="6629fae49393a05397450978507c4ef1", | |
opaque="5ccc069c403ebaf9f0171e9517f40e41" | |
When a UAC resubmits a request with its credentials after receiving a | |
401 (Unauthorized) or 407 (Proxy Authentication Required) response, | |
it MUST increment the CSeq header field value as it would normally | |
when sending an updated request. | |
Rosenberg, et. al. Standards Track [Page 196] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
22.3 Proxy-to-User Authentication | |
Similarly, when a UAC sends a request to a proxy server, the proxy | |
server MAY authenticate the originator before the request is | |
processed. If no credentials (in the Proxy-Authorization header | |
field) are provided in the request, the proxy can challenge the | |
originator to provide credentials by rejecting the request with a 407 | |
(Proxy Authentication Required) status code. The proxy MUST populate | |
the 407 (Proxy Authentication Required) message with a Proxy- | |
Authenticate header field value applicable to the proxy for the | |
requested resource. | |
The use of Proxy-Authenticate and Proxy-Authorization parallel that | |
described in [17], with one difference. Proxies MUST NOT add values | |
to the Proxy-Authorization header field. All 407 (Proxy | |
Authentication Required) responses MUST be forwarded upstream toward | |
the UAC following the procedures for any other response. It is the | |
UAC's responsibility to add the Proxy-Authorization header field | |
value containing credentials for the realm of the proxy that has | |
asked for authentication. | |
If a proxy were to resubmit a request adding a Proxy-Authorization | |
header field value, it would need to increment the CSeq in the new | |
request. However, this would cause the UAC that submitted the | |
original request to discard a response from the UAS, as the CSeq | |
value would be different. | |
When the originating UAC receives the 407 (Proxy Authentication | |
Required) it SHOULD, if it is able, re-originate the request with the | |
proper credentials. It should follow the same procedures for the | |
display of the "realm" parameter that are given above for responding | |
to 401. | |
If no credentials for a realm can be located, UACs MAY attempt to | |
retry the request with a username of "anonymous" and no password (a | |
password of ""). | |
The UAC SHOULD also cache the credentials used in the re-originated | |
request. | |
The following rule is RECOMMENDED for proxy credential caching: | |
If a UA receives a Proxy-Authenticate header field value in a 401/407 | |
response to a request with a particular Call-ID, it should | |
incorporate credentials for that realm in all subsequent requests | |
that contain the same Call-ID. These credentials MUST NOT be cached | |
across dialogs; however, if a UA is configured with the realm of its | |
local outbound proxy, when one exists, then the UA MAY cache | |
Rosenberg, et. al. Standards Track [Page 197] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
credentials for that realm across dialogs. Note that this does mean | |
a future request in a dialog could contain credentials that are not | |
needed by any proxy along the Route header path. | |
Any UA that wishes to authenticate itself to a proxy server -- | |
usually, but not necessarily, after receiving a 407 (Proxy | |
Authentication Required) response -- MAY do so by including a Proxy- | |
Authorization header field value with the request. The Proxy- | |
Authorization request-header field allows the client to identify | |
itself (or its user) to a proxy that requires authentication. The | |
Proxy-Authorization header field value consists of credentials | |
containing the authentication information of the UA for the proxy | |
and/or realm of the resource being requested. | |
A Proxy-Authorization header field value applies only to the proxy | |
whose realm is identified in the "realm" parameter (this proxy may | |
previously have demanded authentication using the Proxy-Authenticate | |
field). When multiple proxies are used in a chain, a Proxy- | |
Authorization header field value MUST NOT be consumed by any proxy | |
whose realm does not match the "realm" parameter specified in that | |
value. | |
Note that if an authentication scheme that does not support realms is | |
used in the Proxy-Authorization header field, a proxy server MUST | |
attempt to parse all Proxy-Authorization header field values to | |
determine whether one of them has what the proxy server considers to | |
be valid credentials. Because this is potentially very time- | |
consuming in large networks, proxy servers SHOULD use an | |
authentication scheme that supports realms in the Proxy-Authorization | |
header field. | |
If a request is forked (as described in Section 16.7), various proxy | |
servers and/or UAs may wish to challenge the UAC. In this case, the | |
forking proxy server is responsible for aggregating these challenges | |
into a single response. Each WWW-Authenticate and Proxy-Authenticate | |
value received in responses to the forked request MUST be placed into | |
the single response that is sent by the forking proxy to the UA; the | |
ordering of these header field values is not significant. | |
When a proxy server issues a challenge in response to a request, | |
it will not proxy the request until the UAC has retried the | |
request with valid credentials. A forking proxy may forward a | |
request simultaneously to multiple proxy servers that require | |
authentication, each of which in turn will not forward the request | |
until the originating UAC has authenticated itself in their | |
respective realm. If the UAC does not provide credentials for | |
Rosenberg, et. al. Standards Track [Page 198] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
each challenge, the proxy servers that issued the challenges will | |
not forward requests to the UA where the destination user might be | |
located, and therefore, the virtues of forking are largely lost. | |
When resubmitting its request in response to a 401 (Unauthorized) or | |
407 (Proxy Authentication Required) that contains multiple | |
challenges, a UAC MAY include an Authorization value for each WWW- | |
Authenticate value and a Proxy-Authorization value for each Proxy- | |
Authenticate value for which the UAC wishes to supply a credential. | |
As noted above, multiple credentials in a request SHOULD be | |
differentiated by the "realm" parameter. | |
It is possible for multiple challenges associated with the same realm | |
to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication | |
Required). This can occur, for example, when multiple proxies within | |
the same administrative domain, which use a common realm, are reached | |
by a forking request. When it retries a request, a UAC MAY therefore | |
supply multiple credentials in Authorization or Proxy-Authorization | |
header fields with the same "realm" parameter value. The same | |
credentials SHOULD be used for the same realm. | |
22.4 The Digest Authentication Scheme | |
This section describes the modifications and clarifications required | |
to apply the HTTP Digest authentication scheme to SIP. The SIP | |
scheme usage is almost completely identical to that for HTTP [17]. | |
Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], | |
SIP servers supporting RFC 2617 MUST ensure they are backwards | |
compatible with RFC 2069. Procedures for this backwards | |
compatibility are specified in RFC 2617. Note, however, that SIP | |
servers MUST NOT accept or request Basic authentication. | |
The rules for Digest authentication follow those defined in [17], | |
with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following | |
differences: | |
1. The URI included in the challenge has the following BNF: | |
URI = SIP-URI / SIPS-URI | |
2. The BNF in RFC 2617 has an error in that the 'uri' parameter | |
of the Authorization header field for HTTP Digest | |
Rosenberg, et. al. Standards Track [Page 199] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
authentication is not enclosed in quotation marks. (The | |
example in Section 3.5 of RFC 2617 is correct.) For SIP, the | |
'uri' MUST be enclosed in quotation marks. | |
3. The BNF for digest-uri-value is: | |
digest-uri-value = Request-URI ; as defined in Section 25 | |
4. The example procedure for choosing a nonce based on Etag does | |
not work for SIP. | |
5. The text in RFC 2617 [17] regarding cache operation does not | |
apply to SIP. | |
6. RFC 2617 [17] requires that a server check that the URI in the | |
request line and the URI included in the Authorization header | |
field point to the same resource. In a SIP context, these two | |
URIs may refer to different users, due to forwarding at some | |
proxy. Therefore, in SIP, a server MAY check that the | |
Request-URI in the Authorization header field value | |
corresponds to a user for whom the server is willing to accept | |
forwarded or direct requests, but it is not necessarily a | |
failure if the two fields are not equivalent. | |
7. As a clarification to the calculation of the A2 value for | |
message integrity assurance in the Digest authentication | |
scheme, implementers should assume, when the entity-body is | |
empty (that is, when SIP messages have no body) that the hash | |
of the entity-body resolves to the MD5 hash of an empty | |
string, or: | |
H(entity-body) = MD5("") = | |
"d41d8cd98f00b204e9800998ecf8427e" | |
8. RFC 2617 notes that a cnonce value MUST NOT be sent in an | |
Authorization (and by extension Proxy-Authorization) header | |
field if no qop directive has been sent. Therefore, any | |
algorithms that have a dependency on the cnonce (including | |
"MD5-Sess") require that the qop directive be sent. Use of | |
the "qop" parameter is optional in RFC 2617 for the purposes | |
of backwards compatibility with RFC 2069; since RFC 2543 was | |
based on RFC 2069, the "qop" parameter must unfortunately | |
remain optional for clients and servers to receive. However, | |
servers MUST always send a "qop" parameter in WWW-Authenticate | |
and Proxy-Authenticate header field values. If a client | |
receives a "qop" parameter in a challenge header field, it | |
MUST send the "qop" parameter in any resulting authorization | |
header field. | |
Rosenberg, et. al. Standards Track [Page 200] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
RFC 2543 did not allow usage of the Authentication-Info header field | |
(it effectively used RFC 2069). However, we now allow usage of this | |
header field, since it provides integrity checks over the bodies and | |
provides mutual authentication. RFC 2617 [17] defines mechanisms for | |
backwards compatibility using the qop attribute in the request. | |
These mechanisms MUST be used by a server to determine if the client | |
supports the new mechanisms in RFC 2617 that were not specified in | |
RFC 2069. | |
23 S/MIME | |
SIP messages carry MIME bodies and the MIME standard includes | |
mechanisms for securing MIME contents to ensure both integrity and | |
confidentiality (including the 'multipart/signed' and | |
'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23] | |
and RFC 2633 [24]). Implementers should note, however, that there | |
may be rare network intermediaries (not typical proxy servers) that | |
rely on viewing or modifying the bodies of SIP messages (especially | |
SDP), and that secure MIME may prevent these sorts of intermediaries | |
from functioning. | |
This applies particularly to certain types of firewalls. | |
The PGP mechanism for encrypting the header fields and bodies of | |
SIP messages described in RFC 2543 has been deprecated. | |
23.1 S/MIME Certificates | |
The certificates that are used to identify an end-user for the | |
purposes of S/MIME differ from those used by servers in one important | |
respect - rather than asserting that the identity of the holder | |
corresponds to a particular hostname, these certificates assert that | |
the holder is identified by an end-user address. This address is | |
composed of the concatenation of the "userinfo" "@" and "domainname" | |
portions of a SIP or SIPS URI (in other words, an email address of | |
the form "bob@biloxi.com"), most commonly corresponding to a user's | |
address-of-record. | |
These certificates are also associated with keys that are used to | |
sign or encrypt bodies of SIP messages. Bodies are signed with the | |
private key of the sender (who may include their public key with the | |
message as appropriate), but bodies are encrypted with the public key | |
of the intended recipient. Obviously, senders must have | |
foreknowledge of the public key of recipients in order to encrypt | |
message bodies. Public keys can be stored within a UA on a virtual | |
keyring. | |
Rosenberg, et. al. Standards Track [Page 201] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Each user agent that supports S/MIME MUST contain a keyring | |
specifically for end-users' certificates. This keyring should map | |
between addresses of record and corresponding certificates. Over | |
time, users SHOULD use the same certificate when they populate the | |
originating URI of signaling (the From header field) with the same | |
address-of-record. | |
Any mechanisms depending on the existence of end-user certificates | |
are seriously limited in that there is virtually no consolidated | |
authority today that provides certificates for end-user applications. | |
However, users SHOULD acquire certificates from known public | |
certificate authorities. As an alternative, users MAY create self- | |
signed certificates. The implications of self-signed certificates | |
are explored further in Section 26.4.2. Implementations may also use | |
pre-configured certificates in deployments in which a previous trust | |
relationship exists between all SIP entities. | |
Above and beyond the problem of acquiring an end-user certificate, | |
there are few well-known centralized directories that distribute | |
end-user certificates. However, the holder of a certificate SHOULD | |
publish their certificate in any public directories as appropriate. | |
Similarly, UACs SHOULD support a mechanism for importing (manually or | |
automatically) certificates discovered in public directories | |
corresponding to the target URIs of SIP requests. | |
23.2 S/MIME Key Exchange | |
SIP itself can also be used as a means to distribute public keys in | |
the following manner. | |
Whenever the CMS SignedData message is used in S/MIME for SIP, it | |
MUST contain the certificate bearing the public key necessary to | |
verify the signature. | |
When a UAC sends a request containing an S/MIME body that initiates a | |
dialog, or sends a non-INVITE request outside the context of a | |
dialog, the UAC SHOULD structure the body as an S/MIME | |
'multipart/signed' CMS SignedData body. If the desired CMS service | |
is EnvelopedData (and the public key of the target user is known), | |
the UAC SHOULD send the EnvelopedData message encapsulated within a | |
SignedData message. | |
When a UAS receives a request containing an S/MIME CMS body that | |
includes a certificate, the UAS SHOULD first validate the | |
certificate, if possible, with any available root certificates for | |
certificate authorities. The UAS SHOULD also determine the subject | |
of the certificate (for S/MIME, the SubjectAltName will contain the | |
appropriate identity) and compare this value to the From header field | |
Rosenberg, et. al. Standards Track [Page 202] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
of the request. If the certificate cannot be verified, because it is | |
self-signed, or signed by no known authority, or if it is verifiable | |
but its subject does not correspond to the From header field of | |
request, the UAS MUST notify its user of the status of the | |
certificate (including the subject of the certificate, its signer, | |
and any key fingerprint information) and request explicit permission | |
before proceeding. If the certificate was successfully verified and | |
the subject of the certificate corresponds to the From header field | |
of the SIP request, or if the user (after notification) explicitly | |
authorizes the use of the certificate, the UAS SHOULD add this | |
certificate to a local keyring, indexed by the address-of-record of | |
the holder of the certificate. | |
When a UAS sends a response containing an S/MIME body that answers | |
the first request in a dialog, or a response to a non-INVITE request | |
outside the context of a dialog, the UAS SHOULD structure the body as | |
an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS | |
service is EnvelopedData, the UAS SHOULD send the EnvelopedData | |
message encapsulated within a SignedData message. | |
When a UAC receives a response containing an S/MIME CMS body that | |
includes a certificate, the UAC SHOULD first validate the | |
certificate, if possible, with any appropriate root certificate. The | |
UAC SHOULD also determine the subject of the certificate and compare | |
this value to the To field of the response; although the two may very | |
well be different, and this is not necessarily indicative of a | |
security breach. If the certificate cannot be verified because it is | |
self-signed, or signed by no known authority, the UAC MUST notify its | |
user of the status of the certificate (including the subject of the | |
certificate, its signator, and any key fingerprint information) and | |
request explicit permission before proceeding. If the certificate | |
was successfully verified, and the subject of the certificate | |
corresponds to the To header field in the response, or if the user | |
(after notification) explicitly authorizes the use of the | |
certificate, the UAC SHOULD add this certificate to a local keyring, | |
indexed by the address-of-record of the holder of the certificate. | |
If the UAC had not transmitted its own certificate to the UAS in any | |
previous transaction, it SHOULD use a CMS SignedData body for its | |
next request or response. | |
On future occasions, when the UA receives requests or responses that | |
contain a From header field corresponding to a value in its keyring, | |
the UA SHOULD compare the certificate offered in these messages with | |
the existing certificate in its keyring. If there is a discrepancy, | |
the UA MUST notify its user of a change of the certificate | |
(preferably in terms that indicate that this is a potential security | |
breach) and acquire the user's permission before continuing to | |
Rosenberg, et. al. Standards Track [Page 203] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
process the signaling. If the user authorizes this certificate, it | |
SHOULD be added to the keyring alongside any previous value(s) for | |
this address-of-record. | |
Note well however, that this key exchange mechanism does not | |
guarantee the secure exchange of keys when self-signed certificates, | |
or certificates signed by an obscure authority, are used - it is | |
vulnerable to well-known attacks. In the opinion of the authors, | |
however, the security it provides is proverbially better than | |
nothing; it is in fact comparable to the widely used SSH application. | |
These limitations are explored in greater detail in Section 26.4.2. | |
If a UA receives an S/MIME body that has been encrypted with a public | |
key unknown to the recipient, it MUST reject the request with a 493 | |
(Undecipherable) response. This response SHOULD contain a valid | |
certificate for the respondent (corresponding, if possible, to any | |
address of record given in the To header field of the rejected | |
request) within a MIME body with a 'certs-only' "smime-type" | |
parameter. | |
A 493 (Undecipherable) sent without any certificate indicates that | |
the respondent cannot or will not utilize S/MIME encrypted messages, | |
though they may still support S/MIME signatures. | |
Note that a user agent that receives a request containing an S/MIME | |
body that is not optional (with a Content-Disposition header | |
"handling" parameter of "required") MUST reject the request with a | |
415 Unsupported Media Type response if the MIME type is not | |
understood. A user agent that receives such a response when S/MIME | |
is sent SHOULD notify its user that the remote device does not | |
support S/MIME, and it MAY subsequently resend the request without | |
S/MIME, if appropriate; however, this 415 response may constitute a | |
downgrade attack. | |
If a user agent sends an S/MIME body in a request, but receives a | |
response that contains a MIME body that is not secured, the UAC | |
SHOULD notify its user that the session could not be secured. | |
However, if a user agent that supports S/MIME receives a request with | |
an unsecured body, it SHOULD NOT respond with a secured body, but if | |
it expects S/MIME from the sender (for example, because the sender's | |
From header field value corresponds to an identity on its keychain), | |
the UAS SHOULD notify its user that the session could not be secured. | |
A number of conditions that arise in the previous text call for the | |
notification of the user when an anomalous certificate-management | |
event occurs. Users might well ask what they should do under these | |
circumstances. First and foremost, an unexpected change in a | |
certificate, or an absence of security when security is expected, are | |
Rosenberg, et. al. Standards Track [Page 204] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
causes for caution but not necessarily indications that an attack is | |
in progress. Users might abort any connection attempt or refuse a | |
connection request they have received; in telephony parlance, they | |
could hang up and call back. Users may wish to find an alternate | |
means to contact the other party and confirm that their key has | |
legitimately changed. Note that users are sometimes compelled to | |
change their certificates, for example when they suspect that the | |
secrecy of their private key has been compromised. When their | |
private key is no longer private, users must legitimately generate a | |
new key and re-establish trust with any users that held their old | |
key. | |
Finally, if during the course of a dialog a UA receives a certificate | |
in a CMS SignedData message that does not correspond with the | |
certificates previously exchanged during a dialog, the UA MUST notify | |
its user of the change, preferably in terms that indicate that this | |
is a potential security breach. | |
23.3 Securing MIME bodies | |
There are two types of secure MIME bodies that are of interest to | |
SIP: use of these bodies should follow the S/MIME specification [24] | |
with a few variations. | |
o "multipart/signed" MUST be used only with CMS detached | |
signatures. | |
This allows backwards compatibility with non-S/MIME- | |
compliant recipients. | |
o S/MIME bodies SHOULD have a Content-Disposition header field, | |
and the value of the "handling" parameter SHOULD be "required." | |
o If a UAC has no certificate on its keyring associated with the | |
address-of-record to which it wants to send a request, it | |
cannot send an encrypted "application/pkcs7-mime" MIME message. | |
UACs MAY send an initial request such as an OPTIONS message | |
with a CMS detached signature in order to solicit the | |
certificate of the remote side (the signature SHOULD be over a | |
"message/sip" body of the type described in Section 23.4). | |
Note that future standardization work on S/MIME may define | |
non-certificate based keys. | |
o Senders of S/MIME bodies SHOULD use the "SMIMECapabilities" | |
(see Section 2.5.2 of [24]) attribute to express their | |
capabilities and preferences for further communications. Note | |
especially that senders MAY use the "preferSignedData" | |
Rosenberg, et. al. Standards Track [Page 205] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
capability to encourage receivers to respond with CMS | |
SignedData messages (for example, when sending an OPTIONS | |
request as described above). | |
o S/MIME implementations MUST at a minimum support SHA1 as a | |
digital signature algorithm, and 3DES as an encryption | |
algorithm. All other signature and encryption algorithms MAY | |
be supported. Implementations can negotiate support for these | |
algorithms with the "SMIMECapabilities" attribute. | |
o Each S/MIME body in a SIP message SHOULD be signed with only | |
one certificate. If a UA receives a message with multiple | |
signatures, the outermost signature should be treated as the | |
single certificate for this body. Parallel signatures SHOULD | |
NOT be used. | |
The following is an example of an encrypted S/MIME SDP body | |
within a SIP message: | |
INVITE sip:bob@biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
To: Bob <sip:bob@biloxi.com> | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Max-Forwards: 70 | |
Contact: <sip:alice@pc33.atlanta.com> | |
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; | |
name=smime.p7m | |
Content-Disposition: attachment; filename=smime.p7m | |
handling=required | |
******************************************************* | |
* Content-Type: application/sdp * | |
* * | |
* v=0 * | |
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * | |
* s=- * | |
* t=0 0 * | |
* c=IN IP4 pc33.atlanta.com * | |
* m=audio 3456 RTP/AVP 0 1 3 99 * | |
* a=rtpmap:0 PCMU/8000 * | |
******************************************************* | |
Rosenberg, et. al. Standards Track [Page 206] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP | |
As a means of providing some degree of end-to-end authentication, | |
integrity or confidentiality for SIP header fields, S/MIME can | |
encapsulate entire SIP messages within MIME bodies of type | |
"message/sip" and then apply MIME security to these bodies in the | |
same manner as typical SIP bodies. These encapsulated SIP requests | |
and responses do not constitute a separate dialog or transaction, | |
they are a copy of the "outer" message that is used to verify | |
integrity or to supply additional information. | |
If a UAS receives a request that contains a tunneled "message/sip" | |
S/MIME body, it SHOULD include a tunneled "message/sip" body in the | |
response with the same smime-type. | |
Any traditional MIME bodies (such as SDP) SHOULD be attached to the | |
"inner" message so that they can also benefit from S/MIME security. | |
Note that "message/sip" bodies can be sent as a part of a MIME | |
"multipart/mixed" body if any unsecured MIME types should also be | |
transmitted in a request. | |
23.4.1 Integrity and Confidentiality Properties of SIP Headers | |
When the S/MIME integrity or confidentiality mechanisms are used, | |
there may be discrepancies between the values in the "inner" message | |
and values in the "outer" message. The rules for handling any such | |
differences for all of the header fields described in this document | |
are given in this section. | |
Note that for the purposes of loose timestamping, all SIP messages | |
that tunnel "message/sip" SHOULD contain a Date header in both the | |
"inner" and "outer" headers. | |
23.4.1.1 Integrity | |
Whenever integrity checks are performed, the integrity of a header | |
field should be determined by matching the value of the header field | |
in the signed body with that in the "outer" messages using the | |
comparison rules of SIP as described in 20. | |
Header fields that can be legitimately modified by proxy servers are: | |
Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- | |
Authorization. If these header fields are not intact end-to-end, | |
implementations SHOULD NOT consider this a breach of security. | |
Changes to any other header fields defined in this document | |
constitute an integrity violation; users MUST be notified of a | |
discrepancy. | |
Rosenberg, et. al. Standards Track [Page 207] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
23.4.1.2 Confidentiality | |
When messages are encrypted, header fields may be included in the | |
encrypted body that are not present in the "outer" message. | |
Some header fields must always have a plaintext version because they | |
are required header fields in requests and responses - these include: | |
To, From, Call-ID, CSeq, Contact. While it is probably not useful to | |
provide an encrypted alternative for the Call-ID, CSeq, or Contact, | |
providing an alternative to the information in the "outer" To or From | |
is permitted. Note that the values in an encrypted body are not used | |
for the purposes of identifying transactions or dialogs - they are | |
merely informational. If the From header field in an encrypted body | |
differs from the value in the "outer" message, the value within the | |
encrypted body SHOULD be displayed to the user, but MUST NOT be used | |
in the "outer" header fields of any future messages. | |
Primarily, a user agent will want to encrypt header fields that have | |
an end-to-end semantic, including: Subject, Reply-To, Organization, | |
Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, | |
Authentication-Info, Expires, In-Reply-To, Require, Supported, | |
Unsupported, Retry-After, User-Agent, Server, and Warning. If any of | |
these header fields are present in an encrypted body, they should be | |
used instead of any "outer" header fields, whether this entails | |
displaying the header field values to users or setting internal | |
states in the UA. They SHOULD NOT however be used in the "outer" | |
headers of any future messages. | |
If present, the Date header field MUST always be the same in the | |
"inner" and "outer" headers. | |
Since MIME bodies are attached to the "inner" message, | |
implementations will usually encrypt MIME-specific header fields, | |
including: MIME-Version, Content-Type, Content-Length, Content- | |
Language, Content-Encoding and Content-Disposition. The "outer" | |
message will have the proper MIME header fields for S/MIME bodies. | |
These header fields (and any MIME bodies they preface) should be | |
treated as normal MIME header fields and bodies received in a SIP | |
message. | |
It is not particularly useful to encrypt the following header fields: | |
Min-Expires, Timestamp, Authorization, Priority, and WWW- | |
Authenticate. This category also includes those header fields that | |
can be changed by proxy servers (described in the preceding section). | |
UAs SHOULD never include these in an "inner" message if they are not | |
Rosenberg, et. al. Standards Track [Page 208] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
included in the "outer" message. UAs that receive any of these | |
header fields in an encrypted body SHOULD ignore the encrypted | |
values. | |
Note that extensions to SIP may define additional header fields; the | |
authors of these extensions should describe the integrity and | |
confidentiality properties of such header fields. If a SIP UA | |
encounters an unknown header field with an integrity violation, it | |
MUST ignore the header field. | |
23.4.2 Tunneling Integrity and Authentication | |
Tunneling SIP messages within S/MIME bodies can provide integrity for | |
SIP header fields if the header fields that the sender wishes to | |
secure are replicated in a "message/sip" MIME body signed with a CMS | |
detached signature. | |
Provided that the "message/sip" body contains at least the | |
fundamental dialog identifiers (To, From, Call-ID, CSeq), then a | |
signed MIME body can provide limited authentication. At the very | |
least, if the certificate used to sign the body is unknown to the | |
recipient and cannot be verified, the signature can be used to | |
ascertain that a later request in a dialog was transmitted by the | |
same certificate-holder that initiated the dialog. If the recipient | |
of the signed MIME body has some stronger incentive to trust the | |
certificate (they were able to validate it, they acquired it from a | |
trusted repository, or they have used it frequently) then the | |
signature can be taken as a stronger assertion of the identity of the | |
subject of the certificate. | |
In order to eliminate possible confusions about the addition or | |
subtraction of entire header fields, senders SHOULD replicate all | |
header fields from the request within the signed body. Any message | |
bodies that require integrity protection MUST be attached to the | |
"inner" message. | |
If a Date header is present in a message with a signed body, the | |
recipient SHOULD compare the header field value with its own internal | |
clock, if applicable. If a significant time discrepancy is detected | |
(on the order of an hour or more), the user agent SHOULD alert the | |
user to the anomaly, and note that it is a potential security breach. | |
If an integrity violation in a message is detected by its recipient, | |
the message MAY be rejected with a 403 (Forbidden) response if it is | |
a request, or any existing dialog MAY be terminated. UAs SHOULD | |
notify users of this circumstance and request explicit guidance on | |
how to proceed. | |
Rosenberg, et. al. Standards Track [Page 209] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The following is an example of the use of a tunneled "message/sip" | |
body: | |
INVITE sip:bob@biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
To: Bob <sip:bob@biloxi.com> | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Max-Forwards: 70 | |
Date: Thu, 21 Feb 2002 13:02:03 GMT | |
Contact: <sip:alice@pc33.atlanta.com> | |
Content-Type: multipart/signed; | |
protocol="application/pkcs7-signature"; | |
micalg=sha1; boundary=boundary42 | |
Content-Length: 568 | |
--boundary42 | |
Content-Type: message/sip | |
INVITE sip:bob@biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
To: Bob <bob@biloxi.com> | |
From: Alice <alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Max-Forwards: 70 | |
Date: Thu, 21 Feb 2002 13:02:03 GMT | |
Contact: <sip:alice@pc33.atlanta.com> | |
Content-Type: application/sdp | |
Content-Length: 147 | |
v=0 | |
o=UserA 2890844526 2890844526 IN IP4 here.com | |
s=Session SDP | |
c=IN IP4 pc33.atlanta.com | |
t=0 0 | |
m=audio 49172 RTP/AVP 0 | |
a=rtpmap:0 PCMU/8000 | |
--boundary42 | |
Content-Type: application/pkcs7-signature; name=smime.p7s | |
Content-Transfer-Encoding: base64 | |
Content-Disposition: attachment; filename=smime.p7s; | |
handling=required | |
Rosenberg, et. al. Standards Track [Page 210] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 | |
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj | |
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 | |
7GhIGfHfYT64VQbnj756 | |
--boundary42- | |
23.4.3 Tunneling Encryption | |
It may also be desirable to use this mechanism to encrypt a | |
"message/sip" MIME body within a CMS EnvelopedData message S/MIME | |
body, but in practice, most header fields are of at least some use to | |
the network; the general use of encryption with S/MIME is to secure | |
message bodies like SDP rather than message headers. Some | |
informational header fields, such as the Subject or Organization | |
could perhaps warrant end-to-end security. Headers defined by future | |
SIP applications might also require obfuscation. | |
Another possible application of encrypting header fields is selective | |
anonymity. A request could be constructed with a From header field | |
that contains no personal information (for example, | |
sip:anonymous@anonymizer.invalid). However, a second From header | |
field containing the genuine address-of-record of the originator | |
could be encrypted within a "message/sip" MIME body where it will | |
only be visible to the endpoints of a dialog. | |
Note that if this mechanism is used for anonymity, the From header | |
field will no longer be usable by the recipient of a message as an | |
index to their certificate keychain for retrieving the proper | |
S/MIME key to associated with the sender. The message must first | |
be decrypted, and the "inner" From header field MUST be used as an | |
index. | |
In order to provide end-to-end integrity, encrypted "message/sip" | |
MIME bodies SHOULD be signed by the sender. This creates a | |
"multipart/signed" MIME body that contains an encrypted body and a | |
signature, both of type "application/pkcs7-mime". | |
Rosenberg, et. al. Standards Track [Page 211] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
In the following example, of an encrypted and signed message, the | |
text boxed in asterisks ("*") is encrypted: | |
INVITE sip:bob@biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
To: Bob <sip:bob@biloxi.com> | |
From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Max-Forwards: 70 | |
Date: Thu, 21 Feb 2002 13:02:03 GMT | |
Contact: <sip:pc33.atlanta.com> | |
Content-Type: multipart/signed; | |
protocol="application/pkcs7-signature"; | |
micalg=sha1; boundary=boundary42 | |
Content-Length: 568 | |
--boundary42 | |
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; | |
name=smime.p7m | |
Content-Transfer-Encoding: base64 | |
Content-Disposition: attachment; filename=smime.p7m | |
handling=required | |
Content-Length: 231 | |
*********************************************************** | |
* Content-Type: message/sip * | |
* * | |
* INVITE sip:bob@biloxi.com SIP/2.0 * | |
* Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * | |
* To: Bob <bob@biloxi.com> * | |
* From: Alice <alice@atlanta.com>;tag=1928301774 * | |
* Call-ID: a84b4c76e66710 * | |
* CSeq: 314159 INVITE * | |
* Max-Forwards: 70 * | |
* Date: Thu, 21 Feb 2002 13:02:03 GMT * | |
* Contact: <sip:alice@pc33.atlanta.com> * | |
* * | |
* Content-Type: application/sdp * | |
* * | |
* v=0 * | |
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * | |
* s=Session SDP * | |
* t=0 0 * | |
* c=IN IP4 pc33.atlanta.com * | |
* m=audio 3456 RTP/AVP 0 1 3 99 * | |
* a=rtpmap:0 PCMU/8000 * | |
*********************************************************** | |
Rosenberg, et. al. Standards Track [Page 212] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
--boundary42 | |
Content-Type: application/pkcs7-signature; name=smime.p7s | |
Content-Transfer-Encoding: base64 | |
Content-Disposition: attachment; filename=smime.p7s; | |
handling=required | |
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 | |
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj | |
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 | |
7GhIGfHfYT64VQbnj756 | |
--boundary42- | |
24 Examples | |
In the following examples, we often omit the message body and the | |
corresponding Content-Length and Content-Type header fields for | |
brevity. | |
24.1 Registration | |
Bob registers on start-up. The message flow is shown in Figure 9. | |
Note that the authentication usually required for registration is not | |
shown for simplicity. | |
biloxi.com Bob's | |
registrar softphone | |
| | | |
| REGISTER F1 | | |
|<---------------| | |
| 200 OK F2 | | |
|--------------->| | |
Figure 9: SIP Registration Example | |
F1 REGISTER Bob -> Registrar | |
REGISTER sip:registrar.biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 | |
Max-Forwards: 70 | |
To: Bob <sip:bob@biloxi.com> | |
From: Bob <sip:bob@biloxi.com>;tag=456248 | |
Call-ID: 843817637684230@998sdasdh09 | |
CSeq: 1826 REGISTER | |
Contact: <sip:bob@192.0.2.4> | |
Expires: 7200 | |
Content-Length: 0 | |
Rosenberg, et. al. Standards Track [Page 213] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The registration expires after two hours. The registrar responds | |
with a 200 OK: | |
F2 200 OK Registrar -> Bob | |
SIP/2.0 200 OK | |
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 | |
;received=192.0.2.4 | |
To: Bob <sip:bob@biloxi.com>;tag=2493k59kd | |
From: Bob <sip:bob@biloxi.com>;tag=456248 | |
Call-ID: 843817637684230@998sdasdh09 | |
CSeq: 1826 REGISTER | |
Contact: <sip:bob@192.0.2.4> | |
Expires: 7200 | |
Content-Length: 0 | |
24.2 Session Setup | |
This example contains the full details of the example session setup | |
in Section 4. The message flow is shown in Figure 1. Note that | |
these flows show the minimum required set of header fields - some | |
other header fields such as Allow and Supported would normally be | |
present. | |
F1 INVITE Alice -> atlanta.com proxy | |
INVITE sip:bob@biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
Max-Forwards: 70 | |
To: Bob <sip:bob@biloxi.com> | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Contact: <sip:alice@pc33.atlanta.com> | |
Content-Type: application/sdp | |
Content-Length: 142 | |
(Alice's SDP not shown) | |
Rosenberg, et. al. Standards Track [Page 214] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
F2 100 Trying atlanta.com proxy -> Alice | |
SIP/2.0 100 Trying | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
To: Bob <sip:bob@biloxi.com> | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Content-Length: 0 | |
F3 INVITE atlanta.com proxy -> biloxi.com proxy | |
INVITE sip:bob@biloxi.com SIP/2.0 | |
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
Max-Forwards: 69 | |
To: Bob <sip:bob@biloxi.com> | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Contact: <sip:alice@pc33.atlanta.com> | |
Content-Type: application/sdp | |
Content-Length: 142 | |
(Alice's SDP not shown) | |
F4 100 Trying biloxi.com proxy -> atlanta.com proxy | |
SIP/2.0 100 Trying | |
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 | |
;received=192.0.2.2 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
To: Bob <sip:bob@biloxi.com> | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Content-Length: 0 | |
Rosenberg, et. al. Standards Track [Page 215] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
F5 INVITE biloxi.com proxy -> Bob | |
INVITE sip:bob@192.0.2.4 SIP/2.0 | |
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 | |
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 | |
;received=192.0.2.2 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
Max-Forwards: 68 | |
To: Bob <sip:bob@biloxi.com> | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Contact: <sip:alice@pc33.atlanta.com> | |
Content-Type: application/sdp | |
Content-Length: 142 | |
(Alice's SDP not shown) | |
F6 180 Ringing Bob -> biloxi.com proxy | |
SIP/2.0 180 Ringing | |
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 | |
;received=192.0.2.3 | |
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 | |
;received=192.0.2.2 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
Contact: <sip:bob@192.0.2.4> | |
CSeq: 314159 INVITE | |
Content-Length: 0 | |
F7 180 Ringing biloxi.com proxy -> atlanta.com proxy | |
SIP/2.0 180 Ringing | |
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 | |
;received=192.0.2.2 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
Contact: <sip:bob@192.0.2.4> | |
CSeq: 314159 INVITE | |
Content-Length: 0 | |
Rosenberg, et. al. Standards Track [Page 216] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
F8 180 Ringing atlanta.com proxy -> Alice | |
SIP/2.0 180 Ringing | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
Contact: <sip:bob@192.0.2.4> | |
CSeq: 314159 INVITE | |
Content-Length: 0 | |
F9 200 OK Bob -> biloxi.com proxy | |
SIP/2.0 200 OK | |
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 | |
;received=192.0.2.3 | |
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 | |
;received=192.0.2.2 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Contact: <sip:bob@192.0.2.4> | |
Content-Type: application/sdp | |
Content-Length: 131 | |
(Bob's SDP not shown) | |
F10 200 OK biloxi.com proxy -> atlanta.com proxy | |
SIP/2.0 200 OK | |
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 | |
;received=192.0.2.2 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Contact: <sip:bob@192.0.2.4> | |
Content-Type: application/sdp | |
Content-Length: 131 | |
(Bob's SDP not shown) | |
Rosenberg, et. al. Standards Track [Page 217] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
F11 200 OK atlanta.com proxy -> Alice | |
SIP/2.0 200 OK | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 | |
;received=192.0.2.1 | |
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 INVITE | |
Contact: <sip:bob@192.0.2.4> | |
Content-Type: application/sdp | |
Content-Length: 131 | |
(Bob's SDP not shown) | |
F12 ACK Alice -> Bob | |
ACK sip:bob@192.0.2.4 SIP/2.0 | |
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 | |
Max-Forwards: 70 | |
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
From: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 314159 ACK | |
Content-Length: 0 | |
The media session between Alice and Bob is now established. | |
Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq | |
numbering space, which, in this example, begins with 231. Since Bob | |
is making the request, the To and From URIs and tags have been | |
swapped. | |
F13 BYE Bob -> Alice | |
BYE sip:alice@pc33.atlanta.com SIP/2.0 | |
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 | |
Max-Forwards: 70 | |
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
To: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 231 BYE | |
Content-Length: 0 | |
Rosenberg, et. al. Standards Track [Page 218] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
F14 200 OK Alice -> Bob | |
SIP/2.0 200 OK | |
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 | |
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf | |
To: Alice <sip:alice@atlanta.com>;tag=1928301774 | |
Call-ID: a84b4c76e66710 | |
CSeq: 231 BYE | |
Content-Length: 0 | |
The SIP Call Flows document [40] contains further examples of SIP | |
messages. | |
25 Augmented BNF for the SIP Protocol | |
All of the mechanisms specified in this document are described in | |
both prose and an augmented Backus-Naur Form (BNF) defined in RFC | |
2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that | |
are used by this specification, and not repeated here. Implementers | |
need to be familiar with the notation and content of RFC 2234 in | |
order to understand this specification. Certain basic rules are in | |
uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle | |
brackets are used within definitions to clarify the use of rule | |
names. | |
The use of square brackets is redundant syntactically. It is used as | |
a semantic hint that the specific parameter is optional to use. | |
25.1 Basic Rules | |
The following rules are used throughout this specification to | |
describe basic parsing constructs. The US-ASCII coded character set | |
is defined by ANSI X3.4-1986. | |
alphanum = ALPHA / DIGIT | |
Rosenberg, et. al. Standards Track [Page 219] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Several rules are incorporated from RFC 2396 [5] but are updated to | |
make them compliant with RFC 2234 [10]. These include: | |
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" | |
/ "$" / "," | |
unreserved = alphanum / mark | |
mark = "-" / "_" / "." / "!" / "~" / "*" / "'" | |
/ "(" / ")" | |
escaped = "%" HEXDIG HEXDIG | |
SIP header field values can be folded onto multiple lines if the | |
continuation line begins with a space or horizontal tab. All linear | |
white space, including folding, has the same semantics as SP. A | |
recipient MAY replace any linear white space with a single SP before | |
interpreting the field value or forwarding the message downstream. | |
This is intended to behave exactly as HTTP/1.1 as described in RFC | |
2616 [8]. The SWS construct is used when linear white space is | |
optional, generally between tokens and separators. | |
LWS = [*WSP CRLF] 1*WSP ; linear whitespace | |
SWS = [LWS] ; sep whitespace | |
To separate the header name from the rest of value, a colon is used, | |
which, by the above rule, allows whitespace before, but no line | |
break, and whitespace after, including a linebreak. The HCOLON | |
defines this construct. | |
HCOLON = *( SP / HTAB ) ":" SWS | |
The TEXT-UTF8 rule is only used for descriptive field contents and | |
values that are not intended to be interpreted by the message parser. | |
Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC | |
2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field | |
contents that are n t quoted strings, where leading and trailing LWS | |
is not meaningful. In this regard, SIP differs from HTTP, which uses | |
the ISO 8859-1 character set. | |
TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) | |
TEXT-UTF8char = %x21-7E / UTF8-NONASCII | |
UTF8-NONASCII = %xC0-DF 1UTF8-CONT | |
/ %xE0-EF 2UTF8-CONT | |
/ %xF0-F7 3UTF8-CONT | |
/ %xF8-Fb 4UTF8-CONT | |
/ %xFC-FD 5UTF8-CONT | |
UTF8-CONT = %x80-BF | |
Rosenberg, et. al. Standards Track [Page 220] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of | |
a header field continuation. It is expected that the folding LWS | |
will be replaced with a single SP before interpretation of the TEXT- | |
UTF8-TRIM value. | |
Hexadecimal numeric characters are used in several protocol elements. | |
Some elements (authentication) force hex alphas to be lower case. | |
LHEX = DIGIT / %x61-66 ;lowercase a-f | |
Many SIP header field values consist of words separated by LWS or | |
special characters. Unless otherwise stated, tokens are case- | |
insensitive. These special characters MUST be in a quoted string to | |
be used within a parameter value. The word construct is used in | |
Call-ID to allow most separators to be used. | |
token = 1*(alphanum / "-" / "." / "!" / "%" / "*" | |
/ "_" / "+" / "`" / "'" / "~" ) | |
separators = "(" / ")" / "<" / ">" / "@" / | |
"," / ";" / ":" / "\" / DQUOTE / | |
"/" / "[" / "]" / "?" / "=" / | |
"{" / "}" / SP / HTAB | |
word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / | |
"_" / "+" / "`" / "'" / "~" / | |
"(" / ")" / "<" / ">" / | |
":" / "\" / DQUOTE / | |
"/" / "[" / "]" / "?" / | |
"{" / "}" ) | |
When tokens are used or separators are used between elements, | |
whitespace is often allowed before or after these characters: | |
STAR = SWS "*" SWS ; asterisk | |
SLASH = SWS "/" SWS ; slash | |
EQUAL = SWS "=" SWS ; equal | |
LPAREN = SWS "(" SWS ; left parenthesis | |
RPAREN = SWS ")" SWS ; right parenthesis | |
RAQUOT = ">" SWS ; right angle quote | |
LAQUOT = SWS "<"; left angle quote | |
COMMA = SWS "," SWS ; comma | |
SEMI = SWS ";" SWS ; semicolon | |
COLON = SWS ":" SWS ; colon | |
LDQUOT = SWS DQUOTE; open double quotation mark | |
RDQUOT = DQUOTE SWS ; close double quotation mark | |
Rosenberg, et. al. Standards Track [Page 221] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Comments can be included in some SIP header fields by surrounding the | |
comment text with parentheses. Comments are only allowed in fields | |
containing "comment" as part of their field value definition. In all | |
other fields, parentheses are considered part of the field value. | |
comment = LPAREN *(ctext / quoted-pair / comment) RPAREN | |
ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII | |
/ LWS | |
ctext includes all chars except left and right parens and backslash. | |
A string of text is parsed as a single word if it is quoted using | |
double-quote marks. In quoted strings, quotation marks (") and | |
backslashes (\) need to be escaped. | |
quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE | |
qdtext = LWS / %x21 / %x23-5B / %x5D-7E | |
/ UTF8-NONASCII | |
The backslash character ("\") MAY be used as a single-character | |
quoting mechanism only within quoted-string and comment constructs. | |
Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this | |
mechanism to avoid conflict with line folding and header separation. | |
quoted-pair = "\" (%x00-09 / %x0B-0C | |
/ %x0E-7F) | |
SIP-URI = "sip:" [ userinfo ] hostport | |
uri-parameters [ headers ] | |
SIPS-URI = "sips:" [ userinfo ] hostport | |
uri-parameters [ headers ] | |
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" | |
user = 1*( unreserved / escaped / user-unreserved ) | |
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" | |
password = *( unreserved / escaped / | |
"&" / "=" / "+" / "$" / "," ) | |
hostport = host [ ":" port ] | |
host = hostname / IPv4address / IPv6reference | |
hostname = *( domainlabel "." ) toplabel [ "." ] | |
domainlabel = alphanum | |
/ alphanum *( alphanum / "-" ) alphanum | |
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum | |
Rosenberg, et. al. Standards Track [Page 222] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT | |
IPv6reference = "[" IPv6address "]" | |
IPv6address = hexpart [ ":" IPv4address ] | |
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] | |
hexseq = hex4 *( ":" hex4) | |
hex4 = 1*4HEXDIG | |
port = 1*DIGIT | |
The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, | |
however, that any characters allowed there that are not allowed in | |
the user part of the SIP URI MUST be escaped. | |
uri-parameters = *( ";" uri-parameter) | |
uri-parameter = transport-param / user-param / method-param | |
/ ttl-param / maddr-param / lr-param / other-param | |
transport-param = "transport=" | |
( "udp" / "tcp" / "sctp" / "tls" | |
/ other-transport) | |
other-transport = token | |
user-param = "user=" ( "phone" / "ip" / other-user) | |
other-user = token | |
method-param = "method=" Method | |
ttl-param = "ttl=" ttl | |
maddr-param = "maddr=" host | |
lr-param = "lr" | |
other-param = pname [ "=" pvalue ] | |
pname = 1*paramchar | |
pvalue = 1*paramchar | |
paramchar = param-unreserved / unreserved / escaped | |
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" | |
headers = "?" header *( "&" header ) | |
header = hname "=" hvalue | |
hname = 1*( hnv-unreserved / unreserved / escaped ) | |
hvalue = *( hnv-unreserved / unreserved / escaped ) | |
hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" | |
SIP-message = Request / Response | |
Request = Request-Line | |
*( message-header ) | |
CRLF | |
[ message-body ] | |
Request-Line = Method SP Request-URI SP SIP-Version CRLF | |
Request-URI = SIP-URI / SIPS-URI / absoluteURI | |
absoluteURI = scheme ":" ( hier-part / opaque-part ) | |
hier-part = ( net-path / abs-path ) [ "?" query ] | |
net-path = "//" authority [ abs-path ] | |
abs-path = "/" path-segments | |
Rosenberg, et. al. Standards Track [Page 223] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
opaque-part = uric-no-slash *uric | |
uric = reserved / unreserved / escaped | |
uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" | |
/ "&" / "=" / "+" / "$" / "," | |
path-segments = segment *( "/" segment ) | |
segment = *pchar *( ";" param ) | |
param = *pchar | |
pchar = unreserved / escaped / | |
":" / "@" / "&" / "=" / "+" / "$" / "," | |
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) | |
authority = srvr / reg-name | |
srvr = [ [ userinfo "@" ] hostport ] | |
reg-name = 1*( unreserved / escaped / "$" / "," | |
/ ";" / ":" / "@" / "&" / "=" / "+" ) | |
query = *uric | |
SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT | |
message-header = (Accept | |
/ Accept-Encoding | |
/ Accept-Language | |
/ Alert-Info | |
/ Allow | |
/ Authentication-Info | |
/ Authorization | |
/ Call-ID | |
/ Call-Info | |
/ Contact | |
/ Content-Disposition | |
/ Content-Encoding | |
/ Content-Language | |
/ Content-Length | |
/ Content-Type | |
/ CSeq | |
/ Date | |
/ Error-Info | |
/ Expires | |
/ From | |
/ In-Reply-To | |
/ Max-Forwards | |
/ MIME-Version | |
/ Min-Expires | |
/ Organization | |
/ Priority | |
/ Proxy-Authenticate | |
/ Proxy-Authorization | |
/ Proxy-Require | |
/ Record-Route | |
/ Reply-To | |
Rosenberg, et. al. Standards Track [Page 224] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
/ Require | |
/ Retry-After | |
/ Route | |
/ Server | |
/ Subject | |
/ Supported | |
/ Timestamp | |
/ To | |
/ Unsupported | |
/ User-Agent | |
/ Via | |
/ Warning | |
/ WWW-Authenticate | |
/ extension-header) CRLF | |
INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps | |
ACKm = %x41.43.4B ; ACK in caps | |
OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps | |
BYEm = %x42.59.45 ; BYE in caps | |
CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps | |
REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps | |
Method = INVITEm / ACKm / OPTIONSm / BYEm | |
/ CANCELm / REGISTERm | |
/ extension-method | |
extension-method = token | |
Response = Status-Line | |
*( message-header ) | |
CRLF | |
[ message-body ] | |
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF | |
Status-Code = Informational | |
/ Redirection | |
/ Success | |
/ Client-Error | |
/ Server-Error | |
/ Global-Failure | |
/ extension-code | |
extension-code = 3DIGIT | |
Reason-Phrase = *(reserved / unreserved / escaped | |
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB) | |
Informational = "100" ; Trying | |
/ "180" ; Ringing | |
/ "181" ; Call Is Being Forwarded | |
/ "182" ; Queued | |
/ "183" ; Session Progress | |
Rosenberg, et. al. Standards Track [Page 225] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Success = "200" ; OK | |
Redirection = "300" ; Multiple Choices | |
/ "301" ; Moved Permanently | |
/ "302" ; Moved Temporarily | |
/ "305" ; Use Proxy | |
/ "380" ; Alternative Service | |
Client-Error = "400" ; Bad Request | |
/ "401" ; Unauthorized | |
/ "402" ; Payment Required | |
/ "403" ; Forbidden | |
/ "404" ; Not Found | |
/ "405" ; Method Not Allowed | |
/ "406" ; Not Acceptable | |
/ "407" ; Proxy Authentication Required | |
/ "408" ; Request Timeout | |
/ "410" ; Gone | |
/ "413" ; Request Entity Too Large | |
/ "414" ; Request-URI Too Large | |
/ "415" ; Unsupported Media Type | |
/ "416" ; Unsupported URI Scheme | |
/ "420" ; Bad Extension | |
/ "421" ; Extension Required | |
/ "423" ; Interval Too Brief | |
/ "480" ; Temporarily not available | |
/ "481" ; Call Leg/Transaction Does Not Exist | |
/ "482" ; Loop Detected | |
/ "483" ; Too Many Hops | |
/ "484" ; Address Incomplete | |
/ "485" ; Ambiguous | |
/ "486" ; Busy Here | |
/ "487" ; Request Terminated | |
/ "488" ; Not Acceptable Here | |
/ "491" ; Request Pending | |
/ "493" ; Undecipherable | |
Server-Error = "500" ; Internal Server Error | |
/ "501" ; Not Implemented | |
/ "502" ; Bad Gateway | |
/ "503" ; Service Unavailable | |
/ "504" ; Server Time-out | |
/ "505" ; SIP Version not supported | |
/ "513" ; Message Too Large | |
Rosenberg, et. al. Standards Track [Page 226] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Global-Failure = "600" ; Busy Everywhere | |
/ "603" ; Decline | |
/ "604" ; Does not exist anywhere | |
/ "606" ; Not Acceptable | |
Accept = "Accept" HCOLON | |
[ accept-range *(COMMA accept-range) ] | |
accept-range = media-range *(SEMI accept-param) | |
media-range = ( "*/*" | |
/ ( m-type SLASH "*" ) | |
/ ( m-type SLASH m-subtype ) | |
) *( SEMI m-parameter ) | |
accept-param = ("q" EQUAL qvalue) / generic-param | |
qvalue = ( "0" [ "." 0*3DIGIT ] ) | |
/ ( "1" [ "." 0*3("0") ] ) | |
generic-param = token [ EQUAL gen-value ] | |
gen-value = token / host / quoted-string | |
Accept-Encoding = "Accept-Encoding" HCOLON | |
[ encoding *(COMMA encoding) ] | |
encoding = codings *(SEMI accept-param) | |
codings = content-coding / "*" | |
content-coding = token | |
Accept-Language = "Accept-Language" HCOLON | |
[ language *(COMMA language) ] | |
language = language-range *(SEMI accept-param) | |
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) | |
Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param) | |
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) | |
Allow = "Allow" HCOLON [Method *(COMMA Method)] | |
Authorization = "Authorization" HCOLON credentials | |
credentials = ("Digest" LWS digest-response) | |
/ other-response | |
digest-response = dig-resp *(COMMA dig-resp) | |
dig-resp = username / realm / nonce / digest-uri | |
/ dresponse / algorithm / cnonce | |
/ opaque / message-qop | |
/ nonce-count / auth-param | |
username = "username" EQUAL username-value | |
username-value = quoted-string | |
digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT | |
digest-uri-value = rquest-uri ; Equal to request-uri as specified | |
by HTTP/1.1 | |
message-qop = "qop" EQUAL qop-value | |
Rosenberg, et. al. Standards Track [Page 227] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
cnonce = "cnonce" EQUAL cnonce-value | |
cnonce-value = nonce-value | |
nonce-count = "nc" EQUAL nc-value | |
nc-value = 8LHEX | |
dresponse = "response" EQUAL request-digest | |
request-digest = LDQUOT 32LHEX RDQUOT | |
auth-param = auth-param-name EQUAL | |
( token / quoted-string ) | |
auth-param-name = token | |
other-response = auth-scheme LWS auth-param | |
*(COMMA auth-param) | |
auth-scheme = token | |
Authentication-Info = "Authentication-Info" HCOLON ainfo | |
*(COMMA ainfo) | |
ainfo = nextnonce / message-qop | |
/ response-auth / cnonce | |
/ nonce-count | |
nextnonce = "nextnonce" EQUAL nonce-value | |
response-auth = "rspauth" EQUAL response-digest | |
response-digest = LDQUOT *LHEX RDQUOT | |
Call-ID = ( "Call-ID" / "i" ) HCOLON callid | |
callid = word [ "@" word ] | |
Call-Info = "Call-Info" HCOLON info *(COMMA info) | |
info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) | |
info-param = ( "purpose" EQUAL ( "icon" / "info" | |
/ "card" / token ) ) / generic-param | |
Contact = ("Contact" / "m" ) HCOLON | |
( STAR / (contact-param *(COMMA contact-param))) | |
contact-param = (name-addr / addr-spec) *(SEMI contact-params) | |
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT | |
addr-spec = SIP-URI / SIPS-URI / absoluteURI | |
display-name = *(token LWS)/ quoted-string | |
contact-params = c-p-q / c-p-expires | |
/ contact-extension | |
c-p-q = "q" EQUAL qvalue | |
c-p-expires = "expires" EQUAL delta-seconds | |
contact-extension = generic-param | |
delta-seconds = 1*DIGIT | |
Content-Disposition = "Content-Disposition" HCOLON | |
disp-type *( SEMI disp-param ) | |
disp-type = "render" / "session" / "icon" / "alert" | |
/ disp-extension-token | |
Rosenberg, et. al. Standards Track [Page 228] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
disp-param = handling-param / generic-param | |
handling-param = "handling" EQUAL | |
( "optional" / "required" | |
/ other-handling ) | |
other-handling = token | |
disp-extension-token = token | |
Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON | |
content-coding *(COMMA content-coding) | |
Content-Language = "Content-Language" HCOLON | |
language-tag *(COMMA language-tag) | |
language-tag = primary-tag *( "-" subtag ) | |
primary-tag = 1*8ALPHA | |
subtag = 1*8ALPHA | |
Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT | |
Content-Type = ( "Content-Type" / "c" ) HCOLON media-type | |
media-type = m-type SLASH m-subtype *(SEMI m-parameter) | |
m-type = discrete-type / composite-type | |
discrete-type = "text" / "image" / "audio" / "video" | |
/ "application" / extension-token | |
composite-type = "message" / "multipart" / extension-token | |
extension-token = ietf-token / x-token | |
ietf-token = token | |
x-token = "x-" token | |
m-subtype = extension-token / iana-token | |
iana-token = token | |
m-parameter = m-attribute EQUAL m-value | |
m-attribute = token | |
m-value = token / quoted-string | |
CSeq = "CSeq" HCOLON 1*DIGIT LWS Method | |
Date = "Date" HCOLON SIP-date | |
SIP-date = rfc1123-date | |
rfc1123-date = wkday "," SP date1 SP time SP "GMT" | |
date1 = 2DIGIT SP month SP 4DIGIT | |
; day month year (e.g., 02 Jun 1982) | |
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | |
; 00:00:00 - 23:59:59 | |
wkday = "Mon" / "Tue" / "Wed" | |
/ "Thu" / "Fri" / "Sat" / "Sun" | |
month = "Jan" / "Feb" / "Mar" / "Apr" | |
/ "May" / "Jun" / "Jul" / "Aug" | |
/ "Sep" / "Oct" / "Nov" / "Dec" | |
Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) | |
Rosenberg, et. al. Standards Track [Page 229] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) | |
Expires = "Expires" HCOLON delta-seconds | |
From = ( "From" / "f" ) HCOLON from-spec | |
from-spec = ( name-addr / addr-spec ) | |
*( SEMI from-param ) | |
from-param = tag-param / generic-param | |
tag-param = "tag" EQUAL token | |
In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid) | |
Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT | |
MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT | |
Min-Expires = "Min-Expires" HCOLON delta-seconds | |
Organization = "Organization" HCOLON [TEXT-UTF8-TRIM] | |
Priority = "Priority" HCOLON priority-value | |
priority-value = "emergency" / "urgent" / "normal" | |
/ "non-urgent" / other-priority | |
other-priority = token | |
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge | |
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) | |
/ other-challenge | |
other-challenge = auth-scheme LWS auth-param | |
*(COMMA auth-param) | |
digest-cln = realm / domain / nonce | |
/ opaque / stale / algorithm | |
/ qop-options / auth-param | |
realm = "realm" EQUAL realm-value | |
realm-value = quoted-string | |
domain = "domain" EQUAL LDQUOT URI | |
*( 1*SP URI ) RDQUOT | |
URI = absoluteURI / abs-path | |
nonce = "nonce" EQUAL nonce-value | |
nonce-value = quoted-string | |
opaque = "opaque" EQUAL quoted-string | |
stale = "stale" EQUAL ( "true" / "false" ) | |
algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" | |
/ token ) | |
qop-options = "qop" EQUAL LDQUOT qop-value | |
*("," qop-value) RDQUOT | |
qop-value = "auth" / "auth-int" / token | |
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials | |
Rosenberg, et. al. Standards Track [Page 230] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Proxy-Require = "Proxy-Require" HCOLON option-tag | |
*(COMMA option-tag) | |
option-tag = token | |
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) | |
rec-route = name-addr *( SEMI rr-param ) | |
rr-param = generic-param | |
Reply-To = "Reply-To" HCOLON rplyto-spec | |
rplyto-spec = ( name-addr / addr-spec ) | |
*( SEMI rplyto-param ) | |
rplyto-param = generic-param | |
Require = "Require" HCOLON option-tag *(COMMA option-tag) | |
Retry-After = "Retry-After" HCOLON delta-seconds | |
[ comment ] *( SEMI retry-param ) | |
retry-param = ("duration" EQUAL delta-seconds) | |
/ generic-param | |
Route = "Route" HCOLON route-param *(COMMA route-param) | |
route-param = name-addr *( SEMI rr-param ) | |
Server = "Server" HCOLON server-val *(LWS server-val) | |
server-val = product / comment | |
product = token [SLASH product-version] | |
product-version = token | |
Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM] | |
Supported = ( "Supported" / "k" ) HCOLON | |
[option-tag *(COMMA option-tag)] | |
Timestamp = "Timestamp" HCOLON 1*(DIGIT) | |
[ "." *(DIGIT) ] [ LWS delay ] | |
delay = *(DIGIT) [ "." *(DIGIT) ] | |
To = ( "To" / "t" ) HCOLON ( name-addr | |
/ addr-spec ) *( SEMI to-param ) | |
to-param = tag-param / generic-param | |
Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag) | |
User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) | |
Rosenberg, et. al. Standards Track [Page 231] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) | |
via-parm = sent-protocol LWS sent-by *( SEMI via-params ) | |
via-params = via-ttl / via-maddr | |
/ via-received / via-branch | |
/ via-extension | |
via-ttl = "ttl" EQUAL ttl | |
via-maddr = "maddr" EQUAL host | |
via-received = "received" EQUAL (IPv4address / IPv6address) | |
via-branch = "branch" EQUAL token | |
via-extension = generic-param | |
sent-protocol = protocol-name SLASH protocol-version | |
SLASH transport | |
protocol-name = "SIP" / token | |
protocol-version = token | |
transport = "UDP" / "TCP" / "TLS" / "SCTP" | |
/ other-transport | |
sent-by = host [ COLON port ] | |
ttl = 1*3DIGIT ; 0 to 255 | |
Warning = "Warning" HCOLON warning-value *(COMMA warning-value) | |
warning-value = warn-code SP warn-agent SP warn-text | |
warn-code = 3DIGIT | |
warn-agent = hostport / pseudonym | |
; the name or pseudonym of the server adding | |
; the Warning header, for use in debugging | |
warn-text = quoted-string | |
pseudonym = token | |
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge | |
extension-header = header-name HCOLON header-value | |
header-name = token | |
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) | |
message-body = *OCTET | |
26 Security Considerations: Threat Model and Security Usage | |
Recommendations | |
SIP is not an easy protocol to secure. Its use of intermediaries, | |
its multi-faceted trust relationships, its expected usage between | |
elements with no trust at all, and its user-to-user operation make | |
security far from trivial. Security solutions are needed that are | |
deployable today, without extensive coordination, in a wide variety | |
of environments and usages. In order to meet these diverse needs, | |
several distinct mechanisms applicable to different aspects and | |
usages of SIP will be required. | |
Rosenberg, et. al. Standards Track [Page 232] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Note that the security of SIP signaling itself has no bearing on the | |
security of protocols used in concert with SIP such as RTP, or with | |
the security implications of any specific bodies SIP might carry | |
(although MIME security plays a substantial role in securing SIP). | |
Any media associated with a session can be encrypted end-to-end | |
independently of any associated SIP signaling. Media encryption is | |
outside the scope of this document. | |
The considerations that follow first examine a set of classic threat | |
models that broadly identify the security needs of SIP. The set of | |
security services required to address these threats is then detailed, | |
followed by an explanation of several security mechanisms that can be | |
used to provide these services. Next, the requirements for | |
implementers of SIP are enumerated, along with exemplary deployments | |
in which these security mechanisms could be used to improve the | |
security of SIP. Some notes on privacy conclude this section. | |
26.1 Attacks and Threat Models | |
This section details some threats that should be common to most | |
deployments of SIP. These threats have been chosen specifically to | |
illustrate each of the security services that SIP requires. | |
The following examples by no means provide an exhaustive list of the | |
threats against SIP; rather, these are "classic" threats that | |
demonstrate the need for particular security services that can | |
potentially prevent whole categories of threats. | |
These attacks assume an environment in which attackers can | |
potentially read any packet on the network - it is anticipated that | |
SIP will frequently be used on the public Internet. Attackers on the | |
network may be able to modify packets (perhaps at some compromised | |
intermediary). Attackers may wish to steal services, eavesdrop on | |
communications, or disrupt sessions. | |
26.1.1 Registration Hijacking | |
The SIP registration mechanism allows a user agent to identify itself | |
to a registrar as a device at which a user (designated by an address | |
of record) is located. A registrar assesses the identity asserted in | |
the From header field of a REGISTER message to determine whether this | |
request can modify the contact addresses associated with the | |
address-of-record in the To header field. While these two fields are | |
frequently the same, there are many valid deployments in which a | |
third-party may register contacts on a user's behalf. | |
Rosenberg, et. al. Standards Track [Page 233] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The From header field of a SIP request, however, can be modified | |
arbitrarily by the owner of a UA, and this opens the door to | |
malicious registrations. An attacker that successfully impersonates | |
a party authorized to change contacts associated with an address-of- | |
record could, for example, de-register all existing contacts for a | |
URI and then register their own device as the appropriate contact | |
address, thereby directing all requests for the affected user to the | |
attacker's device. | |
This threat belongs to a family of threats that rely on the absence | |
of cryptographic assurance of a request's originator. Any SIP UAS | |
that represents a valuable service (a gateway that interworks SIP | |
requests with traditional telephone calls, for example) might want to | |
control access to its resources by authenticating requests that it | |
receives. Even end-user UAs, for example SIP phones, have an | |
interest in ascertaining the identities of originators of requests. | |
This threat demonstrates the need for security services that enable | |
SIP entities to authenticate the originators of requests. | |
26.1.2 Impersonating a Server | |
The domain to which a request is destined is generally specified in | |
the Request-URI. UAs commonly contact a server in this domain | |
directly in order to deliver a request. However, there is always a | |
possibility that an attacker could impersonate the remote server, and | |
that the UA's request could be intercepted by some other party. | |
For example, consider a case in which a redirect server at one | |
domain, chicago.com, impersonates a redirect server at another | |
domain, biloxi.com. A user agent sends a request to biloxi.com, but | |
the redirect server at chicago.com answers with a forged response | |
that has appropriate SIP header fields for a response from | |
biloxi.com. The forged contact addresses in the redirection response | |
could direct the originating UA to inappropriate or insecure | |
resources, or simply prevent requests for biloxi.com from succeeding. | |
This family of threats has a vast membership, many of which are | |
critical. As a converse to the registration hijacking threat, | |
consider the case in which a registration sent to biloxi.com is | |
intercepted by chicago.com, which replies to the intercepted | |
registration with a forged 301 (Moved Permanently) response. This | |
response might seem to come from biloxi.com yet designate chicago.com | |
as the appropriate registrar. All future REGISTER requests from the | |
originating UA would then go to chicago.com. | |
Prevention of this threat requires a means by which UAs can | |
authenticate the servers to whom they send requests. | |
Rosenberg, et. al. Standards Track [Page 234] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
26.1.3 Tampering with Message Bodies | |
As a matter of course, SIP UAs route requests through trusted proxy | |
servers. Regardless of how that trust is established (authentication | |
of proxies is discussed elsewhere in this section), a UA may trust a | |
proxy server to route a request, but not to inspect or possibly | |
modify the bodies contained in that request. | |
Consider a UA that is using SIP message bodies to communicate session | |
encryption keys for a media session. Although it trusts the proxy | |
server of the domain it is contacting to deliver signaling properly, | |
it may not want the administrators of that domain to be capable of | |
decrypting any subsequent media session. Worse yet, if the proxy | |
server were actively malicious, it could modify the session key, | |
either acting as a man-in-the-middle, or perhaps changing the | |
security characteristics requested by the originating UA. | |
This family of threats applies not only to session keys, but to most | |
conceivable forms of content carried end-to-end in SIP. These might | |
include MIME bodies that should be rendered to the user, SDP, or | |
encapsulated telephony signals, among others. Attackers might | |
attempt to modify SDP bodies, for example, in order to point RTP | |
media streams to a wiretapping device in order to eavesdrop on | |
subsequent voice communications. | |
Also note that some header fields in SIP are meaningful end-to-end, | |
for example, Subject. UAs might be protective of these header fields | |
as well as bodies (a malicious intermediary changing the Subject | |
header field might make an important request appear to be spam, for | |
example). However, since many header fields are legitimately | |
inspected or altered by proxy servers as a request is routed, not all | |
header fields should be secured end-to-end. | |
For these reasons, the UA might want to secure SIP message bodies, | |
and in some limited cases header fields, end-to-end. The security | |
services required for bodies include confidentiality, integrity, and | |
authentication. These end-to-end services should be independent of | |
the means used to secure interactions with intermediaries such as | |
proxy servers. | |
26.1.4 Tearing Down Sessions | |
Once a dialog has been established by initial messaging, subsequent | |
requests can be sent that modify the state of the dialog and/or | |
session. It is critical that principals in a session can be certain | |
that such requests are not forged by attackers. | |
Rosenberg, et. al. Standards Track [Page 235] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Consider a case in which a third-party attacker captures some initial | |
messages in a dialog shared by two parties in order to learn the | |
parameters of the session (To tag, From tag, and so forth) and then | |
inserts a BYE request into the session. The attacker could opt to | |
forge the request such that it seemed to come from either | |
participant. Once the BYE is received by its target, the session | |
will be torn down prematurely. | |
Similar mid-session threats include the transmission of forged re- | |
INVITEs that alter the session (possibly to reduce session security | |
or redirect media streams as part of a wiretapping attack). | |
The most effective countermeasure to this threat is the | |
authentication of the sender of the BYE. In this instance, the | |
recipient needs only know that the BYE came from the same party with | |
whom the corresponding dialog was established (as opposed to | |
ascertaining the absolute identity of the sender). Also, if the | |
attacker is unable to learn the parameters of the session due to | |
confidentiality, it would not be possible to forge the BYE. However, | |
some intermediaries (like proxy servers) will need to inspect those | |
parameters as the session is established. | |
26.1.5 Denial of Service and Amplification | |
Denial-of-service attacks focus on rendering a particular network | |
element unavailable, usually by directing an excessive amount of | |
network traffic at its interfaces. A distributed denial-of-service | |
attack allows one network user to cause multiple network hosts to | |
flood a target host with a large amount of network traffic. | |
In many architectures, SIP proxy servers face the public Internet in | |
order to accept requests from worldwide IP endpoints. SIP creates a | |
number of potential opportunities for distributed denial-of-service | |
attacks that must be recognized and addressed by the implementers and | |
operators of SIP systems. | |
Attackers can create bogus requests that contain a falsified source | |
IP address and a corresponding Via header field that identify a | |
targeted host as the originator of the request and then send this | |
request to a large number of SIP network elements, thereby using | |
hapless SIP UAs or proxies to generate denial-of-service traffic | |
aimed at the target. | |
Similarly, attackers might use falsified Route header field values in | |
a request that identify the target host and then send such messages | |
to forking proxies that will amplify messaging sent to the target. | |
Rosenberg, et. al. Standards Track [Page 236] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Record-Route could be used to similar effect when the attacker is | |
certain that the SIP dialog initiated by the request will result in | |
numerous transactions originating in the backwards direction. | |
A number of denial-of-service attacks open up if REGISTER requests | |
are not properly authenticated and authorized by registrars. | |
Attackers could de-register some or all users in an administrative | |
domain, thereby preventing these users from being invited to new | |
sessions. An attacker could also register a large number of contacts | |
designating the same host for a given address-of-record in order to | |
use the registrar and any associated proxy servers as amplifiers in a | |
denial-of-service attack. Attackers might also attempt to deplete | |
available memory and disk resources of a registrar by registering | |
huge numbers of bindings. | |
The use of multicast to transmit SIP requests can greatly increase | |
the potential for denial-of-service attacks. | |
These problems demonstrate a general need to define architectures | |
that minimize the risks of denial-of-service, and the need to be | |
mindful in recommendations for security mechanisms of this class of | |
attacks. | |
26.2 Security Mechanisms | |
From the threats described above, we gather that the fundamental | |
security services required for the SIP protocol are: preserving the | |
confidentiality and integrity of messaging, preventing replay attacks | |
or message spoofing, providing for the authentication and privacy of | |
the participants in a session, and preventing denial-of-service | |
attacks. Bodies within SIP messages separately require the security | |
services of confidentiality, integrity, and authentication. | |
Rather than defining new security mechanisms specific to SIP, SIP | |
reuses wherever possible existing security models derived from the | |
HTTP and SMTP space. | |
Full encryption of messages provides the best means to preserve the | |
confidentiality of signaling - it can also guarantee that messages | |
are not modified by any malicious intermediaries. However, SIP | |
requests and responses cannot be naively encrypted end-to-end in | |
their entirety because message fields such as the Request-URI, Route, | |
and Via need to be visible to proxies in most network architectures | |
so that SIP requests are routed correctly. Note that proxy servers | |
need to modify some features of messages as well (such as adding Via | |
header field values) in order for SIP to function. Proxy servers | |
must therefore be trusted, to some degree, by SIP UAs. To this | |
purpose, low-layer security mechanisms for SIP are recommended, which | |
Rosenberg, et. al. Standards Track [Page 237] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
encrypt the entire SIP requests or responses on the wire on a hop- | |
by-hop basis, and that allow endpoints to verify the identity of | |
proxy servers to whom they send requests. | |
SIP entities also have a need to identify one another in a secure | |
fashion. When a SIP endpoint asserts the identity of its user to a | |
peer UA or to a proxy server, that identity should in some way be | |
verifiable. A cryptographic authentication mechanism is provided in | |
SIP to address this requirement. | |
An independent security mechanism for SIP message bodies supplies an | |
alternative means of end-to-end mutual authentication, as well as | |
providing a limit on the degree to which user agents must trust | |
intermediaries. | |
26.2.1 Transport and Network Layer Security | |
Transport or network layer security encrypts signaling traffic, | |
guaranteeing message confidentiality and integrity. | |
Oftentimes, certificates are used in the establishment of lower-layer | |
security, and these certificates can also be used to provide a means | |
of authentication in many architectures. | |
Two popular alternatives for providing security at the transport and | |
network layer are, respectively, TLS [25] and IPSec [26]. | |
IPSec is a set of network-layer protocol tools that collectively can | |
be used as a secure replacement for traditional IP (Internet | |
Protocol). IPSec is most commonly used in architectures in which a | |
set of hosts or administrative domains have an existing trust | |
relationship with one another. IPSec is usually implemented at the | |
operating system level in a host, or on a security gateway that | |
provides confidentiality and integrity for all traffic it receives | |
from a particular interface (as in a VPN architecture). IPSec can | |
also be used on a hop-by-hop basis. | |
In many architectures IPSec does not require integration with SIP | |
applications; IPSec is perhaps best suited to deployments in which | |
adding security directly to SIP hosts would be arduous. UAs that | |
have a pre-shared keying relationship with their first-hop proxy | |
server are also good candidates to use IPSec. Any deployment of | |
IPSec for SIP would require an IPSec profile describing the protocol | |
tools that would be required to secure SIP. No such profile is given | |
in this document. | |
Rosenberg, et. al. Standards Track [Page 238] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
TLS provides transport-layer security over connection-oriented | |
protocols (for the purposes of this document, TCP); "tls" (signifying | |
TLS over TCP) can be specified as the desired transport protocol | |
within a Via header field value or a SIP-URI. TLS is most suited to | |
architectures in which hop-by-hop security is required between hosts | |
with no pre-existing trust association. For example, Alice trusts | |
her local proxy server, which after a certificate exchange decides to | |
trust Bob's local proxy server, which Bob trusts, hence Bob and Alice | |
can communicate securely. | |
TLS must be tightly coupled with a SIP application. Note that | |
transport mechanisms are specified on a hop-by-hop basis in SIP, thus | |
a UA that sends requests over TLS to a proxy server has no assurance | |
that TLS will be used end-to-end. | |
The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at | |
a minimum by implementers when TLS is used in a SIP application. For | |
purposes of backwards compatibility, proxy servers, redirect servers, | |
and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. | |
Implementers MAY also support any other ciphersuite. | |
26.2.2 SIPS URI Scheme | |
The SIPS URI scheme adheres to the syntax of the SIP URI (described | |
in 19), although the scheme string is "sips" rather than "sip". The | |
semantics of SIPS are very different from the SIP URI, however. SIPS | |
allows resources to specify that they should be reached securely. | |
A SIPS URI can be used as an address-of-record for a particular user | |
- the URI by which the user is canonically known (on their business | |
cards, in the From header field of their requests, in the To header | |
field of REGISTER requests). When used as the Request-URI of a | |
request, the SIPS scheme signifies that each hop over which the | |
request is forwarded, until the request reaches the SIP entity | |
responsible for the domain portion of the Request-URI, must be | |
secured with TLS; once it reaches the domain in question it is | |
handled in accordance with local security and routing policy, quite | |
possibly using TLS for any last hop to a UAS. When used by the | |
originator of a request (as would be the case if they employed a SIPS | |
URI as the address-of-record of the target), SIPS dictates that the | |
entire request path to the target domain be so secured. | |
The SIPS scheme is applicable to many of the other ways in which SIP | |
URIs are used in SIP today in addition to the Request-URI, including | |
in addresses-of-record, contact addresses (the contents of Contact | |
headers, including those of REGISTER methods), and Route headers. In | |
each instance, the SIPS URI scheme allows these existing fields to | |
Rosenberg, et. al. Standards Track [Page 239] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
designate secure resources. The manner in which a SIPS URI is | |
dereferenced in any of these contexts has its own security properties | |
which are detailed in [4]. | |
The use of SIPS in particular entails that mutual TLS authentication | |
SHOULD be employed, as SHOULD the ciphersuite | |
TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the | |
authentication process SHOULD be validated with root certificates | |
held by the client; failure to validate a certificate SHOULD result | |
in the failure of the request. | |
Note that in the SIPS URI scheme, transport is independent of TLS, | |
and thus "sips:alice@atlanta.com;transport=tcp" and | |
"sips:alice@atlanta.com;transport=sctp" are both valid (although | |
note that UDP is not a valid transport for SIPS). The use of | |
"transport=tls" has consequently been deprecated, partly because | |
it was specific to a single hop of the request. This is a change | |
since RFC 2543. | |
Users that distribute a SIPS URI as an address-of-record may elect to | |
operate devices that refuse requests over insecure transports. | |
26.2.3 HTTP Authentication | |
SIP provides a challenge capability, based on HTTP authentication, | |
that relies on the 401 and 407 response codes as well as header | |
fields for carrying challenges and credentials. Without significant | |
modification, the reuse of the HTTP Digest authentication scheme in | |
SIP allows for replay protection and one-way authentication. | |
The usage of Digest authentication in SIP is detailed in Section 22. | |
26.2.4 S/MIME | |
As is discussed above, encrypting entire SIP messages end-to-end for | |
the purpose of confidentiality is not appropriate because network | |
intermediaries (like proxy servers) need to view certain header | |
fields in order to route messages correctly, and if these | |
intermediaries are excluded from security associations, then SIP | |
messages will essentially be non-routable. | |
However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, | |
securing these bodies end-to-end without affecting message headers. | |
S/MIME can provide end-to-end confidentiality and integrity for | |
message bodies, as well as mutual authentication. It is also | |
possible to use S/MIME to provide a form of integrity and | |
confidentiality for SIP header fields through SIP message tunneling. | |
Rosenberg, et. al. Standards Track [Page 240] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The usage of S/MIME in SIP is detailed in Section 23. | |
26.3 Implementing Security Mechanisms | |
26.3.1 Requirements for Implementers of SIP | |
Proxy servers, redirect servers, and registrars MUST implement TLS, | |
and MUST support both mutual and one-way authentication. It is | |
strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also | |
be capable of acting as a TLS server. Proxy servers, redirect | |
servers, and registrars SHOULD possess a site certificate whose | |
subject corresponds to their canonical hostname. UAs MAY have | |
certificates of their own for mutual authentication with TLS, but no | |
provisions are set forth in this document for their use. All SIP | |
elements that support TLS MUST have a mechanism for validating | |
certificates received during TLS negotiation; this entails possession | |
of one or more root certificates issued by certificate authorities | |
(preferably well-known distributors of site certificates comparable | |
to those that issue root certificates for web browsers). | |
All SIP elements that support TLS MUST also support the SIPS URI | |
scheme. | |
Proxy servers, redirect servers, registrars, and UAs MAY also | |
implement IPSec or other lower-layer security protocols. | |
When a UA attempts to contact a proxy server, redirect server, or | |
registrar, the UAC SHOULD initiate a TLS connection over which it | |
will send SIP messages. In some architectures, UASs MAY receive | |
requests over such TLS connections as well. | |
Proxy servers, redirect servers, registrars, and UAs MUST implement | |
Digest Authorization, encompassing all of the aspects required in 22. | |
Proxy servers, redirect servers, and registrars SHOULD be configured | |
with at least one Digest realm, and at least one "realm" string | |
supported by a given server SHOULD correspond to the server's | |
hostname or domainname. | |
UAs MAY support the signing and encrypting of MIME bodies, and | |
transference of credentials with S/MIME as described in Section 23. | |
If a UA holds one or more root certificates of certificate | |
authorities in order to validate certificates for TLS or IPSec, it | |
SHOULD be capable of reusing these to verify S/MIME certificates, as | |
appropriate. A UA MAY hold root certificates specifically for | |
validating S/MIME certificates. | |
Rosenberg, et. al. Standards Track [Page 241] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Note that is it anticipated that future security extensions may | |
upgrade the normative strength associated with S/MIME as S/MIME | |
implementations appear and the problem space becomes better | |
understood. | |
26.3.2 Security Solutions | |
The operation of these security mechanisms in concert can follow the | |
existing web and email security models to some degree. At a high | |
level, UAs authenticate themselves to servers (proxy servers, | |
redirect servers, and registrars) with a Digest username and | |
password; servers authenticate themselves to UAs one hop away, or to | |
another server one hop away (and vice versa), with a site certificate | |
delivered by TLS. | |
On a peer-to-peer level, UAs trust the network to authenticate one | |
another ordinarily; however, S/MIME can also be used to provide | |
direct authentication when the network does not, or if the network | |
itself is not trusted. | |
The following is an illustrative example in which these security | |
mechanisms are used by various UAs and servers to prevent the sorts | |
of threats described in Section 26.1. While implementers and network | |
administrators MAY follow the normative guidelines given in the | |
remainder of this section, these are provided only as example | |
implementations. | |
26.3.2.1 Registration | |
When a UA comes online and registers with its local administrative | |
domain, it SHOULD establish a TLS connection with its registrar | |
(Section 10 describes how the UA reaches its registrar). The | |
registrar SHOULD offer a certificate to the UA, and the site | |
identified by the certificate MUST correspond with the domain in | |
which the UA intends to register; for example, if the UA intends to | |
register the address-of-record 'alice@atlanta.com', the site | |
certificate must identify a host within the atlanta.com domain (such | |
as sip.atlanta.com). When it receives the TLS Certificate message, | |
the UA SHOULD verify the certificate and inspect the site identified | |
by the certificate. If the certificate is invalid, revoked, or if it | |
does not identify the appropriate party, the UA MUST NOT send the | |
REGISTER message and otherwise proceed with the registration. | |
When a valid certificate has been provided by the registrar, the | |
UA knows that the registrar is not an attacker who might redirect | |
the UA, steal passwords, or attempt any similar attacks. | |
Rosenberg, et. al. Standards Track [Page 242] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The UA then creates a REGISTER request that SHOULD be addressed to a | |
Request-URI corresponding to the site certificate received from the | |
registrar. When the UA sends the REGISTER request over the existing | |
TLS connection, the registrar SHOULD challenge the request with a 401 | |
(Proxy Authentication Required) response. The "realm" parameter | |
within the Proxy-Authenticate header field of the response SHOULD | |
correspond to the domain previously given by the site certificate. | |
When the UAC receives the challenge, it SHOULD either prompt the user | |
for credentials or take an appropriate credential from a keyring | |
corresponding to the "realm" parameter in the challenge. The | |
username of this credential SHOULD correspond with the "userinfo" | |
portion of the URI in the To header field of the REGISTER request. | |
Once the Digest credentials have been inserted into an appropriate | |
Proxy-Authorization header field, the REGISTER should be resubmitted | |
to the registrar. | |
Since the registrar requires the user agent to authenticate | |
itself, it would be difficult for an attacker to forge REGISTER | |
requests for the user's address-of-record. Also note that since | |
the REGISTER is sent over a confidential TLS connection, attackers | |
will not be able to intercept the REGISTER to record credentials | |
for any possible replay attack. | |
Once the registration has been accepted by the registrar, the UA | |
SHOULD leave this TLS connection open provided that the registrar | |
also acts as the proxy server to which requests are sent for users in | |
this administrative domain. The existing TLS connection will be | |
reused to deliver incoming requests to the UA that has just completed | |
registration. | |
Because the UA has already authenticated the server on the other | |
side of the TLS connection, all requests that come over this | |
connection are known to have passed through the proxy server - | |
attackers cannot create spoofed requests that appear to have been | |
sent through that proxy server. | |
26.3.2.2 Interdomain Requests | |
Now let's say that Alice's UA would like to initiate a session with a | |
user in a remote administrative domain, namely "bob@biloxi.com". We | |
will also say that the local administrative domain (atlanta.com) has | |
a local outbound proxy. | |
The proxy server that handles inbound requests for an administrative | |
domain MAY also act as a local outbound proxy; for simplicity's sake | |
we'll assume this to be the case for atlanta.com (otherwise the user | |
agent would initiate a new TLS connection to a separate server at | |
this point). Assuming that the client has completed the registration | |
Rosenberg, et. al. Standards Track [Page 243] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
process described in the preceding section, it SHOULD reuse the TLS | |
connection to the local proxy server when it sends an INVITE request | |
to another user. The UA SHOULD reuse cached credentials in the | |
INVITE to avoid prompting the user unnecessarily. | |
When the local outbound proxy server has validated the credentials | |
presented by the UA in the INVITE, it SHOULD inspect the Request-URI | |
to determine how the message should be routed (see [4]). If the | |
"domainname" portion of the Request-URI had corresponded to the local | |
domain (atlanta.com) rather than biloxi.com, then the proxy server | |
would have consulted its location service to determine how best to | |
reach the requested user. | |
Had "alice@atlanta.com" been attempting to contact, say, | |
"alex@atlanta.com", the local proxy would have proxied to the | |
request to the TLS connection Alex had established with the | |
registrar when he registered. Since Alex would receive this | |
request over his authenticated channel, he would be assured that | |
Alice's request had been authorized by the proxy server of the | |
local administrative domain. | |
However, in this instance the Request-URI designates a remote domain. | |
The local outbound proxy server at atlanta.com SHOULD therefore | |
establish a TLS connection with the remote proxy server at | |
biloxi.com. Since both of the participants in this TLS connection | |
are servers that possess site certificates, mutual TLS authentication | |
SHOULD occur. Each side of the connection SHOULD verify and inspect | |
the certificate of the other, noting the domain name that appears in | |
the certificate for comparison with the header fields of SIP | |
messages. The atlanta.com proxy server, for example, SHOULD verify | |
at this stage that the certificate received from the remote side | |
corresponds with the biloxi.com domain. Once it has done so, and TLS | |
negotiation has completed, resulting in a secure channel between the | |
two proxies, the atlanta.com proxy can forward the INVITE request to | |
biloxi.com. | |
The proxy server at biloxi.com SHOULD inspect the certificate of the | |
proxy server at atlanta.com in turn and compare the domain asserted | |
by the certificate with the "domainname" portion of the From header | |
field in the INVITE request. The biloxi proxy MAY have a strict | |
security policy that requires it to reject requests that do not match | |
the administrative domain from which they have been proxied. | |
Such security policies could be instituted to prevent the SIP | |
equivalent of SMTP 'open relays' that are frequently exploited to | |
generate spam. | |
Rosenberg, et. al. Standards Track [Page 244] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
This policy, however, only guarantees that the request came from the | |
domain it ascribes to itself; it does not allow biloxi.com to | |
ascertain how atlanta.com authenticated Alice. Only if biloxi.com | |
has some other way of knowing atlanta.com's authentication policies | |
could it possibly ascertain how Alice proved her identity. | |
biloxi.com might then institute an even stricter policy that forbids | |
requests that come from domains that are not known administratively | |
to share a common authentication policy with biloxi.com. | |
Once the INVITE has been approved by the biloxi proxy, the proxy | |
server SHOULD identify the existing TLS channel, if any, associated | |
with the user targeted by this request (in this case | |
"bob@biloxi.com"). The INVITE should be proxied through this channel | |
to Bob. Since the request is received over a TLS connection that had | |
previously been authenticated as the biloxi proxy, Bob knows that the | |
From header field was not tampered with and that atlanta.com has | |
validated Alice, although not necessarily whether or not to trust | |
Alice's identity. | |
Before they forward the request, both proxy servers SHOULD add a | |
Record-Route header field to the request so that all future requests | |
in this dialog will pass through the proxy servers. The proxy | |
servers can thereby continue to provide security services for the | |
lifetime of this dialog. If the proxy servers do not add themselves | |
to the Record-Route, future messages will pass directly end-to-end | |
between Alice and Bob without any security services (unless the two | |
parties agree on some independent end-to-end security such as | |
S/MIME). In this respect the SIP trapezoid model can provide a nice | |
structure where conventions of agreement between the site proxies can | |
provide a reasonably secure channel between Alice and Bob. | |
An attacker preying on this architecture would, for example, be | |
unable to forge a BYE request and insert it into the signaling | |
stream between Bob and Alice because the attacker has no way of | |
ascertaining the parameters of the session and also because the | |
integrity mechanism transitively protects the traffic between | |
Alice and Bob. | |
26.3.2.3 Peer-to-Peer Requests | |
Alternatively, consider a UA asserting the identity | |
"carol@chicago.com" that has no local outbound proxy. When Carol | |
wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate | |
a TLS connection with the biloxi proxy directly (using the mechanism | |
described in [4] to determine how to best to reach the given | |
Request-URI). When her UA receives a certificate from the biloxi | |
proxy, it SHOULD be verified normally before she passes her INVITE | |
across the TLS connection. However, Carol has no means of proving | |
Rosenberg, et. al. Standards Track [Page 245] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
her identity to the biloxi proxy, but she does have a CMS-detached | |
signature over a "message/sip" body in the INVITE. It is unlikely in | |
this instance that Carol would have any credentials in the biloxi.com | |
realm, since she has no formal association with biloxi.com. The | |
biloxi proxy MAY also have a strict policy that precludes it from | |
even bothering to challenge requests that do not have biloxi.com in | |
the "domainname" portion of the From header field - it treats these | |
users as unauthenticated. | |
The biloxi proxy has a policy for Bob that all non-authenticated | |
requests should be redirected to the appropriate contact address | |
registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>. | |
Carol receives the redirection response over the TLS connection she | |
established with the biloxi proxy, so she trusts the veracity of the | |
contact address. | |
Carol SHOULD then establish a TCP connection with the designated | |
address and send a new INVITE with a Request-URI containing the | |
received contact address (recomputing the signature in the body as | |
the request is readied). Bob receives this INVITE on an insecure | |
interface, but his UA inspects and, in this instance, recognizes the | |
From header field of the request and subsequently matches a locally | |
cached certificate with the one presented in the signature of the | |
body of the INVITE. He replies in similar fashion, authenticating | |
himself to Carol, and a secure dialog begins. | |
Sometimes firewalls or NATs in an administrative domain could | |
preclude the establishment of a direct TCP connection to a UA. In | |
these cases, proxy servers could also potentially relay requests | |
to UAs in a way that has no trust implications (for example, | |
forgoing an existing TLS connection and forwarding the request | |
over cleartext TCP) as local policy dictates. | |
26.3.2.4 DoS Protection | |
In order to minimize the risk of a denial-of-service attack against | |
architectures using these security solutions, implementers should | |
take note of the following guidelines. | |
When the host on which a SIP proxy server is operating is routable | |
from the public Internet, it SHOULD be deployed in an administrative | |
domain with defensive operational policies (blocking source-routed | |
traffic, preferably filtering ping traffic). Both TLS and IPSec can | |
also make use of bastion hosts at the edges of administrative domains | |
that participate in the security associations to aggregate secure | |
tunnels and sockets. These bastion hosts can also take the brunt of | |
denial-of-service attacks, ensuring that SIP hosts within the | |
administrative domain are not encumbered with superfluous messaging. | |
Rosenberg, et. al. Standards Track [Page 246] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
No matter what security solutions are deployed, floods of messages | |
directed at proxy servers can lock up proxy server resources and | |
prevent desirable traffic from reaching its destination. There is a | |
computational expense associated with processing a SIP transaction at | |
a proxy server, and that expense is greater for stateful proxy | |
servers than it is for stateless proxy servers. Therefore, stateful | |
proxies are more susceptible to flooding than stateless proxy | |
servers. | |
UAs and proxy servers SHOULD challenge questionable requests with | |
only a single 401 (Unauthorized) or 407 (Proxy Authentication | |
Required), forgoing the normal response retransmission algorithm, and | |
thus behaving statelessly towards unauthenticated requests. | |
Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication | |
Required) status response amplifies the problem of an attacker | |
using a falsified header field value (such as Via) to direct | |
traffic to a third party. | |
In summary, the mutual authentication of proxy servers through | |
mechanisms such as TLS significantly reduces the potential for rogue | |
intermediaries to introduce falsified requests or responses that can | |
deny service. This commensurately makes it harder for attackers to | |
make innocent SIP nodes into agents of amplification. | |
26.4 Limitations | |
Although these security mechanisms, when applied in a judicious | |
manner, can thwart many threats, there are limitations in the scope | |
of the mechanisms that must be understood by implementers and network | |
operators. | |
26.4.1 HTTP Digest | |
One of the primary limitations of using HTTP Digest in SIP is that | |
the integrity mechanisms in Digest do not work very well for SIP. | |
Specifically, they offer protection of the Request-URI and the method | |
of a message, but not for any of the header fields that UAs would | |
most likely wish to secure. | |
The existing replay protection mechanisms described in RFC 2617 also | |
have some limitations for SIP. The next-nonce mechanism, for | |
example, does not support pipelined requests. The nonce-count | |
mechanism should be used for replay protection. | |
Another limitation of HTTP Digest is the scope of realms. Digest is | |
valuable when a user wants to authenticate themselves to a resource | |
with which they have a pre-existing association, like a service | |
Rosenberg, et. al. Standards Track [Page 247] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
provider of which the user is a customer (which is quite a common | |
scenario and thus Digest provides an extremely useful function). By | |
way of contrast, the scope of TLS is interdomain or multirealm, since | |
certificates are often globally verifiable, so that the UA can | |
authenticate the server with no pre-existing association. | |
26.4.2 S/MIME | |
The largest outstanding defect with the S/MIME mechanism is the lack | |
of a prevalent public key infrastructure for end users. If self- | |
signed certificates (or certificates that cannot be verified by one | |
of the participants in a dialog) are used, the SIP-based key exchange | |
mechanism described in Section 23.2 is susceptible to a man-in-the- | |
middle attack with which an attacker can potentially inspect and | |
modify S/MIME bodies. The attacker needs to intercept the first | |
exchange of keys between the two parties in a dialog, remove the | |
existing CMS-detached signatures from the request and response, and | |
insert a different CMS-detached signature containing a certificate | |
supplied by the attacker (but which seems to be a certificate for the | |
proper address-of-record). Each party will think they have exchanged | |
keys with the other, when in fact each has the public key of the | |
attacker. | |
It is important to note that the attacker can only leverage this | |
vulnerability on the first exchange of keys between two parties - on | |
subsequent occasions, the alteration of the key would be noticeable | |
to the UAs. It would also be difficult for the attacker to remain in | |
the path of all future dialogs between the two parties over time (as | |
potentially days, weeks, or years pass). | |
SSH is susceptible to the same man-in-the-middle attack on the first | |
exchange of keys; however, it is widely acknowledged that while SSH | |
is not perfect, it does improve the security of connections. The use | |
of key fingerprints could provide some assistance to SIP, just as it | |
does for SSH. For example, if two parties use SIP to establish a | |
voice communications session, each could read off the fingerprint of | |
the key they received from the other, which could be compared against | |
the original. It would certainly be more difficult for the man-in- | |
the-middle to emulate the voices of the participants than their | |
signaling (a practice that was used with the Clipper chip-based | |
secure telephone). | |
The S/MIME mechanism allows UAs to send encrypted requests without | |
preamble if they possess a certificate for the destination address- | |
of-record on their keyring. However, it is possible that any | |
particular device registered for an address-of-record will not hold | |
the certificate that has been previously employed by the device's | |
current user, and that it will therefore be unable to process an | |
Rosenberg, et. al. Standards Track [Page 248] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
encrypted request properly, which could lead to some avoidable error | |
signaling. This is especially likely when an encrypted request is | |
forked. | |
The keys associated with S/MIME are most useful when associated with | |
a particular user (an address-of-record) rather than a device (a UA). | |
When users move between devices, it may be difficult to transport | |
private keys securely between UAs; how such keys might be acquired by | |
a device is outside the scope of this document. | |
Another, more prosaic difficulty with the S/MIME mechanism is that it | |
can result in very large messages, especially when the SIP tunneling | |
mechanism described in Section 23.4 is used. For that reason, it is | |
RECOMMENDED that TCP should be used as a transport protocol when | |
S/MIME tunneling is employed. | |
26.4.3 TLS | |
The most commonly voiced concern about TLS is that it cannot run over | |
UDP; TLS requires a connection-oriented underlying transport | |
protocol, which for the purposes of this document means TCP. | |
It may also be arduous for a local outbound proxy server and/or | |
registrar to maintain many simultaneous long-lived TLS connections | |
with numerous UAs. This introduces some valid scalability concerns, | |
especially for intensive ciphersuites. Maintaining redundancy of | |
long-lived TLS connections, especially when a UA is solely | |
responsible for their establishment, could also be cumbersome. | |
TLS only allows SIP entities to authenticate servers to which they | |
are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, | |
nor any other mechanism specified in this document, allows clients to | |
authenticate proxy servers to whom they cannot form a direct TCP | |
connection. | |
26.4.4 SIPS URIs | |
Actually using TLS on every segment of a request path entails that | |
the terminating UAS must be reachable over TLS (perhaps registering | |
with a SIPS URI as a contact address). This is the preferred use of | |
SIPS. Many valid architectures, however, use TLS to secure part of | |
the request path, but rely on some other mechanism for the final hop | |
to a UAS, for example. Thus SIPS cannot guarantee that TLS usage | |
will be truly end-to-end. Note that since many UAs will not accept | |
incoming TLS connections, even those UAs that do support TLS may be | |
required to maintain persistent TLS connections as described in the | |
TLS limitations section above in order to receive requests over TLS | |
as a UAS. | |
Rosenberg, et. al. Standards Track [Page 249] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Location services are not required to provide a SIPS binding for a | |
SIPS Request-URI. Although location services are commonly populated | |
by user registrations (as described in Section 10.2.1), various other | |
protocols and interfaces could conceivably supply contact addresses | |
for an AOR, and these tools are free to map SIPS URIs to SIP URIs as | |
appropriate. When queried for bindings, a location service returns | |
its contact addresses without regard for whether it received a | |
request with a SIPS Request-URI. If a redirect server is accessing | |
the location service, it is up to the entity that processes the | |
Contact header field of a redirection to determine the propriety of | |
the contact addresses. | |
Ensuring that TLS will be used for all of the request segments up to | |
the target domain is somewhat complex. It is possible that | |
cryptographically authenticated proxy servers along the way that are | |
non-compliant or compromised may choose to disregard the forwarding | |
rules associated with SIPS (and the general forwarding rules in | |
Section 16.6). Such malicious intermediaries could, for example, | |
retarget a request from a SIPS URI to a SIP URI in an attempt to | |
downgrade security. | |
Alternatively, an intermediary might legitimately retarget a request | |
from a SIP to a SIPS URI. Recipients of a request whose Request-URI | |
uses the SIPS URI scheme thus cannot assume on the basis of the | |
Request-URI alone that SIPS was used for the entire request path | |
(from the client onwards). | |
To address these concerns, it is RECOMMENDED that recipients of a | |
request whose Request-URI contains a SIP or SIPS URI inspect the To | |
header field value to see if it contains a SIPS URI (though note that | |
it does not constitute a breach of security if this URI has the same | |
scheme but is not equivalent to the URI in the To header field). | |
Although clients may choose to populate the Request-URI and To header | |
field of a request differently, when SIPS is used this disparity | |
could be interpreted as a possible security violation, and the | |
request could consequently be rejected by its recipient. Recipients | |
MAY also inspect the Via header chain in order to double-check | |
whether or not TLS was used for the entire request path until the | |
local administrative domain was reached. S/MIME may also be used by | |
the originating UAC to help ensure that the original form of the To | |
header field is carried end-to-end. | |
If the UAS has reason to believe that the scheme of the Request-URI | |
has been improperly modified in transit, the UA SHOULD notify its | |
user of a potential security breach. | |
Rosenberg, et. al. Standards Track [Page 250] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
As a further measure to prevent downgrade attacks, entities that | |
accept only SIPS requests MAY also refuse connections on insecure | |
ports. | |
End users will undoubtedly discern the difference between SIPS and | |
SIP URIs, and they may manually edit them in response to stimuli. | |
This can either benefit or degrade security. For example, if an | |
attacker corrupts a DNS cache, inserting a fake record set that | |
effectively removes all SIPS records for a proxy server, then any | |
SIPS requests that traverse this proxy server may fail. When a user, | |
however, sees that repeated calls to a SIPS AOR are failing, they | |
could on some devices manually convert the scheme from SIPS to SIP | |
and retry. Of course, there are some safeguards against this (if the | |
destination UA is truly paranoid it could refuse all non-SIPS | |
requests), but it is a limitation worth noting. On the bright side, | |
users might also divine that 'SIPS' would be valid even when they are | |
presented only with a SIP URI. | |
26.5 Privacy | |
SIP messages frequently contain sensitive information about their | |
senders - not just what they have to say, but with whom they | |
communicate, when they communicate and for how long, and from where | |
they participate in sessions. Many applications and their users | |
require that this sort of private information be hidden from any | |
parties that do not need to know it. | |
Note that there are also less direct ways in which private | |
information can be divulged. If a user or service chooses to be | |
reachable at an address that is guessable from the person's name and | |
organizational affiliation (which describes most addresses-of- | |
record), the traditional method of ensuring privacy by having an | |
unlisted "phone number" is compromised. A user location service can | |
infringe on the privacy of the recipient of a session invitation by | |
divulging their specific whereabouts to the caller; an implementation | |
consequently SHOULD be able to restrict, on a per-user basis, what | |
kind of location and availability information is given out to certain | |
classes of callers. This is a whole class of problem that is | |
expected to be studied further in ongoing SIP work. | |
In some cases, users may want to conceal personal information in | |
header fields that convey identity. This can apply not only to the | |
From and related headers representing the originator of the request, | |
but also the To - it may not be appropriate to convey to the final | |
destination a speed-dialing nickname, or an unexpanded identifier for | |
a group of targets, either of which would be removed from the | |
Request-URI as the request is routed, but not changed in the To | |
Rosenberg, et. al. Standards Track [Page 251] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
header field if the two were initially identical. Thus it MAY be | |
desirable for privacy reasons to create a To header field that | |
differs from the Request-URI. | |
27 IANA Considerations | |
All method names, header field names, status codes, and option tags | |
used in SIP applications are registered with IANA through | |
instructions in an IANA Considerations section in an RFC. | |
The specification instructs the IANA to create four new sub- | |
registries under http://www.iana.org/assignments/sip-parameters: | |
Option Tags, Warning Codes (warn-codes), Methods and Response Codes, | |
added to the sub-registry of Header Fields that is already present | |
there. | |
27.1 Option Tags | |
This specification establishes the Option Tags sub-registry under | |
http://www.iana.org/assignments/sip-parameters. | |
Option tags are used in header fields such as Require, Supported, | |
Proxy-Require, and Unsupported in support of SIP compatibility | |
mechanisms for extensions (Section 19.2). The option tag itself is a | |
string that is associated with a particular SIP option (that is, an | |
extension). It identifies the option to SIP endpoints. | |
Option tags are registered by the IANA when they are published in | |
standards track RFCs. The IANA Considerations section of the RFC | |
must include the following information, which appears in the IANA | |
registry along with the RFC number of the publication. | |
o Name of the option tag. The name MAY be of any length, but | |
SHOULD be no more than twenty characters long. The name MUST | |
consist of alphanum (Section 25) characters only. | |
o Descriptive text that describes the extension. | |
27.2 Warn-Codes | |
This specification establishes the Warn-codes sub-registry under | |
http://www.iana.org/assignments/sip-parameters and initiates its | |
population with the warn-codes listed in Section 20.43. Additional | |
warn-codes are registered by RFC publication. | |
Rosenberg, et. al. Standards Track [Page 252] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
The descriptive text for the table of warn-codes is: | |
Warning codes provide information supplemental to the status code in | |
SIP response messages when the failure of the transaction results | |
from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. | |
The "warn-code" consists of three digits. A first digit of "3" | |
indicates warnings specific to SIP. Until a future specification | |
describes uses of warn-codes other than 3xx, only 3xx warn-codes may | |
be registered. | |
Warnings 300 through 329 are reserved for indicating problems with | |
keywords in the session description, 330 through 339 are warnings | |
related to basic network services requested in the session | |
description, 370 through 379 are warnings related to quantitative QoS | |
parameters requested in the session description, and 390 through 399 | |
are miscellaneous warnings that do not fall into one of the above | |
categories. | |
27.3 Header Field Names | |
This obsoletes the IANA instructions about the header sub-registry | |
under http://www.iana.org/assignments/sip-parameters. | |
The following information needs to be provided in an RFC publication | |
in order to register a new header field name: | |
o The RFC number in which the header is registered; | |
o the name of the header field being registered; | |
o a compact form version for that header field, if one is | |
defined; | |
Some common and widely used header fields MAY be assigned one-letter | |
compact forms (Section 7.3.3). Compact forms can only be assigned | |
after SIP working group review, followed by RFC publication. | |
27.4 Method and Response Codes | |
This specification establishes the Method and Response-Code sub- | |
registries under http://www.iana.org/assignments/sip-parameters and | |
initiates their population as follows. The initial Methods table is: | |
Rosenberg, et. al. Standards Track [Page 253] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
INVITE [RFC3261] | |
ACK [RFC3261] | |
BYE [RFC3261] | |
CANCEL [RFC3261] | |
REGISTER [RFC3261] | |
OPTIONS [RFC3261] | |
INFO [RFC2976] | |
The response code table is initially populated from Section 21, the | |
portions labeled Informational, Success, Redirection, Client-Error, | |
Server-Error, and Global-Failure. The table has the following | |
format: | |
Type (e.g., Informational) | |
Number Default Reason Phrase [RFC3261] | |
The following information needs to be provided in an RFC publication | |
in order to register a new response code or method: | |
o The RFC number in which the method or response code is | |
registered; | |
o the number of the response code or name of the method being | |
registered; | |
o the default reason phrase for that response code, if | |
applicable; | |
27.5 The "message/sip" MIME type. | |
This document registers the "message/sip" MIME media type in order to | |
allow SIP messages to be tunneled as bodies within SIP, primarily for | |
end-to-end security purposes. This media type is defined by the | |
following information: | |
Media type name: message | |
Media subtype name: sip | |
Required parameters: none | |
Optional parameters: version | |
version: The SIP-Version number of the enclosed message (e.g., | |
"2.0"). If not present, the version defaults to "2.0". | |
Encoding scheme: SIP messages consist of an 8-bit header | |
optionally followed by a binary MIME data object. As such, SIP | |
messages must be treated as binary. Under normal circumstances | |
SIP messages are transported over binary-capable transports, no | |
special encodings are needed. | |
Rosenberg, et. al. Standards Track [Page 254] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Security considerations: see below | |
Motivation and examples of this usage as a security mechanism | |
in concert with S/MIME are given in 23.4. | |
27.6 New Content-Disposition Parameter Registrations | |
This document also registers four new Content-Disposition header | |
"disposition-types": alert, icon, session and render. The authors | |
request that these values be recorded in the IANA registry for | |
Content-Dispositions. | |
Descriptions of these "disposition-types", including motivation and | |
examples, are given in Section 20.11. | |
Short descriptions suitable for the IANA registry are: | |
alert the body is a custom ring tone to alert the user | |
icon the body is displayed as an icon to the user | |
render the body should be displayed to the user | |
session the body describes a communications session, for | |
example, as RFC 2327 SDP body | |
28 Changes From RFC 2543 | |
This RFC revises RFC 2543. It is mostly backwards compatible with | |
RFC 2543. The changes described here fix many errors discovered in | |
RFC 2543 and provide information on scenarios not detailed in RFC | |
2543. The protocol has been presented in a more cleanly layered | |
model here. | |
We break the differences into functional behavior that is a | |
substantial change from RFC 2543, which has impact on | |
interoperability or correct operation in some cases, and functional | |
behavior that is different from RFC 2543 but not a potential source | |
of interoperability problems. There have been countless | |
clarifications as well, which are not documented here. | |
28.1 Major Functional Changes | |
o When a UAC wishes to terminate a call before it has been answered, | |
it sends CANCEL. If the original INVITE still returns a 2xx, the | |
UAC then sends BYE. BYE can only be sent on an existing call leg | |
(now called a dialog in this RFC), whereas it could be sent at any | |
time in RFC 2543. | |
o The SIP BNF was converted to be RFC 2234 compliant. | |
Rosenberg, et. al. Standards Track [Page 255] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o SIP URL BNF was made more general, allowing a greater set of | |
characters in the user part. Furthermore, comparison rules were | |
simplified to be primarily case-insensitive, and detailed handling | |
of comparison in the presence of parameters was described. The | |
most substantial change is that a URI with a parameter with the | |
default value does not match a URI without that parameter. | |
o Removed Via hiding. It had serious trust issues, since it relied | |
on the next hop to perform the obfuscation process. Instead, Via | |
hiding can be done as a local implementation choice in stateful | |
proxies, and thus is no longer documented. | |
o In RFC 2543, CANCEL and INVITE transactions were intermingled. | |
They are separated now. When a user sends an INVITE and then a | |
CANCEL, the INVITE transaction still terminates normally. A UAS | |
needs to respond to the original INVITE request with a 487 | |
response. | |
o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 | |
allowed the UAS not to send a response to INVITE when a BYE was | |
received. That is disallowed here. The original INVITE needs a | |
response. | |
o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs | |
need to support both UDP and TCP. | |
o In RFC 2543, a forking proxy only passed up one challenge from | |
downstream elements in the event of multiple challenges. In this | |
RFC, proxies are supposed to collect all challenges and place them | |
into the forwarded response. | |
o In Digest credentials, the URI needs to be quoted; this is unclear | |
from RFC 2617 and RFC 2069 which are both inconsistent on it. | |
o SDP processing has been split off into a separate specification | |
[13], and more fully specified as a formal offer/answer exchange | |
process that is effectively tunneled through SIP. SDP is allowed | |
in INVITE/200 or 200/ACK for baseline SIP implementations; RFC | |
2543 alluded to the ability to use it in INVITE, 200, and ACK in a | |
single transaction, but this was not well specified. More complex | |
SDP usages are allowed in extensions. | |
Rosenberg, et. al. Standards Track [Page 256] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o Added full support for IPv6 in URIs and in the Via header field. | |
Support for IPv6 in Via has required that its header field | |
parameters allow the square bracket and colon characters. These | |
characters were previously not permitted. In theory, this could | |
cause interop problems with older implementations. However, we | |
have observed that most implementations accept any non-control | |
ASCII character in these parameters. | |
o DNS SRV procedure is now documented in a separate specification | |
[4]. This procedure uses both SRV and NAPTR resource records and | |
no longer combines data from across SRV records as described in | |
RFC 2543. | |
o Loop detection has been made optional, supplanted by a mandatory | |
usage of Max-Forwards. The loop detection procedure in RFC 2543 | |
had a serious bug which would report "spirals" as an error | |
condition when it was not. The optional loop detection procedure | |
is more fully and correctly specified here. | |
o Usage of tags is now mandatory (they were optional in RFC 2543), | |
as they are now the fundamental building blocks of dialog | |
identification. | |
o Added the Supported header field, allowing for clients to indicate | |
what extensions are supported to a server, which can apply those | |
extensions to the response, and indicate their usage with a | |
Require in the response. | |
o Extension parameters were missing from the BNF for several header | |
fields, and they have been added. | |
o Handling of Route and Record-Route construction was very | |
underspecified in RFC 2543, and also not the right approach. It | |
has been substantially reworked in this specification (and made | |
vastly simpler), and this is arguably the largest change. | |
Backwards compatibility is still provided for deployments that do | |
not use "pre-loaded routes", where the initial request has a set | |
of Route header field values obtained in some way outside of | |
Record-Route. In those situations, the new mechanism is not | |
interoperable. | |
o In RFC 2543, lines in a message could be terminated with CR, LF, | |
or CRLF. This specification only allows CRLF. | |
Rosenberg, et. al. Standards Track [Page 257] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. | |
It is now well specified; if a request had a Route header field, | |
its CANCEL or ACK for a non-2xx response to the request need to | |
carry the same Route header field values. ACKs for 2xx responses | |
use the Route values learned from the Record-Route of the 2xx | |
responses. | |
o RFC 2543 allowed multiple requests in a single UDP packet. This | |
usage has been removed. | |
o Usage of absolute time in the Expires header field and parameter | |
has been removed. It caused interoperability problems in elements | |
that were not time synchronized, a common occurrence. Relative | |
times are used instead. | |
o The branch parameter of the Via header field value is now | |
mandatory for all elements to use. It now plays the role of a | |
unique transaction identifier. This avoids the complex and bug- | |
laden transaction identification rules from RFC 2543. A magic | |
cookie is used in the parameter value to determine if the previous | |
hop has made the parameter globally unique, and comparison falls | |
back to the old rules when it is not present. Thus, | |
interoperability is assured. | |
o In RFC 2543, closure of a TCP connection was made equivalent to a | |
CANCEL. This was nearly impossible to implement (and wrong) for | |
TCP connections between proxies. This has been eliminated, so | |
that there is no coupling between TCP connection state and SIP | |
processing. | |
o RFC 2543 was silent on whether a UA could initiate a new | |
transaction to a peer while another was in progress. That is now | |
specified here. It is allowed for non-INVITE requests, disallowed | |
for INVITE. | |
o PGP was removed. It was not sufficiently specified, and not | |
compatible with the more complete PGP MIME. It was replaced with | |
S/MIME. | |
o Added the "sips" URI scheme for end-to-end TLS. This scheme is | |
not backwards compatible with RFC 2543. Existing elements that | |
receive a request with a SIPS URI scheme in the Request-URI will | |
likely reject the request. This is actually a feature; it ensures | |
that a call to a SIPS URI is only delivered if all path hops can | |
be secured. | |
Rosenberg, et. al. Standards Track [Page 258] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o Additional security features were added with TLS, and these are | |
described in a much larger and complete security considerations | |
section. | |
o In RFC 2543, a proxy was not required to forward provisional | |
responses from 101 to 199 upstream. This was changed to MUST. | |
This is important, since many subsequent features depend on | |
delivery of all provisional responses from 101 to 199. | |
o Little was said about the 503 response code in RFC 2543. It has | |
since found substantial use in indicating failure or overload | |
conditions in proxies. This requires somewhat special treatment. | |
Specifically, receipt of a 503 should trigger an attempt to | |
contact the next element in the result of a DNS SRV lookup. Also, | |
503 response is only forwarded upstream by a proxy under certain | |
conditions. | |
o RFC 2543 defined, but did no sufficiently specify, a mechanism for | |
UA authentication of a server. That has been removed. Instead, | |
the mutual authentication procedures of RFC 2617 are allowed. | |
o A UA cannot send a BYE for a call until it has received an ACK for | |
the initial INVITE. This was allowed in RFC 2543 but leads to a | |
potential race condition. | |
o A UA or proxy cannot send CANCEL for a transaction until it gets a | |
provisional response for the request. This was allowed in RFC | |
2543 but leads to potential race conditions. | |
o The action parameter in registrations has been deprecated. It was | |
insufficient for any useful services, and caused conflicts when | |
application processing was applied in proxies. | |
o RFC 2543 had a number of special cases for multicast. For | |
example, certain responses were suppressed, timers were adjusted, | |
and so on. Multicast now plays a more limited role, and the | |
protocol operation is unaffected by usage of multicast as opposed | |
to unicast. The limitations as a result of that are documented. | |
o Basic authentication has been removed entirely and its usage | |
forbidden. | |
Rosenberg, et. al. Standards Track [Page 259] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
o Proxies no longer forward a 6xx immediately on receiving it. | |
Instead, they CANCEL pending branches immediately. This avoids a | |
potential race condition that would result in a UAC getting a 6xx | |
followed by a 2xx. In all cases except this race condition, the | |
result will be the same - the 6xx is forwarded upstream. | |
o RFC 2543 did not address the problem of request merging. This | |
occurs when a request forks at a proxy and later rejoins at an | |
element. Handling of merging is done only at a UA, and procedures | |
are defined for rejecting all but the first request. | |
28.2 Minor Functional Changes | |
o Added the Alert-Info, Error-Info, and Call-Info header fields for | |
optional content presentation to users. | |
o Added the Content-Language, Content-Disposition and MIME-Version | |
header fields. | |
o Added a "glare handling" mechanism to deal with the case where | |
both parties send each other a re-INVITE simultaneously. It uses | |
the new 491 (Request Pending) error code. | |
o Added the In-Reply-To and Reply-To header fields for supporting | |
the return of missed calls or messages at a later time. | |
o Added TLS and SCTP as valid SIP transports. | |
o There were a variety of mechanisms described for handling failures | |
at any time during a call; those are now generally unified. BYE | |
is sent to terminate. | |
o RFC 2543 mandated retransmission of INVITE responses over TCP, but | |
noted it was really only needed for 2xx. That was an artifact of | |
insufficient protocol layering. With a more coherent transaction | |
layer defined here, that is no longer needed. Only 2xx responses | |
to INVITEs are retransmitted over TCP. | |
o Client and server transaction machines are now driven based on | |
timeouts rather than retransmit counts. This allows the state | |
machines to be properly specified for TCP and UDP. | |
o The Date header field is used in REGISTER responses to provide a | |
simple means for auto-configuration of dates in user agents. | |
o Allowed a registrar to reject registrations with expirations that | |
are too short in duration. Defined the 423 response code and the | |
Min-Expires for this purpose. | |
Rosenberg, et. al. Standards Track [Page 260] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
29 Normative References | |
[1] Handley, M. and V. Jacobson, "SDP: Session Description | |
Protocol", RFC 2327, April 1998. | |
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |
Levels", BCP 14, RFC 2119, March 1997. | |
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. | |
[4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", | |
RFC 3263, June 2002. | |
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource | |
Identifiers (URI): Generic Syntax", RFC 2396, August 1998. | |
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for | |
Transport Layer Security (TLS)", RFC 3268, June 2002. | |
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC | |
2279, January 1998. | |
[8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., | |
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- | |
HTTP/1.1", RFC 2616, June 1999. | |
[9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April | |
2000. | |
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |
Specifications: ABNF", RFC 2234, November 1997. | |
[11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail | |
Extensions (MIME) Part Two: Media Types", RFC 2046, November | |
1996. | |
[12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness | |
Recommendations for Security", RFC 1750, December 1994. | |
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with | |
SDP", RFC 3264, June 2002. | |
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August | |
1980. | |
[15] Postel, J., "DoD Standard Transmission Control Protocol", RFC | |
761, January 1980. | |
Rosenberg, et. al. Standards Track [Page 261] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
[16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, | |
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, | |
"Stream Control Transmission Protocol", RFC 2960, October 2000. | |
[17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | |
Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: | |
Basic and Digest Access Authentication", RFC 2617, June 1999. | |
[18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation | |
Information in Internet Messages: The Content-Disposition Header | |
Field", RFC 2183, August 1997. | |
[19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., | |
Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG | |
Objects", RFC 3204, December 2001. | |
[20] Braden, R., "Requirements for Internet Hosts - Application and | |
Support", STD 3, RFC 1123, October 1989. | |
[21] Alvestrand, H., "IETF Policy on Character Sets and Languages", | |
BCP 18, RFC 2277, January 1998. | |
[22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security | |
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", | |
RFC 1847, October 1995. | |
[23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June | |
1999. | |
[24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, | |
June 1999. | |
[25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC | |
2246, January 1999. | |
[26] Kent, S. and R. Atkinson, "Security Architecture for the | |
Internet Protocol", RFC 2401, November 1998. | |
30 Informative References | |
[27] R. Pandya, "Emerging mobile and personal communication systems," | |
IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. | |
[28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, | |
"RTP: A Transport Protocol for Real-Time Applications", RFC | |
1889, January 1996. | |
Rosenberg, et. al. Standards Track [Page 262] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
[29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming | |
Protocol (RTSP)", RFC 2326, April 1998. | |
[30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and | |
J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November | |
2000. | |
[31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, | |
"SIP: Session Initiation Protocol", RFC 2543, March 1999. | |
[32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL | |
scheme", RFC 2368, July 1998. | |
[33] E. M. Schooler, "A multicast user directory service for | |
synchronous rendezvous," Master's Thesis CS-TR-96-18, Department | |
of Computer Science, California Institute of Technology, | |
Pasadena, California, Aug. 1996. | |
[34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. | |
[35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April | |
1992. | |
[36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC | |
2426, September 1998. | |
[37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical | |
Specification", RFC 2849, June 2000. | |
[38] Palme, J., "Common Internet Message Headers", RFC 2076, | |
February 1997. | |
[39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | |
Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: | |
Digest Access Authentication", RFC 2069, January 1997. | |
[40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, | |
D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call | |
Flow Examples", Work in Progress. | |
[41] E. M. Schooler, "Case study: multimedia conference control in a | |
packet-switched teleconferencing system," Journal of | |
Internetworking: Research and Experience, Vol. 4, pp. 99--120, | |
June 1993. ISI reprint series ISI/RS-93-359. | |
Rosenberg, et. al. Standards Track [Page 263] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
[42] H. Schulzrinne, "Personal mobility for multimedia services in | |
the Internet," in European Workshop on Interactive Distributed | |
Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. | |
1996. | |
[43] Floyd, S., "Congestion Control Principles", RFC 2914, September | |
2000. | |
Rosenberg, et. al. Standards Track [Page 264] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
A Table of Timer Values | |
Table 4 summarizes the meaning and defaults of the various timers | |
used by this specification. | |
Timer Value Section Meaning | |
---------------------------------------------------------------------- | |
T1 500ms default Section 17.1.1.1 RTT Estimate | |
T2 4s Section 17.1.2.2 The maximum retransmit | |
interval for non-INVITE | |
requests and INVITE | |
responses | |
T4 5s Section 17.1.2.2 Maximum duration a | |
message will | |
remain in the network | |
Timer A initially T1 Section 17.1.1.2 INVITE request retransmit | |
interval, for UDP only | |
Timer B 64*T1 Section 17.1.1.2 INVITE transaction | |
timeout timer | |
Timer C > 3min Section 16.6 proxy INVITE transaction | |
bullet 11 timeout | |
Timer D > 32s for UDP Section 17.1.1.2 Wait time for response | |
0s for TCP/SCTP retransmits | |
Timer E initially T1 Section 17.1.2.2 non-INVITE request | |
retransmit interval, | |
UDP only | |
Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction | |
timeout timer | |
Timer G initially T1 Section 17.2.1 INVITE response | |
retransmit interval | |
Timer H 64*T1 Section 17.2.1 Wait time for | |
ACK receipt | |
Timer I T4 for UDP Section 17.2.1 Wait time for | |
0s for TCP/SCTP ACK retransmits | |
Timer J 64*T1 for UDP Section 17.2.2 Wait time for | |
0s for TCP/SCTP non-INVITE request | |
retransmits | |
Timer K T4 for UDP Section 17.1.2.2 Wait time for | |
0s for TCP/SCTP response retransmits | |
Table 4: Summary of timers | |
Rosenberg, et. al. Standards Track [Page 265] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Acknowledgments | |
We wish to thank the members of the IETF MMUSIC and SIP WGs for their | |
comments and suggestions. Detailed comments were provided by Ofir | |
Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, | |
Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John | |
Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, | |
Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders | |
Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William | |
Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe | |
J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick | |
Workman. | |
Brian Rosen provided the compiled BNF. | |
Jean Mahoney provided technical writing assistance. | |
This work is based, inter alia, on [41,42]. | |
Rosenberg, et. al. Standards Track [Page 266] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Authors' Addresses | |
Authors addresses are listed alphabetically for the editors, the | |
writers, and then the original authors of RFC 2543. All listed | |
authors actively contributed large amounts of text to this document. | |
Jonathan Rosenberg | |
dynamicsoft | |
72 Eagle Rock Ave | |
East Hanover, NJ 07936 | |
USA | |
EMail: jdrosen@dynamicsoft.com | |
Henning Schulzrinne | |
Dept. of Computer Science | |
Columbia University | |
1214 Amsterdam Avenue | |
New York, NY 10027 | |
USA | |
EMail: schulzrinne@cs.columbia.edu | |
Gonzalo Camarillo | |
Ericsson | |
Advanced Signalling Research Lab. | |
FIN-02420 Jorvas | |
Finland | |
EMail: Gonzalo.Camarillo@ericsson.com | |
Alan Johnston | |
WorldCom | |
100 South 4th Street | |
St. Louis, MO 63102 | |
USA | |
EMail: alan.johnston@wcom.com | |
Rosenberg, et. al. Standards Track [Page 267] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Jon Peterson | |
NeuStar, Inc | |
1800 Sutter Street, Suite 570 | |
Concord, CA 94520 | |
USA | |
EMail: jon.peterson@neustar.com | |
Robert Sparks | |
dynamicsoft, Inc. | |
5100 Tennyson Parkway | |
Suite 1200 | |
Plano, Texas 75024 | |
USA | |
EMail: rsparks@dynamicsoft.com | |
Mark Handley | |
International Computer Science Institute | |
1947 Center St, Suite 600 | |
Berkeley, CA 94704 | |
USA | |
EMail: mjh@icir.org | |
Eve Schooler | |
AT&T Labs-Research | |
75 Willow Road | |
Menlo Park, CA 94025 | |
USA | |
EMail: schooler@research.att.com | |
Rosenberg, et. al. Standards Track [Page 268] | |
RFC 3261 SIP: Session Initiation Protocol June 2002 | |
Full Copyright Statement | |
Copyright (C) The Internet Society (2002). All Rights Reserved. | |
This document and translations of it may be copied and furnished to | |
others, and derivative works that comment on or otherwise explain it | |
or assist in its implementation may be prepared, copied, published | |
and distributed, in whole or in part, without restriction of any | |
kind, provided that the above copyright notice and this paragraph are | |
included on all such copies and derivative works. However, this | |
document itself may not be modified in any way, such as by removing | |
the copyright notice or references to the Internet Society or other | |
Internet organizations, except as needed for the purpose of | |
developing Internet standards in which case the procedures for | |
copyrights defined in the Internet Standards process must be | |
followed, or as required to translate it into languages other than | |
English. | |
The limited permissions granted above are perpetual and will not be | |
revoked by the Internet Society or its successors or assigns. | |
This document and the information contained herein is provided on an | |
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
Acknowledgement | |
Funding for the RFC Editor function is currently provided by the | |
Internet Society. | |
Rosenberg, et. al. Standards Track [Page 269] | |