|
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 Network Working Group J. Rosenberg |
|
8 Request for Comments: 3261 dynamicsoft |
|
9 Obsoletes: 2543 H. Schulzrinne |
|
10 Category: Standards Track Columbia U. |
|
11 G. Camarillo |
|
12 Ericsson |
|
13 A. Johnston |
|
14 WorldCom |
|
15 J. Peterson |
|
16 Neustar |
|
17 R. Sparks |
|
18 dynamicsoft |
|
19 M. Handley |
|
20 ICIR |
|
21 E. Schooler |
|
22 AT&T |
|
23 June 2002 |
|
24 |
|
25 SIP: Session Initiation Protocol |
|
26 |
|
27 Status of this Memo |
|
28 |
|
29 This document specifies an Internet standards track protocol for the |
|
30 Internet community, and requests discussion and suggestions for |
|
31 improvements. Please refer to the current edition of the "Internet |
|
32 Official Protocol Standards" (STD 1) for the standardization state |
|
33 and status of this protocol. Distribution of this memo is unlimited. |
|
34 |
|
35 Copyright Notice |
|
36 |
|
37 Copyright (C) The Internet Society (2002). All Rights Reserved. |
|
38 |
|
39 Abstract |
|
40 |
|
41 This document describes Session Initiation Protocol (SIP), an |
|
42 application-layer control (signaling) protocol for creating, |
|
43 modifying, and terminating sessions with one or more participants. |
|
44 These sessions include Internet telephone calls, multimedia |
|
45 distribution, and multimedia conferences. |
|
46 |
|
47 SIP invitations used to create sessions carry session descriptions |
|
48 that allow participants to agree on a set of compatible media types. |
|
49 SIP makes use of elements called proxy servers to help route requests |
|
50 to the user's current location, authenticate and authorize users for |
|
51 services, implement provider call-routing policies, and provide |
|
52 features to users. SIP also provides a registration function that |
|
53 allows users to upload their current locations for use by proxy |
|
54 servers. SIP runs on top of several different transport protocols. |
|
55 |
|
56 |
|
57 |
|
58 Rosenberg, et. al. Standards Track [Page 1] |
|
59 |
|
60 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
61 |
|
62 |
|
63 Table of Contents |
|
64 |
|
65 1 Introduction ........................................ 8 |
|
66 2 Overview of SIP Functionality ....................... 9 |
|
67 3 Terminology ......................................... 10 |
|
68 4 Overview of Operation ............................... 10 |
|
69 5 Structure of the Protocol ........................... 18 |
|
70 6 Definitions ......................................... 20 |
|
71 7 SIP Messages ........................................ 26 |
|
72 7.1 Requests ............................................ 27 |
|
73 7.2 Responses ........................................... 28 |
|
74 7.3 Header Fields ....................................... 29 |
|
75 7.3.1 Header Field Format ................................. 30 |
|
76 7.3.2 Header Field Classification ......................... 32 |
|
77 7.3.3 Compact Form ........................................ 32 |
|
78 7.4 Bodies .............................................. 33 |
|
79 7.4.1 Message Body Type ................................... 33 |
|
80 7.4.2 Message Body Length ................................. 33 |
|
81 7.5 Framing SIP Messages ................................ 34 |
|
82 8 General User Agent Behavior ......................... 34 |
|
83 8.1 UAC Behavior ........................................ 35 |
|
84 8.1.1 Generating the Request .............................. 35 |
|
85 8.1.1.1 Request-URI ......................................... 35 |
|
86 8.1.1.2 To .................................................. 36 |
|
87 8.1.1.3 From ................................................ 37 |
|
88 8.1.1.4 Call-ID ............................................. 37 |
|
89 8.1.1.5 CSeq ................................................ 38 |
|
90 8.1.1.6 Max-Forwards ........................................ 38 |
|
91 8.1.1.7 Via ................................................. 39 |
|
92 8.1.1.8 Contact ............................................. 40 |
|
93 8.1.1.9 Supported and Require ............................... 40 |
|
94 8.1.1.10 Additional Message Components ....................... 41 |
|
95 8.1.2 Sending the Request ................................. 41 |
|
96 8.1.3 Processing Responses ................................ 42 |
|
97 8.1.3.1 Transaction Layer Errors ............................ 42 |
|
98 8.1.3.2 Unrecognized Responses .............................. 42 |
|
99 8.1.3.3 Vias ................................................ 43 |
|
100 8.1.3.4 Processing 3xx Responses ............................ 43 |
|
101 8.1.3.5 Processing 4xx Responses ............................ 45 |
|
102 8.2 UAS Behavior ........................................ 46 |
|
103 8.2.1 Method Inspection ................................... 46 |
|
104 8.2.2 Header Inspection ................................... 46 |
|
105 8.2.2.1 To and Request-URI .................................. 46 |
|
106 8.2.2.2 Merged Requests ..................................... 47 |
|
107 8.2.2.3 Require ............................................. 47 |
|
108 8.2.3 Content Processing .................................. 48 |
|
109 8.2.4 Applying Extensions ................................. 49 |
|
110 8.2.5 Processing the Request .............................. 49 |
|
111 |
|
112 |
|
113 |
|
114 Rosenberg, et. al. Standards Track [Page 2] |
|
115 |
|
116 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
117 |
|
118 |
|
119 8.2.6 Generating the Response ............................. 49 |
|
120 8.2.6.1 Sending a Provisional Response ...................... 49 |
|
121 8.2.6.2 Headers and Tags .................................... 50 |
|
122 8.2.7 Stateless UAS Behavior .............................. 50 |
|
123 8.3 Redirect Servers .................................... 51 |
|
124 9 Canceling a Request ................................. 53 |
|
125 9.1 Client Behavior ..................................... 53 |
|
126 9.2 Server Behavior ..................................... 55 |
|
127 10 Registrations ....................................... 56 |
|
128 10.1 Overview ............................................ 56 |
|
129 10.2 Constructing the REGISTER Request ................... 57 |
|
130 10.2.1 Adding Bindings ..................................... 59 |
|
131 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60 |
|
132 10.2.1.2 Preferences among Contact Addresses ................. 61 |
|
133 10.2.2 Removing Bindings ................................... 61 |
|
134 10.2.3 Fetching Bindings ................................... 61 |
|
135 10.2.4 Refreshing Bindings ................................. 61 |
|
136 10.2.5 Setting the Internal Clock .......................... 62 |
|
137 10.2.6 Discovering a Registrar ............................. 62 |
|
138 10.2.7 Transmitting a Request .............................. 62 |
|
139 10.2.8 Error Responses ..................................... 63 |
|
140 10.3 Processing REGISTER Requests ........................ 63 |
|
141 11 Querying for Capabilities ........................... 66 |
|
142 11.1 Construction of OPTIONS Request ..................... 67 |
|
143 11.2 Processing of OPTIONS Request ....................... 68 |
|
144 12 Dialogs ............................................. 69 |
|
145 12.1 Creation of a Dialog ................................ 70 |
|
146 12.1.1 UAS behavior ........................................ 70 |
|
147 12.1.2 UAC Behavior ........................................ 71 |
|
148 12.2 Requests within a Dialog ............................ 72 |
|
149 12.2.1 UAC Behavior ........................................ 73 |
|
150 12.2.1.1 Generating the Request .............................. 73 |
|
151 12.2.1.2 Processing the Responses ............................ 75 |
|
152 12.2.2 UAS Behavior ........................................ 76 |
|
153 12.3 Termination of a Dialog ............................. 77 |
|
154 13 Initiating a Session ................................ 77 |
|
155 13.1 Overview ............................................ 77 |
|
156 13.2 UAC Processing ...................................... 78 |
|
157 13.2.1 Creating the Initial INVITE ......................... 78 |
|
158 13.2.2 Processing INVITE Responses ......................... 81 |
|
159 13.2.2.1 1xx Responses ....................................... 81 |
|
160 13.2.2.2 3xx Responses ....................................... 81 |
|
161 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81 |
|
162 13.2.2.4 2xx Responses ....................................... 82 |
|
163 13.3 UAS Processing ...................................... 83 |
|
164 13.3.1 Processing of the INVITE ............................ 83 |
|
165 13.3.1.1 Progress ............................................ 84 |
|
166 13.3.1.2 The INVITE is Redirected ............................ 84 |
|
167 |
|
168 |
|
169 |
|
170 Rosenberg, et. al. Standards Track [Page 3] |
|
171 |
|
172 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
173 |
|
174 |
|
175 13.3.1.3 The INVITE is Rejected .............................. 85 |
|
176 13.3.1.4 The INVITE is Accepted .............................. 85 |
|
177 14 Modifying an Existing Session ....................... 86 |
|
178 14.1 UAC Behavior ........................................ 86 |
|
179 14.2 UAS Behavior ........................................ 88 |
|
180 15 Terminating a Session ............................... 89 |
|
181 15.1 Terminating a Session with a BYE Request ............ 90 |
|
182 15.1.1 UAC Behavior ........................................ 90 |
|
183 15.1.2 UAS Behavior ........................................ 91 |
|
184 16 Proxy Behavior ...................................... 91 |
|
185 16.1 Overview ............................................ 91 |
|
186 16.2 Stateful Proxy ...................................... 92 |
|
187 16.3 Request Validation .................................. 94 |
|
188 16.4 Route Information Preprocessing ..................... 96 |
|
189 16.5 Determining Request Targets ......................... 97 |
|
190 16.6 Request Forwarding .................................. 99 |
|
191 16.7 Response Processing ................................. 107 |
|
192 16.8 Processing Timer C .................................. 114 |
|
193 16.9 Handling Transport Errors ........................... 115 |
|
194 16.10 CANCEL Processing ................................... 115 |
|
195 16.11 Stateless Proxy ..................................... 116 |
|
196 16.12 Summary of Proxy Route Processing ................... 118 |
|
197 16.12.1 Examples ............................................ 118 |
|
198 16.12.1.1 Basic SIP Trapezoid ................................. 118 |
|
199 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120 |
|
200 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121 |
|
201 17 Transactions ........................................ 122 |
|
202 17.1 Client Transaction .................................. 124 |
|
203 17.1.1 INVITE Client Transaction ........................... 125 |
|
204 17.1.1.1 Overview of INVITE Transaction ...................... 125 |
|
205 17.1.1.2 Formal Description .................................. 125 |
|
206 17.1.1.3 Construction of the ACK Request ..................... 129 |
|
207 17.1.2 Non-INVITE Client Transaction ....................... 130 |
|
208 17.1.2.1 Overview of the non-INVITE Transaction .............. 130 |
|
209 17.1.2.2 Formal Description .................................. 131 |
|
210 17.1.3 Matching Responses to Client Transactions ........... 132 |
|
211 17.1.4 Handling Transport Errors ........................... 133 |
|
212 17.2 Server Transaction .................................. 134 |
|
213 17.2.1 INVITE Server Transaction ........................... 134 |
|
214 17.2.2 Non-INVITE Server Transaction ....................... 137 |
|
215 17.2.3 Matching Requests to Server Transactions ............ 138 |
|
216 17.2.4 Handling Transport Errors ........................... 141 |
|
217 18 Transport ........................................... 141 |
|
218 18.1 Clients ............................................. 142 |
|
219 18.1.1 Sending Requests .................................... 142 |
|
220 18.1.2 Receiving Responses ................................. 144 |
|
221 18.2 Servers ............................................. 145 |
|
222 18.2.1 Receiving Requests .................................. 145 |
|
223 |
|
224 |
|
225 |
|
226 Rosenberg, et. al. Standards Track [Page 4] |
|
227 |
|
228 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
229 |
|
230 |
|
231 18.2.2 Sending Responses ................................... 146 |
|
232 18.3 Framing ............................................. 147 |
|
233 18.4 Error Handling ...................................... 147 |
|
234 19 Common Message Components ........................... 147 |
|
235 19.1 SIP and SIPS Uniform Resource Indicators ............ 148 |
|
236 19.1.1 SIP and SIPS URI Components ......................... 148 |
|
237 19.1.2 Character Escaping Requirements ..................... 152 |
|
238 19.1.3 Example SIP and SIPS URIs ........................... 153 |
|
239 19.1.4 URI Comparison ...................................... 153 |
|
240 19.1.5 Forming Requests from a URI ......................... 156 |
|
241 19.1.6 Relating SIP URIs and tel URLs ...................... 157 |
|
242 19.2 Option Tags ......................................... 158 |
|
243 19.3 Tags ................................................ 159 |
|
244 20 Header Fields ....................................... 159 |
|
245 20.1 Accept .............................................. 161 |
|
246 20.2 Accept-Encoding ..................................... 163 |
|
247 20.3 Accept-Language ..................................... 164 |
|
248 20.4 Alert-Info .......................................... 164 |
|
249 20.5 Allow ............................................... 165 |
|
250 20.6 Authentication-Info ................................. 165 |
|
251 20.7 Authorization ....................................... 165 |
|
252 20.8 Call-ID ............................................. 166 |
|
253 20.9 Call-Info ........................................... 166 |
|
254 20.10 Contact ............................................. 167 |
|
255 20.11 Content-Disposition ................................. 168 |
|
256 20.12 Content-Encoding .................................... 169 |
|
257 20.13 Content-Language .................................... 169 |
|
258 20.14 Content-Length ...................................... 169 |
|
259 20.15 Content-Type ........................................ 170 |
|
260 20.16 CSeq ................................................ 170 |
|
261 20.17 Date ................................................ 170 |
|
262 20.18 Error-Info .......................................... 171 |
|
263 20.19 Expires ............................................. 171 |
|
264 20.20 From ................................................ 172 |
|
265 20.21 In-Reply-To ......................................... 172 |
|
266 20.22 Max-Forwards ........................................ 173 |
|
267 20.23 Min-Expires ......................................... 173 |
|
268 20.24 MIME-Version ........................................ 173 |
|
269 20.25 Organization ........................................ 174 |
|
270 20.26 Priority ............................................ 174 |
|
271 20.27 Proxy-Authenticate .................................. 174 |
|
272 20.28 Proxy-Authorization ................................. 175 |
|
273 20.29 Proxy-Require ....................................... 175 |
|
274 20.30 Record-Route ........................................ 175 |
|
275 20.31 Reply-To ............................................ 176 |
|
276 20.32 Require ............................................. 176 |
|
277 20.33 Retry-After ......................................... 176 |
|
278 20.34 Route ............................................... 177 |
|
279 |
|
280 |
|
281 |
|
282 Rosenberg, et. al. Standards Track [Page 5] |
|
283 |
|
284 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
285 |
|
286 |
|
287 20.35 Server .............................................. 177 |
|
288 20.36 Subject ............................................. 177 |
|
289 20.37 Supported ........................................... 178 |
|
290 20.38 Timestamp ........................................... 178 |
|
291 20.39 To .................................................. 178 |
|
292 20.40 Unsupported ......................................... 179 |
|
293 20.41 User-Agent .......................................... 179 |
|
294 20.42 Via ................................................. 179 |
|
295 20.43 Warning ............................................. 180 |
|
296 20.44 WWW-Authenticate .................................... 182 |
|
297 21 Response Codes ...................................... 182 |
|
298 21.1 Provisional 1xx ..................................... 182 |
|
299 21.1.1 100 Trying .......................................... 183 |
|
300 21.1.2 180 Ringing ......................................... 183 |
|
301 21.1.3 181 Call Is Being Forwarded ......................... 183 |
|
302 21.1.4 182 Queued .......................................... 183 |
|
303 21.1.5 183 Session Progress ................................ 183 |
|
304 21.2 Successful 2xx ...................................... 183 |
|
305 21.2.1 200 OK .............................................. 183 |
|
306 21.3 Redirection 3xx ..................................... 184 |
|
307 21.3.1 300 Multiple Choices ................................ 184 |
|
308 21.3.2 301 Moved Permanently ............................... 184 |
|
309 21.3.3 302 Moved Temporarily ............................... 184 |
|
310 21.3.4 305 Use Proxy ....................................... 185 |
|
311 21.3.5 380 Alternative Service ............................. 185 |
|
312 21.4 Request Failure 4xx ................................. 185 |
|
313 21.4.1 400 Bad Request ..................................... 185 |
|
314 21.4.2 401 Unauthorized .................................... 185 |
|
315 21.4.3 402 Payment Required ................................ 186 |
|
316 21.4.4 403 Forbidden ....................................... 186 |
|
317 21.4.5 404 Not Found ....................................... 186 |
|
318 21.4.6 405 Method Not Allowed .............................. 186 |
|
319 21.4.7 406 Not Acceptable .................................. 186 |
|
320 21.4.8 407 Proxy Authentication Required ................... 186 |
|
321 21.4.9 408 Request Timeout ................................. 186 |
|
322 21.4.10 410 Gone ............................................ 187 |
|
323 21.4.11 413 Request Entity Too Large ........................ 187 |
|
324 21.4.12 414 Request-URI Too Long ............................ 187 |
|
325 21.4.13 415 Unsupported Media Type .......................... 187 |
|
326 21.4.14 416 Unsupported URI Scheme .......................... 187 |
|
327 21.4.15 420 Bad Extension ................................... 187 |
|
328 21.4.16 421 Extension Required .............................. 188 |
|
329 21.4.17 423 Interval Too Brief .............................. 188 |
|
330 21.4.18 480 Temporarily Unavailable ......................... 188 |
|
331 21.4.19 481 Call/Transaction Does Not Exist ................. 188 |
|
332 21.4.20 482 Loop Detected ................................... 188 |
|
333 21.4.21 483 Too Many Hops ................................... 189 |
|
334 21.4.22 484 Address Incomplete .............................. 189 |
|
335 |
|
336 |
|
337 |
|
338 Rosenberg, et. al. Standards Track [Page 6] |
|
339 |
|
340 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
341 |
|
342 |
|
343 21.4.23 485 Ambiguous ....................................... 189 |
|
344 21.4.24 486 Busy Here ....................................... 189 |
|
345 21.4.25 487 Request Terminated .............................. 190 |
|
346 21.4.26 488 Not Acceptable Here ............................. 190 |
|
347 21.4.27 491 Request Pending ................................. 190 |
|
348 21.4.28 493 Undecipherable .................................. 190 |
|
349 21.5 Server Failure 5xx .................................. 190 |
|
350 21.5.1 500 Server Internal Error ........................... 190 |
|
351 21.5.2 501 Not Implemented ................................. 191 |
|
352 21.5.3 502 Bad Gateway ..................................... 191 |
|
353 21.5.4 503 Service Unavailable ............................. 191 |
|
354 21.5.5 504 Server Time-out ................................. 191 |
|
355 21.5.6 505 Version Not Supported ........................... 192 |
|
356 21.5.7 513 Message Too Large ............................... 192 |
|
357 21.6 Global Failures 6xx ................................. 192 |
|
358 21.6.1 600 Busy Everywhere ................................. 192 |
|
359 21.6.2 603 Decline ......................................... 192 |
|
360 21.6.3 604 Does Not Exist Anywhere ......................... 192 |
|
361 21.6.4 606 Not Acceptable .................................. 192 |
|
362 22 Usage of HTTP Authentication ........................ 193 |
|
363 22.1 Framework ........................................... 193 |
|
364 22.2 User-to-User Authentication ......................... 195 |
|
365 22.3 Proxy-to-User Authentication ........................ 197 |
|
366 22.4 The Digest Authentication Scheme .................... 199 |
|
367 23 S/MIME .............................................. 201 |
|
368 23.1 S/MIME Certificates ................................. 201 |
|
369 23.2 S/MIME Key Exchange ................................. 202 |
|
370 23.3 Securing MIME bodies ................................ 205 |
|
371 23.4 SIP Header Privacy and Integrity using S/MIME: |
|
372 Tunneling SIP ....................................... 207 |
|
373 23.4.1 Integrity and Confidentiality Properties of SIP |
|
374 Headers ............................................. 207 |
|
375 23.4.1.1 Integrity ........................................... 207 |
|
376 23.4.1.2 Confidentiality ..................................... 208 |
|
377 23.4.2 Tunneling Integrity and Authentication .............. 209 |
|
378 23.4.3 Tunneling Encryption ................................ 211 |
|
379 24 Examples ............................................ 213 |
|
380 24.1 Registration ........................................ 213 |
|
381 24.2 Session Setup ....................................... 214 |
|
382 25 Augmented BNF for the SIP Protocol .................. 219 |
|
383 25.1 Basic Rules ......................................... 219 |
|
384 26 Security Considerations: Threat Model and Security |
|
385 Usage Recommendations ............................... 232 |
|
386 26.1 Attacks and Threat Models ........................... 233 |
|
387 26.1.1 Registration Hijacking .............................. 233 |
|
388 26.1.2 Impersonating a Server .............................. 234 |
|
389 26.1.3 Tampering with Message Bodies ....................... 235 |
|
390 26.1.4 Tearing Down Sessions ............................... 235 |
|
391 |
|
392 |
|
393 |
|
394 Rosenberg, et. al. Standards Track [Page 7] |
|
395 |
|
396 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
397 |
|
398 |
|
399 26.1.5 Denial of Service and Amplification ................. 236 |
|
400 26.2 Security Mechanisms ................................. 237 |
|
401 26.2.1 Transport and Network Layer Security ................ 238 |
|
402 26.2.2 SIPS URI Scheme ..................................... 239 |
|
403 26.2.3 HTTP Authentication ................................. 240 |
|
404 26.2.4 S/MIME .............................................. 240 |
|
405 26.3 Implementing Security Mechanisms .................... 241 |
|
406 26.3.1 Requirements for Implementers of SIP ................ 241 |
|
407 26.3.2 Security Solutions .................................. 242 |
|
408 26.3.2.1 Registration ........................................ 242 |
|
409 26.3.2.2 Interdomain Requests ................................ 243 |
|
410 26.3.2.3 Peer-to-Peer Requests ............................... 245 |
|
411 26.3.2.4 DoS Protection ...................................... 246 |
|
412 26.4 Limitations ......................................... 247 |
|
413 26.4.1 HTTP Digest ......................................... 247 |
|
414 26.4.2 S/MIME .............................................. 248 |
|
415 26.4.3 TLS ................................................. 249 |
|
416 26.4.4 SIPS URIs ........................................... 249 |
|
417 26.5 Privacy ............................................. 251 |
|
418 27 IANA Considerations ................................. 252 |
|
419 27.1 Option Tags ......................................... 252 |
|
420 27.2 Warn-Codes .......................................... 252 |
|
421 27.3 Header Field Names .................................. 253 |
|
422 27.4 Method and Response Codes ........................... 253 |
|
423 27.5 The "message/sip" MIME type. ....................... 254 |
|
424 27.6 New Content-Disposition Parameter Registrations ..... 255 |
|
425 28 Changes From RFC 2543 ............................... 255 |
|
426 28.1 Major Functional Changes ............................ 255 |
|
427 28.2 Minor Functional Changes ............................ 260 |
|
428 29 Normative References ................................ 261 |
|
429 30 Informative References .............................. 262 |
|
430 A Table of Timer Values ............................... 265 |
|
431 Acknowledgments ................................................ 266 |
|
432 Authors' Addresses ............................................. 267 |
|
433 Full Copyright Statement ....................................... 269 |
|
434 |
|
435 1 Introduction |
|
436 |
|
437 There are many applications of the Internet that require the creation |
|
438 and management of a session, where a session is considered an |
|
439 exchange of data between an association of participants. The |
|
440 implementation of these applications is complicated by the practices |
|
441 of participants: users may move between endpoints, they may be |
|
442 addressable by multiple names, and they may communicate in several |
|
443 different media - sometimes simultaneously. Numerous protocols have |
|
444 been authored that carry various forms of real-time multimedia |
|
445 session data such as voice, video, or text messages. The Session |
|
446 Initiation Protocol (SIP) works in concert with these protocols by |
|
447 |
|
448 |
|
449 |
|
450 Rosenberg, et. al. Standards Track [Page 8] |
|
451 |
|
452 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
453 |
|
454 |
|
455 enabling Internet endpoints (called user agents) to discover one |
|
456 another and to agree on a characterization of a session they would |
|
457 like to share. For locating prospective session participants, and |
|
458 for other functions, SIP enables the creation of an infrastructure of |
|
459 network hosts (called proxy servers) to which user agents can send |
|
460 registrations, invitations to sessions, and other requests. SIP is |
|
461 an agile, general-purpose tool for creating, modifying, and |
|
462 terminating sessions that works independently of underlying transport |
|
463 protocols and without dependency on the type of session that is being |
|
464 established. |
|
465 |
|
466 2 Overview of SIP Functionality |
|
467 |
|
468 SIP is an application-layer control protocol that can establish, |
|
469 modify, and terminate multimedia sessions (conferences) such as |
|
470 Internet telephony calls. SIP can also invite participants to |
|
471 already existing sessions, such as multicast conferences. Media can |
|
472 be added to (and removed from) an existing session. SIP |
|
473 transparently supports name mapping and redirection services, which |
|
474 supports personal mobility [27] - users can maintain a single |
|
475 externally visible identifier regardless of their network location. |
|
476 |
|
477 SIP supports five facets of establishing and terminating multimedia |
|
478 communications: |
|
479 |
|
480 User location: determination of the end system to be used for |
|
481 communication; |
|
482 |
|
483 User availability: determination of the willingness of the called |
|
484 party to engage in communications; |
|
485 |
|
486 User capabilities: determination of the media and media parameters |
|
487 to be used; |
|
488 |
|
489 Session setup: "ringing", establishment of session parameters at |
|
490 both called and calling party; |
|
491 |
|
492 Session management: including transfer and termination of |
|
493 sessions, modifying session parameters, and invoking |
|
494 services. |
|
495 |
|
496 SIP is not a vertically integrated communications system. SIP is |
|
497 rather a component that can be used with other IETF protocols to |
|
498 build a complete multimedia architecture. Typically, these |
|
499 architectures will include protocols such as the Real-time Transport |
|
500 Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and |
|
501 providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC |
|
502 2326 [29]) for controlling delivery of streaming media, the Media |
|
503 |
|
504 |
|
505 |
|
506 Rosenberg, et. al. Standards Track [Page 9] |
|
507 |
|
508 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
509 |
|
510 |
|
511 Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling |
|
512 gateways to the Public Switched Telephone Network (PSTN), and the |
|
513 Session Description Protocol (SDP) (RFC 2327 [1]) for describing |
|
514 multimedia sessions. Therefore, SIP should be used in conjunction |
|
515 with other protocols in order to provide complete services to the |
|
516 users. However, the basic functionality and operation of SIP does |
|
517 not depend on any of these protocols. |
|
518 |
|
519 SIP does not provide services. Rather, SIP provides primitives that |
|
520 can be used to implement different services. For example, SIP can |
|
521 locate a user and deliver an opaque object to his current location. |
|
522 If this primitive is used to deliver a session description written in |
|
523 SDP, for instance, the endpoints can agree on the parameters of a |
|
524 session. If the same primitive is used to deliver a photo of the |
|
525 caller as well as the session description, a "caller ID" service can |
|
526 be easily implemented. As this example shows, a single primitive is |
|
527 typically used to provide several different services. |
|
528 |
|
529 SIP does not offer conference control services such as floor control |
|
530 or voting and does not prescribe how a conference is to be managed. |
|
531 SIP can be used to initiate a session that uses some other conference |
|
532 control protocol. Since SIP messages and the sessions they establish |
|
533 can pass through entirely different networks, SIP cannot, and does |
|
534 not, provide any kind of network resource reservation capabilities. |
|
535 |
|
536 The nature of the services provided make security particularly |
|
537 important. To that end, SIP provides a suite of security services, |
|
538 which include denial-of-service prevention, authentication (both user |
|
539 to user and proxy to user), integrity protection, and encryption and |
|
540 privacy services. |
|
541 |
|
542 SIP works with both IPv4 and IPv6. |
|
543 |
|
544 3 Terminology |
|
545 |
|
546 In this document, the key words "MUST", "MUST NOT", "REQUIRED", |
|
547 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT |
|
548 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as |
|
549 described in BCP 14, RFC 2119 [2] and indicate requirement levels for |
|
550 compliant SIP implementations. |
|
551 |
|
552 4 Overview of Operation |
|
553 |
|
554 This section introduces the basic operations of SIP using simple |
|
555 examples. This section is tutorial in nature and does not contain |
|
556 any normative statements. |
|
557 |
|
558 |
|
559 |
|
560 |
|
561 |
|
562 Rosenberg, et. al. Standards Track [Page 10] |
|
563 |
|
564 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
565 |
|
566 |
|
567 The first example shows the basic functions of SIP: location of an |
|
568 end point, signal of a desire to communicate, negotiation of session |
|
569 parameters to establish the session, and teardown of the session once |
|
570 established. |
|
571 |
|
572 Figure 1 shows a typical example of a SIP message exchange between |
|
573 two users, Alice and Bob. (Each message is labeled with the letter |
|
574 "F" and a number for reference by the text.) In this example, Alice |
|
575 uses a SIP application on her PC (referred to as a softphone) to call |
|
576 Bob on his SIP phone over the Internet. Also shown are two SIP proxy |
|
577 servers that act on behalf of Alice and Bob to facilitate the session |
|
578 establishment. This typical arrangement is often referred to as the |
|
579 "SIP trapezoid" as shown by the geometric shape of the dotted lines |
|
580 in Figure 1. |
|
581 |
|
582 Alice "calls" Bob using his SIP identity, a type of Uniform Resource |
|
583 Identifier (URI) called a SIP URI. SIP URIs are defined in Section |
|
584 19.1. It has a similar form to an email address, typically |
|
585 containing a username and a host name. In this case, it is |
|
586 sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP |
|
587 service provider. Alice has a SIP URI of sip:alice@atlanta.com. |
|
588 Alice might have typed in Bob's URI or perhaps clicked on a hyperlink |
|
589 or an entry in an address book. SIP also provides a secure URI, |
|
590 called a SIPS URI. An example would be sips:bob@biloxi.com. A call |
|
591 made to a SIPS URI guarantees that secure, encrypted transport |
|
592 (namely TLS) is used to carry all SIP messages from the caller to the |
|
593 domain of the callee. From there, the request is sent securely to |
|
594 the callee, but with security mechanisms that depend on the policy of |
|
595 the domain of the callee. |
|
596 |
|
597 SIP is based on an HTTP-like request/response transaction model. |
|
598 Each transaction consists of a request that invokes a particular |
|
599 method, or function, on the server and at least one response. In |
|
600 this example, the transaction begins with Alice's softphone sending |
|
601 an INVITE request addressed to Bob's SIP URI. INVITE is an example |
|
602 of a SIP method that specifies the action that the requestor (Alice) |
|
603 wants the server (Bob) to take. The INVITE request contains a number |
|
604 of header fields. Header fields are named attributes that provide |
|
605 additional information about a message. The ones present in an |
|
606 INVITE include a unique identifier for the call, the destination |
|
607 address, Alice's address, and information about the type of session |
|
608 that Alice wishes to establish with Bob. The INVITE (message F1 in |
|
609 Figure 1) might look like this: |
|
610 |
|
611 |
|
612 |
|
613 |
|
614 |
|
615 |
|
616 |
|
617 |
|
618 Rosenberg, et. al. Standards Track [Page 11] |
|
619 |
|
620 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
621 |
|
622 |
|
623 atlanta.com . . . biloxi.com |
|
624 . proxy proxy . |
|
625 . . |
|
626 Alice's . . . . . . . . . . . . . . . . . . . . Bob's |
|
627 softphone SIP Phone |
|
628 | | | | |
|
629 | INVITE F1 | | | |
|
630 |--------------->| INVITE F2 | | |
|
631 | 100 Trying F3 |--------------->| INVITE F4 | |
|
632 |<---------------| 100 Trying F5 |--------------->| |
|
633 | |<-------------- | 180 Ringing F6 | |
|
634 | | 180 Ringing F7 |<---------------| |
|
635 | 180 Ringing F8 |<---------------| 200 OK F9 | |
|
636 |<---------------| 200 OK F10 |<---------------| |
|
637 | 200 OK F11 |<---------------| | |
|
638 |<---------------| | | |
|
639 | ACK F12 | |
|
640 |------------------------------------------------->| |
|
641 | Media Session | |
|
642 |<================================================>| |
|
643 | BYE F13 | |
|
644 |<-------------------------------------------------| |
|
645 | 200 OK F14 | |
|
646 |------------------------------------------------->| |
|
647 | | |
|
648 |
|
649 Figure 1: SIP session setup example with SIP trapezoid |
|
650 |
|
651 INVITE sip:bob@biloxi.com SIP/2.0 |
|
652 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds |
|
653 Max-Forwards: 70 |
|
654 To: Bob <sip:bob@biloxi.com> |
|
655 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
656 Call-ID: a84b4c76e66710@pc33.atlanta.com |
|
657 CSeq: 314159 INVITE |
|
658 Contact: <sip:alice@pc33.atlanta.com> |
|
659 Content-Type: application/sdp |
|
660 Content-Length: 142 |
|
661 |
|
662 (Alice's SDP not shown) |
|
663 |
|
664 The first line of the text-encoded message contains the method name |
|
665 (INVITE). The lines that follow are a list of header fields. This |
|
666 example contains a minimum required set. The header fields are |
|
667 briefly described below: |
|
668 |
|
669 |
|
670 |
|
671 |
|
672 |
|
673 |
|
674 Rosenberg, et. al. Standards Track [Page 12] |
|
675 |
|
676 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
677 |
|
678 |
|
679 Via contains the address (pc33.atlanta.com) at which Alice is |
|
680 expecting to receive responses to this request. It also contains a |
|
681 branch parameter that identifies this transaction. |
|
682 |
|
683 To contains a display name (Bob) and a SIP or SIPS URI |
|
684 (sip:bob@biloxi.com) towards which the request was originally |
|
685 directed. Display names are described in RFC 2822 [3]. |
|
686 |
|
687 From also contains a display name (Alice) and a SIP or SIPS URI |
|
688 (sip:alice@atlanta.com) that indicate the originator of the request. |
|
689 This header field also has a tag parameter containing a random string |
|
690 (1928301774) that was added to the URI by the softphone. It is used |
|
691 for identification purposes. |
|
692 |
|
693 Call-ID contains a globally unique identifier for this call, |
|
694 generated by the combination of a random string and the softphone's |
|
695 host name or IP address. The combination of the To tag, From tag, |
|
696 and Call-ID completely defines a peer-to-peer SIP relationship |
|
697 between Alice and Bob and is referred to as a dialog. |
|
698 |
|
699 CSeq or Command Sequence contains an integer and a method name. The |
|
700 CSeq number is incremented for each new request within a dialog and |
|
701 is a traditional sequence number. |
|
702 |
|
703 Contact contains a SIP or SIPS URI that represents a direct route to |
|
704 contact Alice, usually composed of a username at a fully qualified |
|
705 domain name (FQDN). While an FQDN is preferred, many end systems do |
|
706 not have registered domain names, so IP addresses are permitted. |
|
707 While the Via header field tells other elements where to send the |
|
708 response, the Contact header field tells other elements where to send |
|
709 future requests. |
|
710 |
|
711 Max-Forwards serves to limit the number of hops a request can make on |
|
712 the way to its destination. It consists of an integer that is |
|
713 decremented by one at each hop. |
|
714 |
|
715 Content-Type contains a description of the message body (not shown). |
|
716 |
|
717 Content-Length contains an octet (byte) count of the message body. |
|
718 |
|
719 The complete set of SIP header fields is defined in Section 20. |
|
720 |
|
721 The details of the session, such as the type of media, codec, or |
|
722 sampling rate, are not described using SIP. Rather, the body of a |
|
723 SIP message contains a description of the session, encoded in some |
|
724 other protocol format. One such format is the Session Description |
|
725 Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the |
|
726 |
|
727 |
|
728 |
|
729 |
|
730 Rosenberg, et. al. Standards Track [Page 13] |
|
731 |
|
732 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
733 |
|
734 |
|
735 example) is carried by the SIP message in a way that is analogous to |
|
736 a document attachment being carried by an email message, or a web |
|
737 page being carried in an HTTP message. |
|
738 |
|
739 Since the softphone does not know the location of Bob or the SIP |
|
740 server in the biloxi.com domain, the softphone sends the INVITE to |
|
741 the SIP server that serves Alice's domain, atlanta.com. The address |
|
742 of the atlanta.com SIP server could have been configured in Alice's |
|
743 softphone, or it could have been discovered by DHCP, for example. |
|
744 |
|
745 The atlanta.com SIP server is a type of SIP server known as a proxy |
|
746 server. A proxy server receives SIP requests and forwards them on |
|
747 behalf of the requestor. In this example, the proxy server receives |
|
748 the INVITE request and sends a 100 (Trying) response back to Alice's |
|
749 softphone. The 100 (Trying) response indicates that the INVITE has |
|
750 been received and that the proxy is working on her behalf to route |
|
751 the INVITE to the destination. Responses in SIP use a three-digit |
|
752 code followed by a descriptive phrase. This response contains the |
|
753 same To, From, Call-ID, CSeq and branch parameter in the Via as the |
|
754 INVITE, which allows Alice's softphone to correlate this response to |
|
755 the sent INVITE. The atlanta.com proxy server locates the proxy |
|
756 server at biloxi.com, possibly by performing a particular type of DNS |
|
757 (Domain Name Service) lookup to find the SIP server that serves the |
|
758 biloxi.com domain. This is described in [4]. As a result, it |
|
759 obtains the IP address of the biloxi.com proxy server and forwards, |
|
760 or proxies, the INVITE request there. Before forwarding the request, |
|
761 the atlanta.com proxy server adds an additional Via header field |
|
762 value that contains its own address (the INVITE already contains |
|
763 Alice's address in the first Via). The biloxi.com proxy server |
|
764 receives the INVITE and responds with a 100 (Trying) response back to |
|
765 the atlanta.com proxy server to indicate that it has received the |
|
766 INVITE and is processing the request. The proxy server consults a |
|
767 database, generically called a location service, that contains the |
|
768 current IP address of Bob. (We shall see in the next section how |
|
769 this database can be populated.) The biloxi.com proxy server adds |
|
770 another Via header field value with its own address to the INVITE and |
|
771 proxies it to Bob's SIP phone. |
|
772 |
|
773 Bob's SIP phone receives the INVITE and alerts Bob to the incoming |
|
774 call from Alice so that Bob can decide whether to answer the call, |
|
775 that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 |
|
776 (Ringing) response, which is routed back through the two proxies in |
|
777 the reverse direction. Each proxy uses the Via header field to |
|
778 determine where to send the response and removes its own address from |
|
779 the top. As a result, although DNS and location service lookups were |
|
780 required to route the initial INVITE, the 180 (Ringing) response can |
|
781 be returned to the caller without lookups or without state being |
|
782 |
|
783 |
|
784 |
|
785 |
|
786 Rosenberg, et. al. Standards Track [Page 14] |
|
787 |
|
788 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
789 |
|
790 |
|
791 maintained in the proxies. This also has the desirable property that |
|
792 each proxy that sees the INVITE will also see all responses to the |
|
793 INVITE. |
|
794 |
|
795 When Alice's softphone receives the 180 (Ringing) response, it passes |
|
796 this information to Alice, perhaps using an audio ringback tone or by |
|
797 displaying a message on Alice's screen. |
|
798 |
|
799 In this example, Bob decides to answer the call. When he picks up |
|
800 the handset, his SIP phone sends a 200 (OK) response to indicate that |
|
801 the call has been answered. The 200 (OK) contains a message body |
|
802 with the SDP media description of the type of session that Bob is |
|
803 willing to establish with Alice. As a result, there is a two-phase |
|
804 exchange of SDP messages: Alice sent one to Bob, and Bob sent one |
|
805 back to Alice. This two-phase exchange provides basic negotiation |
|
806 capabilities and is based on a simple offer/answer model of SDP |
|
807 exchange. If Bob did not wish to answer the call or was busy on |
|
808 another call, an error response would have been sent instead of the |
|
809 200 (OK), which would have resulted in no media session being |
|
810 established. The complete list of SIP response codes is in Section |
|
811 21. The 200 (OK) (message F9 in Figure 1) might look like this as |
|
812 Bob sends it out: |
|
813 |
|
814 SIP/2.0 200 OK |
|
815 Via: SIP/2.0/UDP server10.biloxi.com |
|
816 ;branch=z9hG4bKnashds8;received=192.0.2.3 |
|
817 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com |
|
818 ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 |
|
819 Via: SIP/2.0/UDP pc33.atlanta.com |
|
820 ;branch=z9hG4bK776asdhds ;received=192.0.2.1 |
|
821 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
822 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
823 Call-ID: a84b4c76e66710@pc33.atlanta.com |
|
824 CSeq: 314159 INVITE |
|
825 Contact: <sip:bob@192.0.2.4> |
|
826 Content-Type: application/sdp |
|
827 Content-Length: 131 |
|
828 |
|
829 (Bob's SDP not shown) |
|
830 |
|
831 The first line of the response contains the response code (200) and |
|
832 the reason phrase (OK). The remaining lines contain header fields. |
|
833 The Via, To, From, Call-ID, and CSeq header fields are copied from |
|
834 the INVITE request. (There are three Via header field values - one |
|
835 added by Alice's SIP phone, one added by the atlanta.com proxy, and |
|
836 one added by the biloxi.com proxy.) Bob's SIP phone has added a tag |
|
837 parameter to the To header field. This tag will be incorporated by |
|
838 both endpoints into the dialog and will be included in all future |
|
839 |
|
840 |
|
841 |
|
842 Rosenberg, et. al. Standards Track [Page 15] |
|
843 |
|
844 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
845 |
|
846 |
|
847 requests and responses in this call. The Contact header field |
|
848 contains a URI at which Bob can be directly reached at his SIP phone. |
|
849 The Content-Type and Content-Length refer to the message body (not |
|
850 shown) that contains Bob's SDP media information. |
|
851 |
|
852 In addition to DNS and location service lookups shown in this |
|
853 example, proxy servers can make flexible "routing decisions" to |
|
854 decide where to send a request. For example, if Bob's SIP phone |
|
855 returned a 486 (Busy Here) response, the biloxi.com proxy server |
|
856 could proxy the INVITE to Bob's voicemail server. A proxy server can |
|
857 also send an INVITE to a number of locations at the same time. This |
|
858 type of parallel search is known as forking. |
|
859 |
|
860 In this case, the 200 (OK) is routed back through the two proxies and |
|
861 is received by Alice's softphone, which then stops the ringback tone |
|
862 and indicates that the call has been answered. Finally, Alice's |
|
863 softphone sends an acknowledgement message, ACK, to Bob's SIP phone |
|
864 to confirm the reception of the final response (200 (OK)). In this |
|
865 example, the ACK is sent directly from Alice's softphone to Bob's SIP |
|
866 phone, bypassing the two proxies. This occurs because the endpoints |
|
867 have learned each other's address from the Contact header fields |
|
868 through the INVITE/200 (OK) exchange, which was not known when the |
|
869 initial INVITE was sent. The lookups performed by the two proxies |
|
870 are no longer needed, so the proxies drop out of the call flow. This |
|
871 completes the INVITE/200/ACK three-way handshake used to establish |
|
872 SIP sessions. Full details on session setup are in Section 13. |
|
873 |
|
874 Alice and Bob's media session has now begun, and they send media |
|
875 packets using the format to which they agreed in the exchange of SDP. |
|
876 In general, the end-to-end media packets take a different path from |
|
877 the SIP signaling messages. |
|
878 |
|
879 During the session, either Alice or Bob may decide to change the |
|
880 characteristics of the media session. This is accomplished by |
|
881 sending a re-INVITE containing a new media description. This re- |
|
882 INVITE references the existing dialog so that the other party knows |
|
883 that it is to modify an existing session instead of establishing a |
|
884 new session. The other party sends a 200 (OK) to accept the change. |
|
885 The requestor responds to the 200 (OK) with an ACK. If the other |
|
886 party does not accept the change, he sends an error response such as |
|
887 488 (Not Acceptable Here), which also receives an ACK. However, the |
|
888 failure of the re-INVITE does not cause the existing call to fail - |
|
889 the session continues using the previously negotiated |
|
890 characteristics. Full details on session modification are in Section |
|
891 14. |
|
892 |
|
893 |
|
894 |
|
895 |
|
896 |
|
897 |
|
898 Rosenberg, et. al. Standards Track [Page 16] |
|
899 |
|
900 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
901 |
|
902 |
|
903 At the end of the call, Bob disconnects (hangs up) first and |
|
904 generates a BYE message. This BYE is routed directly to Alice's |
|
905 softphone, again bypassing the proxies. Alice confirms receipt of |
|
906 the BYE with a 200 (OK) response, which terminates the session and |
|
907 the BYE transaction. No ACK is sent - an ACK is only sent in |
|
908 response to a response to an INVITE request. The reasons for this |
|
909 special handling for INVITE will be discussed later, but relate to |
|
910 the reliability mechanisms in SIP, the length of time it can take for |
|
911 a ringing phone to be answered, and forking. For this reason, |
|
912 request handling in SIP is often classified as either INVITE or non- |
|
913 INVITE, referring to all other methods besides INVITE. Full details |
|
914 on session termination are in Section 15. |
|
915 |
|
916 Section 24.2 describes the messages shown in Figure 1 in full. |
|
917 |
|
918 In some cases, it may be useful for proxies in the SIP signaling path |
|
919 to see all the messaging between the endpoints for the duration of |
|
920 the session. For example, if the biloxi.com proxy server wished to |
|
921 remain in the SIP messaging path beyond the initial INVITE, it would |
|
922 add to the INVITE a required routing header field known as Record- |
|
923 Route that contained a URI resolving to the hostname or IP address of |
|
924 the proxy. This information would be received by both Bob's SIP |
|
925 phone and (due to the Record-Route header field being passed back in |
|
926 the 200 (OK)) Alice's softphone and stored for the duration of the |
|
927 dialog. The biloxi.com proxy server would then receive and proxy the |
|
928 ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently |
|
929 decide to receive subsequent messages, and those messages will pass |
|
930 through all proxies that elect to receive it. This capability is |
|
931 frequently used for proxies that are providing mid-call features. |
|
932 |
|
933 Registration is another common operation in SIP. Registration is one |
|
934 way that the biloxi.com server can learn the current location of Bob. |
|
935 Upon initialization, and at periodic intervals, Bob's SIP phone sends |
|
936 REGISTER messages to a server in the biloxi.com domain known as a SIP |
|
937 registrar. The REGISTER messages associate Bob's SIP or SIPS URI |
|
938 (sip:bob@biloxi.com) with the machine into which he is currently |
|
939 logged (conveyed as a SIP or SIPS URI in the Contact header field). |
|
940 The registrar writes this association, also called a binding, to a |
|
941 database, called the location service, where it can be used by the |
|
942 proxy in the biloxi.com domain. Often, a registrar server for a |
|
943 domain is co-located with the proxy for that domain. It is an |
|
944 important concept that the distinction between types of SIP servers |
|
945 is logical, not physical. |
|
946 |
|
947 Bob is not limited to registering from a single device. For example, |
|
948 both his SIP phone at home and the one in the office could send |
|
949 registrations. This information is stored together in the location |
|
950 |
|
951 |
|
952 |
|
953 |
|
954 Rosenberg, et. al. Standards Track [Page 17] |
|
955 |
|
956 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
957 |
|
958 |
|
959 service and allows a proxy to perform various types of searches to |
|
960 locate Bob. Similarly, more than one user can be registered on a |
|
961 single device at the same time. |
|
962 |
|
963 The location service is just an abstract concept. It generally |
|
964 contains information that allows a proxy to input a URI and receive a |
|
965 set of zero or more URIs that tell the proxy where to send the |
|
966 request. Registrations are one way to create this information, but |
|
967 not the only way. Arbitrary mapping functions can be configured at |
|
968 the discretion of the administrator. |
|
969 |
|
970 Finally, it is important to note that in SIP, registration is used |
|
971 for routing incoming SIP requests and has no role in authorizing |
|
972 outgoing requests. Authorization and authentication are handled in |
|
973 SIP either on a request-by-request basis with a challenge/response |
|
974 mechanism, or by using a lower layer scheme as discussed in Section |
|
975 26. |
|
976 |
|
977 The complete set of SIP message details for this registration example |
|
978 is in Section 24.1. |
|
979 |
|
980 Additional operations in SIP, such as querying for the capabilities |
|
981 of a SIP server or client using OPTIONS, or canceling a pending |
|
982 request using CANCEL, will be introduced in later sections. |
|
983 |
|
984 5 Structure of the Protocol |
|
985 |
|
986 SIP is structured as a layered protocol, which means that its |
|
987 behavior is described in terms of a set of fairly independent |
|
988 processing stages with only a loose coupling between each stage. The |
|
989 protocol behavior is described as layers for the purpose of |
|
990 presentation, allowing the description of functions common across |
|
991 elements in a single section. It does not dictate an implementation |
|
992 in any way. When we say that an element "contains" a layer, we mean |
|
993 it is compliant to the set of rules defined by that layer. |
|
994 |
|
995 Not every element specified by the protocol contains every layer. |
|
996 Furthermore, the elements specified by SIP are logical elements, not |
|
997 physical ones. A physical realization can choose to act as different |
|
998 logical elements, perhaps even on a transaction-by-transaction basis. |
|
999 |
|
1000 The lowest layer of SIP is its syntax and encoding. Its encoding is |
|
1001 specified using an augmented Backus-Naur Form grammar (BNF). The |
|
1002 complete BNF is specified in Section 25; an overview of a SIP |
|
1003 message's structure can be found in Section 7. |
|
1004 |
|
1005 |
|
1006 |
|
1007 |
|
1008 |
|
1009 |
|
1010 Rosenberg, et. al. Standards Track [Page 18] |
|
1011 |
|
1012 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1013 |
|
1014 |
|
1015 The second layer is the transport layer. It defines how a client |
|
1016 sends requests and receives responses and how a server receives |
|
1017 requests and sends responses over the network. All SIP elements |
|
1018 contain a transport layer. The transport layer is described in |
|
1019 Section 18. |
|
1020 |
|
1021 The third layer is the transaction layer. Transactions are a |
|
1022 fundamental component of SIP. A transaction is a request sent by a |
|
1023 client transaction (using the transport layer) to a server |
|
1024 transaction, along with all responses to that request sent from the |
|
1025 server transaction back to the client. The transaction layer handles |
|
1026 application-layer retransmissions, matching of responses to requests, |
|
1027 and application-layer timeouts. Any task that a user agent client |
|
1028 (UAC) accomplishes takes place using a series of transactions. |
|
1029 Discussion of transactions can be found in Section 17. User agents |
|
1030 contain a transaction layer, as do stateful proxies. Stateless |
|
1031 proxies do not contain a transaction layer. The transaction layer |
|
1032 has a client component (referred to as a client transaction) and a |
|
1033 server component (referred to as a server transaction), each of which |
|
1034 are represented by a finite state machine that is constructed to |
|
1035 process a particular request. |
|
1036 |
|
1037 The layer above the transaction layer is called the transaction user |
|
1038 (TU). Each of the SIP entities, except the stateless proxy, is a |
|
1039 transaction user. When a TU wishes to send a request, it creates a |
|
1040 client transaction instance and passes it the request along with the |
|
1041 destination IP address, port, and transport to which to send the |
|
1042 request. A TU that creates a client transaction can also cancel it. |
|
1043 When a client cancels a transaction, it requests that the server stop |
|
1044 further processing, revert to the state that existed before the |
|
1045 transaction was initiated, and generate a specific error response to |
|
1046 that transaction. This is done with a CANCEL request, which |
|
1047 constitutes its own transaction, but references the transaction to be |
|
1048 cancelled (Section 9). |
|
1049 |
|
1050 The SIP elements, that is, user agent clients and servers, stateless |
|
1051 and stateful proxies and registrars, contain a core that |
|
1052 distinguishes them from each other. Cores, except for the stateless |
|
1053 proxy, are transaction users. While the behavior of the UAC and UAS |
|
1054 cores depends on the method, there are some common rules for all |
|
1055 methods (Section 8). For a UAC, these rules govern the construction |
|
1056 of a request; for a UAS, they govern the processing of a request and |
|
1057 generating a response. Since registrations play an important role in |
|
1058 SIP, a UAS that handles a REGISTER is given the special name |
|
1059 registrar. Section 10 describes UAC and UAS core behavior for the |
|
1060 REGISTER method. Section 11 describes UAC and UAS core behavior for |
|
1061 the OPTIONS method, used for determining the capabilities of a UA. |
|
1062 |
|
1063 |
|
1064 |
|
1065 |
|
1066 Rosenberg, et. al. Standards Track [Page 19] |
|
1067 |
|
1068 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1069 |
|
1070 |
|
1071 Certain other requests are sent within a dialog. A dialog is a |
|
1072 peer-to-peer SIP relationship between two user agents that persists |
|
1073 for some time. The dialog facilitates sequencing of messages and |
|
1074 proper routing of requests between the user agents. The INVITE |
|
1075 method is the only way defined in this specification to establish a |
|
1076 dialog. When a UAC sends a request that is within the context of a |
|
1077 dialog, it follows the common UAC rules as discussed in Section 8 but |
|
1078 also the rules for mid-dialog requests. Section 12 discusses dialogs |
|
1079 and presents the procedures for their construction and maintenance, |
|
1080 in addition to construction of requests within a dialog. |
|
1081 |
|
1082 The most important method in SIP is the INVITE method, which is used |
|
1083 to establish a session between participants. A session is a |
|
1084 collection of participants, and streams of media between them, for |
|
1085 the purposes of communication. Section 13 discusses how sessions are |
|
1086 initiated, resulting in one or more SIP dialogs. Section 14 |
|
1087 discusses how characteristics of that session are modified through |
|
1088 the use of an INVITE request within a dialog. Finally, section 15 |
|
1089 discusses how a session is terminated. |
|
1090 |
|
1091 The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal |
|
1092 entirely with the UA core (Section 9 describes cancellation, which |
|
1093 applies to both UA core and proxy core). Section 16 discusses the |
|
1094 proxy element, which facilitates routing of messages between user |
|
1095 agents. |
|
1096 |
|
1097 6 Definitions |
|
1098 |
|
1099 The following terms have special significance for SIP. |
|
1100 |
|
1101 Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI |
|
1102 that points to a domain with a location service that can map |
|
1103 the URI to another URI where the user might be available. |
|
1104 Typically, the location service is populated through |
|
1105 registrations. An AOR is frequently thought of as the "public |
|
1106 address" of the user. |
|
1107 |
|
1108 Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a |
|
1109 logical entity that receives a request and processes it as a |
|
1110 user agent server (UAS). In order to determine how the request |
|
1111 should be answered, it acts as a user agent client (UAC) and |
|
1112 generates requests. Unlike a proxy server, it maintains dialog |
|
1113 state and must participate in all requests sent on the dialogs |
|
1114 it has established. Since it is a concatenation of a UAC and |
|
1115 UAS, no explicit definitions are needed for its behavior. |
|
1116 |
|
1117 |
|
1118 |
|
1119 |
|
1120 |
|
1121 |
|
1122 Rosenberg, et. al. Standards Track [Page 20] |
|
1123 |
|
1124 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1125 |
|
1126 |
|
1127 Call: A call is an informal term that refers to some communication |
|
1128 between peers, generally set up for the purposes of a |
|
1129 multimedia conversation. |
|
1130 |
|
1131 Call Leg: Another name for a dialog [31]; no longer used in this |
|
1132 specification. |
|
1133 |
|
1134 Call Stateful: A proxy is call stateful if it retains state for a |
|
1135 dialog from the initiating INVITE to the terminating BYE |
|
1136 request. A call stateful proxy is always transaction stateful, |
|
1137 but the converse is not necessarily true. |
|
1138 |
|
1139 Client: A client is any network element that sends SIP requests |
|
1140 and receives SIP responses. Clients may or may not interact |
|
1141 directly with a human user. User agent clients and proxies are |
|
1142 clients. |
|
1143 |
|
1144 Conference: A multimedia session (see below) that contains |
|
1145 multiple participants. |
|
1146 |
|
1147 Core: Core designates the functions specific to a particular type |
|
1148 of SIP entity, i.e., specific to either a stateful or stateless |
|
1149 proxy, a user agent or registrar. All cores, except those for |
|
1150 the stateless proxy, are transaction users. |
|
1151 |
|
1152 Dialog: A dialog is a peer-to-peer SIP relationship between two |
|
1153 UAs that persists for some time. A dialog is established by |
|
1154 SIP messages, such as a 2xx response to an INVITE request. A |
|
1155 dialog is identified by a call identifier, local tag, and a |
|
1156 remote tag. A dialog was formerly known as a call leg in RFC |
|
1157 2543. |
|
1158 |
|
1159 Downstream: A direction of message forwarding within a transaction |
|
1160 that refers to the direction that requests flow from the user |
|
1161 agent client to user agent server. |
|
1162 |
|
1163 Final Response: A response that terminates a SIP transaction, as |
|
1164 opposed to a provisional response that does not. All 2xx, 3xx, |
|
1165 4xx, 5xx and 6xx responses are final. |
|
1166 |
|
1167 Header: A header is a component of a SIP message that conveys |
|
1168 information about the message. It is structured as a sequence |
|
1169 of header fields. |
|
1170 |
|
1171 Header Field: A header field is a component of the SIP message |
|
1172 header. A header field can appear as one or more header field |
|
1173 rows. Header field rows consist of a header field name and zero |
|
1174 or more header field values. Multiple header field values on a |
|
1175 |
|
1176 |
|
1177 |
|
1178 Rosenberg, et. al. Standards Track [Page 21] |
|
1179 |
|
1180 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1181 |
|
1182 |
|
1183 given header field row are separated by commas. Some header |
|
1184 fields can only have a single header field value, and as a |
|
1185 result, always appear as a single header field row. |
|
1186 |
|
1187 Header Field Value: A header field value is a single value; a |
|
1188 header field consists of zero or more header field values. |
|
1189 |
|
1190 Home Domain: The domain providing service to a SIP user. |
|
1191 Typically, this is the domain present in the URI in the |
|
1192 address-of-record of a registration. |
|
1193 |
|
1194 Informational Response: Same as a provisional response. |
|
1195 |
|
1196 Initiator, Calling Party, Caller: The party initiating a session |
|
1197 (and dialog) with an INVITE request. A caller retains this |
|
1198 role from the time it sends the initial INVITE that established |
|
1199 a dialog until the termination of that dialog. |
|
1200 |
|
1201 Invitation: An INVITE request. |
|
1202 |
|
1203 Invitee, Invited User, Called Party, Callee: The party that |
|
1204 receives an INVITE request for the purpose of establishing a |
|
1205 new session. A callee retains this role from the time it |
|
1206 receives the INVITE until the termination of the dialog |
|
1207 established by that INVITE. |
|
1208 |
|
1209 Location Service: A location service is used by a SIP redirect or |
|
1210 proxy server to obtain information about a callee's possible |
|
1211 location(s). It contains a list of bindings of address-of- |
|
1212 record keys to zero or more contact addresses. The bindings |
|
1213 can be created and removed in many ways; this specification |
|
1214 defines a REGISTER method that updates the bindings. |
|
1215 |
|
1216 Loop: A request that arrives at a proxy, is forwarded, and later |
|
1217 arrives back at the same proxy. When it arrives the second |
|
1218 time, its Request-URI is identical to the first time, and other |
|
1219 header fields that affect proxy operation are unchanged, so |
|
1220 that the proxy would make the same processing decision on the |
|
1221 request it made the first time. Looped requests are errors, |
|
1222 and the procedures for detecting them and handling them are |
|
1223 described by the protocol. |
|
1224 |
|
1225 Loose Routing: A proxy is said to be loose routing if it follows |
|
1226 the procedures defined in this specification for processing of |
|
1227 the Route header field. These procedures separate the |
|
1228 destination of the request (present in the Request-URI) from |
|
1229 |
|
1230 |
|
1231 |
|
1232 |
|
1233 |
|
1234 Rosenberg, et. al. Standards Track [Page 22] |
|
1235 |
|
1236 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1237 |
|
1238 |
|
1239 the set of proxies that need to be visited along the way |
|
1240 (present in the Route header field). A proxy compliant to |
|
1241 these mechanisms is also known as a loose router. |
|
1242 |
|
1243 Message: Data sent between SIP elements as part of the protocol. |
|
1244 SIP messages are either requests or responses. |
|
1245 |
|
1246 Method: The method is the primary function that a request is meant |
|
1247 to invoke on a server. The method is carried in the request |
|
1248 message itself. Example methods are INVITE and BYE. |
|
1249 |
|
1250 Outbound Proxy: A proxy that receives requests from a client, even |
|
1251 though it may not be the server resolved by the Request-URI. |
|
1252 Typically, a UA is manually configured with an outbound proxy, |
|
1253 or can learn about one through auto-configuration protocols. |
|
1254 |
|
1255 Parallel Search: In a parallel search, a proxy issues several |
|
1256 requests to possible user locations upon receiving an incoming |
|
1257 request. Rather than issuing one request and then waiting for |
|
1258 the final response before issuing the next request as in a |
|
1259 sequential search, a parallel search issues requests without |
|
1260 waiting for the result of previous requests. |
|
1261 |
|
1262 Provisional Response: A response used by the server to indicate |
|
1263 progress, but that does not terminate a SIP transaction. 1xx |
|
1264 responses are provisional, other responses are considered |
|
1265 final. |
|
1266 |
|
1267 Proxy, Proxy Server: An intermediary entity that acts as both a |
|
1268 server and a client for the purpose of making requests on |
|
1269 behalf of other clients. A proxy server primarily plays the |
|
1270 role of routing, which means its job is to ensure that a |
|
1271 request is sent to another entity "closer" to the targeted |
|
1272 user. Proxies are also useful for enforcing policy (for |
|
1273 example, making sure a user is allowed to make a call). A |
|
1274 proxy interprets, and, if necessary, rewrites specific parts of |
|
1275 a request message before forwarding it. |
|
1276 |
|
1277 Recursion: A client recurses on a 3xx response when it generates a |
|
1278 new request to one or more of the URIs in the Contact header |
|
1279 field in the response. |
|
1280 |
|
1281 Redirect Server: A redirect server is a user agent server that |
|
1282 generates 3xx responses to requests it receives, directing the |
|
1283 client to contact an alternate set of URIs. |
|
1284 |
|
1285 |
|
1286 |
|
1287 |
|
1288 |
|
1289 |
|
1290 Rosenberg, et. al. Standards Track [Page 23] |
|
1291 |
|
1292 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1293 |
|
1294 |
|
1295 Registrar: A registrar is a server that accepts REGISTER requests |
|
1296 and places the information it receives in those requests into |
|
1297 the location service for the domain it handles. |
|
1298 |
|
1299 Regular Transaction: A regular transaction is any transaction with |
|
1300 a method other than INVITE, ACK, or CANCEL. |
|
1301 |
|
1302 Request: A SIP message sent from a client to a server, for the |
|
1303 purpose of invoking a particular operation. |
|
1304 |
|
1305 Response: A SIP message sent from a server to a client, for |
|
1306 indicating the status of a request sent from the client to the |
|
1307 server. |
|
1308 |
|
1309 Ringback: Ringback is the signaling tone produced by the calling |
|
1310 party's application indicating that a called party is being |
|
1311 alerted (ringing). |
|
1312 |
|
1313 Route Set: A route set is a collection of ordered SIP or SIPS URI |
|
1314 which represent a list of proxies that must be traversed when |
|
1315 sending a particular request. A route set can be learned, |
|
1316 through headers like Record-Route, or it can be configured. |
|
1317 |
|
1318 Server: A server is a network element that receives requests in |
|
1319 order to service them and sends back responses to those |
|
1320 requests. Examples of servers are proxies, user agent servers, |
|
1321 redirect servers, and registrars. |
|
1322 |
|
1323 Sequential Search: In a sequential search, a proxy server attempts |
|
1324 each contact address in sequence, proceeding to the next one |
|
1325 only after the previous has generated a final response. A 2xx |
|
1326 or 6xx class final response always terminates a sequential |
|
1327 search. |
|
1328 |
|
1329 Session: From the SDP specification: "A multimedia session is a |
|
1330 set of multimedia senders and receivers and the data streams |
|
1331 flowing from senders to receivers. A multimedia conference is |
|
1332 an example of a multimedia session." (RFC 2327 [1]) (A session |
|
1333 as defined for SDP can comprise one or more RTP sessions.) As |
|
1334 defined, a callee can be invited several times, by different |
|
1335 calls, to the same session. If SDP is used, a session is |
|
1336 defined by the concatenation of the SDP user name, session id, |
|
1337 network type, address type, and address elements in the origin |
|
1338 field. |
|
1339 |
|
1340 SIP Transaction: A SIP transaction occurs between a client and a |
|
1341 server and comprises all messages from the first request sent |
|
1342 from the client to the server up to a final (non-1xx) response |
|
1343 |
|
1344 |
|
1345 |
|
1346 Rosenberg, et. al. Standards Track [Page 24] |
|
1347 |
|
1348 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1349 |
|
1350 |
|
1351 sent from the server to the client. If the request is INVITE |
|
1352 and the final response is a non-2xx, the transaction also |
|
1353 includes an ACK to the response. The ACK for a 2xx response to |
|
1354 an INVITE request is a separate transaction. |
|
1355 |
|
1356 Spiral: A spiral is a SIP request that is routed to a proxy, |
|
1357 forwarded onwards, and arrives once again at that proxy, but |
|
1358 this time differs in a way that will result in a different |
|
1359 processing decision than the original request. Typically, this |
|
1360 means that the request's Request-URI differs from its previous |
|
1361 arrival. A spiral is not an error condition, unlike a loop. A |
|
1362 typical cause for this is call forwarding. A user calls |
|
1363 joe@example.com. The example.com proxy forwards it to Joe's |
|
1364 PC, which in turn, forwards it to bob@example.com. This |
|
1365 request is proxied back to the example.com proxy. However, |
|
1366 this is not a loop. Since the request is targeted at a |
|
1367 different user, it is considered a spiral, and is a valid |
|
1368 condition. |
|
1369 |
|
1370 Stateful Proxy: A logical entity that maintains the client and |
|
1371 server transaction state machines defined by this specification |
|
1372 during the processing of a request, also known as a transaction |
|
1373 stateful proxy. The behavior of a stateful proxy is further |
|
1374 defined in Section 16. A (transaction) stateful proxy is not |
|
1375 the same as a call stateful proxy. |
|
1376 |
|
1377 Stateless Proxy: A logical entity that does not maintain the |
|
1378 client or server transaction state machines defined in this |
|
1379 specification when it processes requests. A stateless proxy |
|
1380 forwards every request it receives downstream and every |
|
1381 response it receives upstream. |
|
1382 |
|
1383 Strict Routing: A proxy is said to be strict routing if it follows |
|
1384 the Route processing rules of RFC 2543 and many prior work in |
|
1385 progress versions of this RFC. That rule caused proxies to |
|
1386 destroy the contents of the Request-URI when a Route header |
|
1387 field was present. Strict routing behavior is not used in this |
|
1388 specification, in favor of a loose routing behavior. Proxies |
|
1389 that perform strict routing are also known as strict routers. |
|
1390 |
|
1391 Target Refresh Request: A target refresh request sent within a |
|
1392 dialog is defined as a request that can modify the remote |
|
1393 target of the dialog. |
|
1394 |
|
1395 Transaction User (TU): The layer of protocol processing that |
|
1396 resides above the transaction layer. Transaction users include |
|
1397 the UAC core, UAS core, and proxy core. |
|
1398 |
|
1399 |
|
1400 |
|
1401 |
|
1402 Rosenberg, et. al. Standards Track [Page 25] |
|
1403 |
|
1404 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1405 |
|
1406 |
|
1407 Upstream: A direction of message forwarding within a transaction |
|
1408 that refers to the direction that responses flow from the user |
|
1409 agent server back to the user agent client. |
|
1410 |
|
1411 URL-encoded: A character string encoded according to RFC 2396, |
|
1412 Section 2.4 [5]. |
|
1413 |
|
1414 User Agent Client (UAC): A user agent client is a logical entity |
|
1415 that creates a new request, and then uses the client |
|
1416 transaction state machinery to send it. The role of UAC lasts |
|
1417 only for the duration of that transaction. In other words, if |
|
1418 a piece of software initiates a request, it acts as a UAC for |
|
1419 the duration of that transaction. If it receives a request |
|
1420 later, it assumes the role of a user agent server for the |
|
1421 processing of that transaction. |
|
1422 |
|
1423 UAC Core: The set of processing functions required of a UAC that |
|
1424 reside above the transaction and transport layers. |
|
1425 |
|
1426 User Agent Server (UAS): A user agent server is a logical entity |
|
1427 that generates a response to a SIP request. The response |
|
1428 accepts, rejects, or redirects the request. This role lasts |
|
1429 only for the duration of that transaction. In other words, if |
|
1430 a piece of software responds to a request, it acts as a UAS for |
|
1431 the duration of that transaction. If it generates a request |
|
1432 later, it assumes the role of a user agent client for the |
|
1433 processing of that transaction. |
|
1434 |
|
1435 UAS Core: The set of processing functions required at a UAS that |
|
1436 resides above the transaction and transport layers. |
|
1437 |
|
1438 User Agent (UA): A logical entity that can act as both a user |
|
1439 agent client and user agent server. |
|
1440 |
|
1441 The role of UAC and UAS, as well as proxy and redirect servers, are |
|
1442 defined on a transaction-by-transaction basis. For example, the user |
|
1443 agent initiating a call acts as a UAC when sending the initial INVITE |
|
1444 request and as a UAS when receiving a BYE request from the callee. |
|
1445 Similarly, the same software can act as a proxy server for one |
|
1446 request and as a redirect server for the next request. |
|
1447 |
|
1448 Proxy, location, and registrar servers defined above are logical |
|
1449 entities; implementations MAY combine them into a single application. |
|
1450 |
|
1451 7 SIP Messages |
|
1452 |
|
1453 SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 |
|
1454 [7]). |
|
1455 |
|
1456 |
|
1457 |
|
1458 Rosenberg, et. al. Standards Track [Page 26] |
|
1459 |
|
1460 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1461 |
|
1462 |
|
1463 A SIP message is either a request from a client to a server, or a |
|
1464 response from a server to a client. |
|
1465 |
|
1466 Both Request (section 7.1) and Response (section 7.2) messages use |
|
1467 the basic format of RFC 2822 [3], even though the syntax differs in |
|
1468 character set and syntax specifics. (SIP allows header fields that |
|
1469 would not be valid RFC 2822 header fields, for example.) Both types |
|
1470 of messages consist of a start-line, one or more header fields, an |
|
1471 empty line indicating the end of the header fields, and an optional |
|
1472 message-body. |
|
1473 |
|
1474 generic-message = start-line |
|
1475 *message-header |
|
1476 CRLF |
|
1477 [ message-body ] |
|
1478 start-line = Request-Line / Status-Line |
|
1479 |
|
1480 The start-line, each message-header line, and the empty line MUST be |
|
1481 terminated by a carriage-return line-feed sequence (CRLF). Note that |
|
1482 the empty line MUST be present even if the message-body is not. |
|
1483 |
|
1484 Except for the above difference in character sets, much of SIP's |
|
1485 message and header field syntax is identical to HTTP/1.1. Rather |
|
1486 than repeating the syntax and semantics here, we use [HX.Y] to refer |
|
1487 to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). |
|
1488 |
|
1489 However, SIP is not an extension of HTTP. |
|
1490 |
|
1491 7.1 Requests |
|
1492 |
|
1493 SIP requests are distinguished by having a Request-Line for a start- |
|
1494 line. A Request-Line contains a method name, a Request-URI, and the |
|
1495 protocol version separated by a single space (SP) character. |
|
1496 |
|
1497 The Request-Line ends with CRLF. No CR or LF are allowed except in |
|
1498 the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed |
|
1499 in any of the elements. |
|
1500 |
|
1501 Request-Line = Method SP Request-URI SP SIP-Version CRLF |
|
1502 |
|
1503 Method: This specification defines six methods: REGISTER for |
|
1504 registering contact information, INVITE, ACK, and CANCEL for |
|
1505 setting up sessions, BYE for terminating sessions, and |
|
1506 OPTIONS for querying servers about their capabilities. SIP |
|
1507 extensions, documented in standards track RFCs, may define |
|
1508 additional methods. |
|
1509 |
|
1510 |
|
1511 |
|
1512 |
|
1513 |
|
1514 Rosenberg, et. al. Standards Track [Page 27] |
|
1515 |
|
1516 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1517 |
|
1518 |
|
1519 Request-URI: The Request-URI is a SIP or SIPS URI as described in |
|
1520 Section 19.1 or a general URI (RFC 2396 [5]). It indicates |
|
1521 the user or service to which this request is being addressed. |
|
1522 The Request-URI MUST NOT contain unescaped spaces or control |
|
1523 characters and MUST NOT be enclosed in "<>". |
|
1524 |
|
1525 SIP elements MAY support Request-URIs with schemes other than |
|
1526 "sip" and "sips", for example the "tel" URI scheme of RFC |
|
1527 2806 [9]. SIP elements MAY translate non-SIP URIs using any |
|
1528 mechanism at their disposal, resulting in SIP URI, SIPS URI, |
|
1529 or some other scheme. |
|
1530 |
|
1531 SIP-Version: Both request and response messages include the |
|
1532 version of SIP in use, and follow [H3.1] (with HTTP replaced |
|
1533 by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version |
|
1534 ordering, compliance requirements, and upgrading of version |
|
1535 numbers. To be compliant with this specification, |
|
1536 applications sending SIP messages MUST include a SIP-Version |
|
1537 of "SIP/2.0". The SIP-Version string is case-insensitive, |
|
1538 but implementations MUST send upper-case. |
|
1539 |
|
1540 Unlike HTTP/1.1, SIP treats the version number as a literal |
|
1541 string. In practice, this should make no difference. |
|
1542 |
|
1543 7.2 Responses |
|
1544 |
|
1545 SIP responses are distinguished from requests by having a Status-Line |
|
1546 as their start-line. A Status-Line consists of the protocol version |
|
1547 followed by a numeric Status-Code and its associated textual phrase, |
|
1548 with each element separated by a single SP character. |
|
1549 |
|
1550 No CR or LF is allowed except in the final CRLF sequence. |
|
1551 |
|
1552 Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF |
|
1553 |
|
1554 The Status-Code is a 3-digit integer result code that indicates the |
|
1555 outcome of an attempt to understand and satisfy a request. The |
|
1556 Reason-Phrase is intended to give a short textual description of the |
|
1557 Status-Code. The Status-Code is intended for use by automata, |
|
1558 whereas the Reason-Phrase is intended for the human user. A client |
|
1559 is not required to examine or display the Reason-Phrase. |
|
1560 |
|
1561 While this specification suggests specific wording for the reason |
|
1562 phrase, implementations MAY choose other text, for example, in the |
|
1563 language indicated in the Accept-Language header field of the |
|
1564 request. |
|
1565 |
|
1566 |
|
1567 |
|
1568 |
|
1569 |
|
1570 Rosenberg, et. al. Standards Track [Page 28] |
|
1571 |
|
1572 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1573 |
|
1574 |
|
1575 The first digit of the Status-Code defines the class of response. |
|
1576 The last two digits do not have any categorization role. For this |
|
1577 reason, any response with a status code between 100 and 199 is |
|
1578 referred to as a "1xx response", any response with a status code |
|
1579 between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows |
|
1580 six values for the first digit: |
|
1581 |
|
1582 1xx: Provisional -- request received, continuing to process the |
|
1583 request; |
|
1584 |
|
1585 2xx: Success -- the action was successfully received, understood, |
|
1586 and accepted; |
|
1587 |
|
1588 3xx: Redirection -- further action needs to be taken in order to |
|
1589 complete the request; |
|
1590 |
|
1591 4xx: Client Error -- the request contains bad syntax or cannot be |
|
1592 fulfilled at this server; |
|
1593 |
|
1594 5xx: Server Error -- the server failed to fulfill an apparently |
|
1595 valid request; |
|
1596 |
|
1597 6xx: Global Failure -- the request cannot be fulfilled at any |
|
1598 server. |
|
1599 |
|
1600 Section 21 defines these classes and describes the individual codes. |
|
1601 |
|
1602 7.3 Header Fields |
|
1603 |
|
1604 SIP header fields are similar to HTTP header fields in both syntax |
|
1605 and semantics. In particular, SIP header fields follow the [H4.2] |
|
1606 definitions of syntax for the message-header and the rules for |
|
1607 extending header fields over multiple lines. However, the latter is |
|
1608 specified in HTTP with implicit whitespace and folding. This |
|
1609 specification conforms to RFC 2234 [10] and uses only explicit |
|
1610 whitespace and folding as an integral part of the grammar. |
|
1611 |
|
1612 [H4.2] also specifies that multiple header fields of the same field |
|
1613 name whose value is a comma-separated list can be combined into one |
|
1614 header field. That applies to SIP as well, but the specific rule is |
|
1615 different because of the different grammars. Specifically, any SIP |
|
1616 header whose grammar is of the form |
|
1617 |
|
1618 header = "header-name" HCOLON header-value *(COMMA header-value) |
|
1619 |
|
1620 allows for combining header fields of the same name into a comma- |
|
1621 separated list. The Contact header field allows a comma-separated |
|
1622 list unless the header field value is "*". |
|
1623 |
|
1624 |
|
1625 |
|
1626 Rosenberg, et. al. Standards Track [Page 29] |
|
1627 |
|
1628 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1629 |
|
1630 |
|
1631 7.3.1 Header Field Format |
|
1632 |
|
1633 Header fields follow the same generic header format as that given in |
|
1634 Section 2.2 of RFC 2822 [3]. Each header field consists of a field |
|
1635 name followed by a colon (":") and the field value. |
|
1636 |
|
1637 field-name: field-value |
|
1638 |
|
1639 The formal grammar for a message-header specified in Section 25 |
|
1640 allows for an arbitrary amount of whitespace on either side of the |
|
1641 colon; however, implementations should avoid spaces between the field |
|
1642 name and the colon and use a single space (SP) between the colon and |
|
1643 the field-value. |
|
1644 |
|
1645 Subject: lunch |
|
1646 Subject : lunch |
|
1647 Subject :lunch |
|
1648 Subject: lunch |
|
1649 |
|
1650 Thus, the above are all valid and equivalent, but the last is the |
|
1651 preferred form. |
|
1652 |
|
1653 Header fields can be extended over multiple lines by preceding each |
|
1654 extra line with at least one SP or horizontal tab (HT). The line |
|
1655 break and the whitespace at the beginning of the next line are |
|
1656 treated as a single SP character. Thus, the following are |
|
1657 equivalent: |
|
1658 |
|
1659 Subject: I know you're there, pick up the phone and talk to me! |
|
1660 Subject: I know you're there, |
|
1661 pick up the phone |
|
1662 and talk to me! |
|
1663 |
|
1664 The relative order of header fields with different field names is not |
|
1665 significant. However, it is RECOMMENDED that header fields which are |
|
1666 needed for proxy processing (Via, Route, Record-Route, Proxy-Require, |
|
1667 Max-Forwards, and Proxy-Authorization, for example) appear towards |
|
1668 the top of the message to facilitate rapid parsing. The relative |
|
1669 order of header field rows with the same field name is important. |
|
1670 Multiple header field rows with the same field-name MAY be present in |
|
1671 a message if and only if the entire field-value for that header field |
|
1672 is defined as a comma-separated list (that is, if follows the grammar |
|
1673 defined in Section 7.3). It MUST be possible to combine the multiple |
|
1674 header field rows into one "field-name: field-value" pair, without |
|
1675 changing the semantics of the message, by appending each subsequent |
|
1676 field-value to the first, each separated by a comma. The exceptions |
|
1677 to this rule are the WWW-Authenticate, Authorization, Proxy- |
|
1678 Authenticate, and Proxy-Authorization header fields. Multiple header |
|
1679 |
|
1680 |
|
1681 |
|
1682 Rosenberg, et. al. Standards Track [Page 30] |
|
1683 |
|
1684 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1685 |
|
1686 |
|
1687 field rows with these names MAY be present in a message, but since |
|
1688 their grammar does not follow the general form listed in Section 7.3, |
|
1689 they MUST NOT be combined into a single header field row. |
|
1690 |
|
1691 Implementations MUST be able to process multiple header field rows |
|
1692 with the same name in any combination of the single-value-per-line or |
|
1693 comma-separated value forms. |
|
1694 |
|
1695 The following groups of header field rows are valid and equivalent: |
|
1696 |
|
1697 Route: <sip:alice@atlanta.com> |
|
1698 Subject: Lunch |
|
1699 Route: <sip:bob@biloxi.com> |
|
1700 Route: <sip:carol@chicago.com> |
|
1701 |
|
1702 Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com> |
|
1703 Route: <sip:carol@chicago.com> |
|
1704 Subject: Lunch |
|
1705 |
|
1706 Subject: Lunch |
|
1707 Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, |
|
1708 <sip:carol@chicago.com> |
|
1709 |
|
1710 Each of the following blocks is valid but not equivalent to the |
|
1711 others: |
|
1712 |
|
1713 Route: <sip:alice@atlanta.com> |
|
1714 Route: <sip:bob@biloxi.com> |
|
1715 Route: <sip:carol@chicago.com> |
|
1716 |
|
1717 Route: <sip:bob@biloxi.com> |
|
1718 Route: <sip:alice@atlanta.com> |
|
1719 Route: <sip:carol@chicago.com> |
|
1720 |
|
1721 Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, |
|
1722 <sip:bob@biloxi.com> |
|
1723 |
|
1724 The format of a header field-value is defined per header-name. It |
|
1725 will always be either an opaque sequence of TEXT-UTF8 octets, or a |
|
1726 combination of whitespace, tokens, separators, and quoted strings. |
|
1727 Many existing header fields will adhere to the general form of a |
|
1728 value followed by a semi-colon separated sequence of parameter-name, |
|
1729 parameter-value pairs: |
|
1730 |
|
1731 field-name: field-value *(;parameter-name=parameter-value) |
|
1732 |
|
1733 |
|
1734 |
|
1735 |
|
1736 |
|
1737 |
|
1738 Rosenberg, et. al. Standards Track [Page 31] |
|
1739 |
|
1740 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1741 |
|
1742 |
|
1743 Even though an arbitrary number of parameter pairs may be attached to |
|
1744 a header field value, any given parameter-name MUST NOT appear more |
|
1745 than once. |
|
1746 |
|
1747 When comparing header fields, field names are always case- |
|
1748 insensitive. Unless otherwise stated in the definition of a |
|
1749 particular header field, field values, parameter names, and parameter |
|
1750 values are case-insensitive. Tokens are always case-insensitive. |
|
1751 Unless specified otherwise, values expressed as quoted strings are |
|
1752 case-sensitive. For example, |
|
1753 |
|
1754 Contact: <sip:alice@atlanta.com>;expires=3600 |
|
1755 |
|
1756 is equivalent to |
|
1757 |
|
1758 CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600 |
|
1759 |
|
1760 and |
|
1761 |
|
1762 Content-Disposition: session;handling=optional |
|
1763 |
|
1764 is equivalent to |
|
1765 |
|
1766 content-disposition: Session;HANDLING=OPTIONAL |
|
1767 |
|
1768 The following two header fields are not equivalent: |
|
1769 |
|
1770 Warning: 370 devnull "Choose a bigger pipe" |
|
1771 Warning: 370 devnull "CHOOSE A BIGGER PIPE" |
|
1772 |
|
1773 7.3.2 Header Field Classification |
|
1774 |
|
1775 Some header fields only make sense in requests or responses. These |
|
1776 are called request header fields and response header fields, |
|
1777 respectively. If a header field appears in a message not matching |
|
1778 its category (such as a request header field in a response), it MUST |
|
1779 be ignored. Section 20 defines the classification of each header |
|
1780 field. |
|
1781 |
|
1782 7.3.3 Compact Form |
|
1783 |
|
1784 SIP provides a mechanism to represent common header field names in an |
|
1785 abbreviated form. This may be useful when messages would otherwise |
|
1786 become too large to be carried on the transport available to it |
|
1787 (exceeding the maximum transmission unit (MTU) when using UDP, for |
|
1788 example). These compact forms are defined in Section 20. A compact |
|
1789 form MAY be substituted for the longer form of a header field name at |
|
1790 any time without changing the semantics of the message. A header |
|
1791 |
|
1792 |
|
1793 |
|
1794 Rosenberg, et. al. Standards Track [Page 32] |
|
1795 |
|
1796 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1797 |
|
1798 |
|
1799 field name MAY appear in both long and short forms within the same |
|
1800 message. Implementations MUST accept both the long and short forms |
|
1801 of each header name. |
|
1802 |
|
1803 7.4 Bodies |
|
1804 |
|
1805 Requests, including new requests defined in extensions to this |
|
1806 specification, MAY contain message bodies unless otherwise noted. |
|
1807 The interpretation of the body depends on the request method. |
|
1808 |
|
1809 For response messages, the request method and the response status |
|
1810 code determine the type and interpretation of any message body. All |
|
1811 responses MAY include a body. |
|
1812 |
|
1813 7.4.1 Message Body Type |
|
1814 |
|
1815 The Internet media type of the message body MUST be given by the |
|
1816 Content-Type header field. If the body has undergone any encoding |
|
1817 such as compression, then this MUST be indicated by the Content- |
|
1818 Encoding header field; otherwise, Content-Encoding MUST be omitted. |
|
1819 If applicable, the character set of the message body is indicated as |
|
1820 part of the Content-Type header-field value. |
|
1821 |
|
1822 The "multipart" MIME type defined in RFC 2046 [11] MAY be used within |
|
1823 the body of the message. Implementations that send requests |
|
1824 containing multipart message bodies MUST send a session description |
|
1825 as a non-multipart message body if the remote implementation requests |
|
1826 this through an Accept header field that does not contain multipart. |
|
1827 |
|
1828 SIP messages MAY contain binary bodies or body parts. When no |
|
1829 explicit charset parameter is provided by the sender, media subtypes |
|
1830 of the "text" type are defined to have a default charset value of |
|
1831 "UTF-8". |
|
1832 |
|
1833 7.4.2 Message Body Length |
|
1834 |
|
1835 The body length in bytes is provided by the Content-Length header |
|
1836 field. Section 20.14 describes the necessary contents of this header |
|
1837 field in detail. |
|
1838 |
|
1839 The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. |
|
1840 (Note: The chunked encoding modifies the body of a message in order |
|
1841 to transfer it as a series of chunks, each with its own size |
|
1842 indicator.) |
|
1843 |
|
1844 |
|
1845 |
|
1846 |
|
1847 |
|
1848 |
|
1849 |
|
1850 Rosenberg, et. al. Standards Track [Page 33] |
|
1851 |
|
1852 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1853 |
|
1854 |
|
1855 7.5 Framing SIP Messages |
|
1856 |
|
1857 Unlike HTTP, SIP implementations can use UDP or other unreliable |
|
1858 datagram protocols. Each such datagram carries one request or |
|
1859 response. See Section 18 on constraints on usage of unreliable |
|
1860 transports. |
|
1861 |
|
1862 Implementations processing SIP messages over stream-oriented |
|
1863 transports MUST ignore any CRLF appearing before the start-line |
|
1864 [H4.1]. |
|
1865 |
|
1866 The Content-Length header field value is used to locate the end of |
|
1867 each SIP message in a stream. It will always be present when SIP |
|
1868 messages are sent over stream-oriented transports. |
|
1869 |
|
1870 8 General User Agent Behavior |
|
1871 |
|
1872 A user agent represents an end system. It contains a user agent |
|
1873 client (UAC), which generates requests, and a user agent server |
|
1874 (UAS), which responds to them. A UAC is capable of generating a |
|
1875 request based on some external stimulus (the user clicking a button, |
|
1876 or a signal on a PSTN line) and processing a response. A UAS is |
|
1877 capable of receiving a request and generating a response based on |
|
1878 user input, external stimulus, the result of a program execution, or |
|
1879 some other mechanism. |
|
1880 |
|
1881 When a UAC sends a request, the request passes through some number of |
|
1882 proxy servers, which forward the request towards the UAS. When the |
|
1883 UAS generates a response, the response is forwarded towards the UAC. |
|
1884 |
|
1885 UAC and UAS procedures depend strongly on two factors. First, based |
|
1886 on whether the request or response is inside or outside of a dialog, |
|
1887 and second, based on the method of a request. Dialogs are discussed |
|
1888 thoroughly in Section 12; they represent a peer-to-peer relationship |
|
1889 between user agents and are established by specific SIP methods, such |
|
1890 as INVITE. |
|
1891 |
|
1892 In this section, we discuss the method-independent rules for UAC and |
|
1893 UAS behavior when processing requests that are outside of a dialog. |
|
1894 This includes, of course, the requests which themselves establish a |
|
1895 dialog. |
|
1896 |
|
1897 Security procedures for requests and responses outside of a dialog |
|
1898 are described in Section 26. Specifically, mechanisms exist for the |
|
1899 UAS and UAC to mutually authenticate. A limited set of privacy |
|
1900 features are also supported through encryption of bodies using |
|
1901 S/MIME. |
|
1902 |
|
1903 |
|
1904 |
|
1905 |
|
1906 Rosenberg, et. al. Standards Track [Page 34] |
|
1907 |
|
1908 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1909 |
|
1910 |
|
1911 8.1 UAC Behavior |
|
1912 |
|
1913 This section covers UAC behavior outside of a dialog. |
|
1914 |
|
1915 8.1.1 Generating the Request |
|
1916 |
|
1917 A valid SIP request formulated by a UAC MUST, at a minimum, contain |
|
1918 the following header fields: To, From, CSeq, Call-ID, Max-Forwards, |
|
1919 and Via; all of these header fields are mandatory in all SIP |
|
1920 requests. These six header fields are the fundamental building |
|
1921 blocks of a SIP message, as they jointly provide for most of the |
|
1922 critical message routing services including the addressing of |
|
1923 messages, the routing of responses, limiting message propagation, |
|
1924 ordering of messages, and the unique identification of transactions. |
|
1925 These header fields are in addition to the mandatory request line, |
|
1926 which contains the method, Request-URI, and SIP version. |
|
1927 |
|
1928 Examples of requests sent outside of a dialog include an INVITE to |
|
1929 establish a session (Section 13) and an OPTIONS to query for |
|
1930 capabilities (Section 11). |
|
1931 |
|
1932 8.1.1.1 Request-URI |
|
1933 |
|
1934 The initial Request-URI of the message SHOULD be set to the value of |
|
1935 the URI in the To field. One notable exception is the REGISTER |
|
1936 method; behavior for setting the Request-URI of REGISTER is given in |
|
1937 Section 10. It may also be undesirable for privacy reasons or |
|
1938 convenience to set these fields to the same value (especially if the |
|
1939 originating UA expects that the Request-URI will be changed during |
|
1940 transit). |
|
1941 |
|
1942 In some special circumstances, the presence of a pre-existing route |
|
1943 set can affect the Request-URI of the message. A pre-existing route |
|
1944 set is an ordered set of URIs that identify a chain of servers, to |
|
1945 which a UAC will send outgoing requests that are outside of a dialog. |
|
1946 Commonly, they are configured on the UA by a user or service provider |
|
1947 manually, or through some other non-SIP mechanism. When a provider |
|
1948 wishes to configure a UA with an outbound proxy, it is RECOMMENDED |
|
1949 that this be done by providing it with a pre-existing route set with |
|
1950 a single URI, that of the outbound proxy. |
|
1951 |
|
1952 When a pre-existing route set is present, the procedures for |
|
1953 populating the Request-URI and Route header field detailed in Section |
|
1954 12.2.1.1 MUST be followed (even though there is no dialog), using the |
|
1955 desired Request-URI as the remote target URI. |
|
1956 |
|
1957 |
|
1958 |
|
1959 |
|
1960 |
|
1961 |
|
1962 Rosenberg, et. al. Standards Track [Page 35] |
|
1963 |
|
1964 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
1965 |
|
1966 |
|
1967 8.1.1.2 To |
|
1968 |
|
1969 The To header field first and foremost specifies the desired |
|
1970 "logical" recipient of the request, or the address-of-record of the |
|
1971 user or resource that is the target of this request. This may or may |
|
1972 not be the ultimate recipient of the request. The To header field |
|
1973 MAY contain a SIP or SIPS URI, but it may also make use of other URI |
|
1974 schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. |
|
1975 All SIP implementations MUST support the SIP URI scheme. Any |
|
1976 implementation that supports TLS MUST support the SIPS URI scheme. |
|
1977 The To header field allows for a display name. |
|
1978 |
|
1979 A UAC may learn how to populate the To header field for a particular |
|
1980 request in a number of ways. Usually the user will suggest the To |
|
1981 header field through a human interface, perhaps inputting the URI |
|
1982 manually or selecting it from some sort of address book. Frequently, |
|
1983 the user will not enter a complete URI, but rather a string of digits |
|
1984 or letters (for example, "bob"). It is at the discretion of the UA |
|
1985 to choose how to interpret this input. Using the string to form the |
|
1986 user part of a SIP URI implies that the UA wishes the name to be |
|
1987 resolved in the domain to the right-hand side (RHS) of the at-sign in |
|
1988 the SIP URI (for instance, sip:bob@example.com). Using the string to |
|
1989 form the user part of a SIPS URI implies that the UA wishes to |
|
1990 communicate securely, and that the name is to be resolved in the |
|
1991 domain to the RHS of the at-sign. The RHS will frequently be the |
|
1992 home domain of the requestor, which allows for the home domain to |
|
1993 process the outgoing request. This is useful for features like |
|
1994 "speed dial" that require interpretation of the user part in the home |
|
1995 domain. The tel URL may be used when the UA does not wish to specify |
|
1996 the domain that should interpret a telephone number that has been |
|
1997 input by the user. Rather, each domain through which the request |
|
1998 passes would be given that opportunity. As an example, a user in an |
|
1999 airport might log in and send requests through an outbound proxy in |
|
2000 the airport. If they enter "411" (this is the phone number for local |
|
2001 directory assistance in the United States), that needs to be |
|
2002 interpreted and processed by the outbound proxy in the airport, not |
|
2003 the user's home domain. In this case, tel:411 would be the right |
|
2004 choice. |
|
2005 |
|
2006 A request outside of a dialog MUST NOT contain a To tag; the tag in |
|
2007 the To field of a request identifies the peer of the dialog. Since |
|
2008 no dialog is established, no tag is present. |
|
2009 |
|
2010 For further information on the To header field, see Section 20.39. |
|
2011 The following is an example of a valid To header field: |
|
2012 |
|
2013 To: Carol <sip:carol@chicago.com> |
|
2014 |
|
2015 |
|
2016 |
|
2017 |
|
2018 Rosenberg, et. al. Standards Track [Page 36] |
|
2019 |
|
2020 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2021 |
|
2022 |
|
2023 8.1.1.3 From |
|
2024 |
|
2025 The From header field indicates the logical identity of the initiator |
|
2026 of the request, possibly the user's address-of-record. Like the To |
|
2027 header field, it contains a URI and optionally a display name. It is |
|
2028 used by SIP elements to determine which processing rules to apply to |
|
2029 a request (for example, automatic call rejection). As such, it is |
|
2030 very important that the From URI not contain IP addresses or the FQDN |
|
2031 of the host on which the UA is running, since these are not logical |
|
2032 names. |
|
2033 |
|
2034 The From header field allows for a display name. A UAC SHOULD use |
|
2035 the display name "Anonymous", along with a syntactically correct, but |
|
2036 otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the |
|
2037 identity of the client is to remain hidden. |
|
2038 |
|
2039 Usually, the value that populates the From header field in requests |
|
2040 generated by a particular UA is pre-provisioned by the user or by the |
|
2041 administrators of the user's local domain. If a particular UA is |
|
2042 used by multiple users, it might have switchable profiles that |
|
2043 include a URI corresponding to the identity of the profiled user. |
|
2044 Recipients of requests can authenticate the originator of a request |
|
2045 in order to ascertain that they are who their From header field |
|
2046 claims they are (see Section 22 for more on authentication). |
|
2047 |
|
2048 The From field MUST contain a new "tag" parameter, chosen by the UAC. |
|
2049 See Section 19.3 for details on choosing a tag. |
|
2050 |
|
2051 For further information on the From header field, see Section 20.20. |
|
2052 Examples: |
|
2053 |
|
2054 From: "Bob" <sips:bob@biloxi.com> ;tag=a48s |
|
2055 From: sip:+12125551212@phone2net.com;tag=887s |
|
2056 From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 |
|
2057 |
|
2058 8.1.1.4 Call-ID |
|
2059 |
|
2060 The Call-ID header field acts as a unique identifier to group |
|
2061 together a series of messages. It MUST be the same for all requests |
|
2062 and responses sent by either UA in a dialog. It SHOULD be the same |
|
2063 in each registration from a UA. |
|
2064 |
|
2065 In a new request created by a UAC outside of any dialog, the Call-ID |
|
2066 header field MUST be selected by the UAC as a globally unique |
|
2067 identifier over space and time unless overridden by method-specific |
|
2068 behavior. All SIP UAs must have a means to guarantee that the Call- |
|
2069 ID header fields they produce will not be inadvertently generated by |
|
2070 any other UA. Note that when requests are retried after certain |
|
2071 |
|
2072 |
|
2073 |
|
2074 Rosenberg, et. al. Standards Track [Page 37] |
|
2075 |
|
2076 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2077 |
|
2078 |
|
2079 failure responses that solicit an amendment to a request (for |
|
2080 example, a challenge for authentication), these retried requests are |
|
2081 not considered new requests, and therefore do not need new Call-ID |
|
2082 header fields; see Section 8.1.3.5. |
|
2083 |
|
2084 Use of cryptographically random identifiers (RFC 1750 [12]) in the |
|
2085 generation of Call-IDs is RECOMMENDED. Implementations MAY use the |
|
2086 form "localid@host". Call-IDs are case-sensitive and are simply |
|
2087 compared byte-by-byte. |
|
2088 |
|
2089 Using cryptographically random identifiers provides some |
|
2090 protection against session hijacking and reduces the likelihood of |
|
2091 unintentional Call-ID collisions. |
|
2092 |
|
2093 No provisioning or human interface is required for the selection of |
|
2094 the Call-ID header field value for a request. |
|
2095 |
|
2096 For further information on the Call-ID header field, see Section |
|
2097 20.8. |
|
2098 |
|
2099 Example: |
|
2100 |
|
2101 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com |
|
2102 |
|
2103 8.1.1.5 CSeq |
|
2104 |
|
2105 The CSeq header field serves as a way to identify and order |
|
2106 transactions. It consists of a sequence number and a method. The |
|
2107 method MUST match that of the request. For non-REGISTER requests |
|
2108 outside of a dialog, the sequence number value is arbitrary. The |
|
2109 sequence number value MUST be expressible as a 32-bit unsigned |
|
2110 integer and MUST be less than 2**31. As long as it follows the above |
|
2111 guidelines, a client may use any mechanism it would like to select |
|
2112 CSeq header field values. |
|
2113 |
|
2114 Section 12.2.1.1 discusses construction of the CSeq for requests |
|
2115 within a dialog. |
|
2116 |
|
2117 Example: |
|
2118 |
|
2119 CSeq: 4711 INVITE |
|
2120 |
|
2121 |
|
2122 |
|
2123 |
|
2124 |
|
2125 |
|
2126 |
|
2127 |
|
2128 |
|
2129 |
|
2130 Rosenberg, et. al. Standards Track [Page 38] |
|
2131 |
|
2132 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2133 |
|
2134 |
|
2135 8.1.1.6 Max-Forwards |
|
2136 |
|
2137 The Max-Forwards header field serves to limit the number of hops a |
|
2138 request can transit on the way to its destination. It consists of an |
|
2139 integer that is decremented by one at each hop. If the Max-Forwards |
|
2140 value reaches 0 before the request reaches its destination, it will |
|
2141 be rejected with a 483(Too Many Hops) error response. |
|
2142 |
|
2143 A UAC MUST insert a Max-Forwards header field into each request it |
|
2144 originates with a value that SHOULD be 70. This number was chosen to |
|
2145 be sufficiently large to guarantee that a request would not be |
|
2146 dropped in any SIP network when there were no loops, but not so large |
|
2147 as to consume proxy resources when a loop does occur. Lower values |
|
2148 should be used with caution and only in networks where topologies are |
|
2149 known by the UA. |
|
2150 |
|
2151 8.1.1.7 Via |
|
2152 |
|
2153 The Via header field indicates the transport used for the transaction |
|
2154 and identifies the location where the response is to be sent. A Via |
|
2155 header field value is added only after the transport that will be |
|
2156 used to reach the next hop has been selected (which may involve the |
|
2157 usage of the procedures in [4]). |
|
2158 |
|
2159 When the UAC creates a request, it MUST insert a Via into that |
|
2160 request. The protocol name and protocol version in the header field |
|
2161 MUST be SIP and 2.0, respectively. The Via header field value MUST |
|
2162 contain a branch parameter. This parameter is used to identify the |
|
2163 transaction created by that request. This parameter is used by both |
|
2164 the client and the server. |
|
2165 |
|
2166 The branch parameter value MUST be unique across space and time for |
|
2167 all requests sent by the UA. The exceptions to this rule are CANCEL |
|
2168 and ACK for non-2xx responses. As discussed below, a CANCEL request |
|
2169 will have the same value of the branch parameter as the request it |
|
2170 cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx |
|
2171 response will also have the same branch ID as the INVITE whose |
|
2172 response it acknowledges. |
|
2173 |
|
2174 The uniqueness property of the branch ID parameter, to facilitate |
|
2175 its use as a transaction ID, was not part of RFC 2543. |
|
2176 |
|
2177 The branch ID inserted by an element compliant with this |
|
2178 specification MUST always begin with the characters "z9hG4bK". These |
|
2179 7 characters are used as a magic cookie (7 is deemed sufficient to |
|
2180 ensure that an older RFC 2543 implementation would not pick such a |
|
2181 value), so that servers receiving the request can determine that the |
|
2182 branch ID was constructed in the fashion described by this |
|
2183 |
|
2184 |
|
2185 |
|
2186 Rosenberg, et. al. Standards Track [Page 39] |
|
2187 |
|
2188 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2189 |
|
2190 |
|
2191 specification (that is, globally unique). Beyond this requirement, |
|
2192 the precise format of the branch token is implementation-defined. |
|
2193 |
|
2194 The Via header maddr, ttl, and sent-by components will be set when |
|
2195 the request is processed by the transport layer (Section 18). |
|
2196 |
|
2197 Via processing for proxies is described in Section 16.6 Item 8 and |
|
2198 Section 16.7 Item 3. |
|
2199 |
|
2200 8.1.1.8 Contact |
|
2201 |
|
2202 The Contact header field provides a SIP or SIPS URI that can be used |
|
2203 to contact that specific instance of the UA for subsequent requests. |
|
2204 The Contact header field MUST be present and contain exactly one SIP |
|
2205 or SIPS URI in any request that can result in the establishment of a |
|
2206 dialog. For the methods defined in this specification, that includes |
|
2207 only the INVITE request. For these requests, the scope of the |
|
2208 Contact is global. That is, the Contact header field value contains |
|
2209 the URI at which the UA would like to receive requests, and this URI |
|
2210 MUST be valid even if used in subsequent requests outside of any |
|
2211 dialogs. |
|
2212 |
|
2213 If the Request-URI or top Route header field value contains a SIPS |
|
2214 URI, the Contact header field MUST contain a SIPS URI as well. |
|
2215 |
|
2216 For further information on the Contact header field, see Section |
|
2217 20.10. |
|
2218 |
|
2219 8.1.1.9 Supported and Require |
|
2220 |
|
2221 If the UAC supports extensions to SIP that can be applied by the |
|
2222 server to the response, the UAC SHOULD include a Supported header |
|
2223 field in the request listing the option tags (Section 19.2) for those |
|
2224 extensions. |
|
2225 |
|
2226 The option tags listed MUST only refer to extensions defined in |
|
2227 standards-track RFCs. This is to prevent servers from insisting that |
|
2228 clients implement non-standard, vendor-defined features in order to |
|
2229 receive service. Extensions defined by experimental and |
|
2230 informational RFCs are explicitly excluded from usage with the |
|
2231 Supported header field in a request, since they too are often used to |
|
2232 document vendor-defined extensions. |
|
2233 |
|
2234 If the UAC wishes to insist that a UAS understand an extension that |
|
2235 the UAC will apply to the request in order to process the request, it |
|
2236 MUST insert a Require header field into the request listing the |
|
2237 option tag for that extension. If the UAC wishes to apply an |
|
2238 extension to the request and insist that any proxies that are |
|
2239 |
|
2240 |
|
2241 |
|
2242 Rosenberg, et. al. Standards Track [Page 40] |
|
2243 |
|
2244 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2245 |
|
2246 |
|
2247 traversed understand that extension, it MUST insert a Proxy-Require |
|
2248 header field into the request listing the option tag for that |
|
2249 extension. |
|
2250 |
|
2251 As with the Supported header field, the option tags in the Require |
|
2252 and Proxy-Require header fields MUST only refer to extensions defined |
|
2253 in standards-track RFCs. |
|
2254 |
|
2255 8.1.1.10 Additional Message Components |
|
2256 |
|
2257 After a new request has been created, and the header fields described |
|
2258 above have been properly constructed, any additional optional header |
|
2259 fields are added, as are any header fields specific to the method. |
|
2260 |
|
2261 SIP requests MAY contain a MIME-encoded message-body. Regardless of |
|
2262 the type of body that a request contains, certain header fields must |
|
2263 be formulated to characterize the contents of the body. For further |
|
2264 information on these header fields, see Sections 20.11 through 20.15. |
|
2265 |
|
2266 8.1.2 Sending the Request |
|
2267 |
|
2268 The destination for the request is then computed. Unless there is |
|
2269 local policy specifying otherwise, the destination MUST be determined |
|
2270 by applying the DNS procedures described in [4] as follows. If the |
|
2271 first element in the route set indicated a strict router (resulting |
|
2272 in forming the request as described in Section 12.2.1.1), the |
|
2273 procedures MUST be applied to the Request-URI of the request. |
|
2274 Otherwise, the procedures are applied to the first Route header field |
|
2275 value in the request (if one exists), or to the request's Request-URI |
|
2276 if there is no Route header field present. These procedures yield an |
|
2277 ordered set of address, port, and transports to attempt. Independent |
|
2278 of which URI is used as input to the procedures of [4], if the |
|
2279 Request-URI specifies a SIPS resource, the UAC MUST follow the |
|
2280 procedures of [4] as if the input URI were a SIPS URI. |
|
2281 |
|
2282 Local policy MAY specify an alternate set of destinations to attempt. |
|
2283 If the Request-URI contains a SIPS URI, any alternate destinations |
|
2284 MUST be contacted with TLS. Beyond that, there are no restrictions |
|
2285 on the alternate destinations if the request contains no Route header |
|
2286 field. This provides a simple alternative to a pre-existing route |
|
2287 set as a way to specify an outbound proxy. However, that approach |
|
2288 for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing |
|
2289 route set with a single URI SHOULD be used instead. If the request |
|
2290 contains a Route header field, the request SHOULD be sent to the |
|
2291 locations derived from its topmost value, but MAY be sent to any |
|
2292 server that the UA is certain will honor the Route and Request-URI |
|
2293 policies specified in this document (as opposed to those in RFC |
|
2294 2543). In particular, a UAC configured with an outbound proxy SHOULD |
|
2295 |
|
2296 |
|
2297 |
|
2298 Rosenberg, et. al. Standards Track [Page 41] |
|
2299 |
|
2300 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2301 |
|
2302 |
|
2303 attempt to send the request to the location indicated in the first |
|
2304 Route header field value instead of adopting the policy of sending |
|
2305 all messages to the outbound proxy. |
|
2306 |
|
2307 This ensures that outbound proxies that do not add Record-Route |
|
2308 header field values will drop out of the path of subsequent |
|
2309 requests. It allows endpoints that cannot resolve the first Route |
|
2310 URI to delegate that task to an outbound proxy. |
|
2311 |
|
2312 The UAC SHOULD follow the procedures defined in [4] for stateful |
|
2313 elements, trying each address until a server is contacted. Each try |
|
2314 constitutes a new transaction, and therefore each carries a different |
|
2315 topmost Via header field value with a new branch parameter. |
|
2316 Furthermore, the transport value in the Via header field is set to |
|
2317 whatever transport was determined for the target server. |
|
2318 |
|
2319 8.1.3 Processing Responses |
|
2320 |
|
2321 Responses are first processed by the transport layer and then passed |
|
2322 up to the transaction layer. The transaction layer performs its |
|
2323 processing and then passes the response up to the TU. The majority |
|
2324 of response processing in the TU is method specific. However, there |
|
2325 are some general behaviors independent of the method. |
|
2326 |
|
2327 8.1.3.1 Transaction Layer Errors |
|
2328 |
|
2329 In some cases, the response returned by the transaction layer will |
|
2330 not be a SIP message, but rather a transaction layer error. When a |
|
2331 timeout error is received from the transaction layer, it MUST be |
|
2332 treated as if a 408 (Request Timeout) status code has been received. |
|
2333 If a fatal transport error is reported by the transport layer |
|
2334 (generally, due to fatal ICMP errors in UDP or connection failures in |
|
2335 TCP), the condition MUST be treated as a 503 (Service Unavailable) |
|
2336 status code. |
|
2337 |
|
2338 8.1.3.2 Unrecognized Responses |
|
2339 |
|
2340 A UAC MUST treat any final response it does not recognize as being |
|
2341 equivalent to the x00 response code of that class, and MUST be able |
|
2342 to process the x00 response code for all classes. For example, if a |
|
2343 UAC receives an unrecognized response code of 431, it can safely |
|
2344 assume that there was something wrong with its request and treat the |
|
2345 response as if it had received a 400 (Bad Request) response code. A |
|
2346 UAC MUST treat any provisional response different than 100 that it |
|
2347 does not recognize as 183 (Session Progress). A UAC MUST be able to |
|
2348 process 100 and 183 responses. |
|
2349 |
|
2350 |
|
2351 |
|
2352 |
|
2353 |
|
2354 Rosenberg, et. al. Standards Track [Page 42] |
|
2355 |
|
2356 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2357 |
|
2358 |
|
2359 8.1.3.3 Vias |
|
2360 |
|
2361 If more than one Via header field value is present in a response, the |
|
2362 UAC SHOULD discard the message. |
|
2363 |
|
2364 The presence of additional Via header field values that precede |
|
2365 the originator of the request suggests that the message was |
|
2366 misrouted or possibly corrupted. |
|
2367 |
|
2368 8.1.3.4 Processing 3xx Responses |
|
2369 |
|
2370 Upon receipt of a redirection response (for example, a 301 response |
|
2371 status code), clients SHOULD use the URI(s) in the Contact header |
|
2372 field to formulate one or more new requests based on the redirected |
|
2373 request. This process is similar to that of a proxy recursing on a |
|
2374 3xx class response as detailed in Sections 16.5 and 16.6. A client |
|
2375 starts with an initial target set containing exactly one URI, the |
|
2376 Request-URI of the original request. If a client wishes to formulate |
|
2377 new requests based on a 3xx class response to that request, it places |
|
2378 the URIs to try into the target set. Subject to the restrictions in |
|
2379 this specification, a client can choose which Contact URIs it places |
|
2380 into the target set. As with proxy recursion, a client processing |
|
2381 3xx class responses MUST NOT add any given URI to the target set more |
|
2382 than once. If the original request had a SIPS URI in the Request- |
|
2383 URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD |
|
2384 inform the user of the redirection to an insecure URI. |
|
2385 |
|
2386 Any new request may receive 3xx responses themselves containing |
|
2387 the original URI as a contact. Two locations can be configured to |
|
2388 redirect to each other. Placing any given URI in the target set |
|
2389 only once prevents infinite redirection loops. |
|
2390 |
|
2391 As the target set grows, the client MAY generate new requests to the |
|
2392 URIs in any order. A common mechanism is to order the set by the "q" |
|
2393 parameter value from the Contact header field value. Requests to the |
|
2394 URIs MAY be generated serially or in parallel. One approach is to |
|
2395 process groups of decreasing q-values serially and process the URIs |
|
2396 in each q-value group in parallel. Another is to perform only serial |
|
2397 processing in decreasing q-value order, arbitrarily choosing between |
|
2398 contacts of equal q-value. |
|
2399 |
|
2400 If contacting an address in the list results in a failure, as defined |
|
2401 in the next paragraph, the element moves to the next address in the |
|
2402 list, until the list is exhausted. If the list is exhausted, then |
|
2403 the request has failed. |
|
2404 |
|
2405 |
|
2406 |
|
2407 |
|
2408 |
|
2409 |
|
2410 Rosenberg, et. al. Standards Track [Page 43] |
|
2411 |
|
2412 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2413 |
|
2414 |
|
2415 Failures SHOULD be detected through failure response codes (codes |
|
2416 greater than 399); for network errors the client transaction will |
|
2417 report any transport layer failures to the transaction user. Note |
|
2418 that some response codes (detailed in 8.1.3.5) indicate that the |
|
2419 request can be retried; requests that are reattempted should not be |
|
2420 considered failures. |
|
2421 |
|
2422 When a failure for a particular contact address is received, the |
|
2423 client SHOULD try the next contact address. This will involve |
|
2424 creating a new client transaction to deliver a new request. |
|
2425 |
|
2426 In order to create a request based on a contact address in a 3xx |
|
2427 response, a UAC MUST copy the entire URI from the target set into the |
|
2428 Request-URI, except for the "method-param" and "header" URI |
|
2429 parameters (see Section 19.1.1 for a definition of these parameters). |
|
2430 It uses the "header" parameters to create header field values for the |
|
2431 new request, overwriting header field values associated with the |
|
2432 redirected request in accordance with the guidelines in Section |
|
2433 19.1.5. |
|
2434 |
|
2435 Note that in some instances, header fields that have been |
|
2436 communicated in the contact address may instead append to existing |
|
2437 request header fields in the original redirected request. As a |
|
2438 general rule, if the header field can accept a comma-separated list |
|
2439 of values, then the new header field value MAY be appended to any |
|
2440 existing values in the original redirected request. If the header |
|
2441 field does not accept multiple values, the value in the original |
|
2442 redirected request MAY be overwritten by the header field value |
|
2443 communicated in the contact address. For example, if a contact |
|
2444 address is returned with the following value: |
|
2445 |
|
2446 sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> |
|
2447 |
|
2448 Then any Subject header field in the original redirected request is |
|
2449 overwritten, but the HTTP URL is merely appended to any existing |
|
2450 Call-Info header field values. |
|
2451 |
|
2452 It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID |
|
2453 used in the original redirected request, but the UAC MAY also choose |
|
2454 to update the Call-ID header field value for new requests, for |
|
2455 example. |
|
2456 |
|
2457 Finally, once the new request has been constructed, it is sent using |
|
2458 a new client transaction, and therefore MUST have a new branch ID in |
|
2459 the top Via field as discussed in Section 8.1.1.7. |
|
2460 |
|
2461 |
|
2462 |
|
2463 |
|
2464 |
|
2465 |
|
2466 Rosenberg, et. al. Standards Track [Page 44] |
|
2467 |
|
2468 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2469 |
|
2470 |
|
2471 In all other respects, requests sent upon receipt of a redirect |
|
2472 response SHOULD re-use the header fields and bodies of the original |
|
2473 request. |
|
2474 |
|
2475 In some instances, Contact header field values may be cached at UAC |
|
2476 temporarily or permanently depending on the status code received and |
|
2477 the presence of an expiration interval; see Sections 21.3.2 and |
|
2478 21.3.3. |
|
2479 |
|
2480 8.1.3.5 Processing 4xx Responses |
|
2481 |
|
2482 Certain 4xx response codes require specific UA processing, |
|
2483 independent of the method. |
|
2484 |
|
2485 If a 401 (Unauthorized) or 407 (Proxy Authentication Required) |
|
2486 response is received, the UAC SHOULD follow the authorization |
|
2487 procedures of Section 22.2 and Section 22.3 to retry the request with |
|
2488 credentials. |
|
2489 |
|
2490 If a 413 (Request Entity Too Large) response is received (Section |
|
2491 21.4.11), the request contained a body that was longer than the UAS |
|
2492 was willing to accept. If possible, the UAC SHOULD retry the |
|
2493 request, either omitting the body or using one of a smaller length. |
|
2494 |
|
2495 If a 415 (Unsupported Media Type) response is received (Section |
|
2496 21.4.13), the request contained media types not supported by the UAS. |
|
2497 The UAC SHOULD retry sending the request, this time only using |
|
2498 content with types listed in the Accept header field in the response, |
|
2499 with encodings listed in the Accept-Encoding header field in the |
|
2500 response, and with languages listed in the Accept-Language in the |
|
2501 response. |
|
2502 |
|
2503 If a 416 (Unsupported URI Scheme) response is received (Section |
|
2504 21.4.14), the Request-URI used a URI scheme not supported by the |
|
2505 server. The client SHOULD retry the request, this time, using a SIP |
|
2506 URI. |
|
2507 |
|
2508 If a 420 (Bad Extension) response is received (Section 21.4.15), the |
|
2509 request contained a Require or Proxy-Require header field listing an |
|
2510 option-tag for a feature not supported by a proxy or UAS. The UAC |
|
2511 SHOULD retry the request, this time omitting any extensions listed in |
|
2512 the Unsupported header field in the response. |
|
2513 |
|
2514 In all of the above cases, the request is retried by creating a new |
|
2515 request with the appropriate modifications. This new request |
|
2516 constitutes a new transaction and SHOULD have the same value of the |
|
2517 Call-ID, To, and From of the previous request, but the CSeq should |
|
2518 contain a new sequence number that is one higher than the previous. |
|
2519 |
|
2520 |
|
2521 |
|
2522 Rosenberg, et. al. Standards Track [Page 45] |
|
2523 |
|
2524 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2525 |
|
2526 |
|
2527 With other 4xx responses, including those yet to be defined, a retry |
|
2528 may or may not be possible depending on the method and the use case. |
|
2529 |
|
2530 8.2 UAS Behavior |
|
2531 |
|
2532 When a request outside of a dialog is processed by a UAS, there is a |
|
2533 set of processing rules that are followed, independent of the method. |
|
2534 Section 12 gives guidance on how a UAS can tell whether a request is |
|
2535 inside or outside of a dialog. |
|
2536 |
|
2537 Note that request processing is atomic. If a request is accepted, |
|
2538 all state changes associated with it MUST be performed. If it is |
|
2539 rejected, all state changes MUST NOT be performed. |
|
2540 |
|
2541 UASs SHOULD process the requests in the order of the steps that |
|
2542 follow in this section (that is, starting with authentication, then |
|
2543 inspecting the method, the header fields, and so on throughout the |
|
2544 remainder of this section). |
|
2545 |
|
2546 8.2.1 Method Inspection |
|
2547 |
|
2548 Once a request is authenticated (or authentication is skipped), the |
|
2549 UAS MUST inspect the method of the request. If the UAS recognizes |
|
2550 but does not support the method of a request, it MUST generate a 405 |
|
2551 (Method Not Allowed) response. Procedures for generating responses |
|
2552 are described in Section 8.2.6. The UAS MUST also add an Allow |
|
2553 header field to the 405 (Method Not Allowed) response. The Allow |
|
2554 header field MUST list the set of methods supported by the UAS |
|
2555 generating the message. The Allow header field is presented in |
|
2556 Section 20.5. |
|
2557 |
|
2558 If the method is one supported by the server, processing continues. |
|
2559 |
|
2560 8.2.2 Header Inspection |
|
2561 |
|
2562 If a UAS does not understand a header field in a request (that is, |
|
2563 the header field is not defined in this specification or in any |
|
2564 supported extension), the server MUST ignore that header field and |
|
2565 continue processing the message. A UAS SHOULD ignore any malformed |
|
2566 header fields that are not necessary for processing requests. |
|
2567 |
|
2568 8.2.2.1 To and Request-URI |
|
2569 |
|
2570 The To header field identifies the original recipient of the request |
|
2571 designated by the user identified in the From field. The original |
|
2572 recipient may or may not be the UAS processing the request, due to |
|
2573 call forwarding or other proxy operations. A UAS MAY apply any |
|
2574 policy it wishes to determine whether to accept requests when the To |
|
2575 |
|
2576 |
|
2577 |
|
2578 Rosenberg, et. al. Standards Track [Page 46] |
|
2579 |
|
2580 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2581 |
|
2582 |
|
2583 header field is not the identity of the UAS. However, it is |
|
2584 RECOMMENDED that a UAS accept requests even if they do not recognize |
|
2585 the URI scheme (for example, a tel: URI) in the To header field, or |
|
2586 if the To header field does not address a known or current user of |
|
2587 this UAS. If, on the other hand, the UAS decides to reject the |
|
2588 request, it SHOULD generate a response with a 403 (Forbidden) status |
|
2589 code and pass it to the server transaction for transmission. |
|
2590 |
|
2591 However, the Request-URI identifies the UAS that is to process the |
|
2592 request. If the Request-URI uses a scheme not supported by the UAS, |
|
2593 it SHOULD reject the request with a 416 (Unsupported URI Scheme) |
|
2594 response. If the Request-URI does not identify an address that the |
|
2595 UAS is willing to accept requests for, it SHOULD reject the request |
|
2596 with a 404 (Not Found) response. Typically, a UA that uses the |
|
2597 REGISTER method to bind its address-of-record to a specific contact |
|
2598 address will see requests whose Request-URI equals that contact |
|
2599 address. Other potential sources of received Request-URIs include |
|
2600 the Contact header fields of requests and responses sent by the UA |
|
2601 that establish or refresh dialogs. |
|
2602 |
|
2603 8.2.2.2 Merged Requests |
|
2604 |
|
2605 If the request has no tag in the To header field, the UAS core MUST |
|
2606 check the request against ongoing transactions. If the From tag, |
|
2607 Call-ID, and CSeq exactly match those associated with an ongoing |
|
2608 transaction, but the request does not match that transaction (based |
|
2609 on the matching rules in Section 17.2.3), the UAS core SHOULD |
|
2610 generate a 482 (Loop Detected) response and pass it to the server |
|
2611 transaction. |
|
2612 |
|
2613 The same request has arrived at the UAS more than once, following |
|
2614 different paths, most likely due to forking. The UAS processes |
|
2615 the first such request received and responds with a 482 (Loop |
|
2616 Detected) to the rest of them. |
|
2617 |
|
2618 8.2.2.3 Require |
|
2619 |
|
2620 Assuming the UAS decides that it is the proper element to process the |
|
2621 request, it examines the Require header field, if present. |
|
2622 |
|
2623 The Require header field is used by a UAC to tell a UAS about SIP |
|
2624 extensions that the UAC expects the UAS to support in order to |
|
2625 process the request properly. Its format is described in Section |
|
2626 20.32. If a UAS does not understand an option-tag listed in a |
|
2627 Require header field, it MUST respond by generating a response with |
|
2628 status code 420 (Bad Extension). The UAS MUST add an Unsupported |
|
2629 header field, and list in it those options it does not understand |
|
2630 amongst those in the Require header field of the request. |
|
2631 |
|
2632 |
|
2633 |
|
2634 Rosenberg, et. al. Standards Track [Page 47] |
|
2635 |
|
2636 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2637 |
|
2638 |
|
2639 Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL |
|
2640 request, or in an ACK request sent for a non-2xx response. These |
|
2641 header fields MUST be ignored if they are present in these requests. |
|
2642 |
|
2643 An ACK request for a 2xx response MUST contain only those Require and |
|
2644 Proxy-Require values that were present in the initial request. |
|
2645 |
|
2646 Example: |
|
2647 |
|
2648 UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 |
|
2649 Require: 100rel |
|
2650 |
|
2651 UAS->UAC: SIP/2.0 420 Bad Extension |
|
2652 Unsupported: 100rel |
|
2653 |
|
2654 This behavior ensures that the client-server interaction will |
|
2655 proceed without delay when all options are understood by both |
|
2656 sides, and only slow down if options are not understood (as in the |
|
2657 example above). For a well-matched client-server pair, the |
|
2658 interaction proceeds quickly, saving a round-trip often required |
|
2659 by negotiation mechanisms. In addition, it also removes ambiguity |
|
2660 when the client requires features that the server does not |
|
2661 understand. Some features, such as call handling fields, are only |
|
2662 of interest to end systems. |
|
2663 |
|
2664 8.2.3 Content Processing |
|
2665 |
|
2666 Assuming the UAS understands any extensions required by the client, |
|
2667 the UAS examines the body of the message, and the header fields that |
|
2668 describe it. If there are any bodies whose type (indicated by the |
|
2669 Content-Type), language (indicated by the Content-Language) or |
|
2670 encoding (indicated by the Content-Encoding) are not understood, and |
|
2671 that body part is not optional (as indicated by the Content- |
|
2672 Disposition header field), the UAS MUST reject the request with a 415 |
|
2673 (Unsupported Media Type) response. The response MUST contain an |
|
2674 Accept header field listing the types of all bodies it understands, |
|
2675 in the event the request contained bodies of types not supported by |
|
2676 the UAS. If the request contained content encodings not understood |
|
2677 by the UAS, the response MUST contain an Accept-Encoding header field |
|
2678 listing the encodings understood by the UAS. If the request |
|
2679 contained content with languages not understood by the UAS, the |
|
2680 response MUST contain an Accept-Language header field indicating the |
|
2681 languages understood by the UAS. Beyond these checks, body handling |
|
2682 depends on the method and type. For further information on the |
|
2683 processing of content-specific header fields, see Section 7.4 as well |
|
2684 as Section 20.11 through 20.15. |
|
2685 |
|
2686 |
|
2687 |
|
2688 |
|
2689 |
|
2690 Rosenberg, et. al. Standards Track [Page 48] |
|
2691 |
|
2692 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2693 |
|
2694 |
|
2695 8.2.4 Applying Extensions |
|
2696 |
|
2697 A UAS that wishes to apply some extension when generating the |
|
2698 response MUST NOT do so unless support for that extension is |
|
2699 indicated in the Supported header field in the request. If the |
|
2700 desired extension is not supported, the server SHOULD rely only on |
|
2701 baseline SIP and any other extensions supported by the client. In |
|
2702 rare circumstances, where the server cannot process the request |
|
2703 without the extension, the server MAY send a 421 (Extension Required) |
|
2704 response. This response indicates that the proper response cannot be |
|
2705 generated without support of a specific extension. The needed |
|
2706 extension(s) MUST be included in a Require header field in the |
|
2707 response. This behavior is NOT RECOMMENDED, as it will generally |
|
2708 break interoperability. |
|
2709 |
|
2710 Any extensions applied to a non-421 response MUST be listed in a |
|
2711 Require header field included in the response. Of course, the server |
|
2712 MUST NOT apply extensions not listed in the Supported header field in |
|
2713 the request. As a result of this, the Require header field in a |
|
2714 response will only ever contain option tags defined in standards- |
|
2715 track RFCs. |
|
2716 |
|
2717 8.2.5 Processing the Request |
|
2718 |
|
2719 Assuming all of the checks in the previous subsections are passed, |
|
2720 the UAS processing becomes method-specific. Section 10 covers the |
|
2721 REGISTER request, Section 11 covers the OPTIONS request, Section 13 |
|
2722 covers the INVITE request, and Section 15 covers the BYE request. |
|
2723 |
|
2724 8.2.6 Generating the Response |
|
2725 |
|
2726 When a UAS wishes to construct a response to a request, it follows |
|
2727 the general procedures detailed in the following subsections. |
|
2728 Additional behaviors specific to the response code in question, which |
|
2729 are not detailed in this section, may also be required. |
|
2730 |
|
2731 Once all procedures associated with the creation of a response have |
|
2732 been completed, the UAS hands the response back to the server |
|
2733 transaction from which it received the request. |
|
2734 |
|
2735 8.2.6.1 Sending a Provisional Response |
|
2736 |
|
2737 One largely non-method-specific guideline for the generation of |
|
2738 responses is that UASs SHOULD NOT issue a provisional response for a |
|
2739 non-INVITE request. Rather, UASs SHOULD generate a final response to |
|
2740 a non-INVITE request as soon as possible. |
|
2741 |
|
2742 |
|
2743 |
|
2744 |
|
2745 |
|
2746 Rosenberg, et. al. Standards Track [Page 49] |
|
2747 |
|
2748 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2749 |
|
2750 |
|
2751 When a 100 (Trying) response is generated, any Timestamp header field |
|
2752 present in the request MUST be copied into this 100 (Trying) |
|
2753 response. If there is a delay in generating the response, the UAS |
|
2754 SHOULD add a delay value into the Timestamp value in the response. |
|
2755 This value MUST contain the difference between the time of sending of |
|
2756 the response and receipt of the request, measured in seconds. |
|
2757 |
|
2758 8.2.6.2 Headers and Tags |
|
2759 |
|
2760 The From field of the response MUST equal the From header field of |
|
2761 the request. The Call-ID header field of the response MUST equal the |
|
2762 Call-ID header field of the request. The CSeq header field of the |
|
2763 response MUST equal the CSeq field of the request. The Via header |
|
2764 field values in the response MUST equal the Via header field values |
|
2765 in the request and MUST maintain the same ordering. |
|
2766 |
|
2767 If a request contained a To tag in the request, the To header field |
|
2768 in the response MUST equal that of the request. However, if the To |
|
2769 header field in the request did not contain a tag, the URI in the To |
|
2770 header field in the response MUST equal the URI in the To header |
|
2771 field; additionally, the UAS MUST add a tag to the To header field in |
|
2772 the response (with the exception of the 100 (Trying) response, in |
|
2773 which a tag MAY be present). This serves to identify the UAS that is |
|
2774 responding, possibly resulting in a component of a dialog ID. The |
|
2775 same tag MUST be used for all responses to that request, both final |
|
2776 and provisional (again excepting the 100 (Trying)). Procedures for |
|
2777 the generation of tags are defined in Section 19.3. |
|
2778 |
|
2779 8.2.7 Stateless UAS Behavior |
|
2780 |
|
2781 A stateless UAS is a UAS that does not maintain transaction state. |
|
2782 It replies to requests normally, but discards any state that would |
|
2783 ordinarily be retained by a UAS after a response has been sent. If a |
|
2784 stateless UAS receives a retransmission of a request, it regenerates |
|
2785 the response and resends it, just as if it were replying to the first |
|
2786 instance of the request. A UAS cannot be stateless unless the request |
|
2787 processing for that method would always result in the same response |
|
2788 if the requests are identical. This rules out stateless registrars, |
|
2789 for example. Stateless UASs do not use a transaction layer; they |
|
2790 receive requests directly from the transport layer and send responses |
|
2791 directly to the transport layer. |
|
2792 |
|
2793 The stateless UAS role is needed primarily to handle unauthenticated |
|
2794 requests for which a challenge response is issued. If |
|
2795 unauthenticated requests were handled statefully, then malicious |
|
2796 floods of unauthenticated requests could create massive amounts of |
|
2797 |
|
2798 |
|
2799 |
|
2800 |
|
2801 |
|
2802 Rosenberg, et. al. Standards Track [Page 50] |
|
2803 |
|
2804 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2805 |
|
2806 |
|
2807 transaction state that might slow or completely halt call processing |
|
2808 in a UAS, effectively creating a denial of service condition; for |
|
2809 more information see Section 26.1.5. |
|
2810 |
|
2811 The most important behaviors of a stateless UAS are the following: |
|
2812 |
|
2813 o A stateless UAS MUST NOT send provisional (1xx) responses. |
|
2814 |
|
2815 o A stateless UAS MUST NOT retransmit responses. |
|
2816 |
|
2817 o A stateless UAS MUST ignore ACK requests. |
|
2818 |
|
2819 o A stateless UAS MUST ignore CANCEL requests. |
|
2820 |
|
2821 o To header tags MUST be generated for responses in a stateless |
|
2822 manner - in a manner that will generate the same tag for the |
|
2823 same request consistently. For information on tag construction |
|
2824 see Section 19.3. |
|
2825 |
|
2826 In all other respects, a stateless UAS behaves in the same manner as |
|
2827 a stateful UAS. A UAS can operate in either a stateful or stateless |
|
2828 mode for each new request. |
|
2829 |
|
2830 8.3 Redirect Servers |
|
2831 |
|
2832 In some architectures it may be desirable to reduce the processing |
|
2833 load on proxy servers that are responsible for routing requests, and |
|
2834 improve signaling path robustness, by relying on redirection. |
|
2835 |
|
2836 Redirection allows servers to push routing information for a request |
|
2837 back in a response to the client, thereby taking themselves out of |
|
2838 the loop of further messaging for this transaction while still aiding |
|
2839 in locating the target of the request. When the originator of the |
|
2840 request receives the redirection, it will send a new request based on |
|
2841 the URI(s) it has received. By propagating URIs from the core of the |
|
2842 network to its edges, redirection allows for considerable network |
|
2843 scalability. |
|
2844 |
|
2845 A redirect server is logically constituted of a server transaction |
|
2846 layer and a transaction user that has access to a location service of |
|
2847 some kind (see Section 10 for more on registrars and location |
|
2848 services). This location service is effectively a database |
|
2849 containing mappings between a single URI and a set of one or more |
|
2850 alternative locations at which the target of that URI can be found. |
|
2851 |
|
2852 A redirect server does not issue any SIP requests of its own. After |
|
2853 receiving a request other than CANCEL, the server either refuses the |
|
2854 request or gathers the list of alternative locations from the |
|
2855 |
|
2856 |
|
2857 |
|
2858 Rosenberg, et. al. Standards Track [Page 51] |
|
2859 |
|
2860 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2861 |
|
2862 |
|
2863 location service and returns a final response of class 3xx. For |
|
2864 well-formed CANCEL requests, it SHOULD return a 2xx response. This |
|
2865 response ends the SIP transaction. The redirect server maintains |
|
2866 transaction state for an entire SIP transaction. It is the |
|
2867 responsibility of clients to detect forwarding loops between redirect |
|
2868 servers. |
|
2869 |
|
2870 When a redirect server returns a 3xx response to a request, it |
|
2871 populates the list of (one or more) alternative locations into the |
|
2872 Contact header field. An "expires" parameter to the Contact header |
|
2873 field values may also be supplied to indicate the lifetime of the |
|
2874 Contact data. |
|
2875 |
|
2876 The Contact header field contains URIs giving the new locations or |
|
2877 user names to try, or may simply specify additional transport |
|
2878 parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) |
|
2879 response may also give the same location and username that was |
|
2880 targeted by the initial request but specify additional transport |
|
2881 parameters such as a different server or multicast address to try, or |
|
2882 a change of SIP transport from UDP to TCP or vice versa. |
|
2883 |
|
2884 However, redirect servers MUST NOT redirect a request to a URI equal |
|
2885 to the one in the Request-URI; instead, provided that the URI does |
|
2886 not point to itself, the server MAY proxy the request to the |
|
2887 destination URI, or MAY reject it with a 404. |
|
2888 |
|
2889 If a client is using an outbound proxy, and that proxy actually |
|
2890 redirects requests, a potential arises for infinite redirection |
|
2891 loops. |
|
2892 |
|
2893 Note that a Contact header field value MAY also refer to a different |
|
2894 resource than the one originally called. For example, a SIP call |
|
2895 connected to PSTN gateway may need to deliver a special informational |
|
2896 announcement such as "The number you have dialed has been changed." |
|
2897 |
|
2898 A Contact response header field can contain any suitable URI |
|
2899 indicating where the called party can be reached, not limited to SIP |
|
2900 URIs. For example, it could contain URIs for phones, fax, or irc (if |
|
2901 they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 |
|
2902 discusses implications and limitations of redirecting a SIPS URI to a |
|
2903 non-SIPS URI. |
|
2904 |
|
2905 The "expires" parameter of a Contact header field value indicates how |
|
2906 long the URI is valid. The value of the parameter is a number |
|
2907 indicating seconds. If this parameter is not provided, the value of |
|
2908 the Expires header field determines how long the URI is valid. |
|
2909 Malformed values SHOULD be treated as equivalent to 3600. |
|
2910 |
|
2911 |
|
2912 |
|
2913 |
|
2914 Rosenberg, et. al. Standards Track [Page 52] |
|
2915 |
|
2916 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2917 |
|
2918 |
|
2919 This provides a modest level of backwards compatibility with RFC |
|
2920 2543, which allowed absolute times in this header field. If an |
|
2921 absolute time is received, it will be treated as malformed, and |
|
2922 then default to 3600. |
|
2923 |
|
2924 Redirect servers MUST ignore features that are not understood |
|
2925 (including unrecognized header fields, any unknown option tags in |
|
2926 Require, or even method names) and proceed with the redirection of |
|
2927 the request in question. |
|
2928 |
|
2929 9 Canceling a Request |
|
2930 |
|
2931 The previous section has discussed general UA behavior for generating |
|
2932 requests and processing responses for requests of all methods. In |
|
2933 this section, we discuss a general purpose method, called CANCEL. |
|
2934 |
|
2935 The CANCEL request, as the name implies, is used to cancel a previous |
|
2936 request sent by a client. Specifically, it asks the UAS to cease |
|
2937 processing the request and to generate an error response to that |
|
2938 request. CANCEL has no effect on a request to which a UAS has |
|
2939 already given a final response. Because of this, it is most useful |
|
2940 to CANCEL requests to which it can take a server long time to |
|
2941 respond. For this reason, CANCEL is best for INVITE requests, which |
|
2942 can take a long time to generate a response. In that usage, a UAS |
|
2943 that receives a CANCEL request for an INVITE, but has not yet sent a |
|
2944 final response, would "stop ringing", and then respond to the INVITE |
|
2945 with a specific error response (a 487). |
|
2946 |
|
2947 CANCEL requests can be constructed and sent by both proxies and user |
|
2948 agent clients. Section 15 discusses under what conditions a UAC |
|
2949 would CANCEL an INVITE request, and Section 16.10 discusses proxy |
|
2950 usage of CANCEL. |
|
2951 |
|
2952 A stateful proxy responds to a CANCEL, rather than simply forwarding |
|
2953 a response it would receive from a downstream element. For that |
|
2954 reason, CANCEL is referred to as a "hop-by-hop" request, since it is |
|
2955 responded to at each stateful proxy hop. |
|
2956 |
|
2957 9.1 Client Behavior |
|
2958 |
|
2959 A CANCEL request SHOULD NOT be sent to cancel a request other than |
|
2960 INVITE. |
|
2961 |
|
2962 Since requests other than INVITE are responded to immediately, |
|
2963 sending a CANCEL for a non-INVITE request would always create a |
|
2964 race condition. |
|
2965 |
|
2966 |
|
2967 |
|
2968 |
|
2969 |
|
2970 Rosenberg, et. al. Standards Track [Page 53] |
|
2971 |
|
2972 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
2973 |
|
2974 |
|
2975 The following procedures are used to construct a CANCEL request. The |
|
2976 Request-URI, Call-ID, To, the numeric part of CSeq, and From header |
|
2977 fields in the CANCEL request MUST be identical to those in the |
|
2978 request being cancelled, including tags. A CANCEL constructed by a |
|
2979 client MUST have only a single Via header field value matching the |
|
2980 top Via value in the request being cancelled. Using the same values |
|
2981 for these header fields allows the CANCEL to be matched with the |
|
2982 request it cancels (Section 9.2 indicates how such matching occurs). |
|
2983 However, the method part of the CSeq header field MUST have a value |
|
2984 of CANCEL. This allows it to be identified and processed as a |
|
2985 transaction in its own right (See Section 17). |
|
2986 |
|
2987 If the request being cancelled contains a Route header field, the |
|
2988 CANCEL request MUST include that Route header field's values. |
|
2989 |
|
2990 This is needed so that stateless proxies are able to route CANCEL |
|
2991 requests properly. |
|
2992 |
|
2993 The CANCEL request MUST NOT contain any Require or Proxy-Require |
|
2994 header fields. |
|
2995 |
|
2996 Once the CANCEL is constructed, the client SHOULD check whether it |
|
2997 has received any response (provisional or final) for the request |
|
2998 being cancelled (herein referred to as the "original request"). |
|
2999 |
|
3000 If no provisional response has been received, the CANCEL request MUST |
|
3001 NOT be sent; rather, the client MUST wait for the arrival of a |
|
3002 provisional response before sending the request. If the original |
|
3003 request has generated a final response, the CANCEL SHOULD NOT be |
|
3004 sent, as it is an effective no-op, since CANCEL has no effect on |
|
3005 requests that have already generated a final response. When the |
|
3006 client decides to send the CANCEL, it creates a client transaction |
|
3007 for the CANCEL and passes it the CANCEL request along with the |
|
3008 destination address, port, and transport. The destination address, |
|
3009 port, and transport for the CANCEL MUST be identical to those used to |
|
3010 send the original request. |
|
3011 |
|
3012 If it was allowed to send the CANCEL before receiving a response |
|
3013 for the previous request, the server could receive the CANCEL |
|
3014 before the original request. |
|
3015 |
|
3016 Note that both the transaction corresponding to the original request |
|
3017 and the CANCEL transaction will complete independently. However, a |
|
3018 UAC canceling a request cannot rely on receiving a 487 (Request |
|
3019 Terminated) response for the original request, as an RFC 2543- |
|
3020 compliant UAS will not generate such a response. If there is no |
|
3021 final response for the original request in 64*T1 seconds (T1 is |
|
3022 |
|
3023 |
|
3024 |
|
3025 |
|
3026 Rosenberg, et. al. Standards Track [Page 54] |
|
3027 |
|
3028 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3029 |
|
3030 |
|
3031 defined in Section 17.1.1.1), the client SHOULD then consider the |
|
3032 original transaction cancelled and SHOULD destroy the client |
|
3033 transaction handling the original request. |
|
3034 |
|
3035 9.2 Server Behavior |
|
3036 |
|
3037 The CANCEL method requests that the TU at the server side cancel a |
|
3038 pending transaction. The TU determines the transaction to be |
|
3039 cancelled by taking the CANCEL request, and then assuming that the |
|
3040 request method is anything but CANCEL or ACK and applying the |
|
3041 transaction matching procedures of Section 17.2.3. The matching |
|
3042 transaction is the one to be cancelled. |
|
3043 |
|
3044 The processing of a CANCEL request at a server depends on the type of |
|
3045 server. A stateless proxy will forward it, a stateful proxy might |
|
3046 respond to it and generate some CANCEL requests of its own, and a UAS |
|
3047 will respond to it. See Section 16.10 for proxy treatment of CANCEL. |
|
3048 |
|
3049 A UAS first processes the CANCEL request according to the general UAS |
|
3050 processing described in Section 8.2. However, since CANCEL requests |
|
3051 are hop-by-hop and cannot be resubmitted, they cannot be challenged |
|
3052 by the server in order to get proper credentials in an Authorization |
|
3053 header field. Note also that CANCEL requests do not contain a |
|
3054 Require header field. |
|
3055 |
|
3056 If the UAS did not find a matching transaction for the CANCEL |
|
3057 according to the procedure above, it SHOULD respond to the CANCEL |
|
3058 with a 481 (Call Leg/Transaction Does Not Exist). If the transaction |
|
3059 for the original request still exists, the behavior of the UAS on |
|
3060 receiving a CANCEL request depends on whether it has already sent a |
|
3061 final response for the original request. If it has, the CANCEL |
|
3062 request has no effect on the processing of the original request, no |
|
3063 effect on any session state, and no effect on the responses generated |
|
3064 for the original request. If the UAS has not issued a final response |
|
3065 for the original request, its behavior depends on the method of the |
|
3066 original request. If the original request was an INVITE, the UAS |
|
3067 SHOULD immediately respond to the INVITE with a 487 (Request |
|
3068 Terminated). A CANCEL request has no impact on the processing of |
|
3069 transactions with any other method defined in this specification. |
|
3070 |
|
3071 Regardless of the method of the original request, as long as the |
|
3072 CANCEL matched an existing transaction, the UAS answers the CANCEL |
|
3073 request itself with a 200 (OK) response. This response is |
|
3074 constructed following the procedures described in Section 8.2.6 |
|
3075 noting that the To tag of the response to the CANCEL and the To tag |
|
3076 in the response to the original request SHOULD be the same. The |
|
3077 response to CANCEL is passed to the server transaction for |
|
3078 transmission. |
|
3079 |
|
3080 |
|
3081 |
|
3082 Rosenberg, et. al. Standards Track [Page 55] |
|
3083 |
|
3084 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3085 |
|
3086 |
|
3087 10 Registrations |
|
3088 |
|
3089 10.1 Overview |
|
3090 |
|
3091 SIP offers a discovery capability. If a user wants to initiate a |
|
3092 session with another user, SIP must discover the current host(s) at |
|
3093 which the destination user is reachable. This discovery process is |
|
3094 frequently accomplished by SIP network elements such as proxy servers |
|
3095 and redirect servers which are responsible for receiving a request, |
|
3096 determining where to send it based on knowledge of the location of |
|
3097 the user, and then sending it there. To do this, SIP network |
|
3098 elements consult an abstract service known as a location service, |
|
3099 which provides address bindings for a particular domain. These |
|
3100 address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, |
|
3101 for example, to one or more URIs that are somehow "closer" to the |
|
3102 desired user, sip:bob@engineering.biloxi.com, for example. |
|
3103 Ultimately, a proxy will consult a location service that maps a |
|
3104 received URI to the user agent(s) at which the desired recipient is |
|
3105 currently residing. |
|
3106 |
|
3107 Registration creates bindings in a location service for a particular |
|
3108 domain that associates an address-of-record URI with one or more |
|
3109 contact addresses. Thus, when a proxy for that domain receives a |
|
3110 request whose Request-URI matches the address-of-record, the proxy |
|
3111 will forward the request to the contact addresses registered to that |
|
3112 address-of-record. Generally, it only makes sense to register an |
|
3113 address-of-record at a domain's location service when requests for |
|
3114 that address-of-record would be routed to that domain. In most |
|
3115 cases, this means that the domain of the registration will need to |
|
3116 match the domain in the URI of the address-of-record. |
|
3117 |
|
3118 There are many ways by which the contents of the location service can |
|
3119 be established. One way is administratively. In the above example, |
|
3120 Bob is known to be a member of the engineering department through |
|
3121 access to a corporate database. However, SIP provides a mechanism |
|
3122 for a UA to create a binding explicitly. This mechanism is known as |
|
3123 registration. |
|
3124 |
|
3125 Registration entails sending a REGISTER request to a special type of |
|
3126 UAS known as a registrar. A registrar acts as the front end to the |
|
3127 location service for a domain, reading and writing mappings based on |
|
3128 the contents of REGISTER requests. This location service is then |
|
3129 typically consulted by a proxy server that is responsible for routing |
|
3130 requests for that domain. |
|
3131 |
|
3132 An illustration of the overall registration process is given in |
|
3133 Figure 2. Note that the registrar and proxy server are logical roles |
|
3134 that can be played by a single device in a network; for purposes of |
|
3135 |
|
3136 |
|
3137 |
|
3138 Rosenberg, et. al. Standards Track [Page 56] |
|
3139 |
|
3140 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3141 |
|
3142 |
|
3143 clarity the two are separated in this illustration. Also note that |
|
3144 UAs may send requests through a proxy server in order to reach a |
|
3145 registrar if the two are separate elements. |
|
3146 |
|
3147 SIP does not mandate a particular mechanism for implementing the |
|
3148 location service. The only requirement is that a registrar for some |
|
3149 domain MUST be able to read and write data to the location service, |
|
3150 and a proxy or a redirect server for that domain MUST be capable of |
|
3151 reading that same data. A registrar MAY be co-located with a |
|
3152 particular SIP proxy server for the same domain. |
|
3153 |
|
3154 10.2 Constructing the REGISTER Request |
|
3155 |
|
3156 REGISTER requests add, remove, and query bindings. A REGISTER |
|
3157 request can add a new binding between an address-of-record and one or |
|
3158 more contact addresses. Registration on behalf of a particular |
|
3159 address-of-record can be performed by a suitably authorized third |
|
3160 party. A client can also remove previous bindings or query to |
|
3161 determine which bindings are currently in place for an address-of- |
|
3162 record. |
|
3163 |
|
3164 Except as noted, the construction of the REGISTER request and the |
|
3165 behavior of clients sending a REGISTER request is identical to the |
|
3166 general UAC behavior described in Section 8.1 and Section 17.1. |
|
3167 |
|
3168 A REGISTER request does not establish a dialog. A UAC MAY include a |
|
3169 Route header field in a REGISTER request based on a pre-existing |
|
3170 route set as described in Section 8.1. The Record-Route header field |
|
3171 has no meaning in REGISTER requests or responses, and MUST be ignored |
|
3172 if present. In particular, the UAC MUST NOT create a new route set |
|
3173 based on the presence or absence of a Record-Route header field in |
|
3174 any response to a REGISTER request. |
|
3175 |
|
3176 The following header fields, except Contact, MUST be included in a |
|
3177 REGISTER request. A Contact header field MAY be included: |
|
3178 |
|
3179 Request-URI: The Request-URI names the domain of the location |
|
3180 service for which the registration is meant (for example, |
|
3181 "sip:chicago.com"). The "userinfo" and "@" components of the |
|
3182 SIP URI MUST NOT be present. |
|
3183 |
|
3184 To: The To header field contains the address of record whose |
|
3185 registration is to be created, queried, or modified. The To |
|
3186 header field and the Request-URI field typically differ, as |
|
3187 the former contains a user name. This address-of-record MUST |
|
3188 be a SIP URI or SIPS URI. |
|
3189 |
|
3190 |
|
3191 |
|
3192 |
|
3193 |
|
3194 Rosenberg, et. al. Standards Track [Page 57] |
|
3195 |
|
3196 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3197 |
|
3198 |
|
3199 From: The From header field contains the address-of-record of the |
|
3200 person responsible for the registration. The value is the |
|
3201 same as the To header field unless the request is a third- |
|
3202 party registration. |
|
3203 |
|
3204 Call-ID: All registrations from a UAC SHOULD use the same Call-ID |
|
3205 header field value for registrations sent to a particular |
|
3206 registrar. |
|
3207 |
|
3208 If the same client were to use different Call-ID values, a |
|
3209 registrar could not detect whether a delayed REGISTER request |
|
3210 might have arrived out of order. |
|
3211 |
|
3212 CSeq: The CSeq value guarantees proper ordering of REGISTER |
|
3213 requests. A UA MUST increment the CSeq value by one for each |
|
3214 REGISTER request with the same Call-ID. |
|
3215 |
|
3216 Contact: REGISTER requests MAY contain a Contact header field with |
|
3217 zero or more values containing address bindings. |
|
3218 |
|
3219 UAs MUST NOT send a new registration (that is, containing new Contact |
|
3220 header field values, as opposed to a retransmission) until they have |
|
3221 received a final response from the registrar for the previous one or |
|
3222 the previous REGISTER request has timed out. |
|
3223 |
|
3224 |
|
3225 |
|
3226 |
|
3227 |
|
3228 |
|
3229 |
|
3230 |
|
3231 |
|
3232 |
|
3233 |
|
3234 |
|
3235 |
|
3236 |
|
3237 |
|
3238 |
|
3239 |
|
3240 |
|
3241 |
|
3242 |
|
3243 |
|
3244 |
|
3245 |
|
3246 |
|
3247 |
|
3248 |
|
3249 |
|
3250 Rosenberg, et. al. Standards Track [Page 58] |
|
3251 |
|
3252 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3253 |
|
3254 |
|
3255 bob |
|
3256 +----+ |
|
3257 | UA | |
|
3258 | | |
|
3259 +----+ |
|
3260 | |
|
3261 |3)INVITE |
|
3262 | carol@chicago.com |
|
3263 chicago.com +--------+ V |
|
3264 +---------+ 2)Store|Location|4)Query +-----+ |
|
3265 |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com |
|
3266 +---------+ +--------+=======>+-----+ |
|
3267 A 5)Resp | |
|
3268 | | |
|
3269 | | |
|
3270 1)REGISTER| | |
|
3271 | | |
|
3272 +----+ | |
|
3273 | UA |<-------------------------------+ |
|
3274 cube2214a| | 6)INVITE |
|
3275 +----+ carol@cube2214a.chicago.com |
|
3276 carol |
|
3277 |
|
3278 Figure 2: REGISTER example |
|
3279 |
|
3280 The following Contact header parameters have a special meaning in |
|
3281 REGISTER requests: |
|
3282 |
|
3283 action: The "action" parameter from RFC 2543 has been deprecated. |
|
3284 UACs SHOULD NOT use the "action" parameter. |
|
3285 |
|
3286 expires: The "expires" parameter indicates how long the UA would |
|
3287 like the binding to be valid. The value is a number |
|
3288 indicating seconds. If this parameter is not provided, the |
|
3289 value of the Expires header field is used instead. |
|
3290 Implementations MAY treat values larger than 2**32-1 |
|
3291 (4294967295 seconds or 136 years) as equivalent to 2**32-1. |
|
3292 Malformed values SHOULD be treated as equivalent to 3600. |
|
3293 |
|
3294 10.2.1 Adding Bindings |
|
3295 |
|
3296 The REGISTER request sent to a registrar includes the contact |
|
3297 address(es) to which SIP requests for the address-of-record should be |
|
3298 forwarded. The address-of-record is included in the To header field |
|
3299 of the REGISTER request. |
|
3300 |
|
3301 |
|
3302 |
|
3303 |
|
3304 |
|
3305 |
|
3306 Rosenberg, et. al. Standards Track [Page 59] |
|
3307 |
|
3308 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3309 |
|
3310 |
|
3311 The Contact header field values of the request typically consist of |
|
3312 SIP or SIPS URIs that identify particular SIP endpoints (for example, |
|
3313 "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme. |
|
3314 A SIP UA can choose to register telephone numbers (with the tel URL, |
|
3315 RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) |
|
3316 as Contacts for an address-of-record, for example. |
|
3317 |
|
3318 For example, Carol, with address-of-record "sip:carol@chicago.com", |
|
3319 would register with the SIP registrar of the domain chicago.com. Her |
|
3320 registrations would then be used by a proxy server in the chicago.com |
|
3321 domain to route requests for Carol's address-of-record to her SIP |
|
3322 endpoint. |
|
3323 |
|
3324 Once a client has established bindings at a registrar, it MAY send |
|
3325 subsequent registrations containing new bindings or modifications to |
|
3326 existing bindings as necessary. The 2xx response to the REGISTER |
|
3327 request will contain, in a Contact header field, a complete list of |
|
3328 bindings that have been registered for this address-of-record at this |
|
3329 registrar. |
|
3330 |
|
3331 If the address-of-record in the To header field of a REGISTER request |
|
3332 is a SIPS URI, then any Contact header field values in the request |
|
3333 SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs |
|
3334 under a SIPS address-of-record when the security of the resource |
|
3335 represented by the contact address is guaranteed by other means. |
|
3336 This may be applicable to URIs that invoke protocols other than SIP, |
|
3337 or SIP devices secured by protocols other than TLS. |
|
3338 |
|
3339 Registrations do not need to update all bindings. Typically, a UA |
|
3340 only updates its own contact addresses. |
|
3341 |
|
3342 10.2.1.1 Setting the Expiration Interval of Contact Addresses |
|
3343 |
|
3344 When a client sends a REGISTER request, it MAY suggest an expiration |
|
3345 interval that indicates how long the client would like the |
|
3346 registration to be valid. (As described in Section 10.3, the |
|
3347 registrar selects the actual time interval based on its local |
|
3348 policy.) |
|
3349 |
|
3350 There are two ways in which a client can suggest an expiration |
|
3351 interval for a binding: through an Expires header field or an |
|
3352 "expires" Contact header parameter. The latter allows expiration |
|
3353 intervals to be suggested on a per-binding basis when more than one |
|
3354 binding is given in a single REGISTER request, whereas the former |
|
3355 suggests an expiration interval for all Contact header field values |
|
3356 that do not contain the "expires" parameter. |
|
3357 |
|
3358 |
|
3359 |
|
3360 |
|
3361 |
|
3362 Rosenberg, et. al. Standards Track [Page 60] |
|
3363 |
|
3364 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3365 |
|
3366 |
|
3367 If neither mechanism for expressing a suggested expiration time is |
|
3368 present in a REGISTER, the client is indicating its desire for the |
|
3369 server to choose. |
|
3370 |
|
3371 10.2.1.2 Preferences among Contact Addresses |
|
3372 |
|
3373 If more than one Contact is sent in a REGISTER request, the |
|
3374 registering UA intends to associate all of the URIs in these Contact |
|
3375 header field values with the address-of-record present in the To |
|
3376 field. This list can be prioritized with the "q" parameter in the |
|
3377 Contact header field. The "q" parameter indicates a relative |
|
3378 preference for the particular Contact header field value compared to |
|
3379 other bindings for this address-of-record. Section 16.6 describes |
|
3380 how a proxy server uses this preference indication. |
|
3381 |
|
3382 10.2.2 Removing Bindings |
|
3383 |
|
3384 Registrations are soft state and expire unless refreshed, but can |
|
3385 also be explicitly removed. A client can attempt to influence the |
|
3386 expiration interval selected by the registrar as described in Section |
|
3387 10.2.1. A UA requests the immediate removal of a binding by |
|
3388 specifying an expiration interval of "0" for that contact address in |
|
3389 a REGISTER request. UAs SHOULD support this mechanism so that |
|
3390 bindings can be removed before their expiration interval has passed. |
|
3391 |
|
3392 The REGISTER-specific Contact header field value of "*" applies to |
|
3393 all registrations, but it MUST NOT be used unless the Expires header |
|
3394 field is present with a value of "0". |
|
3395 |
|
3396 Use of the "*" Contact header field value allows a registering UA |
|
3397 to remove all bindings associated with an address-of-record |
|
3398 without knowing their precise values. |
|
3399 |
|
3400 10.2.3 Fetching Bindings |
|
3401 |
|
3402 A success response to any REGISTER request contains the complete list |
|
3403 of existing bindings, regardless of whether the request contained a |
|
3404 Contact header field. If no Contact header field is present in a |
|
3405 REGISTER request, the list of bindings is left unchanged. |
|
3406 |
|
3407 10.2.4 Refreshing Bindings |
|
3408 |
|
3409 Each UA is responsible for refreshing the bindings that it has |
|
3410 previously established. A UA SHOULD NOT refresh bindings set up by |
|
3411 other UAs. |
|
3412 |
|
3413 |
|
3414 |
|
3415 |
|
3416 |
|
3417 |
|
3418 Rosenberg, et. al. Standards Track [Page 61] |
|
3419 |
|
3420 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3421 |
|
3422 |
|
3423 The 200 (OK) response from the registrar contains a list of Contact |
|
3424 fields enumerating all current bindings. The UA compares each |
|
3425 contact address to see if it created the contact address, using |
|
3426 comparison rules in Section 19.1.4. If so, it updates the expiration |
|
3427 time interval according to the expires parameter or, if absent, the |
|
3428 Expires field value. The UA then issues a REGISTER request for each |
|
3429 of its bindings before the expiration interval has elapsed. It MAY |
|
3430 combine several updates into one REGISTER request. |
|
3431 |
|
3432 A UA SHOULD use the same Call-ID for all registrations during a |
|
3433 single boot cycle. Registration refreshes SHOULD be sent to the same |
|
3434 network address as the original registration, unless redirected. |
|
3435 |
|
3436 10.2.5 Setting the Internal Clock |
|
3437 |
|
3438 If the response for a REGISTER request contains a Date header field, |
|
3439 the client MAY use this header field to learn the current time in |
|
3440 order to set any internal clocks. |
|
3441 |
|
3442 10.2.6 Discovering a Registrar |
|
3443 |
|
3444 UAs can use three ways to determine the address to which to send |
|
3445 registrations: by configuration, using the address-of-record, and |
|
3446 multicast. A UA can be configured, in ways beyond the scope of this |
|
3447 specification, with a registrar address. If there is no configured |
|
3448 registrar address, the UA SHOULD use the host part of the address- |
|
3449 of-record as the Request-URI and address the request there, using the |
|
3450 normal SIP server location mechanisms [4]. For example, the UA for |
|
3451 the user "sip:carol@chicago.com" addresses the REGISTER request to |
|
3452 "sip:chicago.com". |
|
3453 |
|
3454 Finally, a UA can be configured to use multicast. Multicast |
|
3455 registrations are addressed to the well-known "all SIP servers" |
|
3456 multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well- |
|
3457 known IPv6 multicast address has been allocated; such an allocation |
|
3458 will be documented separately when needed. SIP UAs MAY listen to |
|
3459 that address and use it to become aware of the location of other |
|
3460 local users (see [33]); however, they do not respond to the request. |
|
3461 |
|
3462 Multicast registration may be inappropriate in some environments, |
|
3463 for example, if multiple businesses share the same local area |
|
3464 network. |
|
3465 |
|
3466 10.2.7 Transmitting a Request |
|
3467 |
|
3468 Once the REGISTER method has been constructed, and the destination of |
|
3469 the message identified, UACs follow the procedures described in |
|
3470 Section 8.1.2 to hand off the REGISTER to the transaction layer. |
|
3471 |
|
3472 |
|
3473 |
|
3474 Rosenberg, et. al. Standards Track [Page 62] |
|
3475 |
|
3476 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3477 |
|
3478 |
|
3479 If the transaction layer returns a timeout error because the REGISTER |
|
3480 yielded no response, the UAC SHOULD NOT immediately re-attempt a |
|
3481 registration to the same registrar. |
|
3482 |
|
3483 An immediate re-attempt is likely to also timeout. Waiting some |
|
3484 reasonable time interval for the conditions causing the timeout to |
|
3485 be corrected reduces unnecessary load on the network. No specific |
|
3486 interval is mandated. |
|
3487 |
|
3488 10.2.8 Error Responses |
|
3489 |
|
3490 If a UA receives a 423 (Interval Too Brief) response, it MAY retry |
|
3491 the registration after making the expiration interval of all contact |
|
3492 addresses in the REGISTER request equal to or greater than the |
|
3493 expiration interval within the Min-Expires header field of the 423 |
|
3494 (Interval Too Brief) response. |
|
3495 |
|
3496 10.3 Processing REGISTER Requests |
|
3497 |
|
3498 A registrar is a UAS that responds to REGISTER requests and maintains |
|
3499 a list of bindings that are accessible to proxy servers and redirect |
|
3500 servers within its administrative domain. A registrar handles |
|
3501 requests according to Section 8.2 and Section 17.2, but it accepts |
|
3502 only REGISTER requests. A registrar MUST not generate 6xx responses. |
|
3503 |
|
3504 A registrar MAY redirect REGISTER requests as appropriate. One |
|
3505 common usage would be for a registrar listening on a multicast |
|
3506 interface to redirect multicast REGISTER requests to its own unicast |
|
3507 interface with a 302 (Moved Temporarily) response. |
|
3508 |
|
3509 Registrars MUST ignore the Record-Route header field if it is |
|
3510 included in a REGISTER request. Registrars MUST NOT include a |
|
3511 Record-Route header field in any response to a REGISTER request. |
|
3512 |
|
3513 A registrar might receive a request that traversed a proxy which |
|
3514 treats REGISTER as an unknown request and which added a Record- |
|
3515 Route header field value. |
|
3516 |
|
3517 A registrar has to know (for example, through configuration) the set |
|
3518 of domain(s) for which it maintains bindings. REGISTER requests MUST |
|
3519 be processed by a registrar in the order that they are received. |
|
3520 REGISTER requests MUST also be processed atomically, meaning that a |
|
3521 particular REGISTER request is either processed completely or not at |
|
3522 all. Each REGISTER message MUST be processed independently of any |
|
3523 other registration or binding changes. |
|
3524 |
|
3525 |
|
3526 |
|
3527 |
|
3528 |
|
3529 |
|
3530 Rosenberg, et. al. Standards Track [Page 63] |
|
3531 |
|
3532 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3533 |
|
3534 |
|
3535 When receiving a REGISTER request, a registrar follows these steps: |
|
3536 |
|
3537 1. The registrar inspects the Request-URI to determine whether it |
|
3538 has access to bindings for the domain identified in the |
|
3539 Request-URI. If not, and if the server also acts as a proxy |
|
3540 server, the server SHOULD forward the request to the addressed |
|
3541 domain, following the general behavior for proxying messages |
|
3542 described in Section 16. |
|
3543 |
|
3544 2. To guarantee that the registrar supports any necessary |
|
3545 extensions, the registrar MUST process the Require header field |
|
3546 values as described for UASs in Section 8.2.2. |
|
3547 |
|
3548 3. A registrar SHOULD authenticate the UAC. Mechanisms for the |
|
3549 authentication of SIP user agents are described in Section 22. |
|
3550 Registration behavior in no way overrides the generic |
|
3551 authentication framework for SIP. If no authentication |
|
3552 mechanism is available, the registrar MAY take the From address |
|
3553 as the asserted identity of the originator of the request. |
|
3554 |
|
3555 4. The registrar SHOULD determine if the authenticated user is |
|
3556 authorized to modify registrations for this address-of-record. |
|
3557 For example, a registrar might consult an authorization |
|
3558 database that maps user names to a list of addresses-of-record |
|
3559 for which that user has authorization to modify bindings. If |
|
3560 the authenticated user is not authorized to modify bindings, |
|
3561 the registrar MUST return a 403 (Forbidden) and skip the |
|
3562 remaining steps. |
|
3563 |
|
3564 In architectures that support third-party registration, one |
|
3565 entity may be responsible for updating the registrations |
|
3566 associated with multiple addresses-of-record. |
|
3567 |
|
3568 5. The registrar extracts the address-of-record from the To header |
|
3569 field of the request. If the address-of-record is not valid |
|
3570 for the domain in the Request-URI, the registrar MUST send a |
|
3571 404 (Not Found) response and skip the remaining steps. The URI |
|
3572 MUST then be converted to a canonical form. To do that, all |
|
3573 URI parameters MUST be removed (including the user-param), and |
|
3574 any escaped characters MUST be converted to their unescaped |
|
3575 form. The result serves as an index into the list of bindings. |
|
3576 |
|
3577 |
|
3578 |
|
3579 |
|
3580 |
|
3581 |
|
3582 |
|
3583 |
|
3584 |
|
3585 |
|
3586 Rosenberg, et. al. Standards Track [Page 64] |
|
3587 |
|
3588 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3589 |
|
3590 |
|
3591 6. The registrar checks whether the request contains the Contact |
|
3592 header field. If not, it skips to the last step. If the |
|
3593 Contact header field is present, the registrar checks if there |
|
3594 is one Contact field value that contains the special value "*" |
|
3595 and an Expires field. If the request has additional Contact |
|
3596 fields or an expiration time other than zero, the request is |
|
3597 invalid, and the server MUST return a 400 (Invalid Request) and |
|
3598 skip the remaining steps. If not, the registrar checks whether |
|
3599 the Call-ID agrees with the value stored for each binding. If |
|
3600 not, it MUST remove the binding. If it does agree, it MUST |
|
3601 remove the binding only if the CSeq in the request is higher |
|
3602 than the value stored for that binding. Otherwise, the update |
|
3603 MUST be aborted and the request fails. |
|
3604 |
|
3605 7. The registrar now processes each contact address in the Contact |
|
3606 header field in turn. For each address, it determines the |
|
3607 expiration interval as follows: |
|
3608 |
|
3609 - If the field value has an "expires" parameter, that value |
|
3610 MUST be taken as the requested expiration. |
|
3611 |
|
3612 - If there is no such parameter, but the request has an |
|
3613 Expires header field, that value MUST be taken as the |
|
3614 requested expiration. |
|
3615 |
|
3616 - If there is neither, a locally-configured default value MUST |
|
3617 be taken as the requested expiration. |
|
3618 |
|
3619 The registrar MAY choose an expiration less than the requested |
|
3620 expiration interval. If and only if the requested expiration |
|
3621 interval is greater than zero AND smaller than one hour AND |
|
3622 less than a registrar-configured minimum, the registrar MAY |
|
3623 reject the registration with a response of 423 (Interval Too |
|
3624 Brief). This response MUST contain a Min-Expires header field |
|
3625 that states the minimum expiration interval the registrar is |
|
3626 willing to honor. It then skips the remaining steps. |
|
3627 |
|
3628 Allowing the registrar to set the registration interval |
|
3629 protects it against excessively frequent registration refreshes |
|
3630 while limiting the state that it needs to maintain and |
|
3631 decreasing the likelihood of registrations going stale. The |
|
3632 expiration interval of a registration is frequently used in the |
|
3633 creation of services. An example is a follow-me service, where |
|
3634 the user may only be available at a terminal for a brief |
|
3635 period. Therefore, registrars should accept brief |
|
3636 registrations; a request should only be rejected if the |
|
3637 interval is so short that the refreshes would degrade registrar |
|
3638 performance. |
|
3639 |
|
3640 |
|
3641 |
|
3642 Rosenberg, et. al. Standards Track [Page 65] |
|
3643 |
|
3644 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3645 |
|
3646 |
|
3647 For each address, the registrar then searches the list of |
|
3648 current bindings using the URI comparison rules. If the |
|
3649 binding does not exist, it is tentatively added. If the |
|
3650 binding does exist, the registrar checks the Call-ID value. If |
|
3651 the Call-ID value in the existing binding differs from the |
|
3652 Call-ID value in the request, the binding MUST be removed if |
|
3653 the expiration time is zero and updated otherwise. If they are |
|
3654 the same, the registrar compares the CSeq value. If the value |
|
3655 is higher than that of the existing binding, it MUST update or |
|
3656 remove the binding as above. If not, the update MUST be |
|
3657 aborted and the request fails. |
|
3658 |
|
3659 This algorithm ensures that out-of-order requests from the same |
|
3660 UA are ignored. |
|
3661 |
|
3662 Each binding record records the Call-ID and CSeq values from |
|
3663 the request. |
|
3664 |
|
3665 The binding updates MUST be committed (that is, made visible to |
|
3666 the proxy or redirect server) if and only if all binding |
|
3667 updates and additions succeed. If any one of them fails (for |
|
3668 example, because the back-end database commit failed), the |
|
3669 request MUST fail with a 500 (Server Error) response and all |
|
3670 tentative binding updates MUST be removed. |
|
3671 |
|
3672 8. The registrar returns a 200 (OK) response. The response MUST |
|
3673 contain Contact header field values enumerating all current |
|
3674 bindings. Each Contact value MUST feature an "expires" |
|
3675 parameter indicating its expiration interval chosen by the |
|
3676 registrar. The response SHOULD include a Date header field. |
|
3677 |
|
3678 11 Querying for Capabilities |
|
3679 |
|
3680 The SIP method OPTIONS allows a UA to query another UA or a proxy |
|
3681 server as to its capabilities. This allows a client to discover |
|
3682 information about the supported methods, content types, extensions, |
|
3683 codecs, etc. without "ringing" the other party. For example, before |
|
3684 a client inserts a Require header field into an INVITE listing an |
|
3685 option that it is not certain the destination UAS supports, the |
|
3686 client can query the destination UAS with an OPTIONS to see if this |
|
3687 option is returned in a Supported header field. All UAs MUST support |
|
3688 the OPTIONS method. |
|
3689 |
|
3690 The target of the OPTIONS request is identified by the Request-URI, |
|
3691 which could identify another UA or a SIP server. If the OPTIONS is |
|
3692 addressed to a proxy server, the Request-URI is set without a user |
|
3693 part, similar to the way a Request-URI is set for a REGISTER request. |
|
3694 |
|
3695 |
|
3696 |
|
3697 |
|
3698 Rosenberg, et. al. Standards Track [Page 66] |
|
3699 |
|
3700 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3701 |
|
3702 |
|
3703 Alternatively, a server receiving an OPTIONS request with a Max- |
|
3704 Forwards header field value of 0 MAY respond to the request |
|
3705 regardless of the Request-URI. |
|
3706 |
|
3707 This behavior is common with HTTP/1.1. This behavior can be used |
|
3708 as a "traceroute" functionality to check the capabilities of |
|
3709 individual hop servers by sending a series of OPTIONS requests |
|
3710 with incremented Max-Forwards values. |
|
3711 |
|
3712 As is the case for general UA behavior, the transaction layer can |
|
3713 return a timeout error if the OPTIONS yields no response. This may |
|
3714 indicate that the target is unreachable and hence unavailable. |
|
3715 |
|
3716 An OPTIONS request MAY be sent as part of an established dialog to |
|
3717 query the peer on capabilities that may be utilized later in the |
|
3718 dialog. |
|
3719 |
|
3720 11.1 Construction of OPTIONS Request |
|
3721 |
|
3722 An OPTIONS request is constructed using the standard rules for a SIP |
|
3723 request as discussed in Section 8.1.1. |
|
3724 |
|
3725 A Contact header field MAY be present in an OPTIONS. |
|
3726 |
|
3727 An Accept header field SHOULD be included to indicate the type of |
|
3728 message body the UAC wishes to receive in the response. Typically, |
|
3729 this is set to a format that is used to describe the media |
|
3730 capabilities of a UA, such as SDP (application/sdp). |
|
3731 |
|
3732 The response to an OPTIONS request is assumed to be scoped to the |
|
3733 Request-URI in the original request. However, only when an OPTIONS |
|
3734 is sent as part of an established dialog is it guaranteed that future |
|
3735 requests will be received by the server that generated the OPTIONS |
|
3736 response. |
|
3737 |
|
3738 Example OPTIONS request: |
|
3739 |
|
3740 OPTIONS sip:carol@chicago.com SIP/2.0 |
|
3741 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 |
|
3742 Max-Forwards: 70 |
|
3743 To: <sip:carol@chicago.com> |
|
3744 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
3745 Call-ID: a84b4c76e66710 |
|
3746 CSeq: 63104 OPTIONS |
|
3747 Contact: <sip:alice@pc33.atlanta.com> |
|
3748 Accept: application/sdp |
|
3749 Content-Length: 0 |
|
3750 |
|
3751 |
|
3752 |
|
3753 |
|
3754 Rosenberg, et. al. Standards Track [Page 67] |
|
3755 |
|
3756 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3757 |
|
3758 |
|
3759 11.2 Processing of OPTIONS Request |
|
3760 |
|
3761 The response to an OPTIONS is constructed using the standard rules |
|
3762 for a SIP response as discussed in Section 8.2.6. The response code |
|
3763 chosen MUST be the same that would have been chosen had the request |
|
3764 been an INVITE. That is, a 200 (OK) would be returned if the UAS is |
|
3765 ready to accept a call, a 486 (Busy Here) would be returned if the |
|
3766 UAS is busy, etc. This allows an OPTIONS request to be used to |
|
3767 determine the basic state of a UAS, which can be an indication of |
|
3768 whether the UAS will accept an INVITE request. |
|
3769 |
|
3770 An OPTIONS request received within a dialog generates a 200 (OK) |
|
3771 response that is identical to one constructed outside a dialog and |
|
3772 does not have any impact on the dialog. |
|
3773 |
|
3774 This use of OPTIONS has limitations due to the differences in proxy |
|
3775 handling of OPTIONS and INVITE requests. While a forked INVITE can |
|
3776 result in multiple 200 (OK) responses being returned, a forked |
|
3777 OPTIONS will only result in a single 200 (OK) response, since it is |
|
3778 treated by proxies using the non-INVITE handling. See Section 16.7 |
|
3779 for the normative details. |
|
3780 |
|
3781 If the response to an OPTIONS is generated by a proxy server, the |
|
3782 proxy returns a 200 (OK), listing the capabilities of the server. |
|
3783 The response does not contain a message body. |
|
3784 |
|
3785 Allow, Accept, Accept-Encoding, Accept-Language, and Supported header |
|
3786 fields SHOULD be present in a 200 (OK) response to an OPTIONS |
|
3787 request. If the response is generated by a proxy, the Allow header |
|
3788 field SHOULD be omitted as it is ambiguous since a proxy is method |
|
3789 agnostic. Contact header fields MAY be present in a 200 (OK) |
|
3790 response and have the same semantics as in a 3xx response. That is, |
|
3791 they may list a set of alternative names and methods of reaching the |
|
3792 user. A Warning header field MAY be present. |
|
3793 |
|
3794 A message body MAY be sent, the type of which is determined by the |
|
3795 Accept header field in the OPTIONS request (application/sdp is the |
|
3796 default if the Accept header field is not present). If the types |
|
3797 include one that can describe media capabilities, the UAS SHOULD |
|
3798 include a body in the response for that purpose. Details on the |
|
3799 construction of such a body in the case of application/sdp are |
|
3800 described in [13]. |
|
3801 |
|
3802 |
|
3803 |
|
3804 |
|
3805 |
|
3806 |
|
3807 |
|
3808 |
|
3809 |
|
3810 Rosenberg, et. al. Standards Track [Page 68] |
|
3811 |
|
3812 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3813 |
|
3814 |
|
3815 Example OPTIONS response generated by a UAS (corresponding to the |
|
3816 request in Section 11.1): |
|
3817 |
|
3818 SIP/2.0 200 OK |
|
3819 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 |
|
3820 ;received=192.0.2.4 |
|
3821 To: <sip:carol@chicago.com>;tag=93810874 |
|
3822 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
3823 Call-ID: a84b4c76e66710 |
|
3824 CSeq: 63104 OPTIONS |
|
3825 Contact: <sip:carol@chicago.com> |
|
3826 Contact: <mailto:carol@chicago.com> |
|
3827 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE |
|
3828 Accept: application/sdp |
|
3829 Accept-Encoding: gzip |
|
3830 Accept-Language: en |
|
3831 Supported: foo |
|
3832 Content-Type: application/sdp |
|
3833 Content-Length: 274 |
|
3834 |
|
3835 (SDP not shown) |
|
3836 |
|
3837 12 Dialogs |
|
3838 |
|
3839 A key concept for a user agent is that of a dialog. A dialog |
|
3840 represents a peer-to-peer SIP relationship between two user agents |
|
3841 that persists for some time. The dialog facilitates sequencing of |
|
3842 messages between the user agents and proper routing of requests |
|
3843 between both of them. The dialog represents a context in which to |
|
3844 interpret SIP messages. Section 8 discussed method independent UA |
|
3845 processing for requests and responses outside of a dialog. This |
|
3846 section discusses how those requests and responses are used to |
|
3847 construct a dialog, and then how subsequent requests and responses |
|
3848 are sent within a dialog. |
|
3849 |
|
3850 A dialog is identified at each UA with a dialog ID, which consists of |
|
3851 a Call-ID value, a local tag and a remote tag. The dialog ID at each |
|
3852 UA involved in the dialog is not the same. Specifically, the local |
|
3853 tag at one UA is identical to the remote tag at the peer UA. The |
|
3854 tags are opaque tokens that facilitate the generation of unique |
|
3855 dialog IDs. |
|
3856 |
|
3857 A dialog ID is also associated with all responses and with any |
|
3858 request that contains a tag in the To field. The rules for computing |
|
3859 the dialog ID of a message depend on whether the SIP element is a UAC |
|
3860 or UAS. For a UAC, the Call-ID value of the dialog ID is set to the |
|
3861 Call-ID of the message, the remote tag is set to the tag in the To |
|
3862 field of the message, and the local tag is set to the tag in the From |
|
3863 |
|
3864 |
|
3865 |
|
3866 Rosenberg, et. al. Standards Track [Page 69] |
|
3867 |
|
3868 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3869 |
|
3870 |
|
3871 field of the message (these rules apply to both requests and |
|
3872 responses). As one would expect for a UAS, the Call-ID value of the |
|
3873 dialog ID is set to the Call-ID of the message, the remote tag is set |
|
3874 to the tag in the From field of the message, and the local tag is set |
|
3875 to the tag in the To field of the message. |
|
3876 |
|
3877 A dialog contains certain pieces of state needed for further message |
|
3878 transmissions within the dialog. This state consists of the dialog |
|
3879 ID, a local sequence number (used to order requests from the UA to |
|
3880 its peer), a remote sequence number (used to order requests from its |
|
3881 peer to the UA), a local URI, a remote URI, remote target, a boolean |
|
3882 flag called "secure", and a route set, which is an ordered list of |
|
3883 URIs. The route set is the list of servers that need to be traversed |
|
3884 to send a request to the peer. A dialog can also be in the "early" |
|
3885 state, which occurs when it is created with a provisional response, |
|
3886 and then transition to the "confirmed" state when a 2xx final |
|
3887 response arrives. For other responses, or if no response arrives at |
|
3888 all on that dialog, the early dialog terminates. |
|
3889 |
|
3890 12.1 Creation of a Dialog |
|
3891 |
|
3892 Dialogs are created through the generation of non-failure responses |
|
3893 to requests with specific methods. Within this specification, only |
|
3894 2xx and 101-199 responses with a To tag, where the request was |
|
3895 INVITE, will establish a dialog. A dialog established by a non-final |
|
3896 response to a request is in the "early" state and it is called an |
|
3897 early dialog. Extensions MAY define other means for creating |
|
3898 dialogs. Section 13 gives more details that are specific to the |
|
3899 INVITE method. Here, we describe the process for creation of dialog |
|
3900 state that is not dependent on the method. |
|
3901 |
|
3902 UAs MUST assign values to the dialog ID components as described |
|
3903 below. |
|
3904 |
|
3905 12.1.1 UAS behavior |
|
3906 |
|
3907 When a UAS responds to a request with a response that establishes a |
|
3908 dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route |
|
3909 header field values from the request into the response (including the |
|
3910 URIs, URI parameters, and any Record-Route header field parameters, |
|
3911 whether they are known or unknown to the UAS) and MUST maintain the |
|
3912 order of those values. The UAS MUST add a Contact header field to |
|
3913 the response. The Contact header field contains an address where the |
|
3914 UAS would like to be contacted for subsequent requests in the dialog |
|
3915 (which includes the ACK for a 2xx response in the case of an INVITE). |
|
3916 Generally, the host portion of this URI is the IP address or FQDN of |
|
3917 the host. The URI provided in the Contact header field MUST be a SIP |
|
3918 or SIPS URI. If the request that initiated the dialog contained a |
|
3919 |
|
3920 |
|
3921 |
|
3922 Rosenberg, et. al. Standards Track [Page 70] |
|
3923 |
|
3924 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3925 |
|
3926 |
|
3927 SIPS URI in the Request-URI or in the top Record-Route header field |
|
3928 value, if there was any, or the Contact header field if there was no |
|
3929 Record-Route header field, the Contact header field in the response |
|
3930 MUST be a SIPS URI. The URI SHOULD have global scope (that is, the |
|
3931 same URI can be used in messages outside this dialog). The same way, |
|
3932 the scope of the URI in the Contact header field of the INVITE is not |
|
3933 limited to this dialog either. It can therefore be used in messages |
|
3934 to the UAC even outside this dialog. |
|
3935 |
|
3936 The UAS then constructs the state of the dialog. This state MUST be |
|
3937 maintained for the duration of the dialog. |
|
3938 |
|
3939 If the request arrived over TLS, and the Request-URI contained a SIPS |
|
3940 URI, the "secure" flag is set to TRUE. |
|
3941 |
|
3942 The route set MUST be set to the list of URIs in the Record-Route |
|
3943 header field from the request, taken in order and preserving all URI |
|
3944 parameters. If no Record-Route header field is present in the |
|
3945 request, the route set MUST be set to the empty set. This route set, |
|
3946 even if empty, overrides any pre-existing route set for future |
|
3947 requests in this dialog. The remote target MUST be set to the URI |
|
3948 from the Contact header field of the request. |
|
3949 |
|
3950 The remote sequence number MUST be set to the value of the sequence |
|
3951 number in the CSeq header field of the request. The local sequence |
|
3952 number MUST be empty. The call identifier component of the dialog ID |
|
3953 MUST be set to the value of the Call-ID in the request. The local |
|
3954 tag component of the dialog ID MUST be set to the tag in the To field |
|
3955 in the response to the request (which always includes a tag), and the |
|
3956 remote tag component of the dialog ID MUST be set to the tag from the |
|
3957 From field in the request. A UAS MUST be prepared to receive a |
|
3958 request without a tag in the From field, in which case the tag is |
|
3959 considered to have a value of null. |
|
3960 |
|
3961 This is to maintain backwards compatibility with RFC 2543, which |
|
3962 did not mandate From tags. |
|
3963 |
|
3964 The remote URI MUST be set to the URI in the From field, and the |
|
3965 local URI MUST be set to the URI in the To field. |
|
3966 |
|
3967 12.1.2 UAC Behavior |
|
3968 |
|
3969 When a UAC sends a request that can establish a dialog (such as an |
|
3970 INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., |
|
3971 the same SIP URI can be used in messages outside this dialog) in the |
|
3972 Contact header field of the request. If the request has a Request- |
|
3973 URI or a topmost Route header field value with a SIPS URI, the |
|
3974 Contact header field MUST contain a SIPS URI. |
|
3975 |
|
3976 |
|
3977 |
|
3978 Rosenberg, et. al. Standards Track [Page 71] |
|
3979 |
|
3980 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
3981 |
|
3982 |
|
3983 When a UAC receives a response that establishes a dialog, it |
|
3984 constructs the state of the dialog. This state MUST be maintained |
|
3985 for the duration of the dialog. |
|
3986 |
|
3987 If the request was sent over TLS, and the Request-URI contained a |
|
3988 SIPS URI, the "secure" flag is set to TRUE. |
|
3989 |
|
3990 The route set MUST be set to the list of URIs in the Record-Route |
|
3991 header field from the response, taken in reverse order and preserving |
|
3992 all URI parameters. If no Record-Route header field is present in |
|
3993 the response, the route set MUST be set to the empty set. This route |
|
3994 set, even if empty, overrides any pre-existing route set for future |
|
3995 requests in this dialog. The remote target MUST be set to the URI |
|
3996 from the Contact header field of the response. |
|
3997 |
|
3998 The local sequence number MUST be set to the value of the sequence |
|
3999 number in the CSeq header field of the request. The remote sequence |
|
4000 number MUST be empty (it is established when the remote UA sends a |
|
4001 request within the dialog). The call identifier component of the |
|
4002 dialog ID MUST be set to the value of the Call-ID in the request. |
|
4003 The local tag component of the dialog ID MUST be set to the tag in |
|
4004 the From field in the request, and the remote tag component of the |
|
4005 dialog ID MUST be set to the tag in the To field of the response. A |
|
4006 UAC MUST be prepared to receive a response without a tag in the To |
|
4007 field, in which case the tag is considered to have a value of null. |
|
4008 |
|
4009 This is to maintain backwards compatibility with RFC 2543, which |
|
4010 did not mandate To tags. |
|
4011 |
|
4012 The remote URI MUST be set to the URI in the To field, and the local |
|
4013 URI MUST be set to the URI in the From field. |
|
4014 |
|
4015 12.2 Requests within a Dialog |
|
4016 |
|
4017 Once a dialog has been established between two UAs, either of them |
|
4018 MAY initiate new transactions as needed within the dialog. The UA |
|
4019 sending the request will take the UAC role for the transaction. The |
|
4020 UA receiving the request will take the UAS role. Note that these may |
|
4021 be different roles than the UAs held during the transaction that |
|
4022 established the dialog. |
|
4023 |
|
4024 Requests within a dialog MAY contain Record-Route and Contact header |
|
4025 fields. However, these requests do not cause the dialog's route set |
|
4026 to be modified, although they may modify the remote target URI. |
|
4027 Specifically, requests that are not target refresh requests do not |
|
4028 modify the dialog's remote target URI, and requests that are target |
|
4029 refresh requests do. For dialogs that have been established with an |
|
4030 |
|
4031 |
|
4032 |
|
4033 |
|
4034 Rosenberg, et. al. Standards Track [Page 72] |
|
4035 |
|
4036 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4037 |
|
4038 |
|
4039 INVITE, the only target refresh request defined is re-INVITE (see |
|
4040 Section 14). Other extensions may define different target refresh |
|
4041 requests for dialogs established in other ways. |
|
4042 |
|
4043 Note that an ACK is NOT a target refresh request. |
|
4044 |
|
4045 Target refresh requests only update the dialog's remote target URI, |
|
4046 and not the route set formed from the Record-Route. Updating the |
|
4047 latter would introduce severe backwards compatibility problems with |
|
4048 RFC 2543-compliant systems. |
|
4049 |
|
4050 12.2.1 UAC Behavior |
|
4051 |
|
4052 12.2.1.1 Generating the Request |
|
4053 |
|
4054 A request within a dialog is constructed by using many of the |
|
4055 components of the state stored as part of the dialog. |
|
4056 |
|
4057 The URI in the To field of the request MUST be set to the remote URI |
|
4058 from the dialog state. The tag in the To header field of the request |
|
4059 MUST be set to the remote tag of the dialog ID. The From URI of the |
|
4060 request MUST be set to the local URI from the dialog state. The tag |
|
4061 in the From header field of the request MUST be set to the local tag |
|
4062 of the dialog ID. If the value of the remote or local tags is null, |
|
4063 the tag parameter MUST be omitted from the To or From header fields, |
|
4064 respectively. |
|
4065 |
|
4066 Usage of the URI from the To and From fields in the original |
|
4067 request within subsequent requests is done for backwards |
|
4068 compatibility with RFC 2543, which used the URI for dialog |
|
4069 identification. In this specification, only the tags are used for |
|
4070 dialog identification. It is expected that mandatory reflection |
|
4071 of the original To and From URI in mid-dialog requests will be |
|
4072 deprecated in a subsequent revision of this specification. |
|
4073 |
|
4074 The Call-ID of the request MUST be set to the Call-ID of the dialog. |
|
4075 Requests within a dialog MUST contain strictly monotonically |
|
4076 increasing and contiguous CSeq sequence numbers (increasing-by-one) |
|
4077 in each direction (excepting ACK and CANCEL of course, whose numbers |
|
4078 equal the requests being acknowledged or cancelled). Therefore, if |
|
4079 the local sequence number is not empty, the value of the local |
|
4080 sequence number MUST be incremented by one, and this value MUST be |
|
4081 placed into the CSeq header field. If the local sequence number is |
|
4082 empty, an initial value MUST be chosen using the guidelines of |
|
4083 Section 8.1.1.5. The method field in the CSeq header field value |
|
4084 MUST match the method of the request. |
|
4085 |
|
4086 |
|
4087 |
|
4088 |
|
4089 |
|
4090 Rosenberg, et. al. Standards Track [Page 73] |
|
4091 |
|
4092 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4093 |
|
4094 |
|
4095 With a length of 32 bits, a client could generate, within a single |
|
4096 call, one request a second for about 136 years before needing to |
|
4097 wrap around. The initial value of the sequence number is chosen |
|
4098 so that subsequent requests within the same call will not wrap |
|
4099 around. A non-zero initial value allows clients to use a time- |
|
4100 based initial sequence number. A client could, for example, |
|
4101 choose the 31 most significant bits of a 32-bit second clock as an |
|
4102 initial sequence number. |
|
4103 |
|
4104 The UAC uses the remote target and route set to build the Request-URI |
|
4105 and Route header field of the request. |
|
4106 |
|
4107 If the route set is empty, the UAC MUST place the remote target URI |
|
4108 into the Request-URI. The UAC MUST NOT add a Route header field to |
|
4109 the request. |
|
4110 |
|
4111 If the route set is not empty, and the first URI in the route set |
|
4112 contains the lr parameter (see Section 19.1.1), the UAC MUST place |
|
4113 the remote target URI into the Request-URI and MUST include a Route |
|
4114 header field containing the route set values in order, including all |
|
4115 parameters. |
|
4116 |
|
4117 If the route set is not empty, and its first URI does not contain the |
|
4118 lr parameter, the UAC MUST place the first URI from the route set |
|
4119 into the Request-URI, stripping any parameters that are not allowed |
|
4120 in a Request-URI. The UAC MUST add a Route header field containing |
|
4121 the remainder of the route set values in order, including all |
|
4122 parameters. The UAC MUST then place the remote target URI into the |
|
4123 Route header field as the last value. |
|
4124 |
|
4125 For example, if the remote target is sip:user@remoteua and the route |
|
4126 set contains: |
|
4127 |
|
4128 <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4> |
|
4129 |
|
4130 The request will be formed with the following Request-URI and Route |
|
4131 header field: |
|
4132 |
|
4133 METHOD sip:proxy1 |
|
4134 Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua> |
|
4135 |
|
4136 If the first URI of the route set does not contain the lr |
|
4137 parameter, the proxy indicated does not understand the routing |
|
4138 mechanisms described in this document and will act as specified in |
|
4139 RFC 2543, replacing the Request-URI with the first Route header |
|
4140 field value it receives while forwarding the message. Placing the |
|
4141 Request-URI at the end of the Route header field preserves the |
|
4142 |
|
4143 |
|
4144 |
|
4145 |
|
4146 Rosenberg, et. al. Standards Track [Page 74] |
|
4147 |
|
4148 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4149 |
|
4150 |
|
4151 information in that Request-URI across the strict router (it will |
|
4152 be returned to the Request-URI when the request reaches a loose- |
|
4153 router). |
|
4154 |
|
4155 A UAC SHOULD include a Contact header field in any target refresh |
|
4156 requests within a dialog, and unless there is a need to change it, |
|
4157 the URI SHOULD be the same as used in previous requests within the |
|
4158 dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. |
|
4159 As discussed in Section 12.2.2, a Contact header field in a target |
|
4160 refresh request updates the remote target URI. This allows a UA to |
|
4161 provide a new contact address, should its address change during the |
|
4162 duration of the dialog. |
|
4163 |
|
4164 However, requests that are not target refresh requests do not affect |
|
4165 the remote target URI for the dialog. |
|
4166 |
|
4167 The rest of the request is formed as described in Section 8.1.1. |
|
4168 |
|
4169 Once the request has been constructed, the address of the server is |
|
4170 computed and the request is sent, using the same procedures for |
|
4171 requests outside of a dialog (Section 8.1.2). |
|
4172 |
|
4173 The procedures in Section 8.1.2 will normally result in the |
|
4174 request being sent to the address indicated by the topmost Route |
|
4175 header field value or the Request-URI if no Route header field is |
|
4176 present. Subject to certain restrictions, they allow the request |
|
4177 to be sent to an alternate address (such as a default outbound |
|
4178 proxy not represented in the route set). |
|
4179 |
|
4180 12.2.1.2 Processing the Responses |
|
4181 |
|
4182 The UAC will receive responses to the request from the transaction |
|
4183 layer. If the client transaction returns a timeout, this is treated |
|
4184 as a 408 (Request Timeout) response. |
|
4185 |
|
4186 The behavior of a UAC that receives a 3xx response for a request sent |
|
4187 within a dialog is the same as if the request had been sent outside a |
|
4188 dialog. This behavior is described in Section 8.1.3.4. |
|
4189 |
|
4190 Note, however, that when the UAC tries alternative locations, it |
|
4191 still uses the route set for the dialog to build the Route header |
|
4192 of the request. |
|
4193 |
|
4194 When a UAC receives a 2xx response to a target refresh request, it |
|
4195 MUST replace the dialog's remote target URI with the URI from the |
|
4196 Contact header field in that response, if present. |
|
4197 |
|
4198 |
|
4199 |
|
4200 |
|
4201 |
|
4202 Rosenberg, et. al. Standards Track [Page 75] |
|
4203 |
|
4204 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4205 |
|
4206 |
|
4207 If the response for a request within a dialog is a 481 |
|
4208 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC |
|
4209 SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if |
|
4210 no response at all is received for the request (the client |
|
4211 transaction would inform the TU about the timeout.) |
|
4212 |
|
4213 For INVITE initiated dialogs, terminating the dialog consists of |
|
4214 sending a BYE. |
|
4215 |
|
4216 12.2.2 UAS Behavior |
|
4217 |
|
4218 Requests sent within a dialog, as any other requests, are atomic. If |
|
4219 a particular request is accepted by the UAS, all the state changes |
|
4220 associated with it are performed. If the request is rejected, none |
|
4221 of the state changes are performed. |
|
4222 |
|
4223 Note that some requests, such as INVITEs, affect several pieces of |
|
4224 state. |
|
4225 |
|
4226 The UAS will receive the request from the transaction layer. If the |
|
4227 request has a tag in the To header field, the UAS core computes the |
|
4228 dialog identifier corresponding to the request and compares it with |
|
4229 existing dialogs. If there is a match, this is a mid-dialog request. |
|
4230 In that case, the UAS first applies the same processing rules for |
|
4231 requests outside of a dialog, discussed in Section 8.2. |
|
4232 |
|
4233 If the request has a tag in the To header field, but the dialog |
|
4234 identifier does not match any existing dialogs, the UAS may have |
|
4235 crashed and restarted, or it may have received a request for a |
|
4236 different (possibly failed) UAS (the UASs can construct the To tags |
|
4237 so that a UAS can identify that the tag was for a UAS for which it is |
|
4238 providing recovery). Another possibility is that the incoming |
|
4239 request has been simply misrouted. Based on the To tag, the UAS MAY |
|
4240 either accept or reject the request. Accepting the request for |
|
4241 acceptable To tags provides robustness, so that dialogs can persist |
|
4242 even through crashes. UAs wishing to support this capability must |
|
4243 take into consideration some issues such as choosing monotonically |
|
4244 increasing CSeq sequence numbers even across reboots, reconstructing |
|
4245 the route set, and accepting out-of-range RTP timestamps and sequence |
|
4246 numbers. |
|
4247 |
|
4248 If the UAS wishes to reject the request because it does not wish to |
|
4249 recreate the dialog, it MUST respond to the request with a 481 |
|
4250 (Call/Transaction Does Not Exist) status code and pass that to the |
|
4251 server transaction. |
|
4252 |
|
4253 |
|
4254 |
|
4255 |
|
4256 |
|
4257 |
|
4258 Rosenberg, et. al. Standards Track [Page 76] |
|
4259 |
|
4260 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4261 |
|
4262 |
|
4263 Requests that do not change in any way the state of a dialog may be |
|
4264 received within a dialog (for example, an OPTIONS request). They are |
|
4265 processed as if they had been received outside the dialog. |
|
4266 |
|
4267 If the remote sequence number is empty, it MUST be set to the value |
|
4268 of the sequence number in the CSeq header field value in the request. |
|
4269 If the remote sequence number was not empty, but the sequence number |
|
4270 of the request is lower than the remote sequence number, the request |
|
4271 is out of order and MUST be rejected with a 500 (Server Internal |
|
4272 Error) response. If the remote sequence number was not empty, and |
|
4273 the sequence number of the request is greater than the remote |
|
4274 sequence number, the request is in order. It is possible for the |
|
4275 CSeq sequence number to be higher than the remote sequence number by |
|
4276 more than one. This is not an error condition, and a UAS SHOULD be |
|
4277 prepared to receive and process requests with CSeq values more than |
|
4278 one higher than the previous received request. The UAS MUST then set |
|
4279 the remote sequence number to the value of the sequence number in the |
|
4280 CSeq header field value in the request. |
|
4281 |
|
4282 If a proxy challenges a request generated by the UAC, the UAC has |
|
4283 to resubmit the request with credentials. The resubmitted request |
|
4284 will have a new CSeq number. The UAS will never see the first |
|
4285 request, and thus, it will notice a gap in the CSeq number space. |
|
4286 Such a gap does not represent any error condition. |
|
4287 |
|
4288 When a UAS receives a target refresh request, it MUST replace the |
|
4289 dialog's remote target URI with the URI from the Contact header field |
|
4290 in that request, if present. |
|
4291 |
|
4292 12.3 Termination of a Dialog |
|
4293 |
|
4294 Independent of the method, if a request outside of a dialog generates |
|
4295 a non-2xx final response, any early dialogs created through |
|
4296 provisional responses to that request are terminated. The mechanism |
|
4297 for terminating confirmed dialogs is method specific. In this |
|
4298 specification, the BYE method terminates a session and the dialog |
|
4299 associated with it. See Section 15 for details. |
|
4300 |
|
4301 13 Initiating a Session |
|
4302 |
|
4303 13.1 Overview |
|
4304 |
|
4305 When a user agent client desires to initiate a session (for example, |
|
4306 audio, video, or a game), it formulates an INVITE request. The |
|
4307 INVITE request asks a server to establish a session. This request |
|
4308 may be forwarded by proxies, eventually arriving at one or more UAS |
|
4309 that can potentially accept the invitation. These UASs will |
|
4310 frequently need to query the user about whether to accept the |
|
4311 |
|
4312 |
|
4313 |
|
4314 Rosenberg, et. al. Standards Track [Page 77] |
|
4315 |
|
4316 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4317 |
|
4318 |
|
4319 invitation. After some time, those UASs can accept the invitation |
|
4320 (meaning the session is to be established) by sending a 2xx response. |
|
4321 If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is |
|
4322 sent, depending on the reason for the rejection. Before sending a |
|
4323 final response, the UAS can also send provisional responses (1xx) to |
|
4324 advise the UAC of progress in contacting the called user. |
|
4325 |
|
4326 After possibly receiving one or more provisional responses, the UAC |
|
4327 will get one or more 2xx responses or one non-2xx final response. |
|
4328 Because of the protracted amount of time it can take to receive final |
|
4329 responses to INVITE, the reliability mechanisms for INVITE |
|
4330 transactions differ from those of other requests (like OPTIONS). |
|
4331 Once it receives a final response, the UAC needs to send an ACK for |
|
4332 every final response it receives. The procedure for sending this ACK |
|
4333 depends on the type of response. For final responses between 300 and |
|
4334 699, the ACK processing is done in the transaction layer and follows |
|
4335 one set of rules (See Section 17). For 2xx responses, the ACK is |
|
4336 generated by the UAC core. |
|
4337 |
|
4338 A 2xx response to an INVITE establishes a session, and it also |
|
4339 creates a dialog between the UA that issued the INVITE and the UA |
|
4340 that generated the 2xx response. Therefore, when multiple 2xx |
|
4341 responses are received from different remote UAs (because the INVITE |
|
4342 forked), each 2xx establishes a different dialog. All these dialogs |
|
4343 are part of the same call. |
|
4344 |
|
4345 This section provides details on the establishment of a session using |
|
4346 INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and |
|
4347 BYE. |
|
4348 |
|
4349 13.2 UAC Processing |
|
4350 |
|
4351 13.2.1 Creating the Initial INVITE |
|
4352 |
|
4353 Since the initial INVITE represents a request outside of a dialog, |
|
4354 its construction follows the procedures of Section 8.1.1. Additional |
|
4355 processing is required for the specific case of INVITE. |
|
4356 |
|
4357 An Allow header field (Section 20.5) SHOULD be present in the INVITE. |
|
4358 It indicates what methods can be invoked within a dialog, on the UA |
|
4359 sending the INVITE, for the duration of the dialog. For example, a |
|
4360 UA capable of receiving INFO requests within a dialog [34] SHOULD |
|
4361 include an Allow header field listing the INFO method. |
|
4362 |
|
4363 A Supported header field (Section 20.37) SHOULD be present in the |
|
4364 INVITE. It enumerates all the extensions understood by the UAC. |
|
4365 |
|
4366 |
|
4367 |
|
4368 |
|
4369 |
|
4370 Rosenberg, et. al. Standards Track [Page 78] |
|
4371 |
|
4372 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4373 |
|
4374 |
|
4375 An Accept (Section 20.1) header field MAY be present in the INVITE. |
|
4376 It indicates which Content-Types are acceptable to the UA, in both |
|
4377 the response received by it, and in any subsequent requests sent to |
|
4378 it within dialogs established by the INVITE. The Accept header field |
|
4379 is especially useful for indicating support of various session |
|
4380 description formats. |
|
4381 |
|
4382 The UAC MAY add an Expires header field (Section 20.19) to limit the |
|
4383 validity of the invitation. If the time indicated in the Expires |
|
4384 header field is reached and no final answer for the INVITE has been |
|
4385 received, the UAC core SHOULD generate a CANCEL request for the |
|
4386 INVITE, as per Section 9. |
|
4387 |
|
4388 A UAC MAY also find it useful to add, among others, Subject (Section |
|
4389 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) |
|
4390 header fields. They all contain information related to the INVITE. |
|
4391 |
|
4392 The UAC MAY choose to add a message body to the INVITE. Section |
|
4393 8.1.1.10 deals with how to construct the header fields -- Content- |
|
4394 Type among others -- needed to describe the message body. |
|
4395 |
|
4396 There are special rules for message bodies that contain a session |
|
4397 description - their corresponding Content-Disposition is "session". |
|
4398 SIP uses an offer/answer model where one UA sends a session |
|
4399 description, called the offer, which contains a proposed description |
|
4400 of the session. The offer indicates the desired communications means |
|
4401 (audio, video, games), parameters of those means (such as codec |
|
4402 types) and addresses for receiving media from the answerer. The |
|
4403 other UA responds with another session description, called the |
|
4404 answer, which indicates which communications means are accepted, the |
|
4405 parameters that apply to those means, and addresses for receiving |
|
4406 media from the offerer. An offer/answer exchange is within the |
|
4407 context of a dialog, so that if a SIP INVITE results in multiple |
|
4408 dialogs, each is a separate offer/answer exchange. The offer/answer |
|
4409 model defines restrictions on when offers and answers can be made |
|
4410 (for example, you cannot make a new offer while one is in progress). |
|
4411 This results in restrictions on where the offers and answers can |
|
4412 appear in SIP messages. In this specification, offers and answers |
|
4413 can only appear in INVITE requests and responses, and ACK. The usage |
|
4414 of offers and answers is further restricted. For the initial INVITE |
|
4415 transaction, the rules are: |
|
4416 |
|
4417 o The initial offer MUST be in either an INVITE or, if not there, |
|
4418 in the first reliable non-failure message from the UAS back to |
|
4419 the UAC. In this specification, that is the final 2xx |
|
4420 response. |
|
4421 |
|
4422 |
|
4423 |
|
4424 |
|
4425 |
|
4426 Rosenberg, et. al. Standards Track [Page 79] |
|
4427 |
|
4428 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4429 |
|
4430 |
|
4431 o If the initial offer is in an INVITE, the answer MUST be in a |
|
4432 reliable non-failure message from UAS back to UAC which is |
|
4433 correlated to that INVITE. For this specification, that is |
|
4434 only the final 2xx response to that INVITE. That same exact |
|
4435 answer MAY also be placed in any provisional responses sent |
|
4436 prior to the answer. The UAC MUST treat the first session |
|
4437 description it receives as the answer, and MUST ignore any |
|
4438 session descriptions in subsequent responses to the initial |
|
4439 INVITE. |
|
4440 |
|
4441 o If the initial offer is in the first reliable non-failure |
|
4442 message from the UAS back to UAC, the answer MUST be in the |
|
4443 acknowledgement for that message (in this specification, ACK |
|
4444 for a 2xx response). |
|
4445 |
|
4446 o After having sent or received an answer to the first offer, the |
|
4447 UAC MAY generate subsequent offers in requests based on rules |
|
4448 specified for that method, but only if it has received answers |
|
4449 to any previous offers, and has not sent any offers to which it |
|
4450 hasn't gotten an answer. |
|
4451 |
|
4452 o Once the UAS has sent or received an answer to the initial |
|
4453 offer, it MUST NOT generate subsequent offers in any responses |
|
4454 to the initial INVITE. This means that a UAS based on this |
|
4455 specification alone can never generate subsequent offers until |
|
4456 completion of the initial transaction. |
|
4457 |
|
4458 Concretely, the above rules specify two exchanges for UAs compliant |
|
4459 to this specification alone - the offer is in the INVITE, and the |
|
4460 answer in the 2xx (and possibly in a 1xx as well, with the same |
|
4461 value), or the offer is in the 2xx, and the answer is in the ACK. |
|
4462 All user agents that support INVITE MUST support these two exchanges. |
|
4463 |
|
4464 The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be |
|
4465 supported by all user agents as a means to describe sessions, and its |
|
4466 usage for constructing offers and answers MUST follow the procedures |
|
4467 defined in [13]. |
|
4468 |
|
4469 The restrictions of the offer-answer model just described only apply |
|
4470 to bodies whose Content-Disposition header field value is "session". |
|
4471 Therefore, it is possible that both the INVITE and the ACK contain a |
|
4472 body message (for example, the INVITE carries a photo (Content- |
|
4473 Disposition: render) and the ACK a session description (Content- |
|
4474 Disposition: session)). |
|
4475 |
|
4476 If the Content-Disposition header field is missing, bodies of |
|
4477 Content-Type application/sdp imply the disposition "session", while |
|
4478 other content types imply "render". |
|
4479 |
|
4480 |
|
4481 |
|
4482 Rosenberg, et. al. Standards Track [Page 80] |
|
4483 |
|
4484 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4485 |
|
4486 |
|
4487 Once the INVITE has been created, the UAC follows the procedures |
|
4488 defined for sending requests outside of a dialog (Section 8). This |
|
4489 results in the construction of a client transaction that will |
|
4490 ultimately send the request and deliver responses to the UAC. |
|
4491 |
|
4492 13.2.2 Processing INVITE Responses |
|
4493 |
|
4494 Once the INVITE has been passed to the INVITE client transaction, the |
|
4495 UAC waits for responses for the INVITE. If the INVITE client |
|
4496 transaction returns a timeout rather than a response the TU acts as |
|
4497 if a 408 (Request Timeout) response had been received, as described |
|
4498 in Section 8.1.3. |
|
4499 |
|
4500 13.2.2.1 1xx Responses |
|
4501 |
|
4502 Zero, one or multiple provisional responses may arrive before one or |
|
4503 more final responses are received. Provisional responses for an |
|
4504 INVITE request can create "early dialogs". If a provisional response |
|
4505 has a tag in the To field, and if the dialog ID of the response does |
|
4506 not match an existing dialog, one is constructed using the procedures |
|
4507 defined in Section 12.1.2. |
|
4508 |
|
4509 The early dialog will only be needed if the UAC needs to send a |
|
4510 request to its peer within the dialog before the initial INVITE |
|
4511 transaction completes. Header fields present in a provisional |
|
4512 response are applicable as long as the dialog is in the early state |
|
4513 (for example, an Allow header field in a provisional response |
|
4514 contains the methods that can be used in the dialog while this is in |
|
4515 the early state). |
|
4516 |
|
4517 13.2.2.2 3xx Responses |
|
4518 |
|
4519 A 3xx response may contain one or more Contact header field values |
|
4520 providing new addresses where the callee might be reachable. |
|
4521 Depending on the status code of the 3xx response (see Section 21.3), |
|
4522 the UAC MAY choose to try those new addresses. |
|
4523 |
|
4524 13.2.2.3 4xx, 5xx and 6xx Responses |
|
4525 |
|
4526 A single non-2xx final response may be received for the INVITE. 4xx, |
|
4527 5xx and 6xx responses may contain a Contact header field value |
|
4528 indicating the location where additional information about the error |
|
4529 can be found. Subsequent final responses (which would only arrive |
|
4530 under error conditions) MUST be ignored. |
|
4531 |
|
4532 All early dialogs are considered terminated upon reception of the |
|
4533 non-2xx final response. |
|
4534 |
|
4535 |
|
4536 |
|
4537 |
|
4538 Rosenberg, et. al. Standards Track [Page 81] |
|
4539 |
|
4540 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4541 |
|
4542 |
|
4543 After having received the non-2xx final response the UAC core |
|
4544 considers the INVITE transaction completed. The INVITE client |
|
4545 transaction handles the generation of ACKs for the response (see |
|
4546 Section 17). |
|
4547 |
|
4548 13.2.2.4 2xx Responses |
|
4549 |
|
4550 Multiple 2xx responses may arrive at the UAC for a single INVITE |
|
4551 request due to a forking proxy. Each response is distinguished by |
|
4552 the tag parameter in the To header field, and each represents a |
|
4553 distinct dialog, with a distinct dialog identifier. |
|
4554 |
|
4555 If the dialog identifier in the 2xx response matches the dialog |
|
4556 identifier of an existing dialog, the dialog MUST be transitioned to |
|
4557 the "confirmed" state, and the route set for the dialog MUST be |
|
4558 recomputed based on the 2xx response using the procedures of Section |
|
4559 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be |
|
4560 constructed using the procedures of Section 12.1.2. |
|
4561 |
|
4562 Note that the only piece of state that is recomputed is the route |
|
4563 set. Other pieces of state such as the highest sequence numbers |
|
4564 (remote and local) sent within the dialog are not recomputed. The |
|
4565 route set only is recomputed for backwards compatibility. RFC |
|
4566 2543 did not mandate mirroring of the Record-Route header field in |
|
4567 a 1xx, only 2xx. However, we cannot update the entire state of |
|
4568 the dialog, since mid-dialog requests may have been sent within |
|
4569 the early dialog, modifying the sequence numbers, for example. |
|
4570 |
|
4571 The UAC core MUST generate an ACK request for each 2xx received from |
|
4572 the transaction layer. The header fields of the ACK are constructed |
|
4573 in the same way as for any request sent within a dialog (see Section |
|
4574 12) with the exception of the CSeq and the header fields related to |
|
4575 authentication. The sequence number of the CSeq header field MUST be |
|
4576 the same as the INVITE being acknowledged, but the CSeq method MUST |
|
4577 be ACK. The ACK MUST contain the same credentials as the INVITE. If |
|
4578 the 2xx contains an offer (based on the rules above), the ACK MUST |
|
4579 carry an answer in its body. If the offer in the 2xx response is not |
|
4580 acceptable, the UAC core MUST generate a valid answer in the ACK and |
|
4581 then send a BYE immediately. |
|
4582 |
|
4583 Once the ACK has been constructed, the procedures of [4] are used to |
|
4584 determine the destination address, port and transport. However, the |
|
4585 request is passed to the transport layer directly for transmission, |
|
4586 rather than a client transaction. This is because the UAC core |
|
4587 handles retransmissions of the ACK, not the transaction layer. The |
|
4588 ACK MUST be passed to the client transport every time a |
|
4589 retransmission of the 2xx final response that triggered the ACK |
|
4590 arrives. |
|
4591 |
|
4592 |
|
4593 |
|
4594 Rosenberg, et. al. Standards Track [Page 82] |
|
4595 |
|
4596 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4597 |
|
4598 |
|
4599 The UAC core considers the INVITE transaction completed 64*T1 seconds |
|
4600 after the reception of the first 2xx response. At this point all the |
|
4601 early dialogs that have not transitioned to established dialogs are |
|
4602 terminated. Once the INVITE transaction is considered completed by |
|
4603 the UAC core, no more new 2xx responses are expected to arrive. |
|
4604 |
|
4605 If, after acknowledging any 2xx response to an INVITE, the UAC does |
|
4606 not want to continue with that dialog, then the UAC MUST terminate |
|
4607 the dialog by sending a BYE request as described in Section 15. |
|
4608 |
|
4609 13.3 UAS Processing |
|
4610 |
|
4611 13.3.1 Processing of the INVITE |
|
4612 |
|
4613 The UAS core will receive INVITE requests from the transaction layer. |
|
4614 It first performs the request processing procedures of Section 8.2, |
|
4615 which are applied for both requests inside and outside of a dialog. |
|
4616 |
|
4617 Assuming these processing states are completed without generating a |
|
4618 response, the UAS core performs the additional processing steps: |
|
4619 |
|
4620 1. If the request is an INVITE that contains an Expires header |
|
4621 field, the UAS core sets a timer for the number of seconds |
|
4622 indicated in the header field value. When the timer fires, the |
|
4623 invitation is considered to be expired. If the invitation |
|
4624 expires before the UAS has generated a final response, a 487 |
|
4625 (Request Terminated) response SHOULD be generated. |
|
4626 |
|
4627 2. If the request is a mid-dialog request, the method-independent |
|
4628 processing described in Section 12.2.2 is first applied. It |
|
4629 might also modify the session; Section 14 provides details. |
|
4630 |
|
4631 3. If the request has a tag in the To header field but the dialog |
|
4632 identifier does not match any of the existing dialogs, the UAS |
|
4633 may have crashed and restarted, or may have received a request |
|
4634 for a different (possibly failed) UAS. Section 12.2.2 provides |
|
4635 guidelines to achieve a robust behavior under such a situation. |
|
4636 |
|
4637 Processing from here forward assumes that the INVITE is outside of a |
|
4638 dialog, and is thus for the purposes of establishing a new session. |
|
4639 |
|
4640 The INVITE may contain a session description, in which case the UAS |
|
4641 is being presented with an offer for that session. It is possible |
|
4642 that the user is already a participant in that session, even though |
|
4643 the INVITE is outside of a dialog. This can happen when a user is |
|
4644 invited to the same multicast conference by multiple other |
|
4645 participants. If desired, the UAS MAY use identifiers within the |
|
4646 session description to detect this duplication. For example, SDP |
|
4647 |
|
4648 |
|
4649 |
|
4650 Rosenberg, et. al. Standards Track [Page 83] |
|
4651 |
|
4652 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4653 |
|
4654 |
|
4655 contains a session id and version number in the origin (o) field. If |
|
4656 the user is already a member of the session, and the session |
|
4657 parameters contained in the session description have not changed, the |
|
4658 UAS MAY silently accept the INVITE (that is, send a 2xx response |
|
4659 without prompting the user). |
|
4660 |
|
4661 If the INVITE does not contain a session description, the UAS is |
|
4662 being asked to participate in a session, and the UAC has asked that |
|
4663 the UAS provide the offer of the session. It MUST provide the offer |
|
4664 in its first non-failure reliable message back to the UAC. In this |
|
4665 specification, that is a 2xx response to the INVITE. |
|
4666 |
|
4667 The UAS can indicate progress, accept, redirect, or reject the |
|
4668 invitation. In all of these cases, it formulates a response using |
|
4669 the procedures described in Section 8.2.6. |
|
4670 |
|
4671 13.3.1.1 Progress |
|
4672 |
|
4673 If the UAS is not able to answer the invitation immediately, it can |
|
4674 choose to indicate some kind of progress to the UAC (for example, an |
|
4675 indication that a phone is ringing). This is accomplished with a |
|
4676 provisional response between 101 and 199. These provisional |
|
4677 responses establish early dialogs and therefore follow the procedures |
|
4678 of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY |
|
4679 send as many provisional responses as it likes. Each of these MUST |
|
4680 indicate the same dialog ID. However, these will not be delivered |
|
4681 reliably. |
|
4682 |
|
4683 If the UAS desires an extended period of time to answer the INVITE, |
|
4684 it will need to ask for an "extension" in order to prevent proxies |
|
4685 from canceling the transaction. A proxy has the option of canceling |
|
4686 a transaction when there is a gap of 3 minutes between responses in a |
|
4687 transaction. To prevent cancellation, the UAS MUST send a non-100 |
|
4688 provisional response at every minute, to handle the possibility of |
|
4689 lost provisional responses. |
|
4690 |
|
4691 An INVITE transaction can go on for extended durations when the |
|
4692 user is placed on hold, or when interworking with PSTN systems |
|
4693 which allow communications to take place without answering the |
|
4694 call. The latter is common in Interactive Voice Response (IVR) |
|
4695 systems. |
|
4696 |
|
4697 13.3.1.2 The INVITE is Redirected |
|
4698 |
|
4699 If the UAS decides to redirect the call, a 3xx response is sent. A |
|
4700 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved |
|
4701 Temporarily) response SHOULD contain a Contact header field |
|
4702 |
|
4703 |
|
4704 |
|
4705 |
|
4706 Rosenberg, et. al. Standards Track [Page 84] |
|
4707 |
|
4708 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4709 |
|
4710 |
|
4711 containing one or more URIs of new addresses to be tried. The |
|
4712 response is passed to the INVITE server transaction, which will deal |
|
4713 with its retransmissions. |
|
4714 |
|
4715 13.3.1.3 The INVITE is Rejected |
|
4716 |
|
4717 A common scenario occurs when the callee is currently not willing or |
|
4718 able to take additional calls at this end system. A 486 (Busy Here) |
|
4719 SHOULD be returned in such a scenario. If the UAS knows that no |
|
4720 other end system will be able to accept this call, a 600 (Busy |
|
4721 Everywhere) response SHOULD be sent instead. However, it is unlikely |
|
4722 that a UAS will be able to know this in general, and thus this |
|
4723 response will not usually be used. The response is passed to the |
|
4724 INVITE server transaction, which will deal with its retransmissions. |
|
4725 |
|
4726 A UAS rejecting an offer contained in an INVITE SHOULD return a 488 |
|
4727 (Not Acceptable Here) response. Such a response SHOULD include a |
|
4728 Warning header field value explaining why the offer was rejected. |
|
4729 |
|
4730 13.3.1.4 The INVITE is Accepted |
|
4731 |
|
4732 The UAS core generates a 2xx response. This response establishes a |
|
4733 dialog, and therefore follows the procedures of Section 12.1.1 in |
|
4734 addition to those of Section 8.2.6. |
|
4735 |
|
4736 A 2xx response to an INVITE SHOULD contain the Allow header field and |
|
4737 the Supported header field, and MAY contain the Accept header field. |
|
4738 Including these header fields allows the UAC to determine the |
|
4739 features and extensions supported by the UAS for the duration of the |
|
4740 call, without probing. |
|
4741 |
|
4742 If the INVITE request contained an offer, and the UAS had not yet |
|
4743 sent an answer, the 2xx MUST contain an answer. If the INVITE did |
|
4744 not contain an offer, the 2xx MUST contain an offer if the UAS had |
|
4745 not yet sent an offer. |
|
4746 |
|
4747 Once the response has been constructed, it is passed to the INVITE |
|
4748 server transaction. Note, however, that the INVITE server |
|
4749 transaction will be destroyed as soon as it receives this final |
|
4750 response and passes it to the transport. Therefore, it is necessary |
|
4751 to periodically pass the response directly to the transport until the |
|
4752 ACK arrives. The 2xx response is passed to the transport with an |
|
4753 interval that starts at T1 seconds and doubles for each |
|
4754 retransmission until it reaches T2 seconds (T1 and T2 are defined in |
|
4755 Section 17). Response retransmissions cease when an ACK request for |
|
4756 the response is received. This is independent of whatever transport |
|
4757 protocols are used to send the response. |
|
4758 |
|
4759 |
|
4760 |
|
4761 |
|
4762 Rosenberg, et. al. Standards Track [Page 85] |
|
4763 |
|
4764 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4765 |
|
4766 |
|
4767 Since 2xx is retransmitted end-to-end, there may be hops between |
|
4768 UAS and UAC that are UDP. To ensure reliable delivery across |
|
4769 these hops, the response is retransmitted periodically even if the |
|
4770 transport at the UAS is reliable. |
|
4771 |
|
4772 If the server retransmits the 2xx response for 64*T1 seconds without |
|
4773 receiving an ACK, the dialog is confirmed, but the session SHOULD be |
|
4774 terminated. This is accomplished with a BYE, as described in Section |
|
4775 15. |
|
4776 |
|
4777 14 Modifying an Existing Session |
|
4778 |
|
4779 A successful INVITE request (see Section 13) establishes both a |
|
4780 dialog between two user agents and a session using the offer-answer |
|
4781 model. Section 12 explains how to modify an existing dialog using a |
|
4782 target refresh request (for example, changing the remote target URI |
|
4783 of the dialog). This section describes how to modify the actual |
|
4784 session. This modification can involve changing addresses or ports, |
|
4785 adding a media stream, deleting a media stream, and so on. This is |
|
4786 accomplished by sending a new INVITE request within the same dialog |
|
4787 that established the session. An INVITE request sent within an |
|
4788 existing dialog is known as a re-INVITE. |
|
4789 |
|
4790 Note that a single re-INVITE can modify the dialog and the |
|
4791 parameters of the session at the same time. |
|
4792 |
|
4793 Either the caller or callee can modify an existing session. |
|
4794 |
|
4795 The behavior of a UA on detection of media failure is a matter of |
|
4796 local policy. However, automated generation of re-INVITE or BYE is |
|
4797 NOT RECOMMENDED to avoid flooding the network with traffic when there |
|
4798 is congestion. In any case, if these messages are sent |
|
4799 automatically, they SHOULD be sent after some randomized interval. |
|
4800 |
|
4801 Note that the paragraph above refers to automatically generated |
|
4802 BYEs and re-INVITEs. If the user hangs up upon media failure, the |
|
4803 UA would send a BYE request as usual. |
|
4804 |
|
4805 14.1 UAC Behavior |
|
4806 |
|
4807 The same offer-answer model that applies to session descriptions in |
|
4808 INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC |
|
4809 that wants to add a media stream, for example, will create a new |
|
4810 offer that contains this media stream, and send that in an INVITE |
|
4811 request to its peer. It is important to note that the full |
|
4812 description of the session, not just the change, is sent. This |
|
4813 supports stateless session processing in various elements, and |
|
4814 supports failover and recovery capabilities. Of course, a UAC MAY |
|
4815 |
|
4816 |
|
4817 |
|
4818 Rosenberg, et. al. Standards Track [Page 86] |
|
4819 |
|
4820 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4821 |
|
4822 |
|
4823 send a re-INVITE with no session description, in which case the first |
|
4824 reliable non-failure response to the re-INVITE will contain the offer |
|
4825 (in this specification, that is a 2xx response). |
|
4826 |
|
4827 If the session description format has the capability for version |
|
4828 numbers, the offerer SHOULD indicate that the version of the session |
|
4829 description has changed. |
|
4830 |
|
4831 The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set |
|
4832 following the same rules as for regular requests within an existing |
|
4833 dialog, described in Section 12. |
|
4834 |
|
4835 A UAC MAY choose not to add an Alert-Info header field or a body with |
|
4836 Content-Disposition "alert" to re-INVITEs because UASs do not |
|
4837 typically alert the user upon reception of a re-INVITE. |
|
4838 |
|
4839 Unlike an INVITE, which can fork, a re-INVITE will never fork, and |
|
4840 therefore, only ever generate a single final response. The reason a |
|
4841 re-INVITE will never fork is that the Request-URI identifies the |
|
4842 target as the UA instance it established the dialog with, rather than |
|
4843 identifying an address-of-record for the user. |
|
4844 |
|
4845 Note that a UAC MUST NOT initiate a new INVITE transaction within a |
|
4846 dialog while another INVITE transaction is in progress in either |
|
4847 direction. |
|
4848 |
|
4849 1. If there is an ongoing INVITE client transaction, the TU MUST |
|
4850 wait until the transaction reaches the completed or terminated |
|
4851 state before initiating the new INVITE. |
|
4852 |
|
4853 2. If there is an ongoing INVITE server transaction, the TU MUST |
|
4854 wait until the transaction reaches the confirmed or terminated |
|
4855 state before initiating the new INVITE. |
|
4856 |
|
4857 However, a UA MAY initiate a regular transaction while an INVITE |
|
4858 transaction is in progress. A UA MAY also initiate an INVITE |
|
4859 transaction while a regular transaction is in progress. |
|
4860 |
|
4861 If a UA receives a non-2xx final response to a re-INVITE, the session |
|
4862 parameters MUST remain unchanged, as if no re-INVITE had been issued. |
|
4863 Note that, as stated in Section 12.2.1.2, if the non-2xx final |
|
4864 response is a 481 (Call/Transaction Does Not Exist), or a 408 |
|
4865 (Request Timeout), or no response at all is received for the re- |
|
4866 INVITE (that is, a timeout is returned by the INVITE client |
|
4867 transaction), the UAC will terminate the dialog. |
|
4868 |
|
4869 |
|
4870 |
|
4871 |
|
4872 |
|
4873 |
|
4874 Rosenberg, et. al. Standards Track [Page 87] |
|
4875 |
|
4876 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4877 |
|
4878 |
|
4879 If a UAC receives a 491 response to a re-INVITE, it SHOULD start a |
|
4880 timer with a value T chosen as follows: |
|
4881 |
|
4882 1. If the UAC is the owner of the Call-ID of the dialog ID |
|
4883 (meaning it generated the value), T has a randomly chosen value |
|
4884 between 2.1 and 4 seconds in units of 10 ms. |
|
4885 |
|
4886 2. If the UAC is not the owner of the Call-ID of the dialog ID, T |
|
4887 has a randomly chosen value of between 0 and 2 seconds in units |
|
4888 of 10 ms. |
|
4889 |
|
4890 When the timer fires, the UAC SHOULD attempt the re-INVITE once more, |
|
4891 if it still desires for that session modification to take place. For |
|
4892 example, if the call was already hung up with a BYE, the re-INVITE |
|
4893 would not take place. |
|
4894 |
|
4895 The rules for transmitting a re-INVITE and for generating an ACK for |
|
4896 a 2xx response to re-INVITE are the same as for the initial INVITE |
|
4897 (Section 13.2.1). |
|
4898 |
|
4899 14.2 UAS Behavior |
|
4900 |
|
4901 Section 13.3.1 describes the procedure for distinguishing incoming |
|
4902 re-INVITEs from incoming initial INVITEs and handling a re-INVITE for |
|
4903 an existing dialog. |
|
4904 |
|
4905 A UAS that receives a second INVITE before it sends the final |
|
4906 response to a first INVITE with a lower CSeq sequence number on the |
|
4907 same dialog MUST return a 500 (Server Internal Error) response to the |
|
4908 second INVITE and MUST include a Retry-After header field with a |
|
4909 randomly chosen value of between 0 and 10 seconds. |
|
4910 |
|
4911 A UAS that receives an INVITE on a dialog while an INVITE it had sent |
|
4912 on that dialog is in progress MUST return a 491 (Request Pending) |
|
4913 response to the received INVITE. |
|
4914 |
|
4915 If a UA receives a re-INVITE for an existing dialog, it MUST check |
|
4916 any version identifiers in the session description or, if there are |
|
4917 no version identifiers, the content of the session description to see |
|
4918 if it has changed. If the session description has changed, the UAS |
|
4919 MUST adjust the session parameters accordingly, possibly after asking |
|
4920 the user for confirmation. |
|
4921 |
|
4922 Versioning of the session description can be used to accommodate |
|
4923 the capabilities of new arrivals to a conference, add or delete |
|
4924 media, or change from a unicast to a multicast conference. |
|
4925 |
|
4926 |
|
4927 |
|
4928 |
|
4929 |
|
4930 Rosenberg, et. al. Standards Track [Page 88] |
|
4931 |
|
4932 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4933 |
|
4934 |
|
4935 If the new session description is not acceptable, the UAS can reject |
|
4936 it by returning a 488 (Not Acceptable Here) response for the re- |
|
4937 INVITE. This response SHOULD include a Warning header field. |
|
4938 |
|
4939 If a UAS generates a 2xx response and never receives an ACK, it |
|
4940 SHOULD generate a BYE to terminate the dialog. |
|
4941 |
|
4942 A UAS MAY choose not to generate 180 (Ringing) responses for a re- |
|
4943 INVITE because UACs do not typically render this information to the |
|
4944 user. For the same reason, UASs MAY choose not to use an Alert-Info |
|
4945 header field or a body with Content-Disposition "alert" in responses |
|
4946 to a re-INVITE. |
|
4947 |
|
4948 A UAS providing an offer in a 2xx (because the INVITE did not contain |
|
4949 an offer) SHOULD construct the offer as if the UAS were making a |
|
4950 brand new call, subject to the constraints of sending an offer that |
|
4951 updates an existing session, as described in [13] in the case of SDP. |
|
4952 Specifically, this means that it SHOULD include as many media formats |
|
4953 and media types that the UA is willing to support. The UAS MUST |
|
4954 ensure that the session description overlaps with its previous |
|
4955 session description in media formats, transports, or other parameters |
|
4956 that require support from the peer. This is to avoid the need for |
|
4957 the peer to reject the session description. If, however, it is |
|
4958 unacceptable to the UAC, the UAC SHOULD generate an answer with a |
|
4959 valid session description, and then send a BYE to terminate the |
|
4960 session. |
|
4961 |
|
4962 15 Terminating a Session |
|
4963 |
|
4964 This section describes the procedures for terminating a session |
|
4965 established by SIP. The state of the session and the state of the |
|
4966 dialog are very closely related. When a session is initiated with an |
|
4967 INVITE, each 1xx or 2xx response from a distinct UAS creates a |
|
4968 dialog, and if that response completes the offer/answer exchange, it |
|
4969 also creates a session. As a result, each session is "associated" |
|
4970 with a single dialog - the one which resulted in its creation. If an |
|
4971 initial INVITE generates a non-2xx final response, that terminates |
|
4972 all sessions (if any) and all dialogs (if any) that were created |
|
4973 through responses to the request. By virtue of completing the |
|
4974 transaction, a non-2xx final response also prevents further sessions |
|
4975 from being created as a result of the INVITE. The BYE request is |
|
4976 used to terminate a specific session or attempted session. In this |
|
4977 case, the specific session is the one with the peer UA on the other |
|
4978 side of the dialog. When a BYE is received on a dialog, any session |
|
4979 associated with that dialog SHOULD terminate. A UA MUST NOT send a |
|
4980 BYE outside of a dialog. The caller's UA MAY send a BYE for either |
|
4981 confirmed or early dialogs, and the callee's UA MAY send a BYE on |
|
4982 confirmed dialogs, but MUST NOT send a BYE on early dialogs. |
|
4983 |
|
4984 |
|
4985 |
|
4986 Rosenberg, et. al. Standards Track [Page 89] |
|
4987 |
|
4988 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
4989 |
|
4990 |
|
4991 However, the callee's UA MUST NOT send a BYE on a confirmed dialog |
|
4992 until it has received an ACK for its 2xx response or until the server |
|
4993 transaction times out. If no SIP extensions have defined other |
|
4994 application layer states associated with the dialog, the BYE also |
|
4995 terminates the dialog. |
|
4996 |
|
4997 The impact of a non-2xx final response to INVITE on dialogs and |
|
4998 sessions makes the use of CANCEL attractive. The CANCEL attempts to |
|
4999 force a non-2xx response to the INVITE (in particular, a 487). |
|
5000 Therefore, if a UAC wishes to give up on its call attempt entirely, |
|
5001 it can send a CANCEL. If the INVITE results in 2xx final response(s) |
|
5002 to the INVITE, this means that a UAS accepted the invitation while |
|
5003 the CANCEL was in progress. The UAC MAY continue with the sessions |
|
5004 established by any 2xx responses, or MAY terminate them with BYE. |
|
5005 |
|
5006 The notion of "hanging up" is not well defined within SIP. It is |
|
5007 specific to a particular, albeit common, user interface. |
|
5008 Typically, when the user hangs up, it indicates a desire to |
|
5009 terminate the attempt to establish a session, and to terminate any |
|
5010 sessions already created. For the caller's UA, this would imply a |
|
5011 CANCEL request if the initial INVITE has not generated a final |
|
5012 response, and a BYE to all confirmed dialogs after a final |
|
5013 response. For the callee's UA, it would typically imply a BYE; |
|
5014 presumably, when the user picked up the phone, a 2xx was |
|
5015 generated, and so hanging up would result in a BYE after the ACK |
|
5016 is received. This does not mean a user cannot hang up before |
|
5017 receipt of the ACK, it just means that the software in his phone |
|
5018 needs to maintain state for a short while in order to clean up |
|
5019 properly. If the particular UI allows for the user to reject a |
|
5020 call before its answered, a 403 (Forbidden) is a good way to |
|
5021 express that. As per the rules above, a BYE can't be sent. |
|
5022 |
|
5023 15.1 Terminating a Session with a BYE Request |
|
5024 |
|
5025 15.1.1 UAC Behavior |
|
5026 |
|
5027 A BYE request is constructed as would any other request within a |
|
5028 dialog, as described in Section 12. |
|
5029 |
|
5030 Once the BYE is constructed, the UAC core creates a new non-INVITE |
|
5031 client transaction, and passes it the BYE request. The UAC MUST |
|
5032 consider the session terminated (and therefore stop sending or |
|
5033 listening for media) as soon as the BYE request is passed to the |
|
5034 client transaction. If the response for the BYE is a 481 |
|
5035 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no |
|
5036 |
|
5037 |
|
5038 |
|
5039 |
|
5040 |
|
5041 |
|
5042 Rosenberg, et. al. Standards Track [Page 90] |
|
5043 |
|
5044 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5045 |
|
5046 |
|
5047 response at all is received for the BYE (that is, a timeout is |
|
5048 returned by the client transaction), the UAC MUST consider the |
|
5049 session and the dialog terminated. |
|
5050 |
|
5051 15.1.2 UAS Behavior |
|
5052 |
|
5053 A UAS first processes the BYE request according to the general UAS |
|
5054 processing described in Section 8.2. A UAS core receiving a BYE |
|
5055 request checks if it matches an existing dialog. If the BYE does not |
|
5056 match an existing dialog, the UAS core SHOULD generate a 481 |
|
5057 (Call/Transaction Does Not Exist) response and pass that to the |
|
5058 server transaction. |
|
5059 |
|
5060 This rule means that a BYE sent without tags by a UAC will be |
|
5061 rejected. This is a change from RFC 2543, which allowed BYE |
|
5062 without tags. |
|
5063 |
|
5064 A UAS core receiving a BYE request for an existing dialog MUST follow |
|
5065 the procedures of Section 12.2.2 to process the request. Once done, |
|
5066 the UAS SHOULD terminate the session (and therefore stop sending and |
|
5067 listening for media). The only case where it can elect not to are |
|
5068 multicast sessions, where participation is possible even if the other |
|
5069 participant in the dialog has terminated its involvement in the |
|
5070 session. Whether or not it ends its participation on the session, |
|
5071 the UAS core MUST generate a 2xx response to the BYE, and MUST pass |
|
5072 that to the server transaction for transmission. |
|
5073 |
|
5074 The UAS MUST still respond to any pending requests received for that |
|
5075 dialog. It is RECOMMENDED that a 487 (Request Terminated) response |
|
5076 be generated to those pending requests. |
|
5077 |
|
5078 16 Proxy Behavior |
|
5079 |
|
5080 16.1 Overview |
|
5081 |
|
5082 SIP proxies are elements that route SIP requests to user agent |
|
5083 servers and SIP responses to user agent clients. A request may |
|
5084 traverse several proxies on its way to a UAS. Each will make routing |
|
5085 decisions, modifying the request before forwarding it to the next |
|
5086 element. Responses will route through the same set of proxies |
|
5087 traversed by the request in the reverse order. |
|
5088 |
|
5089 Being a proxy is a logical role for a SIP element. When a request |
|
5090 arrives, an element that can play the role of a proxy first decides |
|
5091 if it needs to respond to the request on its own. For instance, the |
|
5092 request may be malformed or the element may need credentials from the |
|
5093 client before acting as a proxy. The element MAY respond with any |
|
5094 |
|
5095 |
|
5096 |
|
5097 |
|
5098 Rosenberg, et. al. Standards Track [Page 91] |
|
5099 |
|
5100 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5101 |
|
5102 |
|
5103 appropriate error code. When responding directly to a request, the |
|
5104 element is playing the role of a UAS and MUST behave as described in |
|
5105 Section 8.2. |
|
5106 |
|
5107 A proxy can operate in either a stateful or stateless mode for each |
|
5108 new request. When stateless, a proxy acts as a simple forwarding |
|
5109 element. It forwards each request downstream to a single element |
|
5110 determined by making a targeting and routing decision based on the |
|
5111 request. It simply forwards every response it receives upstream. A |
|
5112 stateless proxy discards information about a message once the message |
|
5113 has been forwarded. A stateful proxy remembers information |
|
5114 (specifically, transaction state) about each incoming request and any |
|
5115 requests it sends as a result of processing the incoming request. It |
|
5116 uses this information to affect the processing of future messages |
|
5117 associated with that request. A stateful proxy MAY choose to "fork" |
|
5118 a request, routing it to multiple destinations. Any request that is |
|
5119 forwarded to more than one location MUST be handled statefully. |
|
5120 |
|
5121 In some circumstances, a proxy MAY forward requests using stateful |
|
5122 transports (such as TCP) without being transaction-stateful. For |
|
5123 instance, a proxy MAY forward a request from one TCP connection to |
|
5124 another transaction statelessly as long as it places enough |
|
5125 information in the message to be able to forward the response down |
|
5126 the same connection the request arrived on. Requests forwarded |
|
5127 between different types of transports where the proxy's TU must take |
|
5128 an active role in ensuring reliable delivery on one of the transports |
|
5129 MUST be forwarded transaction statefully. |
|
5130 |
|
5131 A stateful proxy MAY transition to stateless operation at any time |
|
5132 during the processing of a request, so long as it did not do anything |
|
5133 that would otherwise prevent it from being stateless initially |
|
5134 (forking, for example, or generation of a 100 response). When |
|
5135 performing such a transition, all state is simply discarded. The |
|
5136 proxy SHOULD NOT initiate a CANCEL request. |
|
5137 |
|
5138 Much of the processing involved when acting statelessly or statefully |
|
5139 for a request is identical. The next several subsections are written |
|
5140 from the point of view of a stateful proxy. The last section calls |
|
5141 out those places where a stateless proxy behaves differently. |
|
5142 |
|
5143 16.2 Stateful Proxy |
|
5144 |
|
5145 When stateful, a proxy is purely a SIP transaction processing engine. |
|
5146 Its behavior is modeled here in terms of the server and client |
|
5147 transactions defined in Section 17. A stateful proxy has a server |
|
5148 transaction associated with one or more client transactions by a |
|
5149 higher layer proxy processing component (see figure 3), known as a |
|
5150 proxy core. An incoming request is processed by a server |
|
5151 |
|
5152 |
|
5153 |
|
5154 Rosenberg, et. al. Standards Track [Page 92] |
|
5155 |
|
5156 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5157 |
|
5158 |
|
5159 transaction. Requests from the server transaction are passed to a |
|
5160 proxy core. The proxy core determines where to route the request, |
|
5161 choosing one or more next-hop locations. An outgoing request for |
|
5162 each next-hop location is processed by its own associated client |
|
5163 transaction. The proxy core collects the responses from the client |
|
5164 transactions and uses them to send responses to the server |
|
5165 transaction. |
|
5166 |
|
5167 A stateful proxy creates a new server transaction for each new |
|
5168 request received. Any retransmissions of the request will then be |
|
5169 handled by that server transaction per Section 17. The proxy core |
|
5170 MUST behave as a UAS with respect to sending an immediate provisional |
|
5171 on that server transaction (such as 100 Trying) as described in |
|
5172 Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 |
|
5173 (Trying) responses to non-INVITE requests. |
|
5174 |
|
5175 This is a model of proxy behavior, not of software. An |
|
5176 implementation is free to take any approach that replicates the |
|
5177 external behavior this model defines. |
|
5178 |
|
5179 For all new requests, including any with unknown methods, an element |
|
5180 intending to proxy the request MUST: |
|
5181 |
|
5182 1. Validate the request (Section 16.3) |
|
5183 |
|
5184 2. Preprocess routing information (Section 16.4) |
|
5185 |
|
5186 3. Determine target(s) for the request (Section 16.5) |
|
5187 |
|
5188 +--------------------+ |
|
5189 | | +---+ |
|
5190 | | | C | |
|
5191 | | | T | |
|
5192 | | +---+ |
|
5193 +---+ | Proxy | +---+ CT = Client Transaction |
|
5194 | S | | "Higher" Layer | | C | |
|
5195 | T | | | | T | ST = Server Transaction |
|
5196 +---+ | | +---+ |
|
5197 | | +---+ |
|
5198 | | | C | |
|
5199 | | | T | |
|
5200 | | +---+ |
|
5201 +--------------------+ |
|
5202 |
|
5203 Figure 3: Stateful Proxy Model |
|
5204 |
|
5205 |
|
5206 |
|
5207 |
|
5208 |
|
5209 |
|
5210 Rosenberg, et. al. Standards Track [Page 93] |
|
5211 |
|
5212 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5213 |
|
5214 |
|
5215 4. Forward the request to each target (Section 16.6) |
|
5216 |
|
5217 5. Process all responses (Section 16.7) |
|
5218 |
|
5219 16.3 Request Validation |
|
5220 |
|
5221 Before an element can proxy a request, it MUST verify the message's |
|
5222 validity. A valid message must pass the following checks: |
|
5223 |
|
5224 1. Reasonable Syntax |
|
5225 |
|
5226 2. URI scheme |
|
5227 |
|
5228 3. Max-Forwards |
|
5229 |
|
5230 4. (Optional) Loop Detection |
|
5231 |
|
5232 5. Proxy-Require |
|
5233 |
|
5234 6. Proxy-Authorization |
|
5235 |
|
5236 If any of these checks fail, the element MUST behave as a user agent |
|
5237 server (see Section 8.2) and respond with an error code. |
|
5238 |
|
5239 Notice that a proxy is not required to detect merged requests and |
|
5240 MUST NOT treat merged requests as an error condition. The endpoints |
|
5241 receiving the requests will resolve the merge as described in Section |
|
5242 8.2.2.2. |
|
5243 |
|
5244 1. Reasonable syntax check |
|
5245 |
|
5246 The request MUST be well-formed enough to be handled with a server |
|
5247 transaction. Any components involved in the remainder of these |
|
5248 Request Validation steps or the Request Forwarding section MUST be |
|
5249 well-formed. Any other components, well-formed or not, SHOULD be |
|
5250 ignored and remain unchanged when the message is forwarded. For |
|
5251 instance, an element would not reject a request because of a |
|
5252 malformed Date header field. Likewise, a proxy would not remove a |
|
5253 malformed Date header field before forwarding a request. |
|
5254 |
|
5255 This protocol is designed to be extended. Future extensions may |
|
5256 define new methods and header fields at any time. An element MUST |
|
5257 NOT refuse to proxy a request because it contains a method or |
|
5258 header field it does not know about. |
|
5259 |
|
5260 |
|
5261 |
|
5262 |
|
5263 |
|
5264 |
|
5265 |
|
5266 Rosenberg, et. al. Standards Track [Page 94] |
|
5267 |
|
5268 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5269 |
|
5270 |
|
5271 2. URI scheme check |
|
5272 |
|
5273 If the Request-URI has a URI whose scheme is not understood by the |
|
5274 proxy, the proxy SHOULD reject the request with a 416 (Unsupported |
|
5275 URI Scheme) response. |
|
5276 |
|
5277 3. Max-Forwards check |
|
5278 |
|
5279 The Max-Forwards header field (Section 20.22) is used to limit the |
|
5280 number of elements a SIP request can traverse. |
|
5281 |
|
5282 If the request does not contain a Max-Forwards header field, this |
|
5283 check is passed. |
|
5284 |
|
5285 If the request contains a Max-Forwards header field with a field |
|
5286 value greater than zero, the check is passed. |
|
5287 |
|
5288 If the request contains a Max-Forwards header field with a field |
|
5289 value of zero (0), the element MUST NOT forward the request. If |
|
5290 the request was for OPTIONS, the element MAY act as the final |
|
5291 recipient and respond per Section 11. Otherwise, the element MUST |
|
5292 return a 483 (Too many hops) response. |
|
5293 |
|
5294 4. Optional Loop Detection check |
|
5295 |
|
5296 An element MAY check for forwarding loops before forwarding a |
|
5297 request. If the request contains a Via header field with a sent- |
|
5298 by value that equals a value placed into previous requests by the |
|
5299 proxy, the request has been forwarded by this element before. The |
|
5300 request has either looped or is legitimately spiraling through the |
|
5301 element. To determine if the request has looped, the element MAY |
|
5302 perform the branch parameter calculation described in Step 8 of |
|
5303 Section 16.6 on this message and compare it to the parameter |
|
5304 received in that Via header field. If the parameters match, the |
|
5305 request has looped. If they differ, the request is spiraling, and |
|
5306 processing continues. If a loop is detected, the element MAY |
|
5307 return a 482 (Loop Detected) response. |
|
5308 |
|
5309 5. Proxy-Require check |
|
5310 |
|
5311 Future extensions to this protocol may introduce features that |
|
5312 require special handling by proxies. Endpoints will include a |
|
5313 Proxy-Require header field in requests that use these features, |
|
5314 telling the proxy not to process the request unless the feature is |
|
5315 understood. |
|
5316 |
|
5317 |
|
5318 |
|
5319 |
|
5320 |
|
5321 |
|
5322 Rosenberg, et. al. Standards Track [Page 95] |
|
5323 |
|
5324 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5325 |
|
5326 |
|
5327 If the request contains a Proxy-Require header field (Section |
|
5328 20.29) with one or more option-tags this element does not |
|
5329 understand, the element MUST return a 420 (Bad Extension) |
|
5330 response. The response MUST include an Unsupported (Section |
|
5331 20.40) header field listing those option-tags the element did not |
|
5332 understand. |
|
5333 |
|
5334 6. Proxy-Authorization check |
|
5335 |
|
5336 If an element requires credentials before forwarding a request, |
|
5337 the request MUST be inspected as described in Section 22.3. That |
|
5338 section also defines what the element must do if the inspection |
|
5339 fails. |
|
5340 |
|
5341 16.4 Route Information Preprocessing |
|
5342 |
|
5343 The proxy MUST inspect the Request-URI of the request. If the |
|
5344 Request-URI of the request contains a value this proxy previously |
|
5345 placed into a Record-Route header field (see Section 16.6 item 4), |
|
5346 the proxy MUST replace the Request-URI in the request with the last |
|
5347 value from the Route header field, and remove that value from the |
|
5348 Route header field. The proxy MUST then proceed as if it received |
|
5349 this modified request. |
|
5350 |
|
5351 This will only happen when the element sending the request to the |
|
5352 proxy (which may have been an endpoint) is a strict router. This |
|
5353 rewrite on receive is necessary to enable backwards compatibility |
|
5354 with those elements. It also allows elements following this |
|
5355 specification to preserve the Request-URI through strict-routing |
|
5356 proxies (see Section 12.2.1.1). |
|
5357 |
|
5358 This requirement does not obligate a proxy to keep state in order |
|
5359 to detect URIs it previously placed in Record-Route header fields. |
|
5360 Instead, a proxy need only place enough information in those URIs |
|
5361 to recognize them as values it provided when they later appear. |
|
5362 |
|
5363 If the Request-URI contains a maddr parameter, the proxy MUST check |
|
5364 to see if its value is in the set of addresses or domains the proxy |
|
5365 is configured to be responsible for. If the Request-URI has a maddr |
|
5366 parameter with a value the proxy is responsible for, and the request |
|
5367 was received using the port and transport indicated (explicitly or by |
|
5368 default) in the Request-URI, the proxy MUST strip the maddr and any |
|
5369 non-default port or transport parameter and continue processing as if |
|
5370 those values had not been present in the request. |
|
5371 |
|
5372 |
|
5373 |
|
5374 |
|
5375 |
|
5376 |
|
5377 |
|
5378 Rosenberg, et. al. Standards Track [Page 96] |
|
5379 |
|
5380 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5381 |
|
5382 |
|
5383 A request may arrive with a maddr matching the proxy, but on a |
|
5384 port or transport different from that indicated in the URI. Such |
|
5385 a request needs to be forwarded to the proxy using the indicated |
|
5386 port and transport. |
|
5387 |
|
5388 If the first value in the Route header field indicates this proxy, |
|
5389 the proxy MUST remove that value from the request. |
|
5390 |
|
5391 16.5 Determining Request Targets |
|
5392 |
|
5393 Next, the proxy calculates the target(s) of the request. The set of |
|
5394 targets will either be predetermined by the contents of the request |
|
5395 or will be obtained from an abstract location service. Each target |
|
5396 in the set is represented as a URI. |
|
5397 |
|
5398 If the Request-URI of the request contains an maddr parameter, the |
|
5399 Request-URI MUST be placed into the target set as the only target |
|
5400 URI, and the proxy MUST proceed to Section 16.6. |
|
5401 |
|
5402 If the domain of the Request-URI indicates a domain this element is |
|
5403 not responsible for, the Request-URI MUST be placed into the target |
|
5404 set as the only target, and the element MUST proceed to the task of |
|
5405 Request Forwarding (Section 16.6). |
|
5406 |
|
5407 There are many circumstances in which a proxy might receive a |
|
5408 request for a domain it is not responsible for. A firewall proxy |
|
5409 handling outgoing calls (the way HTTP proxies handle outgoing |
|
5410 requests) is an example of where this is likely to occur. |
|
5411 |
|
5412 If the target set for the request has not been predetermined as |
|
5413 described above, this implies that the element is responsible for the |
|
5414 domain in the Request-URI, and the element MAY use whatever mechanism |
|
5415 it desires to determine where to send the request. Any of these |
|
5416 mechanisms can be modeled as accessing an abstract Location Service. |
|
5417 This may consist of obtaining information from a location service |
|
5418 created by a SIP Registrar, reading a database, consulting a presence |
|
5419 server, utilizing other protocols, or simply performing an |
|
5420 algorithmic substitution on the Request-URI. When accessing the |
|
5421 location service constructed by a registrar, the Request-URI MUST |
|
5422 first be canonicalized as described in Section 10.3 before being used |
|
5423 as an index. The output of these mechanisms is used to construct the |
|
5424 target set. |
|
5425 |
|
5426 If the Request-URI does not provide sufficient information for the |
|
5427 proxy to determine the target set, it SHOULD return a 485 (Ambiguous) |
|
5428 response. This response SHOULD contain a Contact header field |
|
5429 containing URIs of new addresses to be tried. For example, an INVITE |
|
5430 |
|
5431 |
|
5432 |
|
5433 |
|
5434 Rosenberg, et. al. Standards Track [Page 97] |
|
5435 |
|
5436 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5437 |
|
5438 |
|
5439 to sip:John.Smith@company.com may be ambiguous at a proxy whose |
|
5440 location service has multiple John Smiths listed. See Section |
|
5441 21.4.23 for details. |
|
5442 |
|
5443 Any information in or about the request or the current environment of |
|
5444 the element MAY be used in the construction of the target set. For |
|
5445 instance, different sets may be constructed depending on contents or |
|
5446 the presence of header fields and bodies, the time of day of the |
|
5447 request's arrival, the interface on which the request arrived, |
|
5448 failure of previous requests, or even the element's current level of |
|
5449 utilization. |
|
5450 |
|
5451 As potential targets are located through these services, their URIs |
|
5452 are added to the target set. Targets can only be placed in the |
|
5453 target set once. If a target URI is already present in the set |
|
5454 (based on the definition of equality for the URI type), it MUST NOT |
|
5455 be added again. |
|
5456 |
|
5457 A proxy MUST NOT add additional targets to the target set if the |
|
5458 Request-URI of the original request does not indicate a resource this |
|
5459 proxy is responsible for. |
|
5460 |
|
5461 A proxy can only change the Request-URI of a request during |
|
5462 forwarding if it is responsible for that URI. If the proxy is not |
|
5463 responsible for that URI, it will not recurse on 3xx or 416 |
|
5464 responses as described below. |
|
5465 |
|
5466 If the Request-URI of the original request indicates a resource this |
|
5467 proxy is responsible for, the proxy MAY continue to add targets to |
|
5468 the set after beginning Request Forwarding. It MAY use any |
|
5469 information obtained during that processing to determine new targets. |
|
5470 For instance, a proxy may choose to incorporate contacts obtained in |
|
5471 a redirect response (3xx) into the target set. If a proxy uses a |
|
5472 dynamic source of information while building the target set (for |
|
5473 instance, if it consults a SIP Registrar), it SHOULD monitor that |
|
5474 source for the duration of processing the request. New locations |
|
5475 SHOULD be added to the target set as they become available. As |
|
5476 above, any given URI MUST NOT be added to the set more than once. |
|
5477 |
|
5478 Allowing a URI to be added to the set only once reduces |
|
5479 unnecessary network traffic, and in the case of incorporating |
|
5480 contacts from redirect requests prevents infinite recursion. |
|
5481 |
|
5482 For example, a trivial location service is a "no-op", where the |
|
5483 target URI is equal to the incoming request URI. The request is sent |
|
5484 to a specific next hop proxy for further processing. During request |
|
5485 |
|
5486 |
|
5487 |
|
5488 |
|
5489 |
|
5490 Rosenberg, et. al. Standards Track [Page 98] |
|
5491 |
|
5492 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5493 |
|
5494 |
|
5495 forwarding of Section 16.6, Item 6, the identity of that next hop, |
|
5496 expressed as a SIP or SIPS URI, is inserted as the top-most Route |
|
5497 header field value into the request. |
|
5498 |
|
5499 If the Request-URI indicates a resource at this proxy that does not |
|
5500 exist, the proxy MUST return a 404 (Not Found) response. |
|
5501 |
|
5502 If the target set remains empty after applying all of the above, the |
|
5503 proxy MUST return an error response, which SHOULD be the 480 |
|
5504 (Temporarily Unavailable) response. |
|
5505 |
|
5506 16.6 Request Forwarding |
|
5507 |
|
5508 As soon as the target set is non-empty, a proxy MAY begin forwarding |
|
5509 the request. A stateful proxy MAY process the set in any order. It |
|
5510 MAY process multiple targets serially, allowing each client |
|
5511 transaction to complete before starting the next. It MAY start |
|
5512 client transactions with every target in parallel. It also MAY |
|
5513 arbitrarily divide the set into groups, processing the groups |
|
5514 serially and processing the targets in each group in parallel. |
|
5515 |
|
5516 A common ordering mechanism is to use the qvalue parameter of targets |
|
5517 obtained from Contact header fields (see Section 20.10). Targets are |
|
5518 processed from highest qvalue to lowest. Targets with equal qvalues |
|
5519 may be processed in parallel. |
|
5520 |
|
5521 A stateful proxy must have a mechanism to maintain the target set as |
|
5522 responses are received and associate the responses to each forwarded |
|
5523 request with the original request. For the purposes of this model, |
|
5524 this mechanism is a "response context" created by the proxy layer |
|
5525 before forwarding the first request. |
|
5526 |
|
5527 For each target, the proxy forwards the request following these |
|
5528 steps: |
|
5529 |
|
5530 1. Make a copy of the received request |
|
5531 |
|
5532 2. Update the Request-URI |
|
5533 |
|
5534 3. Update the Max-Forwards header field |
|
5535 |
|
5536 4. Optionally add a Record-route header field value |
|
5537 |
|
5538 5. Optionally add additional header fields |
|
5539 |
|
5540 6. Postprocess routing information |
|
5541 |
|
5542 7. Determine the next-hop address, port, and transport |
|
5543 |
|
5544 |
|
5545 |
|
5546 Rosenberg, et. al. Standards Track [Page 99] |
|
5547 |
|
5548 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5549 |
|
5550 |
|
5551 8. Add a Via header field value |
|
5552 |
|
5553 9. Add a Content-Length header field if necessary |
|
5554 |
|
5555 10. Forward the new request |
|
5556 |
|
5557 11. Set timer C |
|
5558 |
|
5559 Each of these steps is detailed below: |
|
5560 |
|
5561 1. Copy request |
|
5562 |
|
5563 The proxy starts with a copy of the received request. The copy |
|
5564 MUST initially contain all of the header fields from the |
|
5565 received request. Fields not detailed in the processing |
|
5566 described below MUST NOT be removed. The copy SHOULD maintain |
|
5567 the ordering of the header fields as in the received request. |
|
5568 The proxy MUST NOT reorder field values with a common field |
|
5569 name (See Section 7.3.1). The proxy MUST NOT add to, modify, |
|
5570 or remove the message body. |
|
5571 |
|
5572 An actual implementation need not perform a copy; the primary |
|
5573 requirement is that the processing for each next hop begin with |
|
5574 the same request. |
|
5575 |
|
5576 2. Request-URI |
|
5577 |
|
5578 The Request-URI in the copy's start line MUST be replaced with |
|
5579 the URI for this target. If the URI contains any parameters |
|
5580 not allowed in a Request-URI, they MUST be removed. |
|
5581 |
|
5582 This is the essence of a proxy's role. This is the mechanism |
|
5583 through which a proxy routes a request toward its destination. |
|
5584 |
|
5585 In some circumstances, the received Request-URI is placed into |
|
5586 the target set without being modified. For that target, the |
|
5587 replacement above is effectively a no-op. |
|
5588 |
|
5589 3. Max-Forwards |
|
5590 |
|
5591 If the copy contains a Max-Forwards header field, the proxy |
|
5592 MUST decrement its value by one (1). |
|
5593 |
|
5594 If the copy does not contain a Max-Forwards header field, the |
|
5595 proxy MUST add one with a field value, which SHOULD be 70. |
|
5596 |
|
5597 Some existing UAs will not provide a Max-Forwards header field |
|
5598 in a request. |
|
5599 |
|
5600 |
|
5601 |
|
5602 Rosenberg, et. al. Standards Track [Page 100] |
|
5603 |
|
5604 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5605 |
|
5606 |
|
5607 4. Record-Route |
|
5608 |
|
5609 If this proxy wishes to remain on the path of future requests |
|
5610 in a dialog created by this request (assuming the request |
|
5611 creates a dialog), it MUST insert a Record-Route header field |
|
5612 value into the copy before any existing Record-Route header |
|
5613 field values, even if a Route header field is already present. |
|
5614 |
|
5615 Requests establishing a dialog may contain a preloaded Route |
|
5616 header field. |
|
5617 |
|
5618 If this request is already part of a dialog, the proxy SHOULD |
|
5619 insert a Record-Route header field value if it wishes to remain |
|
5620 on the path of future requests in the dialog. In normal |
|
5621 endpoint operation as described in Section 12, these Record- |
|
5622 Route header field values will not have any effect on the route |
|
5623 sets used by the endpoints. |
|
5624 |
|
5625 The proxy will remain on the path if it chooses to not insert a |
|
5626 Record-Route header field value into requests that are already |
|
5627 part of a dialog. However, it would be removed from the path |
|
5628 when an endpoint that has failed reconstitutes the dialog. |
|
5629 |
|
5630 A proxy MAY insert a Record-Route header field value into any |
|
5631 request. If the request does not initiate a dialog, the |
|
5632 endpoints will ignore the value. See Section 12 for details on |
|
5633 how endpoints use the Record-Route header field values to |
|
5634 construct Route header fields. |
|
5635 |
|
5636 Each proxy in the path of a request chooses whether to add a |
|
5637 Record-Route header field value independently - the presence of |
|
5638 a Record-Route header field in a request does not obligate this |
|
5639 proxy to add a value. |
|
5640 |
|
5641 The URI placed in the Record-Route header field value MUST be a |
|
5642 SIP or SIPS URI. This URI MUST contain an lr parameter (see |
|
5643 Section 19.1.1). This URI MAY be different for each |
|
5644 destination the request is forwarded to. The URI SHOULD NOT |
|
5645 contain the transport parameter unless the proxy has knowledge |
|
5646 (such as in a private network) that the next downstream element |
|
5647 that will be in the path of subsequent requests supports that |
|
5648 transport. |
|
5649 |
|
5650 The URI this proxy provides will be used by some other element |
|
5651 to make a routing decision. This proxy, in general, has no way |
|
5652 of knowing the capabilities of that element, so it must |
|
5653 restrict itself to the mandatory elements of a SIP |
|
5654 implementation: SIP URIs and either the TCP or UDP transports. |
|
5655 |
|
5656 |
|
5657 |
|
5658 Rosenberg, et. al. Standards Track [Page 101] |
|
5659 |
|
5660 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5661 |
|
5662 |
|
5663 The URI placed in the Record-Route header field MUST resolve to |
|
5664 the element inserting it (or a suitable stand-in) when the |
|
5665 server location procedures of [4] are applied to it, so that |
|
5666 subsequent requests reach the same SIP element. If the |
|
5667 Request-URI contains a SIPS URI, or the topmost Route header |
|
5668 field value (after the post processing of bullet 6) contains a |
|
5669 SIPS URI, the URI placed into the Record-Route header field |
|
5670 MUST be a SIPS URI. Furthermore, if the request was not |
|
5671 received over TLS, the proxy MUST insert a Record-Route header |
|
5672 field. In a similar fashion, a proxy that receives a request |
|
5673 over TLS, but generates a request without a SIPS URI in the |
|
5674 Request-URI or topmost Route header field value (after the post |
|
5675 processing of bullet 6), MUST insert a Record-Route header |
|
5676 field that is not a SIPS URI. |
|
5677 |
|
5678 A proxy at a security perimeter must remain on the perimeter |
|
5679 throughout the dialog. |
|
5680 |
|
5681 If the URI placed in the Record-Route header field needs to be |
|
5682 rewritten when it passes back through in a response, the URI |
|
5683 MUST be distinct enough to locate at that time. (The request |
|
5684 may spiral through this proxy, resulting in more than one |
|
5685 Record-Route header field value being added). Item 8 of |
|
5686 Section 16.7 recommends a mechanism to make the URI |
|
5687 sufficiently distinct. |
|
5688 |
|
5689 The proxy MAY include parameters in the Record-Route header |
|
5690 field value. These will be echoed in some responses to the |
|
5691 request such as the 200 (OK) responses to INVITE. Such |
|
5692 parameters may be useful for keeping state in the message |
|
5693 rather than the proxy. |
|
5694 |
|
5695 If a proxy needs to be in the path of any type of dialog (such |
|
5696 as one straddling a firewall), it SHOULD add a Record-Route |
|
5697 header field value to every request with a method it does not |
|
5698 understand since that method may have dialog semantics. |
|
5699 |
|
5700 The URI a proxy places into a Record-Route header field is only |
|
5701 valid for the lifetime of any dialog created by the transaction |
|
5702 in which it occurs. A dialog-stateful proxy, for example, MAY |
|
5703 refuse to accept future requests with that value in the |
|
5704 Request-URI after the dialog has terminated. Non-dialog- |
|
5705 stateful proxies, of course, have no concept of when the dialog |
|
5706 has terminated, but they MAY encode enough information in the |
|
5707 value to compare it against the dialog identifier of future |
|
5708 requests and MAY reject requests not matching that information. |
|
5709 Endpoints MUST NOT use a URI obtained from a Record-Route |
|
5710 header field outside the dialog in which it was provided. See |
|
5711 |
|
5712 |
|
5713 |
|
5714 Rosenberg, et. al. Standards Track [Page 102] |
|
5715 |
|
5716 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5717 |
|
5718 |
|
5719 Section 12 for more information on an endpoint's use of |
|
5720 Record-Route header fields. |
|
5721 |
|
5722 Record-routing may be required by certain services where the |
|
5723 proxy needs to observe all messages in a dialog. However, it |
|
5724 slows down processing and impairs scalability and thus proxies |
|
5725 should only record-route if required for a particular service. |
|
5726 |
|
5727 The Record-Route process is designed to work for any SIP |
|
5728 request that initiates a dialog. INVITE is the only such |
|
5729 request in this specification, but extensions to the protocol |
|
5730 MAY define others. |
|
5731 |
|
5732 5. Add Additional Header Fields |
|
5733 |
|
5734 The proxy MAY add any other appropriate header fields to the |
|
5735 copy at this point. |
|
5736 |
|
5737 6. Postprocess routing information |
|
5738 |
|
5739 A proxy MAY have a local policy that mandates that a request |
|
5740 visit a specific set of proxies before being delivered to the |
|
5741 destination. A proxy MUST ensure that all such proxies are |
|
5742 loose routers. Generally, this can only be known with |
|
5743 certainty if the proxies are within the same administrative |
|
5744 domain. This set of proxies is represented by a set of URIs |
|
5745 (each of which contains the lr parameter). This set MUST be |
|
5746 pushed into the Route header field of the copy ahead of any |
|
5747 existing values, if present. If the Route header field is |
|
5748 absent, it MUST be added, containing that list of URIs. |
|
5749 |
|
5750 If the proxy has a local policy that mandates that the request |
|
5751 visit one specific proxy, an alternative to pushing a Route |
|
5752 value into the Route header field is to bypass the forwarding |
|
5753 logic of item 10 below, and instead just send the request to |
|
5754 the address, port, and transport for that specific proxy. If |
|
5755 the request has a Route header field, this alternative MUST NOT |
|
5756 be used unless it is known that next hop proxy is a loose |
|
5757 router. Otherwise, this approach MAY be used, but the Route |
|
5758 insertion mechanism above is preferred for its robustness, |
|
5759 flexibility, generality and consistency of operation. |
|
5760 Furthermore, if the Request-URI contains a SIPS URI, TLS MUST |
|
5761 be used to communicate with that proxy. |
|
5762 |
|
5763 If the copy contains a Route header field, the proxy MUST |
|
5764 inspect the URI in its first value. If that URI does not |
|
5765 contain an lr parameter, the proxy MUST modify the copy as |
|
5766 follows: |
|
5767 |
|
5768 |
|
5769 |
|
5770 Rosenberg, et. al. Standards Track [Page 103] |
|
5771 |
|
5772 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5773 |
|
5774 |
|
5775 - The proxy MUST place the Request-URI into the Route header |
|
5776 field as the last value. |
|
5777 |
|
5778 - The proxy MUST then place the first Route header field value |
|
5779 into the Request-URI and remove that value from the Route |
|
5780 header field. |
|
5781 |
|
5782 Appending the Request-URI to the Route header field is part of |
|
5783 a mechanism used to pass the information in that Request-URI |
|
5784 through strict-routing elements. "Popping" the first Route |
|
5785 header field value into the Request-URI formats the message the |
|
5786 way a strict-routing element expects to receive it (with its |
|
5787 own URI in the Request-URI and the next location to visit in |
|
5788 the first Route header field value). |
|
5789 |
|
5790 7. Determine Next-Hop Address, Port, and Transport |
|
5791 |
|
5792 The proxy MAY have a local policy to send the request to a |
|
5793 specific IP address, port, and transport, independent of the |
|
5794 values of the Route and Request-URI. Such a policy MUST NOT be |
|
5795 used if the proxy is not certain that the IP address, port, and |
|
5796 transport correspond to a server that is a loose router. |
|
5797 However, this mechanism for sending the request through a |
|
5798 specific next hop is NOT RECOMMENDED; instead a Route header |
|
5799 field should be used for that purpose as described above. |
|
5800 |
|
5801 In the absence of such an overriding mechanism, the proxy |
|
5802 applies the procedures listed in [4] as follows to determine |
|
5803 where to send the request. If the proxy has reformatted the |
|
5804 request to send to a strict-routing element as described in |
|
5805 step 6 above, the proxy MUST apply those procedures to the |
|
5806 Request-URI of the request. Otherwise, the proxy MUST apply |
|
5807 the procedures to the first value in the Route header field, if |
|
5808 present, else the Request-URI. The procedures will produce an |
|
5809 ordered set of (address, port, transport) tuples. |
|
5810 Independently of which URI is being used as input to the |
|
5811 procedures of [4], if the Request-URI specifies a SIPS |
|
5812 resource, the proxy MUST follow the procedures of [4] as if the |
|
5813 input URI were a SIPS URI. |
|
5814 |
|
5815 As described in [4], the proxy MUST attempt to deliver the |
|
5816 message to the first tuple in that set, and proceed through the |
|
5817 set in order until the delivery attempt succeeds. |
|
5818 |
|
5819 For each tuple attempted, the proxy MUST format the message as |
|
5820 appropriate for the tuple and send the request using a new |
|
5821 client transaction as detailed in steps 8 through 10. |
|
5822 |
|
5823 |
|
5824 |
|
5825 |
|
5826 Rosenberg, et. al. Standards Track [Page 104] |
|
5827 |
|
5828 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5829 |
|
5830 |
|
5831 Since each attempt uses a new client transaction, it represents |
|
5832 a new branch. Thus, the branch parameter provided with the Via |
|
5833 header field inserted in step 8 MUST be different for each |
|
5834 attempt. |
|
5835 |
|
5836 If the client transaction reports failure to send the request |
|
5837 or a timeout from its state machine, the proxy continues to the |
|
5838 next address in that ordered set. If the ordered set is |
|
5839 exhausted, the request cannot be forwarded to this element in |
|
5840 the target set. The proxy does not need to place anything in |
|
5841 the response context, but otherwise acts as if this element of |
|
5842 the target set returned a 408 (Request Timeout) final response. |
|
5843 |
|
5844 8. Add a Via header field value |
|
5845 |
|
5846 The proxy MUST insert a Via header field value into the copy |
|
5847 before the existing Via header field values. The construction |
|
5848 of this value follows the same guidelines of Section 8.1.1.7. |
|
5849 This implies that the proxy will compute its own branch |
|
5850 parameter, which will be globally unique for that branch, and |
|
5851 contain the requisite magic cookie. Note that this implies that |
|
5852 the branch parameter will be different for different instances |
|
5853 of a spiraled or looped request through a proxy. |
|
5854 |
|
5855 Proxies choosing to detect loops have an additional constraint |
|
5856 in the value they use for construction of the branch parameter. |
|
5857 A proxy choosing to detect loops SHOULD create a branch |
|
5858 parameter separable into two parts by the implementation. The |
|
5859 first part MUST satisfy the constraints of Section 8.1.1.7 as |
|
5860 described above. The second is used to perform loop detection |
|
5861 and distinguish loops from spirals. |
|
5862 |
|
5863 Loop detection is performed by verifying that, when a request |
|
5864 returns to a proxy, those fields having an impact on the |
|
5865 processing of the request have not changed. The value placed |
|
5866 in this part of the branch parameter SHOULD reflect all of |
|
5867 those fields (including any Route, Proxy-Require and Proxy- |
|
5868 Authorization header fields). This is to ensure that if the |
|
5869 request is routed back to the proxy and one of those fields |
|
5870 changes, it is treated as a spiral and not a loop (see Section |
|
5871 16.3). A common way to create this value is to compute a |
|
5872 cryptographic hash of the To tag, From tag, Call-ID header |
|
5873 field, the Request-URI of the request received (before |
|
5874 translation), the topmost Via header, and the sequence number |
|
5875 from the CSeq header field, in addition to any Proxy-Require |
|
5876 and Proxy-Authorization header fields that may be present. The |
|
5877 |
|
5878 |
|
5879 |
|
5880 |
|
5881 |
|
5882 Rosenberg, et. al. Standards Track [Page 105] |
|
5883 |
|
5884 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5885 |
|
5886 |
|
5887 algorithm used to compute the hash is implementation-dependent, |
|
5888 but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a |
|
5889 reasonable choice. (Base64 is not permissible for a token.) |
|
5890 |
|
5891 If a proxy wishes to detect loops, the "branch" parameter it |
|
5892 supplies MUST depend on all information affecting processing of |
|
5893 a request, including the incoming Request-URI and any header |
|
5894 fields affecting the request's admission or routing. This is |
|
5895 necessary to distinguish looped requests from requests whose |
|
5896 routing parameters have changed before returning to this |
|
5897 server. |
|
5898 |
|
5899 The request method MUST NOT be included in the calculation of |
|
5900 the branch parameter. In particular, CANCEL and ACK requests |
|
5901 (for non-2xx responses) MUST have the same branch value as the |
|
5902 corresponding request they cancel or acknowledge. The branch |
|
5903 parameter is used in correlating those requests at the server |
|
5904 handling them (see Sections 17.2.3 and 9.2). |
|
5905 |
|
5906 9. Add a Content-Length header field if necessary |
|
5907 |
|
5908 If the request will be sent to the next hop using a stream- |
|
5909 based transport and the copy contains no Content-Length header |
|
5910 field, the proxy MUST insert one with the correct value for the |
|
5911 body of the request (see Section 20.14). |
|
5912 |
|
5913 10. Forward Request |
|
5914 |
|
5915 A stateful proxy MUST create a new client transaction for this |
|
5916 request as described in Section 17.1 and instructs the |
|
5917 transaction to send the request using the address, port and |
|
5918 transport determined in step 7. |
|
5919 |
|
5920 11. Set timer C |
|
5921 |
|
5922 In order to handle the case where an INVITE request never |
|
5923 generates a final response, the TU uses a timer which is called |
|
5924 timer C. Timer C MUST be set for each client transaction when |
|
5925 an INVITE request is proxied. The timer MUST be larger than 3 |
|
5926 minutes. Section 16.7 bullet 2 discusses how this timer is |
|
5927 updated with provisional responses, and Section 16.8 discusses |
|
5928 processing when it fires. |
|
5929 |
|
5930 |
|
5931 |
|
5932 |
|
5933 |
|
5934 |
|
5935 |
|
5936 |
|
5937 |
|
5938 Rosenberg, et. al. Standards Track [Page 106] |
|
5939 |
|
5940 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5941 |
|
5942 |
|
5943 16.7 Response Processing |
|
5944 |
|
5945 When a response is received by an element, it first tries to locate a |
|
5946 client transaction (Section 17.1.3) matching the response. If none |
|
5947 is found, the element MUST process the response (even if it is an |
|
5948 informational response) as a stateless proxy (described below). If a |
|
5949 match is found, the response is handed to the client transaction. |
|
5950 |
|
5951 Forwarding responses for which a client transaction (or more |
|
5952 generally any knowledge of having sent an associated request) is |
|
5953 not found improves robustness. In particular, it ensures that |
|
5954 "late" 2xx responses to INVITE requests are forwarded properly. |
|
5955 |
|
5956 As client transactions pass responses to the proxy layer, the |
|
5957 following processing MUST take place: |
|
5958 |
|
5959 1. Find the appropriate response context |
|
5960 |
|
5961 2. Update timer C for provisional responses |
|
5962 |
|
5963 3. Remove the topmost Via |
|
5964 |
|
5965 4. Add the response to the response context |
|
5966 |
|
5967 5. Check to see if this response should be forwarded immediately |
|
5968 |
|
5969 6. When necessary, choose the best final response from the |
|
5970 response context |
|
5971 |
|
5972 If no final response has been forwarded after every client |
|
5973 transaction associated with the response context has been terminated, |
|
5974 the proxy must choose and forward the "best" response from those it |
|
5975 has seen so far. |
|
5976 |
|
5977 The following processing MUST be performed on each response that is |
|
5978 forwarded. It is likely that more than one response to each request |
|
5979 will be forwarded: at least each provisional and one final response. |
|
5980 |
|
5981 7. Aggregate authorization header field values if necessary |
|
5982 |
|
5983 8. Optionally rewrite Record-Route header field values |
|
5984 |
|
5985 9. Forward the response |
|
5986 |
|
5987 10. Generate any necessary CANCEL requests |
|
5988 |
|
5989 |
|
5990 |
|
5991 |
|
5992 |
|
5993 |
|
5994 Rosenberg, et. al. Standards Track [Page 107] |
|
5995 |
|
5996 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
5997 |
|
5998 |
|
5999 Each of the above steps are detailed below: |
|
6000 |
|
6001 1. Find Context |
|
6002 |
|
6003 The proxy locates the "response context" it created before |
|
6004 forwarding the original request using the key described in |
|
6005 Section 16.6. The remaining processing steps take place in |
|
6006 this context. |
|
6007 |
|
6008 2. Update timer C for provisional responses |
|
6009 |
|
6010 For an INVITE transaction, if the response is a provisional |
|
6011 response with status codes 101 to 199 inclusive (i.e., anything |
|
6012 but 100), the proxy MUST reset timer C for that client |
|
6013 transaction. The timer MAY be reset to a different value, but |
|
6014 this value MUST be greater than 3 minutes. |
|
6015 |
|
6016 3. Via |
|
6017 |
|
6018 The proxy removes the topmost Via header field value from the |
|
6019 response. |
|
6020 |
|
6021 If no Via header field values remain in the response, the |
|
6022 response was meant for this element and MUST NOT be forwarded. |
|
6023 The remainder of the processing described in this section is |
|
6024 not performed on this message, the UAC processing rules |
|
6025 described in Section 8.1.3 are followed instead (transport |
|
6026 layer processing has already occurred). |
|
6027 |
|
6028 This will happen, for instance, when the element generates |
|
6029 CANCEL requests as described in Section 10. |
|
6030 |
|
6031 4. Add response to context |
|
6032 |
|
6033 Final responses received are stored in the response context |
|
6034 until a final response is generated on the server transaction |
|
6035 associated with this context. The response may be a candidate |
|
6036 for the best final response to be returned on that server |
|
6037 transaction. Information from this response may be needed in |
|
6038 forming the best response, even if this response is not chosen. |
|
6039 |
|
6040 If the proxy chooses to recurse on any contacts in a 3xx |
|
6041 response by adding them to the target set, it MUST remove them |
|
6042 from the response before adding the response to the response |
|
6043 context. However, a proxy SHOULD NOT recurse to a non-SIPS URI |
|
6044 if the Request-URI of the original request was a SIPS URI. If |
|
6045 |
|
6046 |
|
6047 |
|
6048 |
|
6049 |
|
6050 Rosenberg, et. al. Standards Track [Page 108] |
|
6051 |
|
6052 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6053 |
|
6054 |
|
6055 the proxy recurses on all of the contacts in a 3xx response, |
|
6056 the proxy SHOULD NOT add the resulting contactless response to |
|
6057 the response context. |
|
6058 |
|
6059 Removing the contact before adding the response to the response |
|
6060 context prevents the next element upstream from retrying a |
|
6061 location this proxy has already attempted. |
|
6062 |
|
6063 3xx responses may contain a mixture of SIP, SIPS, and non-SIP |
|
6064 URIs. A proxy may choose to recurse on the SIP and SIPS URIs |
|
6065 and place the remainder into the response context to be |
|
6066 returned, potentially in the final response. |
|
6067 |
|
6068 If a proxy receives a 416 (Unsupported URI Scheme) response to |
|
6069 a request whose Request-URI scheme was not SIP, but the scheme |
|
6070 in the original received request was SIP or SIPS (that is, the |
|
6071 proxy changed the scheme from SIP or SIPS to something else |
|
6072 when it proxied a request), the proxy SHOULD add a new URI to |
|
6073 the target set. This URI SHOULD be a SIP URI version of the |
|
6074 non-SIP URI that was just tried. In the case of the tel URL, |
|
6075 this is accomplished by placing the telephone-subscriber part |
|
6076 of the tel URL into the user part of the SIP URI, and setting |
|
6077 the hostpart to the domain where the prior request was sent. |
|
6078 See Section 19.1.6 for more detail on forming SIP URIs from tel |
|
6079 URLs. |
|
6080 |
|
6081 As with a 3xx response, if a proxy "recurses" on the 416 by |
|
6082 trying a SIP or SIPS URI instead, the 416 response SHOULD NOT |
|
6083 be added to the response context. |
|
6084 |
|
6085 5. Check response for forwarding |
|
6086 |
|
6087 Until a final response has been sent on the server transaction, |
|
6088 the following responses MUST be forwarded immediately: |
|
6089 |
|
6090 - Any provisional response other than 100 (Trying) |
|
6091 |
|
6092 - Any 2xx response |
|
6093 |
|
6094 If a 6xx response is received, it is not immediately forwarded, |
|
6095 but the stateful proxy SHOULD cancel all client pending |
|
6096 transactions as described in Section 10, and it MUST NOT create |
|
6097 any new branches in this context. |
|
6098 |
|
6099 This is a change from RFC 2543, which mandated that the proxy |
|
6100 was to forward the 6xx response immediately. For an INVITE |
|
6101 transaction, this approach had the problem that a 2xx response |
|
6102 could arrive on another branch, in which case the proxy would |
|
6103 |
|
6104 |
|
6105 |
|
6106 Rosenberg, et. al. Standards Track [Page 109] |
|
6107 |
|
6108 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6109 |
|
6110 |
|
6111 have to forward the 2xx. The result was that the UAC could |
|
6112 receive a 6xx response followed by a 2xx response, which should |
|
6113 never be allowed to happen. Under the new rules, upon |
|
6114 receiving a 6xx, a proxy will issue a CANCEL request, which |
|
6115 will generally result in 487 responses from all outstanding |
|
6116 client transactions, and then at that point the 6xx is |
|
6117 forwarded upstream. |
|
6118 |
|
6119 After a final response has been sent on the server transaction, |
|
6120 the following responses MUST be forwarded immediately: |
|
6121 |
|
6122 - Any 2xx response to an INVITE request |
|
6123 |
|
6124 A stateful proxy MUST NOT immediately forward any other |
|
6125 responses. In particular, a stateful proxy MUST NOT forward |
|
6126 any 100 (Trying) response. Those responses that are candidates |
|
6127 for forwarding later as the "best" response have been gathered |
|
6128 as described in step "Add Response to Context". |
|
6129 |
|
6130 Any response chosen for immediate forwarding MUST be processed |
|
6131 as described in steps "Aggregate Authorization Header Field |
|
6132 Values" through "Record-Route". |
|
6133 |
|
6134 This step, combined with the next, ensures that a stateful |
|
6135 proxy will forward exactly one final response to a non-INVITE |
|
6136 request, and either exactly one non-2xx response or one or more |
|
6137 2xx responses to an INVITE request. |
|
6138 |
|
6139 6. Choosing the best response |
|
6140 |
|
6141 A stateful proxy MUST send a final response to a response |
|
6142 context's server transaction if no final responses have been |
|
6143 immediately forwarded by the above rules and all client |
|
6144 transactions in this response context have been terminated. |
|
6145 |
|
6146 The stateful proxy MUST choose the "best" final response among |
|
6147 those received and stored in the response context. |
|
6148 |
|
6149 If there are no final responses in the context, the proxy MUST |
|
6150 send a 408 (Request Timeout) response to the server |
|
6151 transaction. |
|
6152 |
|
6153 Otherwise, the proxy MUST forward a response from the responses |
|
6154 stored in the response context. It MUST choose from the 6xx |
|
6155 class responses if any exist in the context. If no 6xx class |
|
6156 responses are present, the proxy SHOULD choose from the lowest |
|
6157 response class stored in the response context. The proxy MAY |
|
6158 select any response within that chosen class. The proxy SHOULD |
|
6159 |
|
6160 |
|
6161 |
|
6162 Rosenberg, et. al. Standards Track [Page 110] |
|
6163 |
|
6164 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6165 |
|
6166 |
|
6167 give preference to responses that provide information affecting |
|
6168 resubmission of this request, such as 401, 407, 415, 420, and |
|
6169 484 if the 4xx class is chosen. |
|
6170 |
|
6171 A proxy which receives a 503 (Service Unavailable) response |
|
6172 SHOULD NOT forward it upstream unless it can determine that any |
|
6173 subsequent requests it might proxy will also generate a 503. |
|
6174 In other words, forwarding a 503 means that the proxy knows it |
|
6175 cannot service any requests, not just the one for the Request- |
|
6176 URI in the request which generated the 503. If the only |
|
6177 response that was received is a 503, the proxy SHOULD generate |
|
6178 a 500 response and forward that upstream. |
|
6179 |
|
6180 The forwarded response MUST be processed as described in steps |
|
6181 "Aggregate Authorization Header Field Values" through "Record- |
|
6182 Route". |
|
6183 |
|
6184 For example, if a proxy forwarded a request to 4 locations, and |
|
6185 received 503, 407, 501, and 404 responses, it may choose to |
|
6186 forward the 407 (Proxy Authentication Required) response. |
|
6187 |
|
6188 1xx and 2xx responses may be involved in the establishment of |
|
6189 dialogs. When a request does not contain a To tag, the To tag |
|
6190 in the response is used by the UAC to distinguish multiple |
|
6191 responses to a dialog creating request. A proxy MUST NOT |
|
6192 insert a tag into the To header field of a 1xx or 2xx response |
|
6193 if the request did not contain one. A proxy MUST NOT modify |
|
6194 the tag in the To header field of a 1xx or 2xx response. |
|
6195 |
|
6196 Since a proxy may not insert a tag into the To header field of |
|
6197 a 1xx response to a request that did not contain one, it cannot |
|
6198 issue non-100 provisional responses on its own. However, it |
|
6199 can branch the request to a UAS sharing the same element as the |
|
6200 proxy. This UAS can return its own provisional responses, |
|
6201 entering into an early dialog with the initiator of the |
|
6202 request. The UAS does not have to be a discreet process from |
|
6203 the proxy. It could be a virtual UAS implemented in the same |
|
6204 code space as the proxy. |
|
6205 |
|
6206 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx |
|
6207 response, the element is effectively acting as a UAS, issuing |
|
6208 its own response, usually based on the responses received from |
|
6209 downstream elements. An element SHOULD preserve the To tag |
|
6210 when simply forwarding a 3-6xx response to a request that did |
|
6211 not contain a To tag. |
|
6212 |
|
6213 A proxy MUST NOT modify the To tag in any forwarded response to |
|
6214 a request that contains a To tag. |
|
6215 |
|
6216 |
|
6217 |
|
6218 Rosenberg, et. al. Standards Track [Page 111] |
|
6219 |
|
6220 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6221 |
|
6222 |
|
6223 While it makes no difference to the upstream elements if the |
|
6224 proxy replaced the To tag in a forwarded 3-6xx response, |
|
6225 preserving the original tag may assist with debugging. |
|
6226 |
|
6227 When the proxy is aggregating information from several |
|
6228 responses, choosing a To tag from among them is arbitrary, and |
|
6229 generating a new To tag may make debugging easier. This |
|
6230 happens, for instance, when combining 401 (Unauthorized) and |
|
6231 407 (Proxy Authentication Required) challenges, or combining |
|
6232 Contact values from unencrypted and unauthenticated 3xx |
|
6233 responses. |
|
6234 |
|
6235 7. Aggregate Authorization Header Field Values |
|
6236 |
|
6237 If the selected response is a 401 (Unauthorized) or 407 (Proxy |
|
6238 Authentication Required), the proxy MUST collect any WWW- |
|
6239 Authenticate and Proxy-Authenticate header field values from |
|
6240 all other 401 (Unauthorized) and 407 (Proxy Authentication |
|
6241 Required) responses received so far in this response context |
|
6242 and add them to this response without modification before |
|
6243 forwarding. The resulting 401 (Unauthorized) or 407 (Proxy |
|
6244 Authentication Required) response could have several WWW- |
|
6245 Authenticate AND Proxy-Authenticate header field values. |
|
6246 |
|
6247 This is necessary because any or all of the destinations the |
|
6248 request was forwarded to may have requested credentials. The |
|
6249 client needs to receive all of those challenges and supply |
|
6250 credentials for each of them when it retries the request. |
|
6251 Motivation for this behavior is provided in Section 26. |
|
6252 |
|
6253 8. Record-Route |
|
6254 |
|
6255 If the selected response contains a Record-Route header field |
|
6256 value originally provided by this proxy, the proxy MAY choose |
|
6257 to rewrite the value before forwarding the response. This |
|
6258 allows the proxy to provide different URIs for itself to the |
|
6259 next upstream and downstream elements. A proxy may choose to |
|
6260 use this mechanism for any reason. For instance, it is useful |
|
6261 for multi-homed hosts. |
|
6262 |
|
6263 If the proxy received the request over TLS, and sent it out |
|
6264 over a non-TLS connection, the proxy MUST rewrite the URI in |
|
6265 the Record-Route header field to be a SIPS URI. If the proxy |
|
6266 received the request over a non-TLS connection, and sent it out |
|
6267 over TLS, the proxy MUST rewrite the URI in the Record-Route |
|
6268 header field to be a SIP URI. |
|
6269 |
|
6270 |
|
6271 |
|
6272 |
|
6273 |
|
6274 Rosenberg, et. al. Standards Track [Page 112] |
|
6275 |
|
6276 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6277 |
|
6278 |
|
6279 The new URI provided by the proxy MUST satisfy the same |
|
6280 constraints on URIs placed in Record-Route header fields in |
|
6281 requests (see Step 4 of Section 16.6) with the following |
|
6282 modifications: |
|
6283 |
|
6284 The URI SHOULD NOT contain the transport parameter unless the |
|
6285 proxy has knowledge that the next upstream (as opposed to |
|
6286 downstream) element that will be in the path of subsequent |
|
6287 requests supports that transport. |
|
6288 |
|
6289 When a proxy does decide to modify the Record-Route header |
|
6290 field in the response, one of the operations it performs is |
|
6291 locating the Record-Route value that it had inserted. If the |
|
6292 request spiraled, and the proxy inserted a Record-Route value |
|
6293 in each iteration of the spiral, locating the correct value in |
|
6294 the response (which must be the proper iteration in the reverse |
|
6295 direction) is tricky. The rules above recommend that a proxy |
|
6296 wishing to rewrite Record-Route header field values insert |
|
6297 sufficiently distinct URIs into the Record-Route header field |
|
6298 so that the right one may be selected for rewriting. A |
|
6299 RECOMMENDED mechanism to achieve this is for the proxy to |
|
6300 append a unique identifier for the proxy instance to the user |
|
6301 portion of the URI. |
|
6302 |
|
6303 When the response arrives, the proxy modifies the first |
|
6304 Record-Route whose identifier matches the proxy instance. The |
|
6305 modification results in a URI without this piece of data |
|
6306 appended to the user portion of the URI. Upon the next |
|
6307 iteration, the same algorithm (find the topmost Record-Route |
|
6308 header field value with the parameter) will correctly extract |
|
6309 the next Record-Route header field value inserted by that |
|
6310 proxy. |
|
6311 |
|
6312 Not every response to a request to which a proxy adds a |
|
6313 Record-Route header field value will contain a Record-Route |
|
6314 header field. If the response does contain a Record-Route |
|
6315 header field, it will contain the value the proxy added. |
|
6316 |
|
6317 9. Forward response |
|
6318 |
|
6319 After performing the processing described in steps "Aggregate |
|
6320 Authorization Header Field Values" through "Record-Route", the |
|
6321 proxy MAY perform any feature specific manipulations on the |
|
6322 selected response. The proxy MUST NOT add to, modify, or |
|
6323 remove the message body. Unless otherwise specified, the proxy |
|
6324 MUST NOT remove any header field values other than the Via |
|
6325 header field value discussed in Section 16.7 Item 3. In |
|
6326 particular, the proxy MUST NOT remove any "received" parameter |
|
6327 |
|
6328 |
|
6329 |
|
6330 Rosenberg, et. al. Standards Track [Page 113] |
|
6331 |
|
6332 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6333 |
|
6334 |
|
6335 it may have added to the next Via header field value while |
|
6336 processing the request associated with this response. The |
|
6337 proxy MUST pass the response to the server transaction |
|
6338 associated with the response context. This will result in the |
|
6339 response being sent to the location now indicated in the |
|
6340 topmost Via header field value. If the server transaction is |
|
6341 no longer available to handle the transmission, the element |
|
6342 MUST forward the response statelessly by sending it to the |
|
6343 server transport. The server transaction might indicate |
|
6344 failure to send the response or signal a timeout in its state |
|
6345 machine. These errors would be logged for diagnostic purposes |
|
6346 as appropriate, but the protocol requires no remedial action |
|
6347 from the proxy. |
|
6348 |
|
6349 The proxy MUST maintain the response context until all of its |
|
6350 associated transactions have been terminated, even after |
|
6351 forwarding a final response. |
|
6352 |
|
6353 10. Generate CANCELs |
|
6354 |
|
6355 If the forwarded response was a final response, the proxy MUST |
|
6356 generate a CANCEL request for all pending client transactions |
|
6357 associated with this response context. A proxy SHOULD also |
|
6358 generate a CANCEL request for all pending client transactions |
|
6359 associated with this response context when it receives a 6xx |
|
6360 response. A pending client transaction is one that has |
|
6361 received a provisional response, but no final response (it is |
|
6362 in the proceeding state) and has not had an associated CANCEL |
|
6363 generated for it. Generating CANCEL requests is described in |
|
6364 Section 9.1. |
|
6365 |
|
6366 The requirement to CANCEL pending client transactions upon |
|
6367 forwarding a final response does not guarantee that an endpoint |
|
6368 will not receive multiple 200 (OK) responses to an INVITE. 200 |
|
6369 (OK) responses on more than one branch may be generated before |
|
6370 the CANCEL requests can be sent and processed. Further, it is |
|
6371 reasonable to expect that a future extension may override this |
|
6372 requirement to issue CANCEL requests. |
|
6373 |
|
6374 16.8 Processing Timer C |
|
6375 |
|
6376 If timer C should fire, the proxy MUST either reset the timer with |
|
6377 any value it chooses, or terminate the client transaction. If the |
|
6378 client transaction has received a provisional response, the proxy |
|
6379 MUST generate a CANCEL request matching that transaction. If the |
|
6380 client transaction has not received a provisional response, the proxy |
|
6381 MUST behave as if the transaction received a 408 (Request Timeout) |
|
6382 response. |
|
6383 |
|
6384 |
|
6385 |
|
6386 Rosenberg, et. al. Standards Track [Page 114] |
|
6387 |
|
6388 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6389 |
|
6390 |
|
6391 Allowing the proxy to reset the timer allows the proxy to dynamically |
|
6392 extend the transaction's lifetime based on current conditions (such |
|
6393 as utilization) when the timer fires. |
|
6394 |
|
6395 16.9 Handling Transport Errors |
|
6396 |
|
6397 If the transport layer notifies a proxy of an error when it tries to |
|
6398 forward a request (see Section 18.4), the proxy MUST behave as if the |
|
6399 forwarded request received a 503 (Service Unavailable) response. |
|
6400 |
|
6401 If the proxy is notified of an error when forwarding a response, it |
|
6402 drops the response. The proxy SHOULD NOT cancel any outstanding |
|
6403 client transactions associated with this response context due to this |
|
6404 notification. |
|
6405 |
|
6406 If a proxy cancels its outstanding client transactions, a single |
|
6407 malicious or misbehaving client can cause all transactions to fail |
|
6408 through its Via header field. |
|
6409 |
|
6410 16.10 CANCEL Processing |
|
6411 |
|
6412 A stateful proxy MAY generate a CANCEL to any other request it has |
|
6413 generated at any time (subject to receiving a provisional response to |
|
6414 that request as described in section 9.1). A proxy MUST cancel any |
|
6415 pending client transactions associated with a response context when |
|
6416 it receives a matching CANCEL request. |
|
6417 |
|
6418 A stateful proxy MAY generate CANCEL requests for pending INVITE |
|
6419 client transactions based on the period specified in the INVITE's |
|
6420 Expires header field elapsing. However, this is generally |
|
6421 unnecessary since the endpoints involved will take care of signaling |
|
6422 the end of the transaction. |
|
6423 |
|
6424 While a CANCEL request is handled in a stateful proxy by its own |
|
6425 server transaction, a new response context is not created for it. |
|
6426 Instead, the proxy layer searches its existing response contexts for |
|
6427 the server transaction handling the request associated with this |
|
6428 CANCEL. If a matching response context is found, the element MUST |
|
6429 immediately return a 200 (OK) response to the CANCEL request. In |
|
6430 this case, the element is acting as a user agent server as defined in |
|
6431 Section 8.2. Furthermore, the element MUST generate CANCEL requests |
|
6432 for all pending client transactions in the context as described in |
|
6433 Section 16.7 step 10. |
|
6434 |
|
6435 If a response context is not found, the element does not have any |
|
6436 knowledge of the request to apply the CANCEL to. It MUST statelessly |
|
6437 forward the CANCEL request (it may have statelessly forwarded the |
|
6438 associated request previously). |
|
6439 |
|
6440 |
|
6441 |
|
6442 Rosenberg, et. al. Standards Track [Page 115] |
|
6443 |
|
6444 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6445 |
|
6446 |
|
6447 16.11 Stateless Proxy |
|
6448 |
|
6449 When acting statelessly, a proxy is a simple message forwarder. Much |
|
6450 of the processing performed when acting statelessly is the same as |
|
6451 when behaving statefully. The differences are detailed here. |
|
6452 |
|
6453 A stateless proxy does not have any notion of a transaction, or of |
|
6454 the response context used to describe stateful proxy behavior. |
|
6455 Instead, the stateless proxy takes messages, both requests and |
|
6456 responses, directly from the transport layer (See section 18). As a |
|
6457 result, stateless proxies do not retransmit messages on their own. |
|
6458 They do, however, forward all retransmissions they receive (they do |
|
6459 not have the ability to distinguish a retransmission from the |
|
6460 original message). Furthermore, when handling a request statelessly, |
|
6461 an element MUST NOT generate its own 100 (Trying) or any other |
|
6462 provisional response. |
|
6463 |
|
6464 A stateless proxy MUST validate a request as described in Section |
|
6465 16.3 |
|
6466 |
|
6467 A stateless proxy MUST follow the request processing steps described |
|
6468 in Sections 16.4 through 16.5 with the following exception: |
|
6469 |
|
6470 o A stateless proxy MUST choose one and only one target from the |
|
6471 target set. This choice MUST only rely on fields in the |
|
6472 message and time-invariant properties of the server. In |
|
6473 particular, a retransmitted request MUST be forwarded to the |
|
6474 same destination each time it is processed. Furthermore, |
|
6475 CANCEL and non-Routed ACK requests MUST generate the same |
|
6476 choice as their associated INVITE. |
|
6477 |
|
6478 A stateless proxy MUST follow the request processing steps described |
|
6479 in Section 16.6 with the following exceptions: |
|
6480 |
|
6481 o The requirement for unique branch IDs across space and time |
|
6482 applies to stateless proxies as well. However, a stateless |
|
6483 proxy cannot simply use a random number generator to compute |
|
6484 the first component of the branch ID, as described in Section |
|
6485 16.6 bullet 8. This is because retransmissions of a request |
|
6486 need to have the same value, and a stateless proxy cannot tell |
|
6487 a retransmission from the original request. Therefore, the |
|
6488 component of the branch parameter that makes it unique MUST be |
|
6489 the same each time a retransmitted request is forwarded. Thus |
|
6490 for a stateless proxy, the branch parameter MUST be computed as |
|
6491 a combinatoric function of message parameters which are |
|
6492 invariant on retransmission. |
|
6493 |
|
6494 |
|
6495 |
|
6496 |
|
6497 |
|
6498 Rosenberg, et. al. Standards Track [Page 116] |
|
6499 |
|
6500 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6501 |
|
6502 |
|
6503 The stateless proxy MAY use any technique it likes to guarantee |
|
6504 uniqueness of its branch IDs across transactions. However, the |
|
6505 following procedure is RECOMMENDED. The proxy examines the |
|
6506 branch ID in the topmost Via header field of the received |
|
6507 request. If it begins with the magic cookie, the first |
|
6508 component of the branch ID of the outgoing request is computed |
|
6509 as a hash of the received branch ID. Otherwise, the first |
|
6510 component of the branch ID is computed as a hash of the topmost |
|
6511 Via, the tag in the To header field, the tag in the From header |
|
6512 field, the Call-ID header field, the CSeq number (but not |
|
6513 method), and the Request-URI from the received request. One of |
|
6514 these fields will always vary across two different |
|
6515 transactions. |
|
6516 |
|
6517 o All other message transformations specified in Section 16.6 |
|
6518 MUST result in the same transformation of a retransmitted |
|
6519 request. In particular, if the proxy inserts a Record-Route |
|
6520 value or pushes URIs into the Route header field, it MUST place |
|
6521 the same values in retransmissions of the request. As for the |
|
6522 Via branch parameter, this implies that the transformations |
|
6523 MUST be based on time-invariant configuration or |
|
6524 retransmission-invariant properties of the request. |
|
6525 |
|
6526 o A stateless proxy determines where to forward the request as |
|
6527 described for stateful proxies in Section 16.6 Item 10. The |
|
6528 request is sent directly to the transport layer instead of |
|
6529 through a client transaction. |
|
6530 |
|
6531 Since a stateless proxy must forward retransmitted requests to |
|
6532 the same destination and add identical branch parameters to |
|
6533 each of them, it can only use information from the message |
|
6534 itself and time-invariant configuration data for those |
|
6535 calculations. If the configuration state is not time-invariant |
|
6536 (for example, if a routing table is updated) any requests that |
|
6537 could be affected by the change may not be forwarded |
|
6538 statelessly during an interval equal to the transaction timeout |
|
6539 window before or after the change. The method of processing |
|
6540 the affected requests in that interval is an implementation |
|
6541 decision. A common solution is to forward them transaction |
|
6542 statefully. |
|
6543 |
|
6544 Stateless proxies MUST NOT perform special processing for CANCEL |
|
6545 requests. They are processed by the above rules as any other |
|
6546 requests. In particular, a stateless proxy applies the same Route |
|
6547 header field processing to CANCEL requests that it applies to any |
|
6548 other request. |
|
6549 |
|
6550 |
|
6551 |
|
6552 |
|
6553 |
|
6554 Rosenberg, et. al. Standards Track [Page 117] |
|
6555 |
|
6556 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6557 |
|
6558 |
|
6559 Response processing as described in Section 16.7 does not apply to a |
|
6560 proxy behaving statelessly. When a response arrives at a stateless |
|
6561 proxy, the proxy MUST inspect the sent-by value in the first |
|
6562 (topmost) Via header field value. If that address matches the proxy, |
|
6563 (it equals a value this proxy has inserted into previous requests) |
|
6564 the proxy MUST remove that header field value from the response and |
|
6565 forward the result to the location indicated in the next Via header |
|
6566 field value. The proxy MUST NOT add to, modify, or remove the |
|
6567 message body. Unless specified otherwise, the proxy MUST NOT remove |
|
6568 any other header field values. If the address does not match the |
|
6569 proxy, the message MUST be silently discarded. |
|
6570 |
|
6571 16.12 Summary of Proxy Route Processing |
|
6572 |
|
6573 In the absence of local policy to the contrary, the processing a |
|
6574 proxy performs on a request containing a Route header field can be |
|
6575 summarized in the following steps. |
|
6576 |
|
6577 1. The proxy will inspect the Request-URI. If it indicates a |
|
6578 resource owned by this proxy, the proxy will replace it with |
|
6579 the results of running a location service. Otherwise, the |
|
6580 proxy will not change the Request-URI. |
|
6581 |
|
6582 2. The proxy will inspect the URI in the topmost Route header |
|
6583 field value. If it indicates this proxy, the proxy removes it |
|
6584 from the Route header field (this route node has been |
|
6585 reached). |
|
6586 |
|
6587 3. The proxy will forward the request to the resource indicated |
|
6588 by the URI in the topmost Route header field value or in the |
|
6589 Request-URI if no Route header field is present. The proxy |
|
6590 determines the address, port and transport to use when |
|
6591 forwarding the request by applying the procedures in [4] to |
|
6592 that URI. |
|
6593 |
|
6594 If no strict-routing elements are encountered on the path of the |
|
6595 request, the Request-URI will always indicate the target of the |
|
6596 request. |
|
6597 |
|
6598 16.12.1 Examples |
|
6599 |
|
6600 16.12.1.1 Basic SIP Trapezoid |
|
6601 |
|
6602 This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with |
|
6603 both proxies record-routing. Here is the flow. |
|
6604 |
|
6605 |
|
6606 |
|
6607 |
|
6608 |
|
6609 |
|
6610 Rosenberg, et. al. Standards Track [Page 118] |
|
6611 |
|
6612 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6613 |
|
6614 |
|
6615 U1 sends: |
|
6616 |
|
6617 INVITE sip:callee@domain.com SIP/2.0 |
|
6618 Contact: sip:caller@u1.example.com |
|
6619 |
|
6620 to P1. P1 is an outbound proxy. P1 is not responsible for |
|
6621 domain.com, so it looks it up in DNS and sends it there. It also |
|
6622 adds a Record-Route header field value: |
|
6623 |
|
6624 INVITE sip:callee@domain.com SIP/2.0 |
|
6625 Contact: sip:caller@u1.example.com |
|
6626 Record-Route: <sip:p1.example.com;lr> |
|
6627 |
|
6628 P2 gets this. It is responsible for domain.com so it runs a location |
|
6629 service and rewrites the Request-URI. It also adds a Record-Route |
|
6630 header field value. There is no Route header field, so it resolves |
|
6631 the new Request-URI to determine where to send the request: |
|
6632 |
|
6633 INVITE sip:callee@u2.domain.com SIP/2.0 |
|
6634 Contact: sip:caller@u1.example.com |
|
6635 Record-Route: <sip:p2.domain.com;lr> |
|
6636 Record-Route: <sip:p1.example.com;lr> |
|
6637 |
|
6638 The callee at u2.domain.com gets this and responds with a 200 OK: |
|
6639 |
|
6640 SIP/2.0 200 OK |
|
6641 Contact: sip:callee@u2.domain.com |
|
6642 Record-Route: <sip:p2.domain.com;lr> |
|
6643 Record-Route: <sip:p1.example.com;lr> |
|
6644 |
|
6645 The callee at u2 also sets its dialog state's remote target URI to |
|
6646 sip:caller@u1.example.com and its route set to: |
|
6647 |
|
6648 (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>) |
|
6649 |
|
6650 This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its |
|
6651 dialog state's remote target URI to sip:callee@u2.domain.com and its |
|
6652 route set to: |
|
6653 |
|
6654 (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>) |
|
6655 |
|
6656 Since all the route set elements contain the lr parameter, U1 |
|
6657 constructs the following BYE request: |
|
6658 |
|
6659 BYE sip:callee@u2.domain.com SIP/2.0 |
|
6660 Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr> |
|
6661 |
|
6662 |
|
6663 |
|
6664 |
|
6665 |
|
6666 Rosenberg, et. al. Standards Track [Page 119] |
|
6667 |
|
6668 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6669 |
|
6670 |
|
6671 As any other element (including proxies) would do, it resolves the |
|
6672 URI in the topmost Route header field value using DNS to determine |
|
6673 where to send the request. This goes to P1. P1 notices that it is |
|
6674 not responsible for the resource indicated in the Request-URI so it |
|
6675 doesn't change it. It does see that it is the first value in the |
|
6676 Route header field, so it removes that value, and forwards the |
|
6677 request to P2: |
|
6678 |
|
6679 BYE sip:callee@u2.domain.com SIP/2.0 |
|
6680 Route: <sip:p2.domain.com;lr> |
|
6681 |
|
6682 P2 also notices it is not responsible for the resource indicated by |
|
6683 the Request-URI (it is responsible for domain.com, not |
|
6684 u2.domain.com), so it doesn't change it. It does see itself in the |
|
6685 first Route header field value, so it removes it and forwards the |
|
6686 following to u2.domain.com based on a DNS lookup against the |
|
6687 Request-URI: |
|
6688 |
|
6689 BYE sip:callee@u2.domain.com SIP/2.0 |
|
6690 |
|
6691 16.12.1.2 Traversing a Strict-Routing Proxy |
|
6692 |
|
6693 In this scenario, a dialog is established across four proxies, each |
|
6694 of which adds Record-Route header field values. The third proxy |
|
6695 implements the strict-routing procedures specified in RFC 2543 and |
|
6696 many works in progress. |
|
6697 |
|
6698 U1->P1->P2->P3->P4->U2 |
|
6699 |
|
6700 The INVITE arriving at U2 contains: |
|
6701 |
|
6702 INVITE sip:callee@u2.domain.com SIP/2.0 |
|
6703 Contact: sip:caller@u1.example.com |
|
6704 Record-Route: <sip:p4.domain.com;lr> |
|
6705 Record-Route: <sip:p3.middle.com> |
|
6706 Record-Route: <sip:p2.example.com;lr> |
|
6707 Record-Route: <sip:p1.example.com;lr> |
|
6708 |
|
6709 Which U2 responds to with a 200 OK. Later, U2 sends the following |
|
6710 BYE request to P4 based on the first Route header field value. |
|
6711 |
|
6712 BYE sip:caller@u1.example.com SIP/2.0 |
|
6713 Route: <sip:p4.domain.com;lr> |
|
6714 Route: <sip:p3.middle.com> |
|
6715 Route: <sip:p2.example.com;lr> |
|
6716 Route: <sip:p1.example.com;lr> |
|
6717 |
|
6718 |
|
6719 |
|
6720 |
|
6721 |
|
6722 Rosenberg, et. al. Standards Track [Page 120] |
|
6723 |
|
6724 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6725 |
|
6726 |
|
6727 P4 is not responsible for the resource indicated in the Request-URI |
|
6728 so it will leave it alone. It notices that it is the element in the |
|
6729 first Route header field value so it removes it. It then prepares to |
|
6730 send the request based on the now first Route header field value of |
|
6731 sip:p3.middle.com, but it notices that this URI does not contain the |
|
6732 lr parameter, so before sending, it reformats the request to be: |
|
6733 |
|
6734 BYE sip:p3.middle.com SIP/2.0 |
|
6735 Route: <sip:p2.example.com;lr> |
|
6736 Route: <sip:p1.example.com;lr> |
|
6737 Route: <sip:caller@u1.example.com> |
|
6738 |
|
6739 P3 is a strict router, so it forwards the following to P2: |
|
6740 |
|
6741 BYE sip:p2.example.com;lr SIP/2.0 |
|
6742 Route: <sip:p1.example.com;lr> |
|
6743 Route: <sip:caller@u1.example.com> |
|
6744 |
|
6745 P2 sees the request-URI is a value it placed into a Record-Route |
|
6746 header field, so before further processing, it rewrites the request |
|
6747 to be: |
|
6748 |
|
6749 BYE sip:caller@u1.example.com SIP/2.0 |
|
6750 Route: <sip:p1.example.com;lr> |
|
6751 |
|
6752 P2 is not responsible for u1.example.com, so it sends the request to |
|
6753 P1 based on the resolution of the Route header field value. |
|
6754 |
|
6755 P1 notices itself in the topmost Route header field value, so it |
|
6756 removes it, resulting in: |
|
6757 |
|
6758 BYE sip:caller@u1.example.com SIP/2.0 |
|
6759 |
|
6760 Since P1 is not responsible for u1.example.com and there is no Route |
|
6761 header field, P1 will forward the request to u1.example.com based on |
|
6762 the Request-URI. |
|
6763 |
|
6764 16.12.1.3 Rewriting Record-Route Header Field Values |
|
6765 |
|
6766 In this scenario, U1 and U2 are in different private namespaces and |
|
6767 they enter a dialog through a proxy P1, which acts as a gateway |
|
6768 between the namespaces. |
|
6769 |
|
6770 U1->P1->U2 |
|
6771 |
|
6772 |
|
6773 |
|
6774 |
|
6775 |
|
6776 |
|
6777 |
|
6778 Rosenberg, et. al. Standards Track [Page 121] |
|
6779 |
|
6780 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6781 |
|
6782 |
|
6783 U1 sends: |
|
6784 |
|
6785 INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 |
|
6786 Contact: <sip:caller@u1.leftprivatespace.com> |
|
6787 |
|
6788 P1 uses its location service and sends the following to U2: |
|
6789 |
|
6790 INVITE sip:callee@rightprivatespace.com SIP/2.0 |
|
6791 Contact: <sip:caller@u1.leftprivatespace.com> |
|
6792 Record-Route: <sip:gateway.rightprivatespace.com;lr> |
|
6793 |
|
6794 U2 sends this 200 (OK) back to P1: |
|
6795 |
|
6796 SIP/2.0 200 OK |
|
6797 Contact: <sip:callee@u2.rightprivatespace.com> |
|
6798 Record-Route: <sip:gateway.rightprivatespace.com;lr> |
|
6799 |
|
6800 P1 rewrites its Record-Route header parameter to provide a value that |
|
6801 U1 will find useful, and sends the following to U1: |
|
6802 |
|
6803 SIP/2.0 200 OK |
|
6804 Contact: <sip:callee@u2.rightprivatespace.com> |
|
6805 Record-Route: <sip:gateway.leftprivatespace.com;lr> |
|
6806 |
|
6807 Later, U1 sends the following BYE request to P1: |
|
6808 |
|
6809 BYE sip:callee@u2.rightprivatespace.com SIP/2.0 |
|
6810 Route: <sip:gateway.leftprivatespace.com;lr> |
|
6811 |
|
6812 which P1 forwards to U2 as: |
|
6813 |
|
6814 BYE sip:callee@u2.rightprivatespace.com SIP/2.0 |
|
6815 |
|
6816 17 Transactions |
|
6817 |
|
6818 SIP is a transactional protocol: interactions between components take |
|
6819 place in a series of independent message exchanges. Specifically, a |
|
6820 SIP transaction consists of a single request and any responses to |
|
6821 that request, which include zero or more provisional responses and |
|
6822 one or more final responses. In the case of a transaction where the |
|
6823 request was an INVITE (known as an INVITE transaction), the |
|
6824 transaction also includes the ACK only if the final response was not |
|
6825 a 2xx response. If the response was a 2xx, the ACK is not considered |
|
6826 part of the transaction. |
|
6827 |
|
6828 The reason for this separation is rooted in the importance of |
|
6829 delivering all 200 (OK) responses to an INVITE to the UAC. To |
|
6830 deliver them all to the UAC, the UAS alone takes responsibility |
|
6831 |
|
6832 |
|
6833 |
|
6834 Rosenberg, et. al. Standards Track [Page 122] |
|
6835 |
|
6836 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6837 |
|
6838 |
|
6839 for retransmitting them (see Section 13.3.1.4), and the UAC alone |
|
6840 takes responsibility for acknowledging them with ACK (see Section |
|
6841 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is |
|
6842 effectively considered its own transaction. |
|
6843 |
|
6844 Transactions have a client side and a server side. The client side |
|
6845 is known as a client transaction and the server side as a server |
|
6846 transaction. The client transaction sends the request, and the |
|
6847 server transaction sends the response. The client and server |
|
6848 transactions are logical functions that are embedded in any number of |
|
6849 elements. Specifically, they exist within user agents and stateful |
|
6850 proxy servers. Consider the example in Section 4. In this example, |
|
6851 the UAC executes the client transaction, and its outbound proxy |
|
6852 executes the server transaction. The outbound proxy also executes a |
|
6853 client transaction, which sends the request to a server transaction |
|
6854 in the inbound proxy. That proxy also executes a client transaction, |
|
6855 which in turn sends the request to a server transaction in the UAS. |
|
6856 This is shown in Figure 4. |
|
6857 |
|
6858 +---------+ +---------+ +---------+ +---------+ |
|
6859 | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | |
|
6860 | |C||------->||S| |C||------->||S| |C||------->||S| | |
|
6861 | |l|| ||e| |l|| ||e| |l|| ||e| | |
|
6862 | |i|| ||r| |i|| ||r| |i|| ||r| | |
|
6863 | |e|| ||v| |e|| ||v| |e|| ||v| | |
|
6864 | |n|| ||e| |n|| ||e| |n|| ||e| | |
|
6865 | |t|| ||r| |t|| ||r| |t|| ||r| | |
|
6866 | | || || | | || || | | || || | | |
|
6867 | |T|| ||T| |T|| ||T| |T|| ||T| | |
|
6868 | |r|| ||r| |r|| ||r| |r|| ||r| | |
|
6869 | |a|| ||a| |a|| ||a| |a|| ||a| | |
|
6870 | |n|| ||n| |n|| ||n| |n|| ||n| | |
|
6871 | |s||Response||s| |s||Response||s| |s||Response||s| | |
|
6872 | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | |
|
6873 +---------+ +---------+ +---------+ +---------+ |
|
6874 UAC Outbound Inbound UAS |
|
6875 Proxy Proxy |
|
6876 |
|
6877 Figure 4: Transaction relationships |
|
6878 |
|
6879 A stateless proxy does not contain a client or server transaction. |
|
6880 The transaction exists between the UA or stateful proxy on one side, |
|
6881 and the UA or stateful proxy on the other side. As far as SIP |
|
6882 transactions are concerned, stateless proxies are effectively |
|
6883 transparent. The purpose of the client transaction is to receive a |
|
6884 request from the element in which the client is embedded (call this |
|
6885 element the "Transaction User" or TU; it can be a UA or a stateful |
|
6886 proxy), and reliably deliver the request to a server transaction. |
|
6887 |
|
6888 |
|
6889 |
|
6890 Rosenberg, et. al. Standards Track [Page 123] |
|
6891 |
|
6892 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6893 |
|
6894 |
|
6895 The client transaction is also responsible for receiving responses |
|
6896 and delivering them to the TU, filtering out any response |
|
6897 retransmissions or disallowed responses (such as a response to ACK). |
|
6898 Additionally, in the case of an INVITE request, the client |
|
6899 transaction is responsible for generating the ACK request for any |
|
6900 final response accepting a 2xx response. |
|
6901 |
|
6902 Similarly, the purpose of the server transaction is to receive |
|
6903 requests from the transport layer and deliver them to the TU. The |
|
6904 server transaction filters any request retransmissions from the |
|
6905 network. The server transaction accepts responses from the TU and |
|
6906 delivers them to the transport layer for transmission over the |
|
6907 network. In the case of an INVITE transaction, it absorbs the ACK |
|
6908 request for any final response excepting a 2xx response. |
|
6909 |
|
6910 The 2xx response and its ACK receive special treatment. This |
|
6911 response is retransmitted only by a UAS, and its ACK generated only |
|
6912 by the UAC. This end-to-end treatment is needed so that a caller |
|
6913 knows the entire set of users that have accepted the call. Because |
|
6914 of this special handling, retransmissions of the 2xx response are |
|
6915 handled by the UA core, not the transaction layer. Similarly, |
|
6916 generation of the ACK for the 2xx is handled by the UA core. Each |
|
6917 proxy along the path merely forwards each 2xx response to INVITE and |
|
6918 its corresponding ACK. |
|
6919 |
|
6920 17.1 Client Transaction |
|
6921 |
|
6922 The client transaction provides its functionality through the |
|
6923 maintenance of a state machine. |
|
6924 |
|
6925 The TU communicates with the client transaction through a simple |
|
6926 interface. When the TU wishes to initiate a new transaction, it |
|
6927 creates a client transaction and passes it the SIP request to send |
|
6928 and an IP address, port, and transport to which to send it. The |
|
6929 client transaction begins execution of its state machine. Valid |
|
6930 responses are passed up to the TU from the client transaction. |
|
6931 |
|
6932 There are two types of client transaction state machines, depending |
|
6933 on the method of the request passed by the TU. One handles client |
|
6934 transactions for INVITE requests. This type of machine is referred |
|
6935 to as an INVITE client transaction. Another type handles client |
|
6936 transactions for all requests except INVITE and ACK. This is |
|
6937 referred to as a non-INVITE client transaction. There is no client |
|
6938 transaction for ACK. If the TU wishes to send an ACK, it passes one |
|
6939 directly to the transport layer for transmission. |
|
6940 |
|
6941 |
|
6942 |
|
6943 |
|
6944 |
|
6945 |
|
6946 Rosenberg, et. al. Standards Track [Page 124] |
|
6947 |
|
6948 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
6949 |
|
6950 |
|
6951 The INVITE transaction is different from those of other methods |
|
6952 because of its extended duration. Normally, human input is required |
|
6953 in order to respond to an INVITE. The long delays expected for |
|
6954 sending a response argue for a three-way handshake. On the other |
|
6955 hand, requests of other methods are expected to complete rapidly. |
|
6956 Because of the non-INVITE transaction's reliance on a two-way |
|
6957 handshake, TUs SHOULD respond immediately to non-INVITE requests. |
|
6958 |
|
6959 17.1.1 INVITE Client Transaction |
|
6960 |
|
6961 17.1.1.1 Overview of INVITE Transaction |
|
6962 |
|
6963 The INVITE transaction consists of a three-way handshake. The client |
|
6964 transaction sends an INVITE, the server transaction sends responses, |
|
6965 and the client transaction sends an ACK. For unreliable transports |
|
6966 (such as UDP), the client transaction retransmits requests at an |
|
6967 interval that starts at T1 seconds and doubles after every |
|
6968 retransmission. T1 is an estimate of the round-trip time (RTT), and |
|
6969 it defaults to 500 ms. Nearly all of the transaction timers |
|
6970 described here scale with T1, and changing T1 adjusts their values. |
|
6971 The request is not retransmitted over reliable transports. After |
|
6972 receiving a 1xx response, any retransmissions cease altogether, and |
|
6973 the client waits for further responses. The server transaction can |
|
6974 send additional 1xx responses, which are not transmitted reliably by |
|
6975 the server transaction. Eventually, the server transaction decides |
|
6976 to send a final response. For unreliable transports, that response |
|
6977 is retransmitted periodically, and for reliable transports, it is |
|
6978 sent once. For each final response that is received at the client |
|
6979 transaction, the client transaction sends an ACK, the purpose of |
|
6980 which is to quench retransmissions of the response. |
|
6981 |
|
6982 17.1.1.2 Formal Description |
|
6983 |
|
6984 The state machine for the INVITE client transaction is shown in |
|
6985 Figure 5. The initial state, "calling", MUST be entered when the TU |
|
6986 initiates a new client transaction with an INVITE request. The |
|
6987 client transaction MUST pass the request to the transport layer for |
|
6988 transmission (see Section 18). If an unreliable transport is being |
|
6989 used, the client transaction MUST start timer A with a value of T1. |
|
6990 If a reliable transport is being used, the client transaction SHOULD |
|
6991 NOT start timer A (Timer A controls request retransmissions). For |
|
6992 any transport, the client transaction MUST start timer B with a value |
|
6993 of 64*T1 seconds (Timer B controls transaction timeouts). |
|
6994 |
|
6995 When timer A fires, the client transaction MUST retransmit the |
|
6996 request by passing it to the transport layer, and MUST reset the |
|
6997 timer with a value of 2*T1. The formal definition of retransmit |
|
6998 |
|
6999 |
|
7000 |
|
7001 |
|
7002 Rosenberg, et. al. Standards Track [Page 125] |
|
7003 |
|
7004 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7005 |
|
7006 |
|
7007 within the context of the transaction layer is to take the message |
|
7008 previously sent to the transport layer and pass it to the transport |
|
7009 layer once more. |
|
7010 |
|
7011 When timer A fires 2*T1 seconds later, the request MUST be |
|
7012 retransmitted again (assuming the client transaction is still in this |
|
7013 state). This process MUST continue so that the request is |
|
7014 retransmitted with intervals that double after each transmission. |
|
7015 These retransmissions SHOULD only be done while the client |
|
7016 transaction is in the "calling" state. |
|
7017 |
|
7018 The default value for T1 is 500 ms. T1 is an estimate of the RTT |
|
7019 between the client and server transactions. Elements MAY (though it |
|
7020 is NOT RECOMMENDED) use smaller values of T1 within closed, private |
|
7021 networks that do not permit general Internet connection. T1 MAY be |
|
7022 chosen larger, and this is RECOMMENDED if it is known in advance |
|
7023 (such as on high latency access links) that the RTT is larger. |
|
7024 Whatever the value of T1, the exponential backoffs on retransmissions |
|
7025 described in this section MUST be used. |
|
7026 |
|
7027 If the client transaction is still in the "Calling" state when timer |
|
7028 B fires, the client transaction SHOULD inform the TU that a timeout |
|
7029 has occurred. The client transaction MUST NOT generate an ACK. The |
|
7030 value of 64*T1 is equal to the amount of time required to send seven |
|
7031 requests in the case of an unreliable transport. |
|
7032 |
|
7033 If the client transaction receives a provisional response while in |
|
7034 the "Calling" state, it transitions to the "Proceeding" state. In the |
|
7035 "Proceeding" state, the client transaction SHOULD NOT retransmit the |
|
7036 request any longer. Furthermore, the provisional response MUST be |
|
7037 passed to the TU. Any further provisional responses MUST be passed |
|
7038 up to the TU while in the "Proceeding" state. |
|
7039 |
|
7040 When in either the "Calling" or "Proceeding" states, reception of a |
|
7041 response with status code from 300-699 MUST cause the client |
|
7042 transaction to transition to "Completed". The client transaction |
|
7043 MUST pass the received response up to the TU, and the client |
|
7044 transaction MUST generate an ACK request, even if the transport is |
|
7045 reliable (guidelines for constructing the ACK from the response are |
|
7046 given in Section 17.1.1.3) and then pass the ACK to the transport |
|
7047 layer for transmission. The ACK MUST be sent to the same address, |
|
7048 port, and transport to which the original request was sent. The |
|
7049 client transaction SHOULD start timer D when it enters the |
|
7050 "Completed" state, with a value of at least 32 seconds for unreliable |
|
7051 transports, and a value of zero seconds for reliable transports. |
|
7052 Timer D reflects the amount of time that the server transaction can |
|
7053 remain in the "Completed" state when unreliable transports are used. |
|
7054 This is equal to Timer H in the INVITE server transaction, whose |
|
7055 |
|
7056 |
|
7057 |
|
7058 Rosenberg, et. al. Standards Track [Page 126] |
|
7059 |
|
7060 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7061 |
|
7062 |
|
7063 default is 64*T1. However, the client transaction does not know the |
|
7064 value of T1 in use by the server transaction, so an absolute minimum |
|
7065 of 32s is used instead of basing Timer D on T1. |
|
7066 |
|
7067 Any retransmissions of the final response that are received while in |
|
7068 the "Completed" state MUST cause the ACK to be re-passed to the |
|
7069 transport layer for retransmission, but the newly received response |
|
7070 MUST NOT be passed up to the TU. A retransmission of the response is |
|
7071 defined as any response which would match the same client transaction |
|
7072 based on the rules of Section 17.1.3. |
|
7073 |
|
7074 |
|
7075 |
|
7076 |
|
7077 |
|
7078 |
|
7079 |
|
7080 |
|
7081 |
|
7082 |
|
7083 |
|
7084 |
|
7085 |
|
7086 |
|
7087 |
|
7088 |
|
7089 |
|
7090 |
|
7091 |
|
7092 |
|
7093 |
|
7094 |
|
7095 |
|
7096 |
|
7097 |
|
7098 |
|
7099 |
|
7100 |
|
7101 |
|
7102 |
|
7103 |
|
7104 |
|
7105 |
|
7106 |
|
7107 |
|
7108 |
|
7109 |
|
7110 |
|
7111 |
|
7112 |
|
7113 |
|
7114 Rosenberg, et. al. Standards Track [Page 127] |
|
7115 |
|
7116 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7117 |
|
7118 |
|
7119 |INVITE from TU |
|
7120 Timer A fires |INVITE sent |
|
7121 Reset A, V Timer B fires |
|
7122 INVITE sent +-----------+ or Transport Err. |
|
7123 +---------| |---------------+inform TU |
|
7124 | | Calling | | |
|
7125 +-------->| |-------------->| |
|
7126 +-----------+ 2xx | |
|
7127 | | 2xx to TU | |
|
7128 | |1xx | |
|
7129 300-699 +---------------+ |1xx to TU | |
|
7130 ACK sent | | | |
|
7131 resp. to TU | 1xx V | |
|
7132 | 1xx to TU -----------+ | |
|
7133 | +---------| | | |
|
7134 | | |Proceeding |-------------->| |
|
7135 | +-------->| | 2xx | |
|
7136 | +-----------+ 2xx to TU | |
|
7137 | 300-699 | | |
|
7138 | ACK sent, | | |
|
7139 | resp. to TU| | |
|
7140 | | | NOTE: |
|
7141 | 300-699 V | |
|
7142 | ACK sent +-----------+Transport Err. | transitions |
|
7143 | +---------| |Inform TU | labeled with |
|
7144 | | | Completed |-------------->| the event |
|
7145 | +-------->| | | over the action |
|
7146 | +-----------+ | to take |
|
7147 | ^ | | |
|
7148 | | | Timer D fires | |
|
7149 +--------------+ | - | |
|
7150 | | |
|
7151 V | |
|
7152 +-----------+ | |
|
7153 | | | |
|
7154 | Terminated|<--------------+ |
|
7155 | | |
|
7156 +-----------+ |
|
7157 |
|
7158 Figure 5: INVITE client transaction |
|
7159 |
|
7160 If timer D fires while the client transaction is in the "Completed" |
|
7161 state, the client transaction MUST move to the terminated state. |
|
7162 |
|
7163 When in either the "Calling" or "Proceeding" states, reception of a |
|
7164 2xx response MUST cause the client transaction to enter the |
|
7165 "Terminated" state, and the response MUST be passed up to the TU. |
|
7166 The handling of this response depends on whether the TU is a proxy |
|
7167 |
|
7168 |
|
7169 |
|
7170 Rosenberg, et. al. Standards Track [Page 128] |
|
7171 |
|
7172 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7173 |
|
7174 |
|
7175 core or a UAC core. A UAC core will handle generation of the ACK for |
|
7176 this response, while a proxy core will always forward the 200 (OK) |
|
7177 upstream. The differing treatment of 200 (OK) between proxy and UAC |
|
7178 is the reason that handling of it does not take place in the |
|
7179 transaction layer. |
|
7180 |
|
7181 The client transaction MUST be destroyed the instant it enters the |
|
7182 "Terminated" state. This is actually necessary to guarantee correct |
|
7183 operation. The reason is that 2xx responses to an INVITE are treated |
|
7184 differently; each one is forwarded by proxies, and the ACK handling |
|
7185 in a UAC is different. Thus, each 2xx needs to be passed to a proxy |
|
7186 core (so that it can be forwarded) and to a UAC core (so it can be |
|
7187 acknowledged). No transaction layer processing takes place. |
|
7188 Whenever a response is received by the transport, if the transport |
|
7189 layer finds no matching client transaction (using the rules of |
|
7190 Section 17.1.3), the response is passed directly to the core. Since |
|
7191 the matching client transaction is destroyed by the first 2xx, |
|
7192 subsequent 2xx will find no match and therefore be passed to the |
|
7193 core. |
|
7194 |
|
7195 17.1.1.3 Construction of the ACK Request |
|
7196 |
|
7197 This section specifies the construction of ACK requests sent within |
|
7198 the client transaction. A UAC core that generates an ACK for 2xx |
|
7199 MUST instead follow the rules described in Section 13. |
|
7200 |
|
7201 The ACK request constructed by the client transaction MUST contain |
|
7202 values for the Call-ID, From, and Request-URI that are equal to the |
|
7203 values of those header fields in the request passed to the transport |
|
7204 by the client transaction (call this the "original request"). The To |
|
7205 header field in the ACK MUST equal the To header field in the |
|
7206 response being acknowledged, and therefore will usually differ from |
|
7207 the To header field in the original request by the addition of the |
|
7208 tag parameter. The ACK MUST contain a single Via header field, and |
|
7209 this MUST be equal to the top Via header field of the original |
|
7210 request. The CSeq header field in the ACK MUST contain the same |
|
7211 value for the sequence number as was present in the original request, |
|
7212 but the method parameter MUST be equal to "ACK". |
|
7213 |
|
7214 |
|
7215 |
|
7216 |
|
7217 |
|
7218 |
|
7219 |
|
7220 |
|
7221 |
|
7222 |
|
7223 |
|
7224 |
|
7225 |
|
7226 Rosenberg, et. al. Standards Track [Page 129] |
|
7227 |
|
7228 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7229 |
|
7230 |
|
7231 If the INVITE request whose response is being acknowledged had Route |
|
7232 header fields, those header fields MUST appear in the ACK. This is |
|
7233 to ensure that the ACK can be routed properly through any downstream |
|
7234 stateless proxies. |
|
7235 |
|
7236 Although any request MAY contain a body, a body in an ACK is special |
|
7237 since the request cannot be rejected if the body is not understood. |
|
7238 Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, |
|
7239 but if done, the body types are restricted to any that appeared in |
|
7240 the INVITE, assuming that the response to the INVITE was not 415. If |
|
7241 it was, the body in the ACK MAY be any type listed in the Accept |
|
7242 header field in the 415. |
|
7243 |
|
7244 For example, consider the following request: |
|
7245 |
|
7246 INVITE sip:bob@biloxi.com SIP/2.0 |
|
7247 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff |
|
7248 To: Bob <sip:bob@biloxi.com> |
|
7249 From: Alice <sip:alice@atlanta.com>;tag=88sja8x |
|
7250 Max-Forwards: 70 |
|
7251 Call-ID: 987asjd97y7atg |
|
7252 CSeq: 986759 INVITE |
|
7253 |
|
7254 The ACK request for a non-2xx final response to this request would |
|
7255 look like this: |
|
7256 |
|
7257 ACK sip:bob@biloxi.com SIP/2.0 |
|
7258 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff |
|
7259 To: Bob <sip:bob@biloxi.com>;tag=99sa0xk |
|
7260 From: Alice <sip:alice@atlanta.com>;tag=88sja8x |
|
7261 Max-Forwards: 70 |
|
7262 Call-ID: 987asjd97y7atg |
|
7263 CSeq: 986759 ACK |
|
7264 |
|
7265 17.1.2 Non-INVITE Client Transaction |
|
7266 |
|
7267 17.1.2.1 Overview of the non-INVITE Transaction |
|
7268 |
|
7269 Non-INVITE transactions do not make use of ACK. They are simple |
|
7270 request-response interactions. For unreliable transports, requests |
|
7271 are retransmitted at an interval which starts at T1 and doubles until |
|
7272 it hits T2. If a provisional response is received, retransmissions |
|
7273 continue for unreliable transports, but at an interval of T2. The |
|
7274 server transaction retransmits the last response it sent, which can |
|
7275 be a provisional or final response, only when a retransmission of the |
|
7276 request is received. This is why request retransmissions need to |
|
7277 continue even after a provisional response; they are to ensure |
|
7278 reliable delivery of the final response. |
|
7279 |
|
7280 |
|
7281 |
|
7282 Rosenberg, et. al. Standards Track [Page 130] |
|
7283 |
|
7284 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7285 |
|
7286 |
|
7287 Unlike an INVITE transaction, a non-INVITE transaction has no special |
|
7288 handling for the 2xx response. The result is that only a single 2xx |
|
7289 response to a non-INVITE is ever delivered to a UAC. |
|
7290 |
|
7291 17.1.2.2 Formal Description |
|
7292 |
|
7293 The state machine for the non-INVITE client transaction is shown in |
|
7294 Figure 6. It is very similar to the state machine for INVITE. |
|
7295 |
|
7296 The "Trying" state is entered when the TU initiates a new client |
|
7297 transaction with a request. When entering this state, the client |
|
7298 transaction SHOULD set timer F to fire in 64*T1 seconds. The request |
|
7299 MUST be passed to the transport layer for transmission. If an |
|
7300 unreliable transport is in use, the client transaction MUST set timer |
|
7301 E to fire in T1 seconds. If timer E fires while still in this state, |
|
7302 the timer is reset, but this time with a value of MIN(2*T1, T2). |
|
7303 When the timer fires again, it is reset to a MIN(4*T1, T2). This |
|
7304 process continues so that retransmissions occur with an exponentially |
|
7305 increasing interval that caps at T2. The default value of T2 is 4s, |
|
7306 and it represents the amount of time a non-INVITE server transaction |
|
7307 will take to respond to a request, if it does not respond |
|
7308 immediately. For the default values of T1 and T2, this results in |
|
7309 intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. |
|
7310 |
|
7311 If Timer F fires while the client transaction is still in the |
|
7312 "Trying" state, the client transaction SHOULD inform the TU about the |
|
7313 timeout, and then it SHOULD enter the "Terminated" state. If a |
|
7314 provisional response is received while in the "Trying" state, the |
|
7315 response MUST be passed to the TU, and then the client transaction |
|
7316 SHOULD move to the "Proceeding" state. If a final response (status |
|
7317 codes 200-699) is received while in the "Trying" state, the response |
|
7318 MUST be passed to the TU, and the client transaction MUST transition |
|
7319 to the "Completed" state. |
|
7320 |
|
7321 If Timer E fires while in the "Proceeding" state, the request MUST be |
|
7322 passed to the transport layer for retransmission, and Timer E MUST be |
|
7323 reset with a value of T2 seconds. If timer F fires while in the |
|
7324 "Proceeding" state, the TU MUST be informed of a timeout, and the |
|
7325 client transaction MUST transition to the terminated state. If a |
|
7326 final response (status codes 200-699) is received while in the |
|
7327 "Proceeding" state, the response MUST be passed to the TU, and the |
|
7328 client transaction MUST transition to the "Completed" state. |
|
7329 |
|
7330 Once the client transaction enters the "Completed" state, it MUST set |
|
7331 Timer K to fire in T4 seconds for unreliable transports, and zero |
|
7332 seconds for reliable transports. The "Completed" state exists to |
|
7333 buffer any additional response retransmissions that may be received |
|
7334 (which is why the client transaction remains there only for |
|
7335 |
|
7336 |
|
7337 |
|
7338 Rosenberg, et. al. Standards Track [Page 131] |
|
7339 |
|
7340 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7341 |
|
7342 |
|
7343 unreliable transports). T4 represents the amount of time the network |
|
7344 will take to clear messages between client and server transactions. |
|
7345 The default value of T4 is 5s. A response is a retransmission when |
|
7346 it matches the same transaction, using the rules specified in Section |
|
7347 17.1.3. If Timer K fires while in this state, the client transaction |
|
7348 MUST transition to the "Terminated" state. |
|
7349 |
|
7350 Once the transaction is in the terminated state, it MUST be destroyed |
|
7351 immediately. |
|
7352 |
|
7353 17.1.3 Matching Responses to Client Transactions |
|
7354 |
|
7355 When the transport layer in the client receives a response, it has to |
|
7356 determine which client transaction will handle the response, so that |
|
7357 the processing of Sections 17.1.1 and 17.1.2 can take place. The |
|
7358 branch parameter in the top Via header field is used for this |
|
7359 purpose. A response matches a client transaction under two |
|
7360 conditions: |
|
7361 |
|
7362 1. If the response has the same value of the branch parameter in |
|
7363 the top Via header field as the branch parameter in the top |
|
7364 Via header field of the request that created the transaction. |
|
7365 |
|
7366 2. If the method parameter in the CSeq header field matches the |
|
7367 method of the request that created the transaction. The |
|
7368 method is needed since a CANCEL request constitutes a |
|
7369 different transaction, but shares the same value of the branch |
|
7370 parameter. |
|
7371 |
|
7372 If a request is sent via multicast, it is possible that it will |
|
7373 generate multiple responses from different servers. These responses |
|
7374 will all have the same branch parameter in the topmost Via, but vary |
|
7375 in the To tag. The first response received, based on the rules |
|
7376 above, will be used, and others will be viewed as retransmissions. |
|
7377 That is not an error; multicast SIP provides only a rudimentary |
|
7378 "single-hop-discovery-like" service that is limited to processing a |
|
7379 single response. See Section 18.1.1 for details. |
|
7380 |
|
7381 |
|
7382 |
|
7383 |
|
7384 |
|
7385 |
|
7386 |
|
7387 |
|
7388 |
|
7389 |
|
7390 |
|
7391 |
|
7392 |
|
7393 |
|
7394 Rosenberg, et. al. Standards Track [Page 132] |
|
7395 |
|
7396 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7397 |
|
7398 |
|
7399 17.1.4 Handling Transport Errors |
|
7400 |
|
7401 |Request from TU |
|
7402 |send request |
|
7403 Timer E V |
|
7404 send request +-----------+ |
|
7405 +---------| |-------------------+ |
|
7406 | | Trying | Timer F | |
|
7407 +-------->| | or Transport Err.| |
|
7408 +-----------+ inform TU | |
|
7409 200-699 | | | |
|
7410 resp. to TU | |1xx | |
|
7411 +---------------+ |resp. to TU | |
|
7412 | | | |
|
7413 | Timer E V Timer F | |
|
7414 | send req +-----------+ or Transport Err. | |
|
7415 | +---------| | inform TU | |
|
7416 | | |Proceeding |------------------>| |
|
7417 | +-------->| |-----+ | |
|
7418 | +-----------+ |1xx | |
|
7419 | | ^ |resp to TU | |
|
7420 | 200-699 | +--------+ | |
|
7421 | resp. to TU | | |
|
7422 | | | |
|
7423 | V | |
|
7424 | +-----------+ | |
|
7425 | | | | |
|
7426 | | Completed | | |
|
7427 | | | | |
|
7428 | +-----------+ | |
|
7429 | ^ | | |
|
7430 | | | Timer K | |
|
7431 +--------------+ | - | |
|
7432 | | |
|
7433 V | |
|
7434 NOTE: +-----------+ | |
|
7435 | | | |
|
7436 transitions | Terminated|<------------------+ |
|
7437 labeled with | | |
|
7438 the event +-----------+ |
|
7439 over the action |
|
7440 to take |
|
7441 |
|
7442 Figure 6: non-INVITE client transaction |
|
7443 |
|
7444 When the client transaction sends a request to the transport layer to |
|
7445 be sent, the following procedures are followed if the transport layer |
|
7446 indicates a failure. |
|
7447 |
|
7448 |
|
7449 |
|
7450 Rosenberg, et. al. Standards Track [Page 133] |
|
7451 |
|
7452 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7453 |
|
7454 |
|
7455 The client transaction SHOULD inform the TU that a transport failure |
|
7456 has occurred, and the client transaction SHOULD transition directly |
|
7457 to the "Terminated" state. The TU will handle the failover |
|
7458 mechanisms described in [4]. |
|
7459 |
|
7460 17.2 Server Transaction |
|
7461 |
|
7462 The server transaction is responsible for the delivery of requests to |
|
7463 the TU and the reliable transmission of responses. It accomplishes |
|
7464 this through a state machine. Server transactions are created by the |
|
7465 core when a request is received, and transaction handling is desired |
|
7466 for that request (this is not always the case). |
|
7467 |
|
7468 As with the client transactions, the state machine depends on whether |
|
7469 the received request is an INVITE request. |
|
7470 |
|
7471 17.2.1 INVITE Server Transaction |
|
7472 |
|
7473 The state diagram for the INVITE server transaction is shown in |
|
7474 Figure 7. |
|
7475 |
|
7476 When a server transaction is constructed for a request, it enters the |
|
7477 "Proceeding" state. The server transaction MUST generate a 100 |
|
7478 (Trying) response unless it knows that the TU will generate a |
|
7479 provisional or final response within 200 ms, in which case it MAY |
|
7480 generate a 100 (Trying) response. This provisional response is |
|
7481 needed to quench request retransmissions rapidly in order to avoid |
|
7482 network congestion. The 100 (Trying) response is constructed |
|
7483 according to the procedures in Section 8.2.6, except that the |
|
7484 insertion of tags in the To header field of the response (when none |
|
7485 was present in the request) is downgraded from MAY to SHOULD NOT. |
|
7486 The request MUST be passed to the TU. |
|
7487 |
|
7488 The TU passes any number of provisional responses to the server |
|
7489 transaction. So long as the server transaction is in the |
|
7490 "Proceeding" state, each of these MUST be passed to the transport |
|
7491 layer for transmission. They are not sent reliably by the |
|
7492 transaction layer (they are not retransmitted by it) and do not cause |
|
7493 a change in the state of the server transaction. If a request |
|
7494 retransmission is received while in the "Proceeding" state, the most |
|
7495 recent provisional response that was received from the TU MUST be |
|
7496 passed to the transport layer for retransmission. A request is a |
|
7497 retransmission if it matches the same server transaction based on the |
|
7498 rules of Section 17.2.3. |
|
7499 |
|
7500 If, while in the "Proceeding" state, the TU passes a 2xx response to |
|
7501 the server transaction, the server transaction MUST pass this |
|
7502 response to the transport layer for transmission. It is not |
|
7503 |
|
7504 |
|
7505 |
|
7506 Rosenberg, et. al. Standards Track [Page 134] |
|
7507 |
|
7508 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7509 |
|
7510 |
|
7511 retransmitted by the server transaction; retransmissions of 2xx |
|
7512 responses are handled by the TU. The server transaction MUST then |
|
7513 transition to the "Terminated" state. |
|
7514 |
|
7515 While in the "Proceeding" state, if the TU passes a response with |
|
7516 status code from 300 to 699 to the server transaction, the response |
|
7517 MUST be passed to the transport layer for transmission, and the state |
|
7518 machine MUST enter the "Completed" state. For unreliable transports, |
|
7519 timer G is set to fire in T1 seconds, and is not set to fire for |
|
7520 reliable transports. |
|
7521 |
|
7522 This is a change from RFC 2543, where responses were always |
|
7523 retransmitted, even over reliable transports. |
|
7524 |
|
7525 When the "Completed" state is entered, timer H MUST be set to fire in |
|
7526 64*T1 seconds for all transports. Timer H determines when the server |
|
7527 transaction abandons retransmitting the response. Its value is |
|
7528 chosen to equal Timer B, the amount of time a client transaction will |
|
7529 continue to retry sending a request. If timer G fires, the response |
|
7530 is passed to the transport layer once more for retransmission, and |
|
7531 timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when |
|
7532 timer G fires, the response is passed to the transport again for |
|
7533 transmission, and timer G is reset with a value that doubles, unless |
|
7534 that value exceeds T2, in which case it is reset with the value of |
|
7535 T2. This is identical to the retransmit behavior for requests in the |
|
7536 "Trying" state of the non-INVITE client transaction. Furthermore, |
|
7537 while in the "Completed" state, if a request retransmission is |
|
7538 received, the server SHOULD pass the response to the transport for |
|
7539 retransmission. |
|
7540 |
|
7541 If an ACK is received while the server transaction is in the |
|
7542 "Completed" state, the server transaction MUST transition to the |
|
7543 "Confirmed" state. As Timer G is ignored in this state, any |
|
7544 retransmissions of the response will cease. |
|
7545 |
|
7546 If timer H fires while in the "Completed" state, it implies that the |
|
7547 ACK was never received. In this case, the server transaction MUST |
|
7548 transition to the "Terminated" state, and MUST indicate to the TU |
|
7549 that a transaction failure has occurred. |
|
7550 |
|
7551 |
|
7552 |
|
7553 |
|
7554 |
|
7555 |
|
7556 |
|
7557 |
|
7558 |
|
7559 |
|
7560 |
|
7561 |
|
7562 Rosenberg, et. al. Standards Track [Page 135] |
|
7563 |
|
7564 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7565 |
|
7566 |
|
7567 |INVITE |
|
7568 |pass INV to TU |
|
7569 INVITE V send 100 if TU won't in 200ms |
|
7570 send response+-----------+ |
|
7571 +--------| |--------+101-199 from TU |
|
7572 | | Proceeding| |send response |
|
7573 +------->| |<-------+ |
|
7574 | | Transport Err. |
|
7575 | | Inform TU |
|
7576 | |--------------->+ |
|
7577 +-----------+ | |
|
7578 300-699 from TU | |2xx from TU | |
|
7579 send response | |send response | |
|
7580 | +------------------>+ |
|
7581 | | |
|
7582 INVITE V Timer G fires | |
|
7583 send response+-----------+ send response | |
|
7584 +--------| |--------+ | |
|
7585 | | Completed | | | |
|
7586 +------->| |<-------+ | |
|
7587 +-----------+ | |
|
7588 | | | |
|
7589 ACK | | | |
|
7590 - | +------------------>+ |
|
7591 | Timer H fires | |
|
7592 V or Transport Err.| |
|
7593 +-----------+ Inform TU | |
|
7594 | | | |
|
7595 | Confirmed | | |
|
7596 | | | |
|
7597 +-----------+ | |
|
7598 | | |
|
7599 |Timer I fires | |
|
7600 |- | |
|
7601 | | |
|
7602 V | |
|
7603 +-----------+ | |
|
7604 | | | |
|
7605 | Terminated|<---------------+ |
|
7606 | | |
|
7607 +-----------+ |
|
7608 |
|
7609 Figure 7: INVITE server transaction |
|
7610 |
|
7611 |
|
7612 |
|
7613 |
|
7614 |
|
7615 |
|
7616 |
|
7617 |
|
7618 Rosenberg, et. al. Standards Track [Page 136] |
|
7619 |
|
7620 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7621 |
|
7622 |
|
7623 The purpose of the "Confirmed" state is to absorb any additional ACK |
|
7624 messages that arrive, triggered from retransmissions of the final |
|
7625 response. When this state is entered, timer I is set to fire in T4 |
|
7626 seconds for unreliable transports, and zero seconds for reliable |
|
7627 transports. Once timer I fires, the server MUST transition to the |
|
7628 "Terminated" state. |
|
7629 |
|
7630 Once the transaction is in the "Terminated" state, it MUST be |
|
7631 destroyed immediately. As with client transactions, this is needed |
|
7632 to ensure reliability of the 2xx responses to INVITE. |
|
7633 |
|
7634 17.2.2 Non-INVITE Server Transaction |
|
7635 |
|
7636 The state machine for the non-INVITE server transaction is shown in |
|
7637 Figure 8. |
|
7638 |
|
7639 The state machine is initialized in the "Trying" state and is passed |
|
7640 a request other than INVITE or ACK when initialized. This request is |
|
7641 passed up to the TU. Once in the "Trying" state, any further request |
|
7642 retransmissions are discarded. A request is a retransmission if it |
|
7643 matches the same server transaction, using the rules specified in |
|
7644 Section 17.2.3. |
|
7645 |
|
7646 While in the "Trying" state, if the TU passes a provisional response |
|
7647 to the server transaction, the server transaction MUST enter the |
|
7648 "Proceeding" state. The response MUST be passed to the transport |
|
7649 layer for transmission. Any further provisional responses that are |
|
7650 received from the TU while in the "Proceeding" state MUST be passed |
|
7651 to the transport layer for transmission. If a retransmission of the |
|
7652 request is received while in the "Proceeding" state, the most |
|
7653 recently sent provisional response MUST be passed to the transport |
|
7654 layer for retransmission. If the TU passes a final response (status |
|
7655 codes 200-699) to the server while in the "Proceeding" state, the |
|
7656 transaction MUST enter the "Completed" state, and the response MUST |
|
7657 be passed to the transport layer for transmission. |
|
7658 |
|
7659 When the server transaction enters the "Completed" state, it MUST set |
|
7660 Timer J to fire in 64*T1 seconds for unreliable transports, and zero |
|
7661 seconds for reliable transports. While in the "Completed" state, the |
|
7662 server transaction MUST pass the final response to the transport |
|
7663 layer for retransmission whenever a retransmission of the request is |
|
7664 received. Any other final responses passed by the TU to the server |
|
7665 transaction MUST be discarded while in the "Completed" state. The |
|
7666 server transaction remains in this state until Timer J fires, at |
|
7667 which point it MUST transition to the "Terminated" state. |
|
7668 |
|
7669 The server transaction MUST be destroyed the instant it enters the |
|
7670 "Terminated" state. |
|
7671 |
|
7672 |
|
7673 |
|
7674 Rosenberg, et. al. Standards Track [Page 137] |
|
7675 |
|
7676 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7677 |
|
7678 |
|
7679 17.2.3 Matching Requests to Server Transactions |
|
7680 |
|
7681 When a request is received from the network by the server, it has to |
|
7682 be matched to an existing transaction. This is accomplished in the |
|
7683 following manner. |
|
7684 |
|
7685 The branch parameter in the topmost Via header field of the request |
|
7686 is examined. If it is present and begins with the magic cookie |
|
7687 "z9hG4bK", the request was generated by a client transaction |
|
7688 compliant to this specification. Therefore, the branch parameter |
|
7689 will be unique across all transactions sent by that client. The |
|
7690 request matches a transaction if: |
|
7691 |
|
7692 1. the branch parameter in the request is equal to the one in the |
|
7693 top Via header field of the request that created the |
|
7694 transaction, and |
|
7695 |
|
7696 2. the sent-by value in the top Via of the request is equal to the |
|
7697 one in the request that created the transaction, and |
|
7698 |
|
7699 3. the method of the request matches the one that created the |
|
7700 transaction, except for ACK, where the method of the request |
|
7701 that created the transaction is INVITE. |
|
7702 |
|
7703 This matching rule applies to both INVITE and non-INVITE transactions |
|
7704 alike. |
|
7705 |
|
7706 The sent-by value is used as part of the matching process because |
|
7707 there could be accidental or malicious duplication of branch |
|
7708 parameters from different clients. |
|
7709 |
|
7710 If the branch parameter in the top Via header field is not present, |
|
7711 or does not contain the magic cookie, the following procedures are |
|
7712 used. These exist to handle backwards compatibility with RFC 2543 |
|
7713 compliant implementations. |
|
7714 |
|
7715 The INVITE request matches a transaction if the Request-URI, To tag, |
|
7716 From tag, Call-ID, CSeq, and top Via header field match those of the |
|
7717 INVITE request which created the transaction. In this case, the |
|
7718 INVITE is a retransmission of the original one that created the |
|
7719 transaction. The ACK request matches a transaction if the Request- |
|
7720 URI, From tag, Call-ID, CSeq number (not the method), and top Via |
|
7721 header field match those of the INVITE request which created the |
|
7722 transaction, and the To tag of the ACK matches the To tag of the |
|
7723 response sent by the server transaction. Matching is done based on |
|
7724 the matching rules defined for each of those header fields. |
|
7725 Inclusion of the tag in the To header field in the ACK matching |
|
7726 process helps disambiguate ACK for 2xx from ACK for other responses |
|
7727 |
|
7728 |
|
7729 |
|
7730 Rosenberg, et. al. Standards Track [Page 138] |
|
7731 |
|
7732 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7733 |
|
7734 |
|
7735 at a proxy, which may have forwarded both responses (This can occur |
|
7736 in unusual conditions. Specifically, when a proxy forked a request, |
|
7737 and then crashes, the responses may be delivered to another proxy, |
|
7738 which might end up forwarding multiple responses upstream). An ACK |
|
7739 request that matches an INVITE transaction matched by a previous ACK |
|
7740 is considered a retransmission of that previous ACK. |
|
7741 |
|
7742 |
|
7743 |
|
7744 |
|
7745 |
|
7746 |
|
7747 |
|
7748 |
|
7749 |
|
7750 |
|
7751 |
|
7752 |
|
7753 |
|
7754 |
|
7755 |
|
7756 |
|
7757 |
|
7758 |
|
7759 |
|
7760 |
|
7761 |
|
7762 |
|
7763 |
|
7764 |
|
7765 |
|
7766 |
|
7767 |
|
7768 |
|
7769 |
|
7770 |
|
7771 |
|
7772 |
|
7773 |
|
7774 |
|
7775 |
|
7776 |
|
7777 |
|
7778 |
|
7779 |
|
7780 |
|
7781 |
|
7782 |
|
7783 |
|
7784 |
|
7785 |
|
7786 Rosenberg, et. al. Standards Track [Page 139] |
|
7787 |
|
7788 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7789 |
|
7790 |
|
7791 |Request received |
|
7792 |pass to TU |
|
7793 V |
|
7794 +-----------+ |
|
7795 | | |
|
7796 | Trying |-------------+ |
|
7797 | | | |
|
7798 +-----------+ |200-699 from TU |
|
7799 | |send response |
|
7800 |1xx from TU | |
|
7801 |send response | |
|
7802 | | |
|
7803 Request V 1xx from TU | |
|
7804 send response+-----------+send response| |
|
7805 +--------| |--------+ | |
|
7806 | | Proceeding| | | |
|
7807 +------->| |<-------+ | |
|
7808 +<--------------| | | |
|
7809 |Trnsprt Err +-----------+ | |
|
7810 |Inform TU | | |
|
7811 | | | |
|
7812 | |200-699 from TU | |
|
7813 | |send response | |
|
7814 | Request V | |
|
7815 | send response+-----------+ | |
|
7816 | +--------| | | |
|
7817 | | | Completed |<------------+ |
|
7818 | +------->| | |
|
7819 +<--------------| | |
|
7820 |Trnsprt Err +-----------+ |
|
7821 |Inform TU | |
|
7822 | |Timer J fires |
|
7823 | |- |
|
7824 | | |
|
7825 | V |
|
7826 | +-----------+ |
|
7827 | | | |
|
7828 +-------------->| Terminated| |
|
7829 | | |
|
7830 +-----------+ |
|
7831 |
|
7832 Figure 8: non-INVITE server transaction |
|
7833 |
|
7834 For all other request methods, a request is matched to a transaction |
|
7835 if the Request-URI, To tag, From tag, Call-ID, CSeq (including the |
|
7836 method), and top Via header field match those of the request that |
|
7837 created the transaction. Matching is done based on the matching |
|
7838 |
|
7839 |
|
7840 |
|
7841 |
|
7842 Rosenberg, et. al. Standards Track [Page 140] |
|
7843 |
|
7844 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7845 |
|
7846 |
|
7847 rules defined for each of those header fields. When a non-INVITE |
|
7848 request matches an existing transaction, it is a retransmission of |
|
7849 the request that created that transaction. |
|
7850 |
|
7851 Because the matching rules include the Request-URI, the server cannot |
|
7852 match a response to a transaction. When the TU passes a response to |
|
7853 the server transaction, it must pass it to the specific server |
|
7854 transaction for which the response is targeted. |
|
7855 |
|
7856 17.2.4 Handling Transport Errors |
|
7857 |
|
7858 When the server transaction sends a response to the transport layer |
|
7859 to be sent, the following procedures are followed if the transport |
|
7860 layer indicates a failure. |
|
7861 |
|
7862 First, the procedures in [4] are followed, which attempt to deliver |
|
7863 the response to a backup. If those should all fail, based on the |
|
7864 definition of failure in [4], the server transaction SHOULD inform |
|
7865 the TU that a failure has occurred, and SHOULD transition to the |
|
7866 terminated state. |
|
7867 |
|
7868 18 Transport |
|
7869 |
|
7870 The transport layer is responsible for the actual transmission of |
|
7871 requests and responses over network transports. This includes |
|
7872 determination of the connection to use for a request or response in |
|
7873 the case of connection-oriented transports. |
|
7874 |
|
7875 The transport layer is responsible for managing persistent |
|
7876 connections for transport protocols like TCP and SCTP, or TLS over |
|
7877 those, including ones opened to the transport layer. This includes |
|
7878 connections opened by the client or server transports, so that |
|
7879 connections are shared between client and server transport functions. |
|
7880 These connections are indexed by the tuple formed from the address, |
|
7881 port, and transport protocol at the far end of the connection. When |
|
7882 a connection is opened by the transport layer, this index is set to |
|
7883 the destination IP, port and transport. When the connection is |
|
7884 accepted by the transport layer, this index is set to the source IP |
|
7885 address, port number, and transport. Note that, because the source |
|
7886 port is often ephemeral, but it cannot be known whether it is |
|
7887 ephemeral or selected through procedures in [4], connections accepted |
|
7888 by the transport layer will frequently not be reused. The result is |
|
7889 that two proxies in a "peering" relationship using a connection- |
|
7890 oriented transport frequently will have two connections in use, one |
|
7891 for transactions initiated in each direction. |
|
7892 |
|
7893 |
|
7894 |
|
7895 |
|
7896 |
|
7897 |
|
7898 Rosenberg, et. al. Standards Track [Page 141] |
|
7899 |
|
7900 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7901 |
|
7902 |
|
7903 It is RECOMMENDED that connections be kept open for some |
|
7904 implementation-defined duration after the last message was sent or |
|
7905 received over that connection. This duration SHOULD at least equal |
|
7906 the longest amount of time the element would need in order to bring a |
|
7907 transaction from instantiation to the terminated state. This is to |
|
7908 make it likely that transactions are completed over the same |
|
7909 connection on which they are initiated (for example, request, |
|
7910 response, and in the case of INVITE, ACK for non-2xx responses). |
|
7911 This usually means at least 64*T1 (see Section 17.1.1.1 for a |
|
7912 definition of T1). However, it could be larger in an element that |
|
7913 has a TU using a large value for timer C (bullet 11 of Section 16.6), |
|
7914 for example. |
|
7915 |
|
7916 All SIP elements MUST implement UDP and TCP. SIP elements MAY |
|
7917 implement other protocols. |
|
7918 |
|
7919 Making TCP mandatory for the UA is a substantial change from RFC |
|
7920 2543. It has arisen out of the need to handle larger messages, |
|
7921 which MUST use TCP, as discussed below. Thus, even if an element |
|
7922 never sends large messages, it may receive one and needs to be |
|
7923 able to handle them. |
|
7924 |
|
7925 18.1 Clients |
|
7926 |
|
7927 18.1.1 Sending Requests |
|
7928 |
|
7929 The client side of the transport layer is responsible for sending the |
|
7930 request and receiving responses. The user of the transport layer |
|
7931 passes the client transport the request, an IP address, port, |
|
7932 transport, and possibly TTL for multicast destinations. |
|
7933 |
|
7934 If a request is within 200 bytes of the path MTU, or if it is larger |
|
7935 than 1300 bytes and the path MTU is unknown, the request MUST be sent |
|
7936 using an RFC 2914 [43] congestion controlled transport protocol, such |
|
7937 as TCP. If this causes a change in the transport protocol from the |
|
7938 one indicated in the top Via, the value in the top Via MUST be |
|
7939 changed. This prevents fragmentation of messages over UDP and |
|
7940 provides congestion control for larger messages. However, |
|
7941 implementations MUST be able to handle messages up to the maximum |
|
7942 datagram packet size. For UDP, this size is 65,535 bytes, including |
|
7943 IP and UDP headers. |
|
7944 |
|
7945 The 200 byte "buffer" between the message size and the MTU |
|
7946 accommodates the fact that the response in SIP can be larger than |
|
7947 the request. This happens due to the addition of Record-Route |
|
7948 header field values to the responses to INVITE, for example. With |
|
7949 the extra buffer, the response can be about 170 bytes larger than |
|
7950 the request, and still not be fragmented on IPv4 (about 30 bytes |
|
7951 |
|
7952 |
|
7953 |
|
7954 Rosenberg, et. al. Standards Track [Page 142] |
|
7955 |
|
7956 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
7957 |
|
7958 |
|
7959 is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when |
|
7960 path MTU is not known, based on the assumption of a 1500 byte |
|
7961 Ethernet MTU. |
|
7962 |
|
7963 If an element sends a request over TCP because of these message size |
|
7964 constraints, and that request would have otherwise been sent over |
|
7965 UDP, if the attempt to establish the connection generates either an |
|
7966 ICMP Protocol Not Supported, or results in a TCP reset, the element |
|
7967 SHOULD retry the request, using UDP. This is only to provide |
|
7968 backwards compatibility with RFC 2543 compliant implementations that |
|
7969 do not support TCP. It is anticipated that this behavior will be |
|
7970 deprecated in a future revision of this specification. |
|
7971 |
|
7972 A client that sends a request to a multicast address MUST add the |
|
7973 "maddr" parameter to its Via header field value containing the |
|
7974 destination multicast address, and for IPv4, SHOULD add the "ttl" |
|
7975 parameter with a value of 1. Usage of IPv6 multicast is not defined |
|
7976 in this specification, and will be a subject of future |
|
7977 standardization when the need arises. |
|
7978 |
|
7979 These rules result in a purposeful limitation of multicast in SIP. |
|
7980 Its primary function is to provide a "single-hop-discovery-like" |
|
7981 service, delivering a request to a group of homogeneous servers, |
|
7982 where it is only required to process the response from any one of |
|
7983 them. This functionality is most useful for registrations. In fact, |
|
7984 based on the transaction processing rules in Section 17.1.3, the |
|
7985 client transaction will accept the first response, and view any |
|
7986 others as retransmissions because they all contain the same Via |
|
7987 branch identifier. |
|
7988 |
|
7989 Before a request is sent, the client transport MUST insert a value of |
|
7990 the "sent-by" field into the Via header field. This field contains |
|
7991 an IP address or host name, and port. The usage of an FQDN is |
|
7992 RECOMMENDED. This field is used for sending responses under certain |
|
7993 conditions, described below. If the port is absent, the default |
|
7994 value depends on the transport. It is 5060 for UDP, TCP and SCTP, |
|
7995 5061 for TLS. |
|
7996 |
|
7997 For reliable transports, the response is normally sent on the |
|
7998 connection on which the request was received. Therefore, the client |
|
7999 transport MUST be prepared to receive the response on the same |
|
8000 connection used to send the request. Under error conditions, the |
|
8001 server may attempt to open a new connection to send the response. To |
|
8002 handle this case, the transport layer MUST also be prepared to |
|
8003 receive an incoming connection on the source IP address from which |
|
8004 the request was sent and port number in the "sent-by" field. It also |
|
8005 |
|
8006 |
|
8007 |
|
8008 |
|
8009 |
|
8010 Rosenberg, et. al. Standards Track [Page 143] |
|
8011 |
|
8012 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8013 |
|
8014 |
|
8015 MUST be prepared to receive incoming connections on any address and |
|
8016 port that would be selected by a server based on the procedures |
|
8017 described in Section 5 of [4]. |
|
8018 |
|
8019 For unreliable unicast transports, the client transport MUST be |
|
8020 prepared to receive responses on the source IP address from which the |
|
8021 request is sent (as responses are sent back to the source address) |
|
8022 and the port number in the "sent-by" field. Furthermore, as with |
|
8023 reliable transports, in certain cases the response will be sent |
|
8024 elsewhere. The client MUST be prepared to receive responses on any |
|
8025 address and port that would be selected by a server based on the |
|
8026 procedures described in Section 5 of [4]. |
|
8027 |
|
8028 For multicast, the client transport MUST be prepared to receive |
|
8029 responses on the same multicast group and port to which the request |
|
8030 is sent (that is, it needs to be a member of the multicast group it |
|
8031 sent the request to.) |
|
8032 |
|
8033 If a request is destined to an IP address, port, and transport to |
|
8034 which an existing connection is open, it is RECOMMENDED that this |
|
8035 connection be used to send the request, but another connection MAY be |
|
8036 opened and used. |
|
8037 |
|
8038 If a request is sent using multicast, it is sent to the group |
|
8039 address, port, and TTL provided by the transport user. If a request |
|
8040 is sent using unicast unreliable transports, it is sent to the IP |
|
8041 address and port provided by the transport user. |
|
8042 |
|
8043 18.1.2 Receiving Responses |
|
8044 |
|
8045 When a response is received, the client transport examines the top |
|
8046 Via header field value. If the value of the "sent-by" parameter in |
|
8047 that header field value does not correspond to a value that the |
|
8048 client transport is configured to insert into requests, the response |
|
8049 MUST be silently discarded. |
|
8050 |
|
8051 If there are any client transactions in existence, the client |
|
8052 transport uses the matching procedures of Section 17.1.3 to attempt |
|
8053 to match the response to an existing transaction. If there is a |
|
8054 match, the response MUST be passed to that transaction. Otherwise, |
|
8055 the response MUST be passed to the core (whether it be stateless |
|
8056 proxy, stateful proxy, or UA) for further processing. Handling of |
|
8057 these "stray" responses is dependent on the core (a proxy will |
|
8058 forward them, while a UA will discard, for example). |
|
8059 |
|
8060 |
|
8061 |
|
8062 |
|
8063 |
|
8064 |
|
8065 |
|
8066 Rosenberg, et. al. Standards Track [Page 144] |
|
8067 |
|
8068 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8069 |
|
8070 |
|
8071 18.2 Servers |
|
8072 |
|
8073 18.2.1 Receiving Requests |
|
8074 |
|
8075 A server SHOULD be prepared to receive requests on any IP address, |
|
8076 port and transport combination that can be the result of a DNS lookup |
|
8077 on a SIP or SIPS URI [4] that is handed out for the purposes of |
|
8078 communicating with that server. In this context, "handing out" |
|
8079 includes placing a URI in a Contact header field in a REGISTER |
|
8080 request or a redirect response, or in a Record-Route header field in |
|
8081 a request or response. A URI can also be "handed out" by placing it |
|
8082 on a web page or business card. It is also RECOMMENDED that a server |
|
8083 listen for requests on the default SIP ports (5060 for TCP and UDP, |
|
8084 5061 for TLS over TCP) on all public interfaces. The typical |
|
8085 exception would be private networks, or when multiple server |
|
8086 instances are running on the same host. For any port and interface |
|
8087 that a server listens on for UDP, it MUST listen on that same port |
|
8088 and interface for TCP. This is because a message may need to be sent |
|
8089 using TCP, rather than UDP, if it is too large. As a result, the |
|
8090 converse is not true. A server need not listen for UDP on a |
|
8091 particular address and port just because it is listening on that same |
|
8092 address and port for TCP. There may, of course, be other reasons why |
|
8093 a server needs to listen for UDP on a particular address and port. |
|
8094 |
|
8095 When the server transport receives a request over any transport, it |
|
8096 MUST examine the value of the "sent-by" parameter in the top Via |
|
8097 header field value. If the host portion of the "sent-by" parameter |
|
8098 contains a domain name, or if it contains an IP address that differs |
|
8099 from the packet source address, the server MUST add a "received" |
|
8100 parameter to that Via header field value. This parameter MUST |
|
8101 contain the source address from which the packet was received. This |
|
8102 is to assist the server transport layer in sending the response, |
|
8103 since it must be sent to the source IP address from which the request |
|
8104 came. |
|
8105 |
|
8106 Consider a request received by the server transport which looks like, |
|
8107 in part: |
|
8108 |
|
8109 INVITE sip:bob@Biloxi.com SIP/2.0 |
|
8110 Via: SIP/2.0/UDP bobspc.biloxi.com:5060 |
|
8111 |
|
8112 The request is received with a source IP address of 192.0.2.4. |
|
8113 Before passing the request up, the transport adds a "received" |
|
8114 parameter, so that the request would look like, in part: |
|
8115 |
|
8116 INVITE sip:bob@Biloxi.com SIP/2.0 |
|
8117 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4 |
|
8118 |
|
8119 |
|
8120 |
|
8121 |
|
8122 Rosenberg, et. al. Standards Track [Page 145] |
|
8123 |
|
8124 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8125 |
|
8126 |
|
8127 Next, the server transport attempts to match the request to a server |
|
8128 transaction. It does so using the matching rules described in |
|
8129 Section 17.2.3. If a matching server transaction is found, the |
|
8130 request is passed to that transaction for processing. If no match is |
|
8131 found, the request is passed to the core, which may decide to |
|
8132 construct a new server transaction for that request. Note that when |
|
8133 a UAS core sends a 2xx response to INVITE, the server transaction is |
|
8134 destroyed. This means that when the ACK arrives, there will be no |
|
8135 matching server transaction, and based on this rule, the ACK is |
|
8136 passed to the UAS core, where it is processed. |
|
8137 |
|
8138 18.2.2 Sending Responses |
|
8139 |
|
8140 The server transport uses the value of the top Via header field in |
|
8141 order to determine where to send a response. It MUST follow the |
|
8142 following process: |
|
8143 |
|
8144 o If the "sent-protocol" is a reliable transport protocol such as |
|
8145 TCP or SCTP, or TLS over those, the response MUST be sent using |
|
8146 the existing connection to the source of the original request |
|
8147 that created the transaction, if that connection is still open. |
|
8148 This requires the server transport to maintain an association |
|
8149 between server transactions and transport connections. If that |
|
8150 connection is no longer open, the server SHOULD open a |
|
8151 connection to the IP address in the "received" parameter, if |
|
8152 present, using the port in the "sent-by" value, or the default |
|
8153 port for that transport, if no port is specified. If that |
|
8154 connection attempt fails, the server SHOULD use the procedures |
|
8155 in [4] for servers in order to determine the IP address and |
|
8156 port to open the connection and send the response to. |
|
8157 |
|
8158 o Otherwise, if the Via header field value contains a "maddr" |
|
8159 parameter, the response MUST be forwarded to the address listed |
|
8160 there, using the port indicated in "sent-by", or port 5060 if |
|
8161 none is present. If the address is a multicast address, the |
|
8162 response SHOULD be sent using the TTL indicated in the "ttl" |
|
8163 parameter, or with a TTL of 1 if that parameter is not present. |
|
8164 |
|
8165 o Otherwise (for unreliable unicast transports), if the top Via |
|
8166 has a "received" parameter, the response MUST be sent to the |
|
8167 address in the "received" parameter, using the port indicated |
|
8168 in the "sent-by" value, or using port 5060 if none is specified |
|
8169 explicitly. If this fails, for example, elicits an ICMP "port |
|
8170 unreachable" response, the procedures of Section 5 of [4] |
|
8171 SHOULD be used to determine where to send the response. |
|
8172 |
|
8173 |
|
8174 |
|
8175 |
|
8176 |
|
8177 |
|
8178 Rosenberg, et. al. Standards Track [Page 146] |
|
8179 |
|
8180 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8181 |
|
8182 |
|
8183 o Otherwise, if it is not receiver-tagged, the response MUST be |
|
8184 sent to the address indicated by the "sent-by" value, using the |
|
8185 procedures in Section 5 of [4]. |
|
8186 |
|
8187 18.3 Framing |
|
8188 |
|
8189 In the case of message-oriented transports (such as UDP), if the |
|
8190 message has a Content-Length header field, the message body is |
|
8191 assumed to contain that many bytes. If there are additional bytes in |
|
8192 the transport packet beyond the end of the body, they MUST be |
|
8193 discarded. If the transport packet ends before the end of the |
|
8194 message body, this is considered an error. If the message is a |
|
8195 response, it MUST be discarded. If the message is a request, the |
|
8196 element SHOULD generate a 400 (Bad Request) response. If the message |
|
8197 has no Content-Length header field, the message body is assumed to |
|
8198 end at the end of the transport packet. |
|
8199 |
|
8200 In the case of stream-oriented transports such as TCP, the Content- |
|
8201 Length header field indicates the size of the body. The Content- |
|
8202 Length header field MUST be used with stream oriented transports. |
|
8203 |
|
8204 18.4 Error Handling |
|
8205 |
|
8206 Error handling is independent of whether the message was a request or |
|
8207 response. |
|
8208 |
|
8209 If the transport user asks for a message to be sent over an |
|
8210 unreliable transport, and the result is an ICMP error, the behavior |
|
8211 depends on the type of ICMP error. Host, network, port or protocol |
|
8212 unreachable errors, or parameter problem errors SHOULD cause the |
|
8213 transport layer to inform the transport user of a failure in sending. |
|
8214 Source quench and TTL exceeded ICMP errors SHOULD be ignored. |
|
8215 |
|
8216 If the transport user asks for a request to be sent over a reliable |
|
8217 transport, and the result is a connection failure, the transport |
|
8218 layer SHOULD inform the transport user of a failure in sending. |
|
8219 |
|
8220 19 Common Message Components |
|
8221 |
|
8222 There are certain components of SIP messages that appear in various |
|
8223 places within SIP messages (and sometimes, outside of them) that |
|
8224 merit separate discussion. |
|
8225 |
|
8226 |
|
8227 |
|
8228 |
|
8229 |
|
8230 |
|
8231 |
|
8232 |
|
8233 |
|
8234 Rosenberg, et. al. Standards Track [Page 147] |
|
8235 |
|
8236 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8237 |
|
8238 |
|
8239 19.1 SIP and SIPS Uniform Resource Indicators |
|
8240 |
|
8241 A SIP or SIPS URI identifies a communications resource. Like all |
|
8242 URIs, SIP and SIPS URIs may be placed in web pages, email messages, |
|
8243 or printed literature. They contain sufficient information to |
|
8244 initiate and maintain a communication session with the resource. |
|
8245 |
|
8246 Examples of communications resources include the following: |
|
8247 |
|
8248 o a user of an online service |
|
8249 |
|
8250 o an appearance on a multi-line phone |
|
8251 |
|
8252 o a mailbox on a messaging system |
|
8253 |
|
8254 o a PSTN number at a gateway service |
|
8255 |
|
8256 o a group (such as "sales" or "helpdesk") in an organization |
|
8257 |
|
8258 A SIPS URI specifies that the resource be contacted securely. This |
|
8259 means, in particular, that TLS is to be used between the UAC and the |
|
8260 domain that owns the URI. From there, secure communications are used |
|
8261 to reach the user, where the specific security mechanism depends on |
|
8262 the policy of the domain. Any resource described by a SIP URI can be |
|
8263 "upgraded" to a SIPS URI by just changing the scheme, if it is |
|
8264 desired to communicate with that resource securely. |
|
8265 |
|
8266 19.1.1 SIP and SIPS URI Components |
|
8267 |
|
8268 The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5]. |
|
8269 They use a form similar to the mailto URL, allowing the specification |
|
8270 of SIP request-header fields and the SIP message-body. This makes it |
|
8271 possible to specify the subject, media type, or urgency of sessions |
|
8272 initiated by using a URI on a web page or in an email message. The |
|
8273 formal syntax for a SIP or SIPS URI is presented in Section 25. Its |
|
8274 general form, in the case of a SIP URI, is: |
|
8275 |
|
8276 sip:user:password@host:port;uri-parameters?headers |
|
8277 |
|
8278 The format for a SIPS URI is the same, except that the scheme is |
|
8279 "sips" instead of sip. These tokens, and some of the tokens in their |
|
8280 expansions, have the following meanings: |
|
8281 |
|
8282 user: The identifier of a particular resource at the host being |
|
8283 addressed. The term "host" in this context frequently refers |
|
8284 to a domain. The "userinfo" of a URI consists of this user |
|
8285 field, the password field, and the @ sign following them. The |
|
8286 userinfo part of a URI is optional and MAY be absent when the |
|
8287 |
|
8288 |
|
8289 |
|
8290 Rosenberg, et. al. Standards Track [Page 148] |
|
8291 |
|
8292 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8293 |
|
8294 |
|
8295 destination host does not have a notion of users or when the |
|
8296 host itself is the resource being identified. If the @ sign is |
|
8297 present in a SIP or SIPS URI, the user field MUST NOT be empty. |
|
8298 |
|
8299 If the host being addressed can process telephone numbers, for |
|
8300 instance, an Internet telephony gateway, a telephone- |
|
8301 subscriber field defined in RFC 2806 [9] MAY be used to |
|
8302 populate the user field. There are special escaping rules for |
|
8303 encoding telephone-subscriber fields in SIP and SIPS URIs |
|
8304 described in Section 19.1.2. |
|
8305 |
|
8306 password: A password associated with the user. While the SIP and |
|
8307 SIPS URI syntax allows this field to be present, its use is NOT |
|
8308 RECOMMENDED, because the passing of authentication information |
|
8309 in clear text (such as URIs) has proven to be a security risk |
|
8310 in almost every case where it has been used. For instance, |
|
8311 transporting a PIN number in this field exposes the PIN. |
|
8312 |
|
8313 Note that the password field is just an extension of the user |
|
8314 portion. Implementations not wishing to give special |
|
8315 significance to the password portion of the field MAY simply |
|
8316 treat "user:password" as a single string. |
|
8317 |
|
8318 host: The host providing the SIP resource. The host part contains |
|
8319 either a fully-qualified domain name or numeric IPv4 or IPv6 |
|
8320 address. Using the fully-qualified domain name form is |
|
8321 RECOMMENDED whenever possible. |
|
8322 |
|
8323 port: The port number where the request is to be sent. |
|
8324 |
|
8325 URI parameters: Parameters affecting a request constructed from |
|
8326 the URI. |
|
8327 |
|
8328 URI parameters are added after the hostport component and are |
|
8329 separated by semi-colons. |
|
8330 |
|
8331 URI parameters take the form: |
|
8332 |
|
8333 parameter-name "=" parameter-value |
|
8334 |
|
8335 Even though an arbitrary number of URI parameters may be |
|
8336 included in a URI, any given parameter-name MUST NOT appear |
|
8337 more than once. |
|
8338 |
|
8339 This extensible mechanism includes the transport, maddr, ttl, |
|
8340 user, method and lr parameters. |
|
8341 |
|
8342 |
|
8343 |
|
8344 |
|
8345 |
|
8346 Rosenberg, et. al. Standards Track [Page 149] |
|
8347 |
|
8348 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8349 |
|
8350 |
|
8351 The transport parameter determines the transport mechanism to |
|
8352 be used for sending SIP messages, as specified in [4]. SIP can |
|
8353 use any network transport protocol. Parameter names are |
|
8354 defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP |
|
8355 (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST |
|
8356 indicate a reliable transport. |
|
8357 |
|
8358 The maddr parameter indicates the server address to be |
|
8359 contacted for this user, overriding any address derived from |
|
8360 the host field. When an maddr parameter is present, the port |
|
8361 and transport components of the URI apply to the address |
|
8362 indicated in the maddr parameter value. [4] describes the |
|
8363 proper interpretation of the transport, maddr, and hostport in |
|
8364 order to obtain the destination address, port, and transport |
|
8365 for sending a request. |
|
8366 |
|
8367 The maddr field has been used as a simple form of loose source |
|
8368 routing. It allows a URI to specify a proxy that must be |
|
8369 traversed en-route to the destination. Continuing to use the |
|
8370 maddr parameter this way is strongly discouraged (the |
|
8371 mechanisms that enable it are deprecated). Implementations |
|
8372 should instead use the Route mechanism described in this |
|
8373 document, establishing a pre-existing route set if necessary |
|
8374 (see Section 8.1.1.1). This provides a full URI to describe |
|
8375 the node to be traversed. |
|
8376 |
|
8377 The ttl parameter determines the time-to-live value of the UDP |
|
8378 multicast packet and MUST only be used if maddr is a multicast |
|
8379 address and the transport protocol is UDP. For example, to |
|
8380 specify a call to alice@atlanta.com using multicast to |
|
8381 239.255.255.1 with a ttl of 15, the following URI would be |
|
8382 used: |
|
8383 |
|
8384 sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 |
|
8385 |
|
8386 The set of valid telephone-subscriber strings is a subset of |
|
8387 valid user strings. The user URI parameter exists to |
|
8388 distinguish telephone numbers from user names that happen to |
|
8389 look like telephone numbers. If the user string contains a |
|
8390 telephone number formatted as a telephone-subscriber, the user |
|
8391 parameter value "phone" SHOULD be present. Even without this |
|
8392 parameter, recipients of SIP and SIPS URIs MAY interpret the |
|
8393 pre-@ part as a telephone number if local restrictions on the |
|
8394 name space for user name allow it. |
|
8395 |
|
8396 The method of the SIP request constructed from the URI can be |
|
8397 specified with the method parameter. |
|
8398 |
|
8399 |
|
8400 |
|
8401 |
|
8402 Rosenberg, et. al. Standards Track [Page 150] |
|
8403 |
|
8404 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8405 |
|
8406 |
|
8407 The lr parameter, when present, indicates that the element |
|
8408 responsible for this resource implements the routing mechanisms |
|
8409 specified in this document. This parameter will be used in the |
|
8410 URIs proxies place into Record-Route header field values, and |
|
8411 may appear in the URIs in a pre-existing route set. |
|
8412 |
|
8413 This parameter is used to achieve backwards compatibility with |
|
8414 systems implementing the strict-routing mechanisms of RFC 2543 |
|
8415 and the rfc2543bis drafts up to bis-05. An element preparing |
|
8416 to send a request based on a URI not containing this parameter |
|
8417 can assume the receiving element implements strict-routing and |
|
8418 reformat the message to preserve the information in the |
|
8419 Request-URI. |
|
8420 |
|
8421 Since the uri-parameter mechanism is extensible, SIP elements |
|
8422 MUST silently ignore any uri-parameters that they do not |
|
8423 understand. |
|
8424 |
|
8425 Headers: Header fields to be included in a request constructed |
|
8426 from the URI. |
|
8427 |
|
8428 Headers fields in the SIP request can be specified with the "?" |
|
8429 mechanism within a URI. The header names and values are |
|
8430 encoded in ampersand separated hname = hvalue pairs. The |
|
8431 special hname "body" indicates that the associated hvalue is |
|
8432 the message-body of the SIP request. |
|
8433 |
|
8434 Table 1 summarizes the use of SIP and SIPS URI components based on |
|
8435 the context in which the URI appears. The external column describes |
|
8436 URIs appearing anywhere outside of a SIP message, for instance on a |
|
8437 web page or business card. Entries marked "m" are mandatory, those |
|
8438 marked "o" are optional, and those marked "-" are not allowed. |
|
8439 Elements processing URIs SHOULD ignore any disallowed components if |
|
8440 they are present. The second column indicates the default value of |
|
8441 an optional element if it is not present. "--" indicates that the |
|
8442 element is either not optional, or has no default value. |
|
8443 |
|
8444 URIs in Contact header fields have different restrictions depending |
|
8445 on the context in which the header field appears. One set applies to |
|
8446 messages that establish and maintain dialogs (INVITE and its 200 (OK) |
|
8447 response). The other applies to registration and redirection |
|
8448 messages (REGISTER, its 200 (OK) response, and 3xx class responses to |
|
8449 any method). |
|
8450 |
|
8451 |
|
8452 |
|
8453 |
|
8454 |
|
8455 |
|
8456 |
|
8457 |
|
8458 Rosenberg, et. al. Standards Track [Page 151] |
|
8459 |
|
8460 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8461 |
|
8462 |
|
8463 19.1.2 Character Escaping Requirements |
|
8464 |
|
8465 dialog |
|
8466 reg./redir. Contact/ |
|
8467 default Req.-URI To From Contact R-R/Route external |
|
8468 user -- o o o o o o |
|
8469 password -- o o o o o o |
|
8470 host -- m m m m m m |
|
8471 port (1) o - - o o o |
|
8472 user-param ip o o o o o o |
|
8473 method INVITE - - - - - o |
|
8474 maddr-param -- o - - o o o |
|
8475 ttl-param 1 o - - o - o |
|
8476 transp.-param (2) o - - o o o |
|
8477 lr-param -- o - - - o o |
|
8478 other-param -- o o o o o o |
|
8479 headers -- - - - o - o |
|
8480 |
|
8481 (1): The default port value is transport and scheme dependent. The |
|
8482 default is 5060 for sip: using UDP, TCP, or SCTP. The default is |
|
8483 5061 for sip: using TLS over TCP and sips: over TCP. |
|
8484 |
|
8485 (2): The default transport is scheme dependent. For sip:, it is UDP. |
|
8486 For sips:, it is TCP. |
|
8487 |
|
8488 Table 1: Use and default values of URI components for SIP header |
|
8489 field values, Request-URI and references |
|
8490 |
|
8491 SIP follows the requirements and guidelines of RFC 2396 [5] when |
|
8492 defining the set of characters that must be escaped in a SIP URI, and |
|
8493 uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]: |
|
8494 |
|
8495 The set of characters actually reserved within any given URI |
|
8496 component is defined by that component. In general, a character |
|
8497 is reserved if the semantics of the URI changes if the character |
|
8498 is replaced with its escaped US-ASCII encoding [5]. Excluded US- |
|
8499 ASCII characters (RFC 2396 [5]), such as space and control |
|
8500 characters and characters used as URI delimiters, also MUST be |
|
8501 escaped. URIs MUST NOT contain unescaped space and control |
|
8502 characters. |
|
8503 |
|
8504 For each component, the set of valid BNF expansions defines exactly |
|
8505 which characters may appear unescaped. All other characters MUST be |
|
8506 escaped. |
|
8507 |
|
8508 For example, "@" is not in the set of characters in the user |
|
8509 component, so the user "j@s0n" must have at least the @ sign encoded, |
|
8510 as in "j%40s0n". |
|
8511 |
|
8512 |
|
8513 |
|
8514 Rosenberg, et. al. Standards Track [Page 152] |
|
8515 |
|
8516 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8517 |
|
8518 |
|
8519 Expanding the hname and hvalue tokens in Section 25 show that all URI |
|
8520 reserved characters in header field names and values MUST be escaped. |
|
8521 |
|
8522 The telephone-subscriber subset of the user component has special |
|
8523 escaping considerations. The set of characters not reserved in the |
|
8524 RFC 2806 [9] description of telephone-subscriber contains a number of |
|
8525 characters in various syntax elements that need to be escaped when |
|
8526 used in SIP URIs. Any characters occurring in a telephone-subscriber |
|
8527 that do not appear in an expansion of the BNF for the user rule MUST |
|
8528 be escaped. |
|
8529 |
|
8530 Note that character escaping is not allowed in the host component of |
|
8531 a SIP or SIPS URI (the % character is not valid in its expansion). |
|
8532 This is likely to change in the future as requirements for |
|
8533 Internationalized Domain Names are finalized. Current |
|
8534 implementations MUST NOT attempt to improve robustness by treating |
|
8535 received escaped characters in the host component as literally |
|
8536 equivalent to their unescaped counterpart. The behavior required to |
|
8537 meet the requirements of IDN may be significantly different. |
|
8538 |
|
8539 19.1.3 Example SIP and SIPS URIs |
|
8540 |
|
8541 sip:alice@atlanta.com |
|
8542 sip:alice:secretword@atlanta.com;transport=tcp |
|
8543 sips:alice@atlanta.com?subject=project%20x&priority=urgent |
|
8544 sip:+1-212-555-1212:1234@gateway.com;user=phone |
|
8545 sips:1212@gateway.com |
|
8546 sip:alice@192.0.2.4 |
|
8547 sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com |
|
8548 sip:alice;day=tuesday@atlanta.com |
|
8549 |
|
8550 The last sample URI above has a user field value of |
|
8551 "alice;day=tuesday". The escaping rules defined above allow a |
|
8552 semicolon to appear unescaped in this field. For the purposes of |
|
8553 this protocol, the field is opaque. The structure of that value is |
|
8554 only useful to the SIP element responsible for the resource. |
|
8555 |
|
8556 19.1.4 URI Comparison |
|
8557 |
|
8558 Some operations in this specification require determining whether two |
|
8559 SIP or SIPS URIs are equivalent. In this specification, registrars |
|
8560 need to compare bindings in Contact URIs in REGISTER requests (see |
|
8561 Section 10.3.). SIP and SIPS URIs are compared for equality |
|
8562 according to the following rules: |
|
8563 |
|
8564 o A SIP and SIPS URI are never equivalent. |
|
8565 |
|
8566 |
|
8567 |
|
8568 |
|
8569 |
|
8570 Rosenberg, et. al. Standards Track [Page 153] |
|
8571 |
|
8572 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8573 |
|
8574 |
|
8575 o Comparison of the userinfo of SIP and SIPS URIs is case- |
|
8576 sensitive. This includes userinfo containing passwords or |
|
8577 formatted as telephone-subscribers. Comparison of all other |
|
8578 components of the URI is case-insensitive unless explicitly |
|
8579 defined otherwise. |
|
8580 |
|
8581 o The ordering of parameters and header fields is not significant |
|
8582 in comparing SIP and SIPS URIs. |
|
8583 |
|
8584 o Characters other than those in the "reserved" set (see RFC 2396 |
|
8585 [5]) are equivalent to their ""%" HEX HEX" encoding. |
|
8586 |
|
8587 o An IP address that is the result of a DNS lookup of a host name |
|
8588 does not match that host name. |
|
8589 |
|
8590 o For two URIs to be equal, the user, password, host, and port |
|
8591 components must match. |
|
8592 |
|
8593 A URI omitting the user component will not match a URI that |
|
8594 includes one. A URI omitting the password component will not |
|
8595 match a URI that includes one. |
|
8596 |
|
8597 A URI omitting any component with a default value will not |
|
8598 match a URI explicitly containing that component with its |
|
8599 default value. For instance, a URI omitting the optional port |
|
8600 component will not match a URI explicitly declaring port 5060. |
|
8601 The same is true for the transport-parameter, ttl-parameter, |
|
8602 user-parameter, and method components. |
|
8603 |
|
8604 Defining sip:user@host to not be equivalent to |
|
8605 sip:user@host:5060 is a change from RFC 2543. When deriving |
|
8606 addresses from URIs, equivalent addresses are expected from |
|
8607 equivalent URIs. The URI sip:user@host:5060 will always |
|
8608 resolve to port 5060. The URI sip:user@host may resolve to |
|
8609 other ports through the DNS SRV mechanisms detailed in [4]. |
|
8610 |
|
8611 o URI uri-parameter components are compared as follows: |
|
8612 |
|
8613 - Any uri-parameter appearing in both URIs must match. |
|
8614 |
|
8615 - A user, ttl, or method uri-parameter appearing in only one |
|
8616 URI never matches, even if it contains the default value. |
|
8617 |
|
8618 - A URI that includes an maddr parameter will not match a URI |
|
8619 that contains no maddr parameter. |
|
8620 |
|
8621 - All other uri-parameters appearing in only one URI are |
|
8622 ignored when comparing the URIs. |
|
8623 |
|
8624 |
|
8625 |
|
8626 Rosenberg, et. al. Standards Track [Page 154] |
|
8627 |
|
8628 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8629 |
|
8630 |
|
8631 o URI header components are never ignored. Any present header |
|
8632 component MUST be present in both URIs and match for the URIs |
|
8633 to match. The matching rules are defined for each header field |
|
8634 in Section 20. |
|
8635 |
|
8636 The URIs within each of the following sets are equivalent: |
|
8637 |
|
8638 sip:%61lice@atlanta.com;transport=TCP |
|
8639 sip:alice@AtLanTa.CoM;Transport=tcp |
|
8640 |
|
8641 sip:carol@chicago.com |
|
8642 sip:carol@chicago.com;newparam=5 |
|
8643 sip:carol@chicago.com;security=on |
|
8644 |
|
8645 sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com |
|
8646 sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com |
|
8647 |
|
8648 sip:alice@atlanta.com?subject=project%20x&priority=urgent |
|
8649 sip:alice@atlanta.com?priority=urgent&subject=project%20x |
|
8650 |
|
8651 The URIs within each of the following sets are not equivalent: |
|
8652 |
|
8653 SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) |
|
8654 sip:alice@AtLanTa.CoM;Transport=UDP |
|
8655 |
|
8656 sip:bob@biloxi.com (can resolve to different ports) |
|
8657 sip:bob@biloxi.com:5060 |
|
8658 |
|
8659 sip:bob@biloxi.com (can resolve to different transports) |
|
8660 sip:bob@biloxi.com;transport=udp |
|
8661 |
|
8662 sip:bob@biloxi.com (can resolve to different port and transports) |
|
8663 sip:bob@biloxi.com:6000;transport=tcp |
|
8664 |
|
8665 sip:carol@chicago.com (different header component) |
|
8666 sip:carol@chicago.com?Subject=next%20meeting |
|
8667 |
|
8668 sip:bob@phone21.boxesbybob.com (even though that's what |
|
8669 sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) |
|
8670 |
|
8671 Note that equality is not transitive: |
|
8672 |
|
8673 o sip:carol@chicago.com and sip:carol@chicago.com;security=on are |
|
8674 equivalent |
|
8675 |
|
8676 o sip:carol@chicago.com and sip:carol@chicago.com;security=off |
|
8677 are equivalent |
|
8678 |
|
8679 |
|
8680 |
|
8681 |
|
8682 Rosenberg, et. al. Standards Track [Page 155] |
|
8683 |
|
8684 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8685 |
|
8686 |
|
8687 o sip:carol@chicago.com;security=on and |
|
8688 sip:carol@chicago.com;security=off are not equivalent |
|
8689 |
|
8690 19.1.5 Forming Requests from a URI |
|
8691 |
|
8692 An implementation needs to take care when forming requests directly |
|
8693 from a URI. URIs from business cards, web pages, and even from |
|
8694 sources inside the protocol such as registered contacts may contain |
|
8695 inappropriate header fields or body parts. |
|
8696 |
|
8697 An implementation MUST include any provided transport, maddr, ttl, or |
|
8698 user parameter in the Request-URI of the formed request. If the URI |
|
8699 contains a method parameter, its value MUST be used as the method of |
|
8700 the request. The method parameter MUST NOT be placed in the |
|
8701 Request-URI. Unknown URI parameters MUST be placed in the message's |
|
8702 Request-URI. |
|
8703 |
|
8704 An implementation SHOULD treat the presence of any headers or body |
|
8705 parts in the URI as a desire to include them in the message, and |
|
8706 choose to honor the request on a per-component basis. |
|
8707 |
|
8708 An implementation SHOULD NOT honor these obviously dangerous header |
|
8709 fields: From, Call-ID, CSeq, Via, and Record-Route. |
|
8710 |
|
8711 An implementation SHOULD NOT honor any requested Route header field |
|
8712 values in order to not be used as an unwitting agent in malicious |
|
8713 attacks. |
|
8714 |
|
8715 An implementation SHOULD NOT honor requests to include header fields |
|
8716 that may cause it to falsely advertise its location or capabilities. |
|
8717 These include: Accept, Accept-Encoding, Accept-Language, Allow, |
|
8718 Contact (in its dialog usage), Organization, Supported, and User- |
|
8719 Agent. |
|
8720 |
|
8721 An implementation SHOULD verify the accuracy of any requested |
|
8722 descriptive header fields, including: Content-Disposition, Content- |
|
8723 Encoding, Content-Language, Content-Length, Content-Type, Date, |
|
8724 Mime-Version, and Timestamp. |
|
8725 |
|
8726 If the request formed from constructing a message from a given URI is |
|
8727 not a valid SIP request, the URI is invalid. An implementation MUST |
|
8728 NOT proceed with transmitting the request. It should instead pursue |
|
8729 the course of action due an invalid URI in the context it occurs. |
|
8730 |
|
8731 The constructed request can be invalid in many ways. These |
|
8732 include, but are not limited to, syntax error in header fields, |
|
8733 invalid combinations of URI parameters, or an incorrect |
|
8734 description of the message body. |
|
8735 |
|
8736 |
|
8737 |
|
8738 Rosenberg, et. al. Standards Track [Page 156] |
|
8739 |
|
8740 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8741 |
|
8742 |
|
8743 Sending a request formed from a given URI may require capabilities |
|
8744 unavailable to the implementation. The URI might indicate use of an |
|
8745 unimplemented transport or extension, for example. An implementation |
|
8746 SHOULD refuse to send these requests rather than modifying them to |
|
8747 match their capabilities. An implementation MUST NOT send a request |
|
8748 requiring an extension that it does not support. |
|
8749 |
|
8750 For example, such a request can be formed through the presence of |
|
8751 a Require header parameter or a method URI parameter with an |
|
8752 unknown or explicitly unsupported value. |
|
8753 |
|
8754 19.1.6 Relating SIP URIs and tel URLs |
|
8755 |
|
8756 When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the |
|
8757 entire telephone-subscriber portion of the tel URL, including any |
|
8758 parameters, is placed into the userinfo part of the SIP or SIPS URI. |
|
8759 |
|
8760 Thus, tel:+358-555-1234567;postd=pp22 becomes |
|
8761 |
|
8762 sip:+358-555-1234567;postd=pp22@foo.com;user=phone |
|
8763 |
|
8764 or |
|
8765 sips:+358-555-1234567;postd=pp22@foo.com;user=phone |
|
8766 |
|
8767 not |
|
8768 sip:+358-555-1234567@foo.com;postd=pp22;user=phone |
|
8769 |
|
8770 or |
|
8771 |
|
8772 sips:+358-555-1234567@foo.com;postd=pp22;user=phone |
|
8773 |
|
8774 In general, equivalent "tel" URLs converted to SIP or SIPS URIs in |
|
8775 this fashion may not produce equivalent SIP or SIPS URIs. The |
|
8776 userinfo of SIP and SIPS URIs are compared as a case-sensitive |
|
8777 string. Variance in case-insensitive portions of tel URLs and |
|
8778 reordering of tel URL parameters does not affect tel URL equivalence, |
|
8779 but does affect the equivalence of SIP URIs formed from them. |
|
8780 |
|
8781 For example, |
|
8782 |
|
8783 tel:+358-555-1234567;postd=pp22 |
|
8784 tel:+358-555-1234567;POSTD=PP22 |
|
8785 |
|
8786 are equivalent, while |
|
8787 |
|
8788 sip:+358-555-1234567;postd=pp22@foo.com;user=phone |
|
8789 sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone |
|
8790 |
|
8791 |
|
8792 |
|
8793 |
|
8794 Rosenberg, et. al. Standards Track [Page 157] |
|
8795 |
|
8796 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8797 |
|
8798 |
|
8799 are not. |
|
8800 |
|
8801 Likewise, |
|
8802 |
|
8803 tel:+358-555-1234567;postd=pp22;isub=1411 |
|
8804 tel:+358-555-1234567;isub=1411;postd=pp22 |
|
8805 |
|
8806 are equivalent, while |
|
8807 |
|
8808 sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone |
|
8809 sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone |
|
8810 |
|
8811 are not. |
|
8812 |
|
8813 To mitigate this problem, elements constructing telephone-subscriber |
|
8814 fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold |
|
8815 any case-insensitive portion of telephone-subscriber to lower case, |
|
8816 and order the telephone-subscriber parameters lexically by parameter |
|
8817 name, excepting isdn-subaddress and post-dial, which occur first and |
|
8818 in that order. (All components of a tel URL except for future- |
|
8819 extension parameters are defined to be compared case-insensitive.) |
|
8820 |
|
8821 Following this suggestion, both |
|
8822 |
|
8823 tel:+358-555-1234567;postd=pp22 |
|
8824 tel:+358-555-1234567;POSTD=PP22 |
|
8825 |
|
8826 become |
|
8827 |
|
8828 sip:+358-555-1234567;postd=pp22@foo.com;user=phone |
|
8829 |
|
8830 and both |
|
8831 |
|
8832 tel:+358-555-1234567;tsp=a.b;phone-context=5 |
|
8833 tel:+358-555-1234567;phone-context=5;tsp=a.b |
|
8834 |
|
8835 become |
|
8836 |
|
8837 sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone |
|
8838 |
|
8839 19.2 Option Tags |
|
8840 |
|
8841 Option tags are unique identifiers used to designate new options |
|
8842 (extensions) in SIP. These tags are used in Require (Section 20.32), |
|
8843 Proxy-Require (Section 20.29), Supported (Section 20.37) and |
|
8844 Unsupported (Section 20.40) header fields. Note that these options |
|
8845 appear as parameters in those header fields in an option-tag = token |
|
8846 form (see Section 25 for the definition of token). |
|
8847 |
|
8848 |
|
8849 |
|
8850 Rosenberg, et. al. Standards Track [Page 158] |
|
8851 |
|
8852 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8853 |
|
8854 |
|
8855 Option tags are defined in standards track RFCs. This is a change |
|
8856 from past practice, and is instituted to ensure continuing multi- |
|
8857 vendor interoperability (see discussion in Section 20.32 and Section |
|
8858 20.37). An IANA registry of option tags is used to ensure easy |
|
8859 reference. |
|
8860 |
|
8861 19.3 Tags |
|
8862 |
|
8863 The "tag" parameter is used in the To and From header fields of SIP |
|
8864 messages. It serves as a general mechanism to identify a dialog, |
|
8865 which is the combination of the Call-ID along with two tags, one from |
|
8866 each participant in the dialog. When a UA sends a request outside of |
|
8867 a dialog, it contains a From tag only, providing "half" of the dialog |
|
8868 ID. The dialog is completed from the response(s), each of which |
|
8869 contributes the second half in the To header field. The forking of |
|
8870 SIP requests means that multiple dialogs can be established from a |
|
8871 single request. This also explains the need for the two-sided dialog |
|
8872 identifier; without a contribution from the recipients, the |
|
8873 originator could not disambiguate the multiple dialogs established |
|
8874 from a single request. |
|
8875 |
|
8876 When a tag is generated by a UA for insertion into a request or |
|
8877 response, it MUST be globally unique and cryptographically random |
|
8878 with at least 32 bits of randomness. A property of this selection |
|
8879 requirement is that a UA will place a different tag into the From |
|
8880 header of an INVITE than it would place into the To header of the |
|
8881 response to the same INVITE. This is needed in order for a UA to |
|
8882 invite itself to a session, a common case for "hairpinning" of calls |
|
8883 in PSTN gateways. Similarly, two INVITEs for different calls will |
|
8884 have different From tags, and two responses for different calls will |
|
8885 have different To tags. |
|
8886 |
|
8887 Besides the requirement for global uniqueness, the algorithm for |
|
8888 generating a tag is implementation-specific. Tags are helpful in |
|
8889 fault tolerant systems, where a dialog is to be recovered on an |
|
8890 alternate server after a failure. A UAS can select the tag in such a |
|
8891 way that a backup can recognize a request as part of a dialog on the |
|
8892 failed server, and therefore determine that it should attempt to |
|
8893 recover the dialog and any other state associated with it. |
|
8894 |
|
8895 20 Header Fields |
|
8896 |
|
8897 The general syntax for header fields is covered in Section 7.3. This |
|
8898 section lists the full set of header fields along with notes on |
|
8899 syntax, meaning, and usage. Throughout this section, we use [HX.Y] |
|
8900 to refer to Section X.Y of the current HTTP/1.1 specification RFC |
|
8901 2616 [8]. Examples of each header field are given. |
|
8902 |
|
8903 |
|
8904 |
|
8905 |
|
8906 Rosenberg, et. al. Standards Track [Page 159] |
|
8907 |
|
8908 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8909 |
|
8910 |
|
8911 Information about header fields in relation to methods and proxy |
|
8912 processing is summarized in Tables 2 and 3. |
|
8913 |
|
8914 The "where" column describes the request and response types in which |
|
8915 the header field can be used. Values in this column are: |
|
8916 |
|
8917 R: header field may only appear in requests; |
|
8918 |
|
8919 r: header field may only appear in responses; |
|
8920 |
|
8921 2xx, 4xx, etc.: A numerical value or range indicates response |
|
8922 codes with which the header field can be used; |
|
8923 |
|
8924 c: header field is copied from the request to the response. |
|
8925 |
|
8926 An empty entry in the "where" column indicates that the header |
|
8927 field may be present in all requests and responses. |
|
8928 |
|
8929 The "proxy" column describes the operations a proxy may perform on a |
|
8930 header field: |
|
8931 |
|
8932 a: A proxy can add or concatenate the header field if not present. |
|
8933 |
|
8934 m: A proxy can modify an existing header field value. |
|
8935 |
|
8936 d: A proxy can delete a header field value. |
|
8937 |
|
8938 r: A proxy must be able to read the header field, and thus this |
|
8939 header field cannot be encrypted. |
|
8940 |
|
8941 The next six columns relate to the presence of a header field in a |
|
8942 method: |
|
8943 |
|
8944 c: Conditional; requirements on the header field depend on the |
|
8945 context of the message. |
|
8946 |
|
8947 m: The header field is mandatory. |
|
8948 |
|
8949 m*: The header field SHOULD be sent, but clients/servers need to |
|
8950 be prepared to receive messages without that header field. |
|
8951 |
|
8952 o: The header field is optional. |
|
8953 |
|
8954 t: The header field SHOULD be sent, but clients/servers need to be |
|
8955 prepared to receive messages without that header field. |
|
8956 |
|
8957 If a stream-based protocol (such as TCP) is used as a |
|
8958 transport, then the header field MUST be sent. |
|
8959 |
|
8960 |
|
8961 |
|
8962 Rosenberg, et. al. Standards Track [Page 160] |
|
8963 |
|
8964 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
8965 |
|
8966 |
|
8967 *: The header field is required if the message body is not empty. |
|
8968 See Sections 20.14, 20.15 and 7.4 for details. |
|
8969 |
|
8970 -: The header field is not applicable. |
|
8971 |
|
8972 "Optional" means that an element MAY include the header field in a |
|
8973 request or response, and a UA MAY ignore the header field if present |
|
8974 in the request or response (The exception to this rule is the Require |
|
8975 header field discussed in 20.32). A "mandatory" header field MUST be |
|
8976 present in a request, and MUST be understood by the UAS receiving the |
|
8977 request. A mandatory response header field MUST be present in the |
|
8978 response, and the header field MUST be understood by the UAC |
|
8979 processing the response. "Not applicable" means that the header |
|
8980 field MUST NOT be present in a request. If one is placed in a |
|
8981 request by mistake, it MUST be ignored by the UAS receiving the |
|
8982 request. Similarly, a header field labeled "not applicable" for a |
|
8983 response means that the UAS MUST NOT place the header field in the |
|
8984 response, and the UAC MUST ignore the header field in the response. |
|
8985 |
|
8986 A UA SHOULD ignore extension header parameters that are not |
|
8987 understood. |
|
8988 |
|
8989 A compact form of some common header field names is also defined for |
|
8990 use when overall message size is an issue. |
|
8991 |
|
8992 The Contact, From, and To header fields contain a URI. If the URI |
|
8993 contains a comma, question mark or semicolon, the URI MUST be |
|
8994 enclosed in angle brackets (< and >). Any URI parameters are |
|
8995 contained within these brackets. If the URI is not enclosed in angle |
|
8996 brackets, any semicolon-delimited parameters are header-parameters, |
|
8997 not URI parameters. |
|
8998 |
|
8999 20.1 Accept |
|
9000 |
|
9001 The Accept header field follows the syntax defined in [H14.1]. The |
|
9002 semantics are also identical, with the exception that if no Accept |
|
9003 header field is present, the server SHOULD assume a default value of |
|
9004 application/sdp. |
|
9005 |
|
9006 An empty Accept header field means that no formats are acceptable. |
|
9007 |
|
9008 |
|
9009 |
|
9010 |
|
9011 |
|
9012 |
|
9013 |
|
9014 |
|
9015 |
|
9016 |
|
9017 |
|
9018 Rosenberg, et. al. Standards Track [Page 161] |
|
9019 |
|
9020 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9021 |
|
9022 |
|
9023 Example: |
|
9024 |
|
9025 Header field where proxy ACK BYE CAN INV OPT REG |
|
9026 ___________________________________________________________ |
|
9027 Accept R - o - o m* o |
|
9028 Accept 2xx - - - o m* o |
|
9029 Accept 415 - c - c c c |
|
9030 Accept-Encoding R - o - o o o |
|
9031 Accept-Encoding 2xx - - - o m* o |
|
9032 Accept-Encoding 415 - c - c c c |
|
9033 Accept-Language R - o - o o o |
|
9034 Accept-Language 2xx - - - o m* o |
|
9035 Accept-Language 415 - c - c c c |
|
9036 Alert-Info R ar - - - o - - |
|
9037 Alert-Info 180 ar - - - o - - |
|
9038 Allow R - o - o o o |
|
9039 Allow 2xx - o - m* m* o |
|
9040 Allow r - o - o o o |
|
9041 Allow 405 - m - m m m |
|
9042 Authentication-Info 2xx - o - o o o |
|
9043 Authorization R o o o o o o |
|
9044 Call-ID c r m m m m m m |
|
9045 Call-Info ar - - - o o o |
|
9046 Contact R o - - m o o |
|
9047 Contact 1xx - - - o - - |
|
9048 Contact 2xx - - - m o o |
|
9049 Contact 3xx d - o - o o o |
|
9050 Contact 485 - o - o o o |
|
9051 Content-Disposition o o - o o o |
|
9052 Content-Encoding o o - o o o |
|
9053 Content-Language o o - o o o |
|
9054 Content-Length ar t t t t t t |
|
9055 Content-Type * * - * * * |
|
9056 CSeq c r m m m m m m |
|
9057 Date a o o o o o o |
|
9058 Error-Info 300-699 a - o o o o o |
|
9059 Expires - - - o - o |
|
9060 From c r m m m m m m |
|
9061 In-Reply-To R - - - o - - |
|
9062 Max-Forwards R amr m m m m m m |
|
9063 Min-Expires 423 - - - - - m |
|
9064 MIME-Version o o - o o o |
|
9065 Organization ar - - - o o o |
|
9066 |
|
9067 Table 2: Summary of header fields, A--O |
|
9068 |
|
9069 |
|
9070 |
|
9071 |
|
9072 |
|
9073 |
|
9074 Rosenberg, et. al. Standards Track [Page 162] |
|
9075 |
|
9076 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9077 |
|
9078 |
|
9079 Header field where proxy ACK BYE CAN INV OPT REG |
|
9080 ___________________________________________________________________ |
|
9081 Priority R ar - - - o - - |
|
9082 Proxy-Authenticate 407 ar - m - m m m |
|
9083 Proxy-Authenticate 401 ar - o o o o o |
|
9084 Proxy-Authorization R dr o o - o o o |
|
9085 Proxy-Require R ar - o - o o o |
|
9086 Record-Route R ar o o o o o - |
|
9087 Record-Route 2xx,18x mr - o o o o - |
|
9088 Reply-To - - - o - - |
|
9089 Require ar - c - c c c |
|
9090 Retry-After 404,413,480,486 - o o o o o |
|
9091 500,503 - o o o o o |
|
9092 600,603 - o o o o o |
|
9093 Route R adr c c c c c c |
|
9094 Server r - o o o o o |
|
9095 Subject R - - - o - - |
|
9096 Supported R - o o m* o o |
|
9097 Supported 2xx - o o m* m* o |
|
9098 Timestamp o o o o o o |
|
9099 To c(1) r m m m m m m |
|
9100 Unsupported 420 - m - m m m |
|
9101 User-Agent o o o o o o |
|
9102 Via R amr m m m m m m |
|
9103 Via rc dr m m m m m m |
|
9104 Warning r - o o o o o |
|
9105 WWW-Authenticate 401 ar - m - m m m |
|
9106 WWW-Authenticate 407 ar - o - o o o |
|
9107 |
|
9108 Table 3: Summary of header fields, P--Z; (1): copied with possible |
|
9109 addition of tag |
|
9110 |
|
9111 Accept: application/sdp;level=1, application/x-private, text/html |
|
9112 |
|
9113 20.2 Accept-Encoding |
|
9114 |
|
9115 The Accept-Encoding header field is similar to Accept, but restricts |
|
9116 the content-codings [H3.5] that are acceptable in the response. See |
|
9117 [H14.3]. The semantics in SIP are identical to those defined in |
|
9118 [H14.3]. |
|
9119 |
|
9120 An empty Accept-Encoding header field is permissible. It is |
|
9121 equivalent to Accept-Encoding: identity, that is, only the identity |
|
9122 encoding, meaning no encoding, is permissible. |
|
9123 |
|
9124 If no Accept-Encoding header field is present, the server SHOULD |
|
9125 assume a default value of identity. |
|
9126 |
|
9127 |
|
9128 |
|
9129 |
|
9130 Rosenberg, et. al. Standards Track [Page 163] |
|
9131 |
|
9132 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9133 |
|
9134 |
|
9135 This differs slightly from the HTTP definition, which indicates that |
|
9136 when not present, any encoding can be used, but the identity encoding |
|
9137 is preferred. |
|
9138 |
|
9139 Example: |
|
9140 |
|
9141 Accept-Encoding: gzip |
|
9142 |
|
9143 20.3 Accept-Language |
|
9144 |
|
9145 The Accept-Language header field is used in requests to indicate the |
|
9146 preferred languages for reason phrases, session descriptions, or |
|
9147 status responses carried as message bodies in the response. If no |
|
9148 Accept-Language header field is present, the server SHOULD assume all |
|
9149 languages are acceptable to the client. |
|
9150 |
|
9151 The Accept-Language header field follows the syntax defined in |
|
9152 [H14.4]. The rules for ordering the languages based on the "q" |
|
9153 parameter apply to SIP as well. |
|
9154 |
|
9155 Example: |
|
9156 |
|
9157 Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
|
9158 |
|
9159 20.4 Alert-Info |
|
9160 |
|
9161 When present in an INVITE request, the Alert-Info header field |
|
9162 specifies an alternative ring tone to the UAS. When present in a 180 |
|
9163 (Ringing) response, the Alert-Info header field specifies an |
|
9164 alternative ringback tone to the UAC. A typical usage is for a proxy |
|
9165 to insert this header field to provide a distinctive ring feature. |
|
9166 |
|
9167 The Alert-Info header field can introduce security risks. These |
|
9168 risks and the ways to handle them are discussed in Section 20.9, |
|
9169 which discusses the Call-Info header field since the risks are |
|
9170 identical. |
|
9171 |
|
9172 In addition, a user SHOULD be able to disable this feature |
|
9173 selectively. |
|
9174 |
|
9175 This helps prevent disruptions that could result from the use of |
|
9176 this header field by untrusted elements. |
|
9177 |
|
9178 Example: |
|
9179 |
|
9180 Alert-Info: <http://www.example.com/sounds/moo.wav> |
|
9181 |
|
9182 |
|
9183 |
|
9184 |
|
9185 |
|
9186 Rosenberg, et. al. Standards Track [Page 164] |
|
9187 |
|
9188 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9189 |
|
9190 |
|
9191 20.5 Allow |
|
9192 |
|
9193 The Allow header field lists the set of methods supported by the UA |
|
9194 generating the message. |
|
9195 |
|
9196 All methods, including ACK and CANCEL, understood by the UA MUST be |
|
9197 included in the list of methods in the Allow header field, when |
|
9198 present. The absence of an Allow header field MUST NOT be |
|
9199 interpreted to mean that the UA sending the message supports no |
|
9200 methods. Rather, it implies that the UA is not providing any |
|
9201 information on what methods it supports. |
|
9202 |
|
9203 Supplying an Allow header field in responses to methods other than |
|
9204 OPTIONS reduces the number of messages needed. |
|
9205 |
|
9206 Example: |
|
9207 |
|
9208 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE |
|
9209 |
|
9210 20.6 Authentication-Info |
|
9211 |
|
9212 The Authentication-Info header field provides for mutual |
|
9213 authentication with HTTP Digest. A UAS MAY include this header field |
|
9214 in a 2xx response to a request that was successfully authenticated |
|
9215 using digest based on the Authorization header field. |
|
9216 |
|
9217 Syntax and semantics follow those specified in RFC 2617 [17]. |
|
9218 |
|
9219 Example: |
|
9220 |
|
9221 Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c" |
|
9222 |
|
9223 20.7 Authorization |
|
9224 |
|
9225 The Authorization header field contains authentication credentials of |
|
9226 a UA. Section 22.2 overviews the use of the Authorization header |
|
9227 field, and Section 22.4 describes the syntax and semantics when used |
|
9228 with HTTP authentication. |
|
9229 |
|
9230 This header field, along with Proxy-Authorization, breaks the general |
|
9231 rules about multiple header field values. Although not a comma- |
|
9232 separated list, this header field name may be present multiple times, |
|
9233 and MUST NOT be combined into a single header line using the usual |
|
9234 rules described in Section 7.3. |
|
9235 |
|
9236 |
|
9237 |
|
9238 |
|
9239 |
|
9240 |
|
9241 |
|
9242 Rosenberg, et. al. Standards Track [Page 165] |
|
9243 |
|
9244 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9245 |
|
9246 |
|
9247 In the example below, there are no quotes around the Digest |
|
9248 parameter: |
|
9249 |
|
9250 Authorization: Digest username="Alice", realm="atlanta.com", |
|
9251 nonce="84a4cc6f3082121f32b42a2187831a9e", |
|
9252 response="7587245234b3434cc3412213e5f113a5432" |
|
9253 |
|
9254 20.8 Call-ID |
|
9255 |
|
9256 The Call-ID header field uniquely identifies a particular invitation |
|
9257 or all registrations of a particular client. A single multimedia |
|
9258 conference can give rise to several calls with different Call-IDs, |
|
9259 for example, if a user invites a single individual several times to |
|
9260 the same (long-running) conference. Call-IDs are case-sensitive and |
|
9261 are simply compared byte-by-byte. |
|
9262 |
|
9263 The compact form of the Call-ID header field is i. |
|
9264 |
|
9265 Examples: |
|
9266 |
|
9267 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com |
|
9268 i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 |
|
9269 |
|
9270 20.9 Call-Info |
|
9271 |
|
9272 The Call-Info header field provides additional information about the |
|
9273 caller or callee, depending on whether it is found in a request or |
|
9274 response. The purpose of the URI is described by the "purpose" |
|
9275 parameter. The "icon" parameter designates an image suitable as an |
|
9276 iconic representation of the caller or callee. The "info" parameter |
|
9277 describes the caller or callee in general, for example, through a web |
|
9278 page. The "card" parameter provides a business card, for example, in |
|
9279 vCard [36] or LDIF [37] formats. Additional tokens can be registered |
|
9280 using IANA and the procedures in Section 27. |
|
9281 |
|
9282 Use of the Call-Info header field can pose a security risk. If a |
|
9283 callee fetches the URIs provided by a malicious caller, the callee |
|
9284 may be at risk for displaying inappropriate or offensive content, |
|
9285 dangerous or illegal content, and so on. Therefore, it is |
|
9286 RECOMMENDED that a UA only render the information in the Call-Info |
|
9287 header field if it can verify the authenticity of the element that |
|
9288 originated the header field and trusts that element. This need not |
|
9289 be the peer UA; a proxy can insert this header field into requests. |
|
9290 |
|
9291 Example: |
|
9292 |
|
9293 Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, |
|
9294 <http://www.example.com/alice/> ;purpose=info |
|
9295 |
|
9296 |
|
9297 |
|
9298 Rosenberg, et. al. Standards Track [Page 166] |
|
9299 |
|
9300 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9301 |
|
9302 |
|
9303 20.10 Contact |
|
9304 |
|
9305 A Contact header field value provides a URI whose meaning depends on |
|
9306 the type of request or response it is in. |
|
9307 |
|
9308 A Contact header field value can contain a display name, a URI with |
|
9309 URI parameters, and header parameters. |
|
9310 |
|
9311 This document defines the Contact parameters "q" and "expires". |
|
9312 These parameters are only used when the Contact is present in a |
|
9313 REGISTER request or response, or in a 3xx response. Additional |
|
9314 parameters may be defined in other specifications. |
|
9315 |
|
9316 When the header field value contains a display name, the URI |
|
9317 including all URI parameters is enclosed in "<" and ">". If no "<" |
|
9318 and ">" are present, all parameters after the URI are header |
|
9319 parameters, not URI parameters. The display name can be tokens, or a |
|
9320 quoted string, if a larger character set is desired. |
|
9321 |
|
9322 Even if the "display-name" is empty, the "name-addr" form MUST be |
|
9323 used if the "addr-spec" contains a comma, semicolon, or question |
|
9324 mark. There may or may not be LWS between the display-name and the |
|
9325 "<". |
|
9326 |
|
9327 These rules for parsing a display name, URI and URI parameters, and |
|
9328 header parameters also apply for the header fields To and From. |
|
9329 |
|
9330 The Contact header field has a role similar to the Location header |
|
9331 field in HTTP. However, the HTTP header field only allows one |
|
9332 address, unquoted. Since URIs can contain commas and semicolons |
|
9333 as reserved characters, they can be mistaken for header or |
|
9334 parameter delimiters, respectively. |
|
9335 |
|
9336 The compact form of the Contact header field is m (for "moved"). |
|
9337 |
|
9338 Examples: |
|
9339 |
|
9340 Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com> |
|
9341 ;q=0.7; expires=3600, |
|
9342 "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1 |
|
9343 m: <sips:bob@192.0.2.4>;expires=60 |
|
9344 |
|
9345 |
|
9346 |
|
9347 |
|
9348 |
|
9349 |
|
9350 |
|
9351 |
|
9352 |
|
9353 |
|
9354 Rosenberg, et. al. Standards Track [Page 167] |
|
9355 |
|
9356 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9357 |
|
9358 |
|
9359 20.11 Content-Disposition |
|
9360 |
|
9361 The Content-Disposition header field describes how the message body |
|
9362 or, for multipart messages, a message body part is to be interpreted |
|
9363 by the UAC or UAS. This SIP header field extends the MIME Content- |
|
9364 Type (RFC 2183 [18]). |
|
9365 |
|
9366 Several new "disposition-types" of the Content-Disposition header are |
|
9367 defined by SIP. The value "session" indicates that the body part |
|
9368 describes a session, for either calls or early (pre-call) media. The |
|
9369 value "render" indicates that the body part should be displayed or |
|
9370 otherwise rendered to the user. Note that the value "render" is used |
|
9371 rather than "inline" to avoid the connotation that the MIME body is |
|
9372 displayed as a part of the rendering of the entire message (since the |
|
9373 MIME bodies of SIP messages oftentimes are not displayed to users). |
|
9374 For backward-compatibility, if the Content-Disposition header field |
|
9375 is missing, the server SHOULD assume bodies of Content-Type |
|
9376 application/sdp are the disposition "session", while other content |
|
9377 types are "render". |
|
9378 |
|
9379 The disposition type "icon" indicates that the body part contains an |
|
9380 image suitable as an iconic representation of the caller or callee |
|
9381 that could be rendered informationally by a user agent when a message |
|
9382 has been received, or persistently while a dialog takes place. The |
|
9383 value "alert" indicates that the body part contains information, such |
|
9384 as an audio clip, that should be rendered by the user agent in an |
|
9385 attempt to alert the user to the receipt of a request, generally a |
|
9386 request that initiates a dialog; this alerting body could for example |
|
9387 be rendered as a ring tone for a phone call after a 180 Ringing |
|
9388 provisional response has been sent. |
|
9389 |
|
9390 Any MIME body with a "disposition-type" that renders content to the |
|
9391 user should only be processed when a message has been properly |
|
9392 authenticated. |
|
9393 |
|
9394 The handling parameter, handling-param, describes how the UAS should |
|
9395 react if it receives a message body whose content type or disposition |
|
9396 type it does not understand. The parameter has defined values of |
|
9397 "optional" and "required". If the handling parameter is missing, the |
|
9398 value "required" SHOULD be assumed. The handling parameter is |
|
9399 described in RFC 3204 [19]. |
|
9400 |
|
9401 If this header field is missing, the MIME type determines the default |
|
9402 content disposition. If there is none, "render" is assumed. |
|
9403 |
|
9404 Example: |
|
9405 |
|
9406 Content-Disposition: session |
|
9407 |
|
9408 |
|
9409 |
|
9410 Rosenberg, et. al. Standards Track [Page 168] |
|
9411 |
|
9412 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9413 |
|
9414 |
|
9415 20.12 Content-Encoding |
|
9416 |
|
9417 The Content-Encoding header field is used as a modifier to the |
|
9418 "media-type". When present, its value indicates what additional |
|
9419 content codings have been applied to the entity-body, and thus what |
|
9420 decoding mechanisms MUST be applied in order to obtain the media-type |
|
9421 referenced by the Content-Type header field. Content-Encoding is |
|
9422 primarily used to allow a body to be compressed without losing the |
|
9423 identity of its underlying media type. |
|
9424 |
|
9425 If multiple encodings have been applied to an entity-body, the |
|
9426 content codings MUST be listed in the order in which they were |
|
9427 applied. |
|
9428 |
|
9429 All content-coding values are case-insensitive. IANA acts as a |
|
9430 registry for content-coding value tokens. See [H3.5] for a |
|
9431 definition of the syntax for content-coding. |
|
9432 |
|
9433 Clients MAY apply content encodings to the body in requests. A |
|
9434 server MAY apply content encodings to the bodies in responses. The |
|
9435 server MUST only use encodings listed in the Accept-Encoding header |
|
9436 field in the request. |
|
9437 |
|
9438 The compact form of the Content-Encoding header field is e. |
|
9439 Examples: |
|
9440 |
|
9441 Content-Encoding: gzip |
|
9442 e: tar |
|
9443 |
|
9444 20.13 Content-Language |
|
9445 |
|
9446 See [H14.12]. Example: |
|
9447 |
|
9448 Content-Language: fr |
|
9449 |
|
9450 20.14 Content-Length |
|
9451 |
|
9452 The Content-Length header field indicates the size of the message- |
|
9453 body, in decimal number of octets, sent to the recipient. |
|
9454 Applications SHOULD use this field to indicate the size of the |
|
9455 message-body to be transferred, regardless of the media type of the |
|
9456 entity. If a stream-based protocol (such as TCP) is used as |
|
9457 transport, the header field MUST be used. |
|
9458 |
|
9459 The size of the message-body does not include the CRLF separating |
|
9460 header fields and body. Any Content-Length greater than or equal to |
|
9461 zero is a valid value. If no body is present in a message, then the |
|
9462 Content-Length header field value MUST be set to zero. |
|
9463 |
|
9464 |
|
9465 |
|
9466 Rosenberg, et. al. Standards Track [Page 169] |
|
9467 |
|
9468 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9469 |
|
9470 |
|
9471 The ability to omit Content-Length simplifies the creation of |
|
9472 cgi-like scripts that dynamically generate responses. |
|
9473 |
|
9474 The compact form of the header field is l. |
|
9475 |
|
9476 Examples: |
|
9477 |
|
9478 Content-Length: 349 |
|
9479 l: 173 |
|
9480 |
|
9481 20.15 Content-Type |
|
9482 |
|
9483 The Content-Type header field indicates the media type of the |
|
9484 message-body sent to the recipient. The "media-type" element is |
|
9485 defined in [H3.7]. The Content-Type header field MUST be present if |
|
9486 the body is not empty. If the body is empty, and a Content-Type |
|
9487 header field is present, it indicates that the body of the specific |
|
9488 type has zero length (for example, an empty audio file). |
|
9489 |
|
9490 The compact form of the header field is c. |
|
9491 |
|
9492 Examples: |
|
9493 |
|
9494 Content-Type: application/sdp |
|
9495 c: text/html; charset=ISO-8859-4 |
|
9496 |
|
9497 20.16 CSeq |
|
9498 |
|
9499 A CSeq header field in a request contains a single decimal sequence |
|
9500 number and the request method. The sequence number MUST be |
|
9501 expressible as a 32-bit unsigned integer. The method part of CSeq is |
|
9502 case-sensitive. The CSeq header field serves to order transactions |
|
9503 within a dialog, to provide a means to uniquely identify |
|
9504 transactions, and to differentiate between new requests and request |
|
9505 retransmissions. Two CSeq header fields are considered equal if the |
|
9506 sequence number and the request method are identical. Example: |
|
9507 |
|
9508 CSeq: 4711 INVITE |
|
9509 |
|
9510 20.17 Date |
|
9511 |
|
9512 The Date header field contains the date and time. Unlike HTTP/1.1, |
|
9513 SIP only supports the most recent RFC 1123 [20] format for dates. As |
|
9514 in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while |
|
9515 RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive. |
|
9516 |
|
9517 The Date header field reflects the time when the request or response |
|
9518 is first sent. |
|
9519 |
|
9520 |
|
9521 |
|
9522 Rosenberg, et. al. Standards Track [Page 170] |
|
9523 |
|
9524 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9525 |
|
9526 |
|
9527 The Date header field can be used by simple end systems without a |
|
9528 battery-backed clock to acquire a notion of current time. |
|
9529 However, in its GMT form, it requires clients to know their offset |
|
9530 from GMT. |
|
9531 |
|
9532 Example: |
|
9533 |
|
9534 Date: Sat, 13 Nov 2010 23:29:00 GMT |
|
9535 |
|
9536 20.18 Error-Info |
|
9537 |
|
9538 The Error-Info header field provides a pointer to additional |
|
9539 information about the error status response. |
|
9540 |
|
9541 SIP UACs have user interface capabilities ranging from pop-up |
|
9542 windows and audio on PC softclients to audio-only on "black" |
|
9543 phones or endpoints connected via gateways. Rather than forcing a |
|
9544 server generating an error to choose between sending an error |
|
9545 status code with a detailed reason phrase and playing an audio |
|
9546 recording, the Error-Info header field allows both to be sent. |
|
9547 The UAC then has the choice of which error indicator to render to |
|
9548 the caller. |
|
9549 |
|
9550 A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if |
|
9551 it were a Contact in a redirect and generate a new INVITE, resulting |
|
9552 in a recorded announcement session being established. A non-SIP URI |
|
9553 MAY be rendered to the user. |
|
9554 |
|
9555 Examples: |
|
9556 |
|
9557 SIP/2.0 404 The number you have dialed is not in service |
|
9558 Error-Info: <sip:not-in-service-recording@atlanta.com> |
|
9559 |
|
9560 20.19 Expires |
|
9561 |
|
9562 The Expires header field gives the relative time after which the |
|
9563 message (or content) expires. |
|
9564 |
|
9565 The precise meaning of this is method dependent. |
|
9566 |
|
9567 The expiration time in an INVITE does not affect the duration of the |
|
9568 actual session that may result from the invitation. Session |
|
9569 description protocols may offer the ability to express time limits on |
|
9570 the session duration, however. |
|
9571 |
|
9572 The value of this field is an integral number of seconds (in decimal) |
|
9573 between 0 and (2**32)-1, measured from the receipt of the request. |
|
9574 |
|
9575 |
|
9576 |
|
9577 |
|
9578 Rosenberg, et. al. Standards Track [Page 171] |
|
9579 |
|
9580 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9581 |
|
9582 |
|
9583 Example: |
|
9584 |
|
9585 Expires: 5 |
|
9586 |
|
9587 20.20 From |
|
9588 |
|
9589 The From header field indicates the initiator of the request. This |
|
9590 may be different from the initiator of the dialog. Requests sent by |
|
9591 the callee to the caller use the callee's address in the From header |
|
9592 field. |
|
9593 |
|
9594 The optional "display-name" is meant to be rendered by a human user |
|
9595 interface. A system SHOULD use the display name "Anonymous" if the |
|
9596 identity of the client is to remain hidden. Even if the "display- |
|
9597 name" is empty, the "name-addr" form MUST be used if the "addr-spec" |
|
9598 contains a comma, question mark, or semicolon. Syntax issues are |
|
9599 discussed in Section 7.3.1. |
|
9600 |
|
9601 Two From header fields are equivalent if their URIs match, and their |
|
9602 parameters match. Extension parameters in one header field, not |
|
9603 present in the other are ignored for the purposes of comparison. This |
|
9604 means that the display name and presence or absence of angle brackets |
|
9605 do not affect matching. |
|
9606 |
|
9607 See Section 20.10 for the rules for parsing a display name, URI and |
|
9608 URI parameters, and header field parameters. |
|
9609 |
|
9610 The compact form of the From header field is f. |
|
9611 |
|
9612 Examples: |
|
9613 |
|
9614 From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s |
|
9615 From: sip:+12125551212@server.phone2net.com;tag=887s |
|
9616 f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 |
|
9617 |
|
9618 20.21 In-Reply-To |
|
9619 |
|
9620 The In-Reply-To header field enumerates the Call-IDs that this call |
|
9621 references or returns. These Call-IDs may have been cached by the |
|
9622 client then included in this header field in a return call. |
|
9623 |
|
9624 This allows automatic call distribution systems to route return |
|
9625 calls to the originator of the first call. This also allows |
|
9626 callees to filter calls, so that only return calls for calls they |
|
9627 originated will be accepted. This field is not a substitute for |
|
9628 request authentication. |
|
9629 |
|
9630 |
|
9631 |
|
9632 |
|
9633 |
|
9634 Rosenberg, et. al. Standards Track [Page 172] |
|
9635 |
|
9636 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9637 |
|
9638 |
|
9639 Example: |
|
9640 |
|
9641 In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com |
|
9642 |
|
9643 20.22 Max-Forwards |
|
9644 |
|
9645 The Max-Forwards header field must be used with any SIP method to |
|
9646 limit the number of proxies or gateways that can forward the request |
|
9647 to the next downstream server. This can also be useful when the |
|
9648 client is attempting to trace a request chain that appears to be |
|
9649 failing or looping in mid-chain. |
|
9650 |
|
9651 The Max-Forwards value is an integer in the range 0-255 indicating |
|
9652 the remaining number of times this request message is allowed to be |
|
9653 forwarded. This count is decremented by each server that forwards |
|
9654 the request. The recommended initial value is 70. |
|
9655 |
|
9656 This header field should be inserted by elements that can not |
|
9657 otherwise guarantee loop detection. For example, a B2BUA should |
|
9658 insert a Max-Forwards header field. |
|
9659 |
|
9660 Example: |
|
9661 |
|
9662 Max-Forwards: 6 |
|
9663 |
|
9664 20.23 Min-Expires |
|
9665 |
|
9666 The Min-Expires header field conveys the minimum refresh interval |
|
9667 supported for soft-state elements managed by that server. This |
|
9668 includes Contact header fields that are stored by a registrar. The |
|
9669 header field contains a decimal integer number of seconds from 0 to |
|
9670 (2**32)-1. The use of the header field in a 423 (Interval Too Brief) |
|
9671 response is described in Sections 10.2.8, 10.3, and 21.4.17. |
|
9672 |
|
9673 Example: |
|
9674 |
|
9675 Min-Expires: 60 |
|
9676 |
|
9677 20.24 MIME-Version |
|
9678 |
|
9679 See [H19.4.1]. |
|
9680 |
|
9681 Example: |
|
9682 |
|
9683 MIME-Version: 1.0 |
|
9684 |
|
9685 |
|
9686 |
|
9687 |
|
9688 |
|
9689 |
|
9690 Rosenberg, et. al. Standards Track [Page 173] |
|
9691 |
|
9692 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9693 |
|
9694 |
|
9695 20.25 Organization |
|
9696 |
|
9697 The Organization header field conveys the name of the organization to |
|
9698 which the SIP element issuing the request or response belongs. |
|
9699 |
|
9700 The field MAY be used by client software to filter calls. |
|
9701 |
|
9702 Example: |
|
9703 |
|
9704 Organization: Boxes by Bob |
|
9705 |
|
9706 20.26 Priority |
|
9707 |
|
9708 The Priority header field indicates the urgency of the request as |
|
9709 perceived by the client. The Priority header field describes the |
|
9710 priority that the SIP request should have to the receiving human or |
|
9711 its agent. For example, it may be factored into decisions about call |
|
9712 routing and acceptance. For these decisions, a message containing no |
|
9713 Priority header field SHOULD be treated as if it specified a Priority |
|
9714 of "normal". The Priority header field does not influence the use of |
|
9715 communications resources such as packet forwarding priority in |
|
9716 routers or access to circuits in PSTN gateways. The header field can |
|
9717 have the values "non-urgent", "normal", "urgent", and "emergency", |
|
9718 but additional values can be defined elsewhere. It is RECOMMENDED |
|
9719 that the value of "emergency" only be used when life, limb, or |
|
9720 property are in imminent danger. Otherwise, there are no semantics |
|
9721 defined for this header field. |
|
9722 |
|
9723 These are the values of RFC 2076 [38], with the addition of |
|
9724 "emergency". |
|
9725 |
|
9726 Examples: |
|
9727 |
|
9728 Subject: A tornado is heading our way! |
|
9729 Priority: emergency |
|
9730 |
|
9731 or |
|
9732 |
|
9733 Subject: Weekend plans |
|
9734 Priority: non-urgent |
|
9735 |
|
9736 20.27 Proxy-Authenticate |
|
9737 |
|
9738 A Proxy-Authenticate header field value contains an authentication |
|
9739 challenge. |
|
9740 |
|
9741 The use of this header field is defined in [H14.33]. See Section |
|
9742 22.3 for further details on its usage. |
|
9743 |
|
9744 |
|
9745 |
|
9746 Rosenberg, et. al. Standards Track [Page 174] |
|
9747 |
|
9748 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9749 |
|
9750 |
|
9751 Example: |
|
9752 |
|
9753 Proxy-Authenticate: Digest realm="atlanta.com", |
|
9754 domain="sip:ss1.carrier.com", qop="auth", |
|
9755 nonce="f84f1cec41e6cbe5aea9c8e88d359", |
|
9756 opaque="", stale=FALSE, algorithm=MD5 |
|
9757 |
|
9758 20.28 Proxy-Authorization |
|
9759 |
|
9760 The Proxy-Authorization header field allows the client to identify |
|
9761 itself (or its user) to a proxy that requires authentication. A |
|
9762 Proxy-Authorization field value consists of credentials containing |
|
9763 the authentication information of the user agent for the proxy and/or |
|
9764 realm of the resource being requested. |
|
9765 |
|
9766 See Section 22.3 for a definition of the usage of this header field. |
|
9767 |
|
9768 This header field, along with Authorization, breaks the general rules |
|
9769 about multiple header field names. Although not a comma-separated |
|
9770 list, this header field name may be present multiple times, and MUST |
|
9771 NOT be combined into a single header line using the usual rules |
|
9772 described in Section 7.3.1. |
|
9773 |
|
9774 Example: |
|
9775 |
|
9776 Proxy-Authorization: Digest username="Alice", realm="atlanta.com", |
|
9777 nonce="c60f3082ee1212b402a21831ae", |
|
9778 response="245f23415f11432b3434341c022" |
|
9779 |
|
9780 20.29 Proxy-Require |
|
9781 |
|
9782 The Proxy-Require header field is used to indicate proxy-sensitive |
|
9783 features that must be supported by the proxy. See Section 20.32 for |
|
9784 more details on the mechanics of this message and a usage example. |
|
9785 |
|
9786 Example: |
|
9787 |
|
9788 Proxy-Require: foo |
|
9789 |
|
9790 20.30 Record-Route |
|
9791 |
|
9792 The Record-Route header field is inserted by proxies in a request to |
|
9793 force future requests in the dialog to be routed through the proxy. |
|
9794 |
|
9795 Examples of its use with the Route header field are described in |
|
9796 Sections 16.12.1. |
|
9797 |
|
9798 |
|
9799 |
|
9800 |
|
9801 |
|
9802 Rosenberg, et. al. Standards Track [Page 175] |
|
9803 |
|
9804 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9805 |
|
9806 |
|
9807 Example: |
|
9808 |
|
9809 Record-Route: <sip:server10.biloxi.com;lr>, |
|
9810 <sip:bigbox3.site3.atlanta.com;lr> |
|
9811 |
|
9812 20.31 Reply-To |
|
9813 |
|
9814 The Reply-To header field contains a logical return URI that may be |
|
9815 different from the From header field. For example, the URI MAY be |
|
9816 used to return missed calls or unestablished sessions. If the user |
|
9817 wished to remain anonymous, the header field SHOULD either be omitted |
|
9818 from the request or populated in such a way that does not reveal any |
|
9819 private information. |
|
9820 |
|
9821 Even if the "display-name" is empty, the "name-addr" form MUST be |
|
9822 used if the "addr-spec" contains a comma, question mark, or |
|
9823 semicolon. Syntax issues are discussed in Section 7.3.1. |
|
9824 |
|
9825 Example: |
|
9826 |
|
9827 Reply-To: Bob <sip:bob@biloxi.com> |
|
9828 |
|
9829 20.32 Require |
|
9830 |
|
9831 The Require header field is used by UACs to tell UASs about options |
|
9832 that the UAC expects the UAS to support in order to process the |
|
9833 request. Although an optional header field, the Require MUST NOT be |
|
9834 ignored if it is present. |
|
9835 |
|
9836 The Require header field contains a list of option tags, described in |
|
9837 Section 19.2. Each option tag defines a SIP extension that MUST be |
|
9838 understood to process the request. Frequently, this is used to |
|
9839 indicate that a specific set of extension header fields need to be |
|
9840 understood. A UAC compliant to this specification MUST only include |
|
9841 option tags corresponding to standards-track RFCs. |
|
9842 |
|
9843 Example: |
|
9844 |
|
9845 Require: 100rel |
|
9846 |
|
9847 20.33 Retry-After |
|
9848 |
|
9849 The Retry-After header field can be used with a 500 (Server Internal |
|
9850 Error) or 503 (Service Unavailable) response to indicate how long the |
|
9851 service is expected to be unavailable to the requesting client and |
|
9852 with a 404 (Not Found), 413 (Request Entity Too Large), 480 |
|
9853 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 |
|
9854 |
|
9855 |
|
9856 |
|
9857 |
|
9858 Rosenberg, et. al. Standards Track [Page 176] |
|
9859 |
|
9860 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9861 |
|
9862 |
|
9863 (Decline) response to indicate when the called party anticipates |
|
9864 being available again. The value of this field is a positive integer |
|
9865 number of seconds (in decimal) after the time of the response. |
|
9866 |
|
9867 An optional comment can be used to indicate additional information |
|
9868 about the time of callback. An optional "duration" parameter |
|
9869 indicates how long the called party will be reachable starting at the |
|
9870 initial time of availability. If no duration parameter is given, the |
|
9871 service is assumed to be available indefinitely. |
|
9872 |
|
9873 Examples: |
|
9874 |
|
9875 Retry-After: 18000;duration=3600 |
|
9876 Retry-After: 120 (I'm in a meeting) |
|
9877 |
|
9878 20.34 Route |
|
9879 |
|
9880 The Route header field is used to force routing for a request through |
|
9881 the listed set of proxies. Examples of the use of the Route header |
|
9882 field are in Section 16.12.1. |
|
9883 |
|
9884 Example: |
|
9885 |
|
9886 Route: <sip:bigbox3.site3.atlanta.com;lr>, |
|
9887 <sip:server10.biloxi.com;lr> |
|
9888 |
|
9889 20.35 Server |
|
9890 |
|
9891 The Server header field contains information about the software used |
|
9892 by the UAS to handle the request. |
|
9893 |
|
9894 Revealing the specific software version of the server might allow the |
|
9895 server to become more vulnerable to attacks against software that is |
|
9896 known to contain security holes. Implementers SHOULD make the Server |
|
9897 header field a configurable option. |
|
9898 |
|
9899 Example: |
|
9900 |
|
9901 Server: HomeServer v2 |
|
9902 |
|
9903 20.36 Subject |
|
9904 |
|
9905 The Subject header field provides a summary or indicates the nature |
|
9906 of the call, allowing call filtering without having to parse the |
|
9907 session description. The session description does not have to use |
|
9908 the same subject indication as the invitation. |
|
9909 |
|
9910 The compact form of the Subject header field is s. |
|
9911 |
|
9912 |
|
9913 |
|
9914 Rosenberg, et. al. Standards Track [Page 177] |
|
9915 |
|
9916 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9917 |
|
9918 |
|
9919 Example: |
|
9920 |
|
9921 Subject: Need more boxes |
|
9922 s: Tech Support |
|
9923 |
|
9924 20.37 Supported |
|
9925 |
|
9926 The Supported header field enumerates all the extensions supported by |
|
9927 the UAC or UAS. |
|
9928 |
|
9929 The Supported header field contains a list of option tags, described |
|
9930 in Section 19.2, that are understood by the UAC or UAS. A UA |
|
9931 compliant to this specification MUST only include option tags |
|
9932 corresponding to standards-track RFCs. If empty, it means that no |
|
9933 extensions are supported. |
|
9934 |
|
9935 The compact form of the Supported header field is k. |
|
9936 |
|
9937 Example: |
|
9938 |
|
9939 Supported: 100rel |
|
9940 |
|
9941 20.38 Timestamp |
|
9942 |
|
9943 The Timestamp header field describes when the UAC sent the request to |
|
9944 the UAS. |
|
9945 |
|
9946 See Section 8.2.6 for details on how to generate a response to a |
|
9947 request that contains the header field. Although there is no |
|
9948 normative behavior defined here that makes use of the header, it |
|
9949 allows for extensions or SIP applications to obtain RTT estimates. |
|
9950 |
|
9951 Example: |
|
9952 |
|
9953 Timestamp: 54 |
|
9954 |
|
9955 20.39 To |
|
9956 |
|
9957 The To header field specifies the logical recipient of the request. |
|
9958 |
|
9959 The optional "display-name" is meant to be rendered by a human-user |
|
9960 interface. The "tag" parameter serves as a general mechanism for |
|
9961 dialog identification. |
|
9962 |
|
9963 See Section 19.3 for details of the "tag" parameter. |
|
9964 |
|
9965 |
|
9966 |
|
9967 |
|
9968 |
|
9969 |
|
9970 Rosenberg, et. al. Standards Track [Page 178] |
|
9971 |
|
9972 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
9973 |
|
9974 |
|
9975 Comparison of To header fields for equality is identical to |
|
9976 comparison of From header fields. See Section 20.10 for the rules |
|
9977 for parsing a display name, URI and URI parameters, and header field |
|
9978 parameters. |
|
9979 |
|
9980 The compact form of the To header field is t. |
|
9981 |
|
9982 The following are examples of valid To header fields: |
|
9983 |
|
9984 To: The Operator <sip:operator@cs.columbia.edu>;tag=287447 |
|
9985 t: sip:+12125551212@server.phone2net.com |
|
9986 |
|
9987 20.40 Unsupported |
|
9988 |
|
9989 The Unsupported header field lists the features not supported by the |
|
9990 UAS. See Section 20.32 for motivation. |
|
9991 |
|
9992 Example: |
|
9993 |
|
9994 Unsupported: foo |
|
9995 |
|
9996 20.41 User-Agent |
|
9997 |
|
9998 The User-Agent header field contains information about the UAC |
|
9999 originating the request. The semantics of this header field are |
|
10000 defined in [H14.43]. |
|
10001 |
|
10002 Revealing the specific software version of the user agent might allow |
|
10003 the user agent to become more vulnerable to attacks against software |
|
10004 that is known to contain security holes. Implementers SHOULD make |
|
10005 the User-Agent header field a configurable option. |
|
10006 |
|
10007 Example: |
|
10008 |
|
10009 User-Agent: Softphone Beta1.5 |
|
10010 |
|
10011 20.42 Via |
|
10012 |
|
10013 The Via header field indicates the path taken by the request so far |
|
10014 and indicates the path that should be followed in routing responses. |
|
10015 The branch ID parameter in the Via header field values serves as a |
|
10016 transaction identifier, and is used by proxies to detect loops. |
|
10017 |
|
10018 A Via header field value contains the transport protocol used to send |
|
10019 the message, the client's host name or network address, and possibly |
|
10020 the port number at which it wishes to receive responses. A Via |
|
10021 header field value can also contain parameters such as "maddr", |
|
10022 "ttl", "received", and "branch", whose meaning and use are described |
|
10023 |
|
10024 |
|
10025 |
|
10026 Rosenberg, et. al. Standards Track [Page 179] |
|
10027 |
|
10028 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10029 |
|
10030 |
|
10031 in other sections. For implementations compliant to this |
|
10032 specification, the value of the branch parameter MUST start with the |
|
10033 magic cookie "z9hG4bK", as discussed in Section 8.1.1.7. |
|
10034 |
|
10035 Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". |
|
10036 "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the |
|
10037 protocol still indicates "SIP", and the transport protocol is TLS. |
|
10038 |
|
10039 Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 |
|
10040 Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 |
|
10041 ;branch=z9hG4bK77asjd |
|
10042 |
|
10043 The compact form of the Via header field is v. |
|
10044 |
|
10045 In this example, the message originated from a multi-homed host with |
|
10046 two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong |
|
10047 as to which network interface would be used. Erlang.bell- |
|
10048 telephone.com noticed the mismatch and added a parameter to the |
|
10049 previous hop's Via header field value, containing the address that |
|
10050 the packet actually came from. |
|
10051 |
|
10052 The host or network address and port number are not required to |
|
10053 follow the SIP URI syntax. Specifically, LWS on either side of the |
|
10054 ":" or "/" is allowed, as shown here: |
|
10055 |
|
10056 Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 |
|
10057 ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 |
|
10058 |
|
10059 Even though this specification mandates that the branch parameter be |
|
10060 present in all requests, the BNF for the header field indicates that |
|
10061 it is optional. This allows interoperation with RFC 2543 elements, |
|
10062 which did not have to insert the branch parameter. |
|
10063 |
|
10064 Two Via header fields are equal if their sent-protocol and sent-by |
|
10065 fields are equal, both have the same set of parameters, and the |
|
10066 values of all parameters are equal. |
|
10067 |
|
10068 20.43 Warning |
|
10069 |
|
10070 The Warning header field is used to carry additional information |
|
10071 about the status of a response. Warning header field values are sent |
|
10072 with responses and contain a three-digit warning code, host name, and |
|
10073 warning text. |
|
10074 |
|
10075 The "warn-text" should be in a natural language that is most likely |
|
10076 to be intelligible to the human user receiving the response. This |
|
10077 decision can be based on any available knowledge, such as the |
|
10078 location of the user, the Accept-Language field in a request, or the |
|
10079 |
|
10080 |
|
10081 |
|
10082 Rosenberg, et. al. Standards Track [Page 180] |
|
10083 |
|
10084 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10085 |
|
10086 |
|
10087 Content-Language field in a response. The default language is i- |
|
10088 default [21]. |
|
10089 |
|
10090 The currently-defined "warn-code"s are listed below, with a |
|
10091 recommended warn-text in English and a description of their meaning. |
|
10092 These warnings describe failures induced by the session description. |
|
10093 The first digit of warning codes beginning with "3" indicates |
|
10094 warnings specific to SIP. Warnings 300 through 329 are reserved for |
|
10095 indicating problems with keywords in the session description, 330 |
|
10096 through 339 are warnings related to basic network services requested |
|
10097 in the session description, 370 through 379 are warnings related to |
|
10098 quantitative QoS parameters requested in the session description, and |
|
10099 390 through 399 are miscellaneous warnings that do not fall into one |
|
10100 of the above categories. |
|
10101 |
|
10102 300 Incompatible network protocol: One or more network protocols |
|
10103 contained in the session description are not available. |
|
10104 |
|
10105 301 Incompatible network address formats: One or more network |
|
10106 address formats contained in the session description are not |
|
10107 available. |
|
10108 |
|
10109 302 Incompatible transport protocol: One or more transport |
|
10110 protocols described in the session description are not |
|
10111 available. |
|
10112 |
|
10113 303 Incompatible bandwidth units: One or more bandwidth |
|
10114 measurement units contained in the session description were |
|
10115 not understood. |
|
10116 |
|
10117 304 Media type not available: One or more media types contained in |
|
10118 the session description are not available. |
|
10119 |
|
10120 305 Incompatible media format: One or more media formats contained |
|
10121 in the session description are not available. |
|
10122 |
|
10123 306 Attribute not understood: One or more of the media attributes |
|
10124 in the session description are not supported. |
|
10125 |
|
10126 307 Session description parameter not understood: A parameter |
|
10127 other than those listed above was not understood. |
|
10128 |
|
10129 330 Multicast not available: The site where the user is located |
|
10130 does not support multicast. |
|
10131 |
|
10132 331 Unicast not available: The site where the user is located does |
|
10133 not support unicast communication (usually due to the presence |
|
10134 of a firewall). |
|
10135 |
|
10136 |
|
10137 |
|
10138 Rosenberg, et. al. Standards Track [Page 181] |
|
10139 |
|
10140 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10141 |
|
10142 |
|
10143 370 Insufficient bandwidth: The bandwidth specified in the session |
|
10144 description or defined by the media exceeds that known to be |
|
10145 available. |
|
10146 |
|
10147 399 Miscellaneous warning: The warning text can include arbitrary |
|
10148 information to be presented to a human user or logged. A |
|
10149 system receiving this warning MUST NOT take any automated |
|
10150 action. |
|
10151 |
|
10152 1xx and 2xx have been taken by HTTP/1.1. |
|
10153 |
|
10154 Additional "warn-code"s can be defined through IANA, as defined in |
|
10155 Section 27.2. |
|
10156 |
|
10157 Examples: |
|
10158 |
|
10159 Warning: 307 isi.edu "Session parameter 'foo' not understood" |
|
10160 Warning: 301 isi.edu "Incompatible network address type 'E.164'" |
|
10161 |
|
10162 20.44 WWW-Authenticate |
|
10163 |
|
10164 A WWW-Authenticate header field value contains an authentication |
|
10165 challenge. See Section 22.2 for further details on its usage. |
|
10166 |
|
10167 Example: |
|
10168 |
|
10169 WWW-Authenticate: Digest realm="atlanta.com", |
|
10170 domain="sip:boxesbybob.com", qop="auth", |
|
10171 nonce="f84f1cec41e6cbe5aea9c8e88d359", |
|
10172 opaque="", stale=FALSE, algorithm=MD5 |
|
10173 |
|
10174 21 Response Codes |
|
10175 |
|
10176 The response codes are consistent with, and extend, HTTP/1.1 response |
|
10177 codes. Not all HTTP/1.1 response codes are appropriate, and only |
|
10178 those that are appropriate are given here. Other HTTP/1.1 response |
|
10179 codes SHOULD NOT be used. Also, SIP defines a new class, 6xx. |
|
10180 |
|
10181 21.1 Provisional 1xx |
|
10182 |
|
10183 Provisional responses, also known as informational responses, |
|
10184 indicate that the server contacted is performing some further action |
|
10185 and does not yet have a definitive response. A server sends a 1xx |
|
10186 response if it expects to take more than 200 ms to obtain a final |
|
10187 response. Note that 1xx responses are not transmitted reliably. |
|
10188 They never cause the client to send an ACK. Provisional (1xx) |
|
10189 responses MAY contain message bodies, including session descriptions. |
|
10190 |
|
10191 |
|
10192 |
|
10193 |
|
10194 Rosenberg, et. al. Standards Track [Page 182] |
|
10195 |
|
10196 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10197 |
|
10198 |
|
10199 21.1.1 100 Trying |
|
10200 |
|
10201 This response indicates that the request has been received by the |
|
10202 next-hop server and that some unspecified action is being taken on |
|
10203 behalf of this call (for example, a database is being consulted). |
|
10204 This response, like all other provisional responses, stops |
|
10205 retransmissions of an INVITE by a UAC. The 100 (Trying) response is |
|
10206 different from other provisional responses, in that it is never |
|
10207 forwarded upstream by a stateful proxy. |
|
10208 |
|
10209 21.1.2 180 Ringing |
|
10210 |
|
10211 The UA receiving the INVITE is trying to alert the user. This |
|
10212 response MAY be used to initiate local ringback. |
|
10213 |
|
10214 21.1.3 181 Call Is Being Forwarded |
|
10215 |
|
10216 A server MAY use this status code to indicate that the call is being |
|
10217 forwarded to a different set of destinations. |
|
10218 |
|
10219 21.1.4 182 Queued |
|
10220 |
|
10221 The called party is temporarily unavailable, but the server has |
|
10222 decided to queue the call rather than reject it. When the callee |
|
10223 becomes available, it will return the appropriate final status |
|
10224 response. The reason phrase MAY give further details about the |
|
10225 status of the call, for example, "5 calls queued; expected waiting |
|
10226 time is 15 minutes". The server MAY issue several 182 (Queued) |
|
10227 responses to update the caller about the status of the queued call. |
|
10228 |
|
10229 21.1.5 183 Session Progress |
|
10230 |
|
10231 The 183 (Session Progress) response is used to convey information |
|
10232 about the progress of the call that is not otherwise classified. The |
|
10233 Reason-Phrase, header fields, or message body MAY be used to convey |
|
10234 more details about the call progress. |
|
10235 |
|
10236 21.2 Successful 2xx |
|
10237 |
|
10238 The request was successful. |
|
10239 |
|
10240 21.2.1 200 OK |
|
10241 |
|
10242 The request has succeeded. The information returned with the |
|
10243 response depends on the method used in the request. |
|
10244 |
|
10245 |
|
10246 |
|
10247 |
|
10248 |
|
10249 |
|
10250 Rosenberg, et. al. Standards Track [Page 183] |
|
10251 |
|
10252 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10253 |
|
10254 |
|
10255 21.3 Redirection 3xx |
|
10256 |
|
10257 3xx responses give information about the user's new location, or |
|
10258 about alternative services that might be able to satisfy the call. |
|
10259 |
|
10260 21.3.1 300 Multiple Choices |
|
10261 |
|
10262 The address in the request resolved to several choices, each with its |
|
10263 own specific location, and the user (or UA) can select a preferred |
|
10264 communication end point and redirect its request to that location. |
|
10265 |
|
10266 The response MAY include a message body containing a list of resource |
|
10267 characteristics and location(s) from which the user or UA can choose |
|
10268 the one most appropriate, if allowed by the Accept request header |
|
10269 field. However, no MIME types have been defined for this message |
|
10270 body. |
|
10271 |
|
10272 The choices SHOULD also be listed as Contact fields (Section 20.10). |
|
10273 Unlike HTTP, the SIP response MAY contain several Contact fields or a |
|
10274 list of addresses in a Contact field. UAs MAY use the Contact header |
|
10275 field value for automatic redirection or MAY ask the user to confirm |
|
10276 a choice. However, this specification does not define any standard |
|
10277 for such automatic selection. |
|
10278 |
|
10279 This status response is appropriate if the callee can be reached |
|
10280 at several different locations and the server cannot or prefers |
|
10281 not to proxy the request. |
|
10282 |
|
10283 21.3.2 301 Moved Permanently |
|
10284 |
|
10285 The user can no longer be found at the address in the Request-URI, |
|
10286 and the requesting client SHOULD retry at the new address given by |
|
10287 the Contact header field (Section 20.10). The requestor SHOULD |
|
10288 update any local directories, address books, and user location caches |
|
10289 with this new value and redirect future requests to the address(es) |
|
10290 listed. |
|
10291 |
|
10292 21.3.3 302 Moved Temporarily |
|
10293 |
|
10294 The requesting client SHOULD retry the request at the new address(es) |
|
10295 given by the Contact header field (Section 20.10). The Request-URI |
|
10296 of the new request uses the value of the Contact header field in the |
|
10297 response. |
|
10298 |
|
10299 |
|
10300 |
|
10301 |
|
10302 |
|
10303 |
|
10304 |
|
10305 |
|
10306 Rosenberg, et. al. Standards Track [Page 184] |
|
10307 |
|
10308 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10309 |
|
10310 |
|
10311 The duration of the validity of the Contact URI can be indicated |
|
10312 through an Expires (Section 20.19) header field or an expires |
|
10313 parameter in the Contact header field. Both proxies and UAs MAY |
|
10314 cache this URI for the duration of the expiration time. If there is |
|
10315 no explicit expiration time, the address is only valid once for |
|
10316 recursing, and MUST NOT be cached for future transactions. |
|
10317 |
|
10318 If the URI cached from the Contact header field fails, the Request- |
|
10319 URI from the redirected request MAY be tried again a single time. |
|
10320 |
|
10321 The temporary URI may have become out-of-date sooner than the |
|
10322 expiration time, and a new temporary URI may be available. |
|
10323 |
|
10324 21.3.4 305 Use Proxy |
|
10325 |
|
10326 The requested resource MUST be accessed through the proxy given by |
|
10327 the Contact field. The Contact field gives the URI of the proxy. |
|
10328 The recipient is expected to repeat this single request via the |
|
10329 proxy. 305 (Use Proxy) responses MUST only be generated by UASs. |
|
10330 |
|
10331 21.3.5 380 Alternative Service |
|
10332 |
|
10333 The call was not successful, but alternative services are possible. |
|
10334 |
|
10335 The alternative services are described in the message body of the |
|
10336 response. Formats for such bodies are not defined here, and may be |
|
10337 the subject of future standardization. |
|
10338 |
|
10339 21.4 Request Failure 4xx |
|
10340 |
|
10341 4xx responses are definite failure responses from a particular |
|
10342 server. The client SHOULD NOT retry the same request without |
|
10343 modification (for example, adding appropriate authorization). |
|
10344 However, the same request to a different server might be successful. |
|
10345 |
|
10346 21.4.1 400 Bad Request |
|
10347 |
|
10348 The request could not be understood due to malformed syntax. The |
|
10349 Reason-Phrase SHOULD identify the syntax problem in more detail, for |
|
10350 example, "Missing Call-ID header field". |
|
10351 |
|
10352 21.4.2 401 Unauthorized |
|
10353 |
|
10354 The request requires user authentication. This response is issued by |
|
10355 UASs and registrars, while 407 (Proxy Authentication Required) is |
|
10356 used by proxy servers. |
|
10357 |
|
10358 |
|
10359 |
|
10360 |
|
10361 |
|
10362 Rosenberg, et. al. Standards Track [Page 185] |
|
10363 |
|
10364 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10365 |
|
10366 |
|
10367 21.4.3 402 Payment Required |
|
10368 |
|
10369 Reserved for future use. |
|
10370 |
|
10371 21.4.4 403 Forbidden |
|
10372 |
|
10373 The server understood the request, but is refusing to fulfill it. |
|
10374 Authorization will not help, and the request SHOULD NOT be repeated. |
|
10375 |
|
10376 21.4.5 404 Not Found |
|
10377 |
|
10378 The server has definitive information that the user does not exist at |
|
10379 the domain specified in the Request-URI. This status is also |
|
10380 returned if the domain in the Request-URI does not match any of the |
|
10381 domains handled by the recipient of the request. |
|
10382 |
|
10383 21.4.6 405 Method Not Allowed |
|
10384 |
|
10385 The method specified in the Request-Line is understood, but not |
|
10386 allowed for the address identified by the Request-URI. |
|
10387 |
|
10388 The response MUST include an Allow header field containing a list of |
|
10389 valid methods for the indicated address. |
|
10390 |
|
10391 21.4.7 406 Not Acceptable |
|
10392 |
|
10393 The resource identified by the request is only capable of generating |
|
10394 response entities that have content characteristics not acceptable |
|
10395 according to the Accept header field sent in the request. |
|
10396 |
|
10397 21.4.8 407 Proxy Authentication Required |
|
10398 |
|
10399 This code is similar to 401 (Unauthorized), but indicates that the |
|
10400 client MUST first authenticate itself with the proxy. SIP access |
|
10401 authentication is explained in Sections 26 and 22.3. |
|
10402 |
|
10403 This status code can be used for applications where access to the |
|
10404 communication channel (for example, a telephony gateway) rather than |
|
10405 the callee requires authentication. |
|
10406 |
|
10407 21.4.9 408 Request Timeout |
|
10408 |
|
10409 The server could not produce a response within a suitable amount of |
|
10410 time, for example, if it could not determine the location of the user |
|
10411 in time. The client MAY repeat the request without modifications at |
|
10412 any later time. |
|
10413 |
|
10414 |
|
10415 |
|
10416 |
|
10417 |
|
10418 Rosenberg, et. al. Standards Track [Page 186] |
|
10419 |
|
10420 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10421 |
|
10422 |
|
10423 21.4.10 410 Gone |
|
10424 |
|
10425 The requested resource is no longer available at the server and no |
|
10426 forwarding address is known. This condition is expected to be |
|
10427 considered permanent. If the server does not know, or has no |
|
10428 facility to determine, whether or not the condition is permanent, the |
|
10429 status code 404 (Not Found) SHOULD be used instead. |
|
10430 |
|
10431 21.4.11 413 Request Entity Too Large |
|
10432 |
|
10433 The server is refusing to process a request because the request |
|
10434 entity-body is larger than the server is willing or able to process. |
|
10435 The server MAY close the connection to prevent the client from |
|
10436 continuing the request. |
|
10437 |
|
10438 If the condition is temporary, the server SHOULD include a Retry- |
|
10439 After header field to indicate that it is temporary and after what |
|
10440 time the client MAY try again. |
|
10441 |
|
10442 21.4.12 414 Request-URI Too Long |
|
10443 |
|
10444 The server is refusing to service the request because the Request-URI |
|
10445 is longer than the server is willing to interpret. |
|
10446 |
|
10447 21.4.13 415 Unsupported Media Type |
|
10448 |
|
10449 The server is refusing to service the request because the message |
|
10450 body of the request is in a format not supported by the server for |
|
10451 the requested method. The server MUST return a list of acceptable |
|
10452 formats using the Accept, Accept-Encoding, or Accept-Language header |
|
10453 field, depending on the specific problem with the content. UAC |
|
10454 processing of this response is described in Section 8.1.3.5. |
|
10455 |
|
10456 21.4.14 416 Unsupported URI Scheme |
|
10457 |
|
10458 The server cannot process the request because the scheme of the URI |
|
10459 in the Request-URI is unknown to the server. Client processing of |
|
10460 this response is described in Section 8.1.3.5. |
|
10461 |
|
10462 21.4.15 420 Bad Extension |
|
10463 |
|
10464 The server did not understand the protocol extension specified in a |
|
10465 Proxy-Require (Section 20.29) or Require (Section 20.32) header |
|
10466 field. The server MUST include a list of the unsupported extensions |
|
10467 in an Unsupported header field in the response. UAC processing of |
|
10468 this response is described in Section 8.1.3.5. |
|
10469 |
|
10470 |
|
10471 |
|
10472 |
|
10473 |
|
10474 Rosenberg, et. al. Standards Track [Page 187] |
|
10475 |
|
10476 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10477 |
|
10478 |
|
10479 21.4.16 421 Extension Required |
|
10480 |
|
10481 The UAS needs a particular extension to process the request, but this |
|
10482 extension is not listed in a Supported header field in the request. |
|
10483 Responses with this status code MUST contain a Require header field |
|
10484 listing the required extensions. |
|
10485 |
|
10486 A UAS SHOULD NOT use this response unless it truly cannot provide any |
|
10487 useful service to the client. Instead, if a desirable extension is |
|
10488 not listed in the Supported header field, servers SHOULD process the |
|
10489 request using baseline SIP capabilities and any extensions supported |
|
10490 by the client. |
|
10491 |
|
10492 21.4.17 423 Interval Too Brief |
|
10493 |
|
10494 The server is rejecting the request because the expiration time of |
|
10495 the resource refreshed by the request is too short. This response |
|
10496 can be used by a registrar to reject a registration whose Contact |
|
10497 header field expiration time was too small. The use of this response |
|
10498 and the related Min-Expires header field are described in Sections |
|
10499 10.2.8, 10.3, and 20.23. |
|
10500 |
|
10501 21.4.18 480 Temporarily Unavailable |
|
10502 |
|
10503 The callee's end system was contacted successfully but the callee is |
|
10504 currently unavailable (for example, is not logged in, logged in but |
|
10505 in a state that precludes communication with the callee, or has |
|
10506 activated the "do not disturb" feature). The response MAY indicate a |
|
10507 better time to call in the Retry-After header field. The user could |
|
10508 also be available elsewhere (unbeknownst to this server). The reason |
|
10509 phrase SHOULD indicate a more precise cause as to why the callee is |
|
10510 unavailable. This value SHOULD be settable by the UA. Status 486 |
|
10511 (Busy Here) MAY be used to more precisely indicate a particular |
|
10512 reason for the call failure. |
|
10513 |
|
10514 This status is also returned by a redirect or proxy server that |
|
10515 recognizes the user identified by the Request-URI, but does not |
|
10516 currently have a valid forwarding location for that user. |
|
10517 |
|
10518 21.4.19 481 Call/Transaction Does Not Exist |
|
10519 |
|
10520 This status indicates that the UAS received a request that does not |
|
10521 match any existing dialog or transaction. |
|
10522 |
|
10523 21.4.20 482 Loop Detected |
|
10524 |
|
10525 The server has detected a loop (Section 16.3 Item 4). |
|
10526 |
|
10527 |
|
10528 |
|
10529 |
|
10530 Rosenberg, et. al. Standards Track [Page 188] |
|
10531 |
|
10532 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10533 |
|
10534 |
|
10535 21.4.21 483 Too Many Hops |
|
10536 |
|
10537 The server received a request that contains a Max-Forwards (Section |
|
10538 20.22) header field with the value zero. |
|
10539 |
|
10540 21.4.22 484 Address Incomplete |
|
10541 |
|
10542 The server received a request with a Request-URI that was incomplete. |
|
10543 Additional information SHOULD be provided in the reason phrase. |
|
10544 |
|
10545 This status code allows overlapped dialing. With overlapped |
|
10546 dialing, the client does not know the length of the dialing |
|
10547 string. It sends strings of increasing lengths, prompting the |
|
10548 user for more input, until it no longer receives a 484 (Address |
|
10549 Incomplete) status response. |
|
10550 |
|
10551 21.4.23 485 Ambiguous |
|
10552 |
|
10553 The Request-URI was ambiguous. The response MAY contain a listing of |
|
10554 possible unambiguous addresses in Contact header fields. Revealing |
|
10555 alternatives can infringe on privacy of the user or the organization. |
|
10556 It MUST be possible to configure a server to respond with status 404 |
|
10557 (Not Found) or to suppress the listing of possible choices for |
|
10558 ambiguous Request-URIs. |
|
10559 |
|
10560 Example response to a request with the Request-URI |
|
10561 sip:lee@example.com: |
|
10562 |
|
10563 SIP/2.0 485 Ambiguous |
|
10564 Contact: Carol Lee <sip:carol.lee@example.com> |
|
10565 Contact: Ping Lee <sip:p.lee@example.com> |
|
10566 Contact: Lee M. Foote <sips:lee.foote@example.com> |
|
10567 |
|
10568 Some email and voice mail systems provide this functionality. A |
|
10569 status code separate from 3xx is used since the semantics are |
|
10570 different: for 300, it is assumed that the same person or service |
|
10571 will be reached by the choices provided. While an automated |
|
10572 choice or sequential search makes sense for a 3xx response, user |
|
10573 intervention is required for a 485 (Ambiguous) response. |
|
10574 |
|
10575 21.4.24 486 Busy Here |
|
10576 |
|
10577 The callee's end system was contacted successfully, but the callee is |
|
10578 currently not willing or able to take additional calls at this end |
|
10579 system. The response MAY indicate a better time to call in the |
|
10580 Retry-After header field. The user could also be available |
|
10581 |
|
10582 |
|
10583 |
|
10584 |
|
10585 |
|
10586 Rosenberg, et. al. Standards Track [Page 189] |
|
10587 |
|
10588 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10589 |
|
10590 |
|
10591 elsewhere, such as through a voice mail service. Status 600 (Busy |
|
10592 Everywhere) SHOULD be used if the client knows that no other end |
|
10593 system will be able to accept this call. |
|
10594 |
|
10595 21.4.25 487 Request Terminated |
|
10596 |
|
10597 The request was terminated by a BYE or CANCEL request. This response |
|
10598 is never returned for a CANCEL request itself. |
|
10599 |
|
10600 21.4.26 488 Not Acceptable Here |
|
10601 |
|
10602 The response has the same meaning as 606 (Not Acceptable), but only |
|
10603 applies to the specific resource addressed by the Request-URI and the |
|
10604 request may succeed elsewhere. |
|
10605 |
|
10606 A message body containing a description of media capabilities MAY be |
|
10607 present in the response, which is formatted according to the Accept |
|
10608 header field in the INVITE (or application/sdp if not present), the |
|
10609 same as a message body in a 200 (OK) response to an OPTIONS request. |
|
10610 |
|
10611 21.4.27 491 Request Pending |
|
10612 |
|
10613 The request was received by a UAS that had a pending request within |
|
10614 the same dialog. Section 14.2 describes how such "glare" situations |
|
10615 are resolved. |
|
10616 |
|
10617 21.4.28 493 Undecipherable |
|
10618 |
|
10619 The request was received by a UAS that contained an encrypted MIME |
|
10620 body for which the recipient does not possess or will not provide an |
|
10621 appropriate decryption key. This response MAY have a single body |
|
10622 containing an appropriate public key that should be used to encrypt |
|
10623 MIME bodies sent to this UA. Details of the usage of this response |
|
10624 code can be found in Section 23.2. |
|
10625 |
|
10626 21.5 Server Failure 5xx |
|
10627 |
|
10628 5xx responses are failure responses given when a server itself has |
|
10629 erred. |
|
10630 |
|
10631 21.5.1 500 Server Internal Error |
|
10632 |
|
10633 The server encountered an unexpected condition that prevented it from |
|
10634 fulfilling the request. The client MAY display the specific error |
|
10635 condition and MAY retry the request after several seconds. |
|
10636 |
|
10637 If the condition is temporary, the server MAY indicate when the |
|
10638 client may retry the request using the Retry-After header field. |
|
10639 |
|
10640 |
|
10641 |
|
10642 Rosenberg, et. al. Standards Track [Page 190] |
|
10643 |
|
10644 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10645 |
|
10646 |
|
10647 21.5.2 501 Not Implemented |
|
10648 |
|
10649 The server does not support the functionality required to fulfill the |
|
10650 request. This is the appropriate response when a UAS does not |
|
10651 recognize the request method and is not capable of supporting it for |
|
10652 any user. (Proxies forward all requests regardless of method.) |
|
10653 |
|
10654 Note that a 405 (Method Not Allowed) is sent when the server |
|
10655 recognizes the request method, but that method is not allowed or |
|
10656 supported. |
|
10657 |
|
10658 21.5.3 502 Bad Gateway |
|
10659 |
|
10660 The server, while acting as a gateway or proxy, received an invalid |
|
10661 response from the downstream server it accessed in attempting to |
|
10662 fulfill the request. |
|
10663 |
|
10664 21.5.4 503 Service Unavailable |
|
10665 |
|
10666 The server is temporarily unable to process the request due to a |
|
10667 temporary overloading or maintenance of the server. The server MAY |
|
10668 indicate when the client should retry the request in a Retry-After |
|
10669 header field. If no Retry-After is given, the client MUST act as if |
|
10670 it had received a 500 (Server Internal Error) response. |
|
10671 |
|
10672 A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD |
|
10673 attempt to forward the request to an alternate server. It SHOULD NOT |
|
10674 forward any other requests to that server for the duration specified |
|
10675 in the Retry-After header field, if present. |
|
10676 |
|
10677 Servers MAY refuse the connection or drop the request instead of |
|
10678 responding with 503 (Service Unavailable). |
|
10679 |
|
10680 21.5.5 504 Server Time-out |
|
10681 |
|
10682 The server did not receive a timely response from an external server |
|
10683 it accessed in attempting to process the request. 408 (Request |
|
10684 Timeout) should be used instead if there was no response within the |
|
10685 period specified in the Expires header field from the upstream |
|
10686 server. |
|
10687 |
|
10688 21.5.6 505 Version Not Supported |
|
10689 |
|
10690 The server does not support, or refuses to support, the SIP protocol |
|
10691 version that was used in the request. The server is indicating that |
|
10692 it is unable or unwilling to complete the request using the same |
|
10693 major version as the client, other than with this error message. |
|
10694 |
|
10695 |
|
10696 |
|
10697 |
|
10698 Rosenberg, et. al. Standards Track [Page 191] |
|
10699 |
|
10700 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10701 |
|
10702 |
|
10703 21.5.7 513 Message Too Large |
|
10704 |
|
10705 The server was unable to process the request since the message length |
|
10706 exceeded its capabilities. |
|
10707 |
|
10708 21.6 Global Failures 6xx |
|
10709 |
|
10710 6xx responses indicate that a server has definitive information about |
|
10711 a particular user, not just the particular instance indicated in the |
|
10712 Request-URI. |
|
10713 |
|
10714 21.6.1 600 Busy Everywhere |
|
10715 |
|
10716 The callee's end system was contacted successfully but the callee is |
|
10717 busy and does not wish to take the call at this time. The response |
|
10718 MAY indicate a better time to call in the Retry-After header field. |
|
10719 If the callee does not wish to reveal the reason for declining the |
|
10720 call, the callee uses status code 603 (Decline) instead. This status |
|
10721 response is returned only if the client knows that no other end point |
|
10722 (such as a voice mail system) will answer the request. Otherwise, |
|
10723 486 (Busy Here) should be returned. |
|
10724 |
|
10725 21.6.2 603 Decline |
|
10726 |
|
10727 The callee's machine was successfully contacted but the user |
|
10728 explicitly does not wish to or cannot participate. The response MAY |
|
10729 indicate a better time to call in the Retry-After header field. This |
|
10730 status response is returned only if the client knows that no other |
|
10731 end point will answer the request. |
|
10732 |
|
10733 21.6.3 604 Does Not Exist Anywhere |
|
10734 |
|
10735 The server has authoritative information that the user indicated in |
|
10736 the Request-URI does not exist anywhere. |
|
10737 |
|
10738 21.6.4 606 Not Acceptable |
|
10739 |
|
10740 The user's agent was contacted successfully but some aspects of the |
|
10741 session description such as the requested media, bandwidth, or |
|
10742 addressing style were not acceptable. |
|
10743 |
|
10744 A 606 (Not Acceptable) response means that the user wishes to |
|
10745 communicate, but cannot adequately support the session described. |
|
10746 The 606 (Not Acceptable) response MAY contain a list of reasons in a |
|
10747 Warning header field describing why the session described cannot be |
|
10748 supported. Warning reason codes are listed in Section 20.43. |
|
10749 |
|
10750 |
|
10751 |
|
10752 |
|
10753 |
|
10754 Rosenberg, et. al. Standards Track [Page 192] |
|
10755 |
|
10756 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10757 |
|
10758 |
|
10759 A message body containing a description of media capabilities MAY be |
|
10760 present in the response, which is formatted according to the Accept |
|
10761 header field in the INVITE (or application/sdp if not present), the |
|
10762 same as a message body in a 200 (OK) response to an OPTIONS request. |
|
10763 |
|
10764 It is hoped that negotiation will not frequently be needed, and when |
|
10765 a new user is being invited to join an already existing conference, |
|
10766 negotiation may not be possible. It is up to the invitation |
|
10767 initiator to decide whether or not to act on a 606 (Not Acceptable) |
|
10768 response. |
|
10769 |
|
10770 This status response is returned only if the client knows that no |
|
10771 other end point will answer the request. |
|
10772 |
|
10773 22 Usage of HTTP Authentication |
|
10774 |
|
10775 SIP provides a stateless, challenge-based mechanism for |
|
10776 authentication that is based on authentication in HTTP. Any time |
|
10777 that a proxy server or UA receives a request (with the exceptions |
|
10778 given in Section 22.1), it MAY challenge the initiator of the request |
|
10779 to provide assurance of its identity. Once the originator has been |
|
10780 identified, the recipient of the request SHOULD ascertain whether or |
|
10781 not this user is authorized to make the request in question. No |
|
10782 authorization systems are recommended or discussed in this document. |
|
10783 |
|
10784 The "Digest" authentication mechanism described in this section |
|
10785 provides message authentication and replay protection only, without |
|
10786 message integrity or confidentiality. Protective measures above and |
|
10787 beyond those provided by Digest need to be taken to prevent active |
|
10788 attackers from modifying SIP requests and responses. |
|
10789 |
|
10790 Note that due to its weak security, the usage of "Basic" |
|
10791 authentication has been deprecated. Servers MUST NOT accept |
|
10792 credentials using the "Basic" authorization scheme, and servers also |
|
10793 MUST NOT challenge with "Basic". This is a change from RFC 2543. |
|
10794 |
|
10795 22.1 Framework |
|
10796 |
|
10797 The framework for SIP authentication closely parallels that of HTTP |
|
10798 (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, |
|
10799 challenge, realm, realm-value, and credentials is identical (although |
|
10800 the usage of "Basic" as a scheme is not permitted). In SIP, a UAS |
|
10801 uses the 401 (Unauthorized) response to challenge the identity of a |
|
10802 UAC. Additionally, registrars and redirect servers MAY make use of |
|
10803 401 (Unauthorized) responses for authentication, but proxies MUST |
|
10804 NOT, and instead MAY use the 407 (Proxy Authentication Required) |
|
10805 |
|
10806 |
|
10807 |
|
10808 |
|
10809 |
|
10810 Rosenberg, et. al. Standards Track [Page 193] |
|
10811 |
|
10812 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10813 |
|
10814 |
|
10815 response. The requirements for inclusion of the Proxy-Authenticate, |
|
10816 Proxy-Authorization, WWW-Authenticate, and Authorization in the |
|
10817 various messages are identical to those described in RFC 2617 [17]. |
|
10818 |
|
10819 Since SIP does not have the concept of a canonical root URL, the |
|
10820 notion of protection spaces is interpreted differently in SIP. The |
|
10821 realm string alone defines the protection domain. This is a change |
|
10822 from RFC 2543, in which the Request-URI and the realm together |
|
10823 defined the protection domain. |
|
10824 |
|
10825 This previous definition of protection domain caused some amount |
|
10826 of confusion since the Request-URI sent by the UAC and the |
|
10827 Request-URI received by the challenging server might be different, |
|
10828 and indeed the final form of the Request-URI might not be known to |
|
10829 the UAC. Also, the previous definition depended on the presence |
|
10830 of a SIP URI in the Request-URI and seemed to rule out alternative |
|
10831 URI schemes (for example, the tel URL). |
|
10832 |
|
10833 Operators of user agents or proxy servers that will authenticate |
|
10834 received requests MUST adhere to the following guidelines for |
|
10835 creation of a realm string for their server: |
|
10836 |
|
10837 o Realm strings MUST be globally unique. It is RECOMMENDED that |
|
10838 a realm string contain a hostname or domain name, following the |
|
10839 recommendation in Section 3.2.1 of RFC 2617 [17]. |
|
10840 |
|
10841 o Realm strings SHOULD present a human-readable identifier that |
|
10842 can be rendered to a user. |
|
10843 |
|
10844 For example: |
|
10845 |
|
10846 INVITE sip:bob@biloxi.com SIP/2.0 |
|
10847 Authorization: Digest realm="biloxi.com", <...> |
|
10848 |
|
10849 Generally, SIP authentication is meaningful for a specific realm, a |
|
10850 protection domain. Thus, for Digest authentication, each such |
|
10851 protection domain has its own set of usernames and passwords. If a |
|
10852 server does not require authentication for a particular request, it |
|
10853 MAY accept a default username, "anonymous", which has no password |
|
10854 (password of ""). Similarly, UACs representing many users, such as |
|
10855 PSTN gateways, MAY have their own device-specific username and |
|
10856 password, rather than accounts for particular users, for their realm. |
|
10857 |
|
10858 While a server can legitimately challenge most SIP requests, there |
|
10859 are two requests defined by this document that require special |
|
10860 handling for authentication: ACK and CANCEL. |
|
10861 |
|
10862 |
|
10863 |
|
10864 |
|
10865 |
|
10866 Rosenberg, et. al. Standards Track [Page 194] |
|
10867 |
|
10868 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10869 |
|
10870 |
|
10871 Under an authentication scheme that uses responses to carry values |
|
10872 used to compute nonces (such as Digest), some problems come up for |
|
10873 any requests that take no response, including ACK. For this reason, |
|
10874 any credentials in the INVITE that were accepted by a server MUST be |
|
10875 accepted by that server for the ACK. UACs creating an ACK message |
|
10876 will duplicate all of the Authorization and Proxy-Authorization |
|
10877 header field values that appeared in the INVITE to which the ACK |
|
10878 corresponds. Servers MUST NOT attempt to challenge an ACK. |
|
10879 |
|
10880 Although the CANCEL method does take a response (a 2xx), servers MUST |
|
10881 NOT attempt to challenge CANCEL requests since these requests cannot |
|
10882 be resubmitted. Generally, a CANCEL request SHOULD be accepted by a |
|
10883 server if it comes from the same hop that sent the request being |
|
10884 canceled (provided that some sort of transport or network layer |
|
10885 security association, as described in Section 26.2.1, is in place). |
|
10886 |
|
10887 When a UAC receives a challenge, it SHOULD render to the user the |
|
10888 contents of the "realm" parameter in the challenge (which appears in |
|
10889 either a WWW-Authenticate header field or Proxy-Authenticate header |
|
10890 field) if the UAC device does not already know of a credential for |
|
10891 the realm in question. A service provider that pre-configures UAs |
|
10892 with credentials for its realm should be aware that users will not |
|
10893 have the opportunity to present their own credentials for this realm |
|
10894 when challenged at a pre-configured device. |
|
10895 |
|
10896 Finally, note that even if a UAC can locate credentials that are |
|
10897 associated with the proper realm, the potential exists that these |
|
10898 credentials may no longer be valid or that the challenging server |
|
10899 will not accept these credentials for whatever reason (especially |
|
10900 when "anonymous" with no password is submitted). In this instance a |
|
10901 server may repeat its challenge, or it may respond with a 403 |
|
10902 Forbidden. A UAC MUST NOT re-attempt requests with the credentials |
|
10903 that have just been rejected (though the request may be retried if |
|
10904 the nonce was stale). |
|
10905 |
|
10906 22.2 User-to-User Authentication |
|
10907 |
|
10908 When a UAS receives a request from a UAC, the UAS MAY authenticate |
|
10909 the originator before the request is processed. If no credentials |
|
10910 (in the Authorization header field) are provided in the request, the |
|
10911 UAS can challenge the originator to provide credentials by rejecting |
|
10912 the request with a 401 (Unauthorized) status code. |
|
10913 |
|
10914 The WWW-Authenticate response-header field MUST be included in 401 |
|
10915 (Unauthorized) response messages. The field value consists of at |
|
10916 least one challenge that indicates the authentication scheme(s) and |
|
10917 parameters applicable to the realm. |
|
10918 |
|
10919 |
|
10920 |
|
10921 |
|
10922 Rosenberg, et. al. Standards Track [Page 195] |
|
10923 |
|
10924 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10925 |
|
10926 |
|
10927 An example of the WWW-Authenticate header field in a 401 challenge |
|
10928 is: |
|
10929 |
|
10930 WWW-Authenticate: Digest |
|
10931 realm="biloxi.com", |
|
10932 qop="auth,auth-int", |
|
10933 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", |
|
10934 opaque="5ccc069c403ebaf9f0171e9517f40e41" |
|
10935 |
|
10936 When the originating UAC receives the 401 (Unauthorized), it SHOULD, |
|
10937 if it is able, re-originate the request with the proper credentials. |
|
10938 The UAC may require input from the originating user before |
|
10939 proceeding. Once authentication credentials have been supplied |
|
10940 (either directly by the user, or discovered in an internal keyring), |
|
10941 UAs SHOULD cache the credentials for a given value of the To header |
|
10942 field and "realm" and attempt to re-use these values on the next |
|
10943 request for that destination. UAs MAY cache credentials in any way |
|
10944 they would like. |
|
10945 |
|
10946 If no credentials for a realm can be located, UACs MAY attempt to |
|
10947 retry the request with a username of "anonymous" and no password (a |
|
10948 password of ""). |
|
10949 |
|
10950 Once credentials have been located, any UA that wishes to |
|
10951 authenticate itself with a UAS or registrar -- usually, but not |
|
10952 necessarily, after receiving a 401 (Unauthorized) response -- MAY do |
|
10953 so by including an Authorization header field with the request. The |
|
10954 Authorization field value consists of credentials containing the |
|
10955 authentication information of the UA for the realm of the resource |
|
10956 being requested as well as parameters required in support of |
|
10957 authentication and replay protection. |
|
10958 |
|
10959 An example of the Authorization header field is: |
|
10960 |
|
10961 Authorization: Digest username="bob", |
|
10962 realm="biloxi.com", |
|
10963 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", |
|
10964 uri="sip:bob@biloxi.com", |
|
10965 qop=auth, |
|
10966 nc=00000001, |
|
10967 cnonce="0a4f113b", |
|
10968 response="6629fae49393a05397450978507c4ef1", |
|
10969 opaque="5ccc069c403ebaf9f0171e9517f40e41" |
|
10970 |
|
10971 When a UAC resubmits a request with its credentials after receiving a |
|
10972 401 (Unauthorized) or 407 (Proxy Authentication Required) response, |
|
10973 it MUST increment the CSeq header field value as it would normally |
|
10974 when sending an updated request. |
|
10975 |
|
10976 |
|
10977 |
|
10978 Rosenberg, et. al. Standards Track [Page 196] |
|
10979 |
|
10980 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
10981 |
|
10982 |
|
10983 22.3 Proxy-to-User Authentication |
|
10984 |
|
10985 Similarly, when a UAC sends a request to a proxy server, the proxy |
|
10986 server MAY authenticate the originator before the request is |
|
10987 processed. If no credentials (in the Proxy-Authorization header |
|
10988 field) are provided in the request, the proxy can challenge the |
|
10989 originator to provide credentials by rejecting the request with a 407 |
|
10990 (Proxy Authentication Required) status code. The proxy MUST populate |
|
10991 the 407 (Proxy Authentication Required) message with a Proxy- |
|
10992 Authenticate header field value applicable to the proxy for the |
|
10993 requested resource. |
|
10994 |
|
10995 The use of Proxy-Authenticate and Proxy-Authorization parallel that |
|
10996 described in [17], with one difference. Proxies MUST NOT add values |
|
10997 to the Proxy-Authorization header field. All 407 (Proxy |
|
10998 Authentication Required) responses MUST be forwarded upstream toward |
|
10999 the UAC following the procedures for any other response. It is the |
|
11000 UAC's responsibility to add the Proxy-Authorization header field |
|
11001 value containing credentials for the realm of the proxy that has |
|
11002 asked for authentication. |
|
11003 |
|
11004 If a proxy were to resubmit a request adding a Proxy-Authorization |
|
11005 header field value, it would need to increment the CSeq in the new |
|
11006 request. However, this would cause the UAC that submitted the |
|
11007 original request to discard a response from the UAS, as the CSeq |
|
11008 value would be different. |
|
11009 |
|
11010 When the originating UAC receives the 407 (Proxy Authentication |
|
11011 Required) it SHOULD, if it is able, re-originate the request with the |
|
11012 proper credentials. It should follow the same procedures for the |
|
11013 display of the "realm" parameter that are given above for responding |
|
11014 to 401. |
|
11015 |
|
11016 If no credentials for a realm can be located, UACs MAY attempt to |
|
11017 retry the request with a username of "anonymous" and no password (a |
|
11018 password of ""). |
|
11019 |
|
11020 The UAC SHOULD also cache the credentials used in the re-originated |
|
11021 request. |
|
11022 |
|
11023 The following rule is RECOMMENDED for proxy credential caching: |
|
11024 |
|
11025 If a UA receives a Proxy-Authenticate header field value in a 401/407 |
|
11026 response to a request with a particular Call-ID, it should |
|
11027 incorporate credentials for that realm in all subsequent requests |
|
11028 that contain the same Call-ID. These credentials MUST NOT be cached |
|
11029 across dialogs; however, if a UA is configured with the realm of its |
|
11030 local outbound proxy, when one exists, then the UA MAY cache |
|
11031 |
|
11032 |
|
11033 |
|
11034 Rosenberg, et. al. Standards Track [Page 197] |
|
11035 |
|
11036 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11037 |
|
11038 |
|
11039 credentials for that realm across dialogs. Note that this does mean |
|
11040 a future request in a dialog could contain credentials that are not |
|
11041 needed by any proxy along the Route header path. |
|
11042 |
|
11043 Any UA that wishes to authenticate itself to a proxy server -- |
|
11044 usually, but not necessarily, after receiving a 407 (Proxy |
|
11045 Authentication Required) response -- MAY do so by including a Proxy- |
|
11046 Authorization header field value with the request. The Proxy- |
|
11047 Authorization request-header field allows the client to identify |
|
11048 itself (or its user) to a proxy that requires authentication. The |
|
11049 Proxy-Authorization header field value consists of credentials |
|
11050 containing the authentication information of the UA for the proxy |
|
11051 and/or realm of the resource being requested. |
|
11052 |
|
11053 A Proxy-Authorization header field value applies only to the proxy |
|
11054 whose realm is identified in the "realm" parameter (this proxy may |
|
11055 previously have demanded authentication using the Proxy-Authenticate |
|
11056 field). When multiple proxies are used in a chain, a Proxy- |
|
11057 Authorization header field value MUST NOT be consumed by any proxy |
|
11058 whose realm does not match the "realm" parameter specified in that |
|
11059 value. |
|
11060 |
|
11061 Note that if an authentication scheme that does not support realms is |
|
11062 used in the Proxy-Authorization header field, a proxy server MUST |
|
11063 attempt to parse all Proxy-Authorization header field values to |
|
11064 determine whether one of them has what the proxy server considers to |
|
11065 be valid credentials. Because this is potentially very time- |
|
11066 consuming in large networks, proxy servers SHOULD use an |
|
11067 authentication scheme that supports realms in the Proxy-Authorization |
|
11068 header field. |
|
11069 |
|
11070 If a request is forked (as described in Section 16.7), various proxy |
|
11071 servers and/or UAs may wish to challenge the UAC. In this case, the |
|
11072 forking proxy server is responsible for aggregating these challenges |
|
11073 into a single response. Each WWW-Authenticate and Proxy-Authenticate |
|
11074 value received in responses to the forked request MUST be placed into |
|
11075 the single response that is sent by the forking proxy to the UA; the |
|
11076 ordering of these header field values is not significant. |
|
11077 |
|
11078 When a proxy server issues a challenge in response to a request, |
|
11079 it will not proxy the request until the UAC has retried the |
|
11080 request with valid credentials. A forking proxy may forward a |
|
11081 request simultaneously to multiple proxy servers that require |
|
11082 authentication, each of which in turn will not forward the request |
|
11083 until the originating UAC has authenticated itself in their |
|
11084 respective realm. If the UAC does not provide credentials for |
|
11085 |
|
11086 |
|
11087 |
|
11088 |
|
11089 |
|
11090 Rosenberg, et. al. Standards Track [Page 198] |
|
11091 |
|
11092 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11093 |
|
11094 |
|
11095 each challenge, the proxy servers that issued the challenges will |
|
11096 not forward requests to the UA where the destination user might be |
|
11097 located, and therefore, the virtues of forking are largely lost. |
|
11098 |
|
11099 When resubmitting its request in response to a 401 (Unauthorized) or |
|
11100 407 (Proxy Authentication Required) that contains multiple |
|
11101 challenges, a UAC MAY include an Authorization value for each WWW- |
|
11102 Authenticate value and a Proxy-Authorization value for each Proxy- |
|
11103 Authenticate value for which the UAC wishes to supply a credential. |
|
11104 As noted above, multiple credentials in a request SHOULD be |
|
11105 differentiated by the "realm" parameter. |
|
11106 |
|
11107 It is possible for multiple challenges associated with the same realm |
|
11108 to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication |
|
11109 Required). This can occur, for example, when multiple proxies within |
|
11110 the same administrative domain, which use a common realm, are reached |
|
11111 by a forking request. When it retries a request, a UAC MAY therefore |
|
11112 supply multiple credentials in Authorization or Proxy-Authorization |
|
11113 header fields with the same "realm" parameter value. The same |
|
11114 credentials SHOULD be used for the same realm. |
|
11115 |
|
11116 22.4 The Digest Authentication Scheme |
|
11117 |
|
11118 This section describes the modifications and clarifications required |
|
11119 to apply the HTTP Digest authentication scheme to SIP. The SIP |
|
11120 scheme usage is almost completely identical to that for HTTP [17]. |
|
11121 |
|
11122 Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], |
|
11123 SIP servers supporting RFC 2617 MUST ensure they are backwards |
|
11124 compatible with RFC 2069. Procedures for this backwards |
|
11125 compatibility are specified in RFC 2617. Note, however, that SIP |
|
11126 servers MUST NOT accept or request Basic authentication. |
|
11127 |
|
11128 The rules for Digest authentication follow those defined in [17], |
|
11129 with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following |
|
11130 differences: |
|
11131 |
|
11132 1. The URI included in the challenge has the following BNF: |
|
11133 |
|
11134 URI = SIP-URI / SIPS-URI |
|
11135 |
|
11136 2. The BNF in RFC 2617 has an error in that the 'uri' parameter |
|
11137 of the Authorization header field for HTTP Digest |
|
11138 |
|
11139 |
|
11140 |
|
11141 |
|
11142 |
|
11143 |
|
11144 |
|
11145 |
|
11146 Rosenberg, et. al. Standards Track [Page 199] |
|
11147 |
|
11148 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11149 |
|
11150 |
|
11151 authentication is not enclosed in quotation marks. (The |
|
11152 example in Section 3.5 of RFC 2617 is correct.) For SIP, the |
|
11153 'uri' MUST be enclosed in quotation marks. |
|
11154 |
|
11155 3. The BNF for digest-uri-value is: |
|
11156 |
|
11157 digest-uri-value = Request-URI ; as defined in Section 25 |
|
11158 |
|
11159 4. The example procedure for choosing a nonce based on Etag does |
|
11160 not work for SIP. |
|
11161 |
|
11162 5. The text in RFC 2617 [17] regarding cache operation does not |
|
11163 apply to SIP. |
|
11164 |
|
11165 6. RFC 2617 [17] requires that a server check that the URI in the |
|
11166 request line and the URI included in the Authorization header |
|
11167 field point to the same resource. In a SIP context, these two |
|
11168 URIs may refer to different users, due to forwarding at some |
|
11169 proxy. Therefore, in SIP, a server MAY check that the |
|
11170 Request-URI in the Authorization header field value |
|
11171 corresponds to a user for whom the server is willing to accept |
|
11172 forwarded or direct requests, but it is not necessarily a |
|
11173 failure if the two fields are not equivalent. |
|
11174 |
|
11175 7. As a clarification to the calculation of the A2 value for |
|
11176 message integrity assurance in the Digest authentication |
|
11177 scheme, implementers should assume, when the entity-body is |
|
11178 empty (that is, when SIP messages have no body) that the hash |
|
11179 of the entity-body resolves to the MD5 hash of an empty |
|
11180 string, or: |
|
11181 |
|
11182 H(entity-body) = MD5("") = |
|
11183 "d41d8cd98f00b204e9800998ecf8427e" |
|
11184 |
|
11185 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an |
|
11186 Authorization (and by extension Proxy-Authorization) header |
|
11187 field if no qop directive has been sent. Therefore, any |
|
11188 algorithms that have a dependency on the cnonce (including |
|
11189 "MD5-Sess") require that the qop directive be sent. Use of |
|
11190 the "qop" parameter is optional in RFC 2617 for the purposes |
|
11191 of backwards compatibility with RFC 2069; since RFC 2543 was |
|
11192 based on RFC 2069, the "qop" parameter must unfortunately |
|
11193 remain optional for clients and servers to receive. However, |
|
11194 servers MUST always send a "qop" parameter in WWW-Authenticate |
|
11195 and Proxy-Authenticate header field values. If a client |
|
11196 receives a "qop" parameter in a challenge header field, it |
|
11197 MUST send the "qop" parameter in any resulting authorization |
|
11198 header field. |
|
11199 |
|
11200 |
|
11201 |
|
11202 Rosenberg, et. al. Standards Track [Page 200] |
|
11203 |
|
11204 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11205 |
|
11206 |
|
11207 RFC 2543 did not allow usage of the Authentication-Info header field |
|
11208 (it effectively used RFC 2069). However, we now allow usage of this |
|
11209 header field, since it provides integrity checks over the bodies and |
|
11210 provides mutual authentication. RFC 2617 [17] defines mechanisms for |
|
11211 backwards compatibility using the qop attribute in the request. |
|
11212 These mechanisms MUST be used by a server to determine if the client |
|
11213 supports the new mechanisms in RFC 2617 that were not specified in |
|
11214 RFC 2069. |
|
11215 |
|
11216 23 S/MIME |
|
11217 |
|
11218 SIP messages carry MIME bodies and the MIME standard includes |
|
11219 mechanisms for securing MIME contents to ensure both integrity and |
|
11220 confidentiality (including the 'multipart/signed' and |
|
11221 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23] |
|
11222 and RFC 2633 [24]). Implementers should note, however, that there |
|
11223 may be rare network intermediaries (not typical proxy servers) that |
|
11224 rely on viewing or modifying the bodies of SIP messages (especially |
|
11225 SDP), and that secure MIME may prevent these sorts of intermediaries |
|
11226 from functioning. |
|
11227 |
|
11228 This applies particularly to certain types of firewalls. |
|
11229 |
|
11230 The PGP mechanism for encrypting the header fields and bodies of |
|
11231 SIP messages described in RFC 2543 has been deprecated. |
|
11232 |
|
11233 23.1 S/MIME Certificates |
|
11234 |
|
11235 The certificates that are used to identify an end-user for the |
|
11236 purposes of S/MIME differ from those used by servers in one important |
|
11237 respect - rather than asserting that the identity of the holder |
|
11238 corresponds to a particular hostname, these certificates assert that |
|
11239 the holder is identified by an end-user address. This address is |
|
11240 composed of the concatenation of the "userinfo" "@" and "domainname" |
|
11241 portions of a SIP or SIPS URI (in other words, an email address of |
|
11242 the form "bob@biloxi.com"), most commonly corresponding to a user's |
|
11243 address-of-record. |
|
11244 |
|
11245 These certificates are also associated with keys that are used to |
|
11246 sign or encrypt bodies of SIP messages. Bodies are signed with the |
|
11247 private key of the sender (who may include their public key with the |
|
11248 message as appropriate), but bodies are encrypted with the public key |
|
11249 of the intended recipient. Obviously, senders must have |
|
11250 foreknowledge of the public key of recipients in order to encrypt |
|
11251 message bodies. Public keys can be stored within a UA on a virtual |
|
11252 keyring. |
|
11253 |
|
11254 |
|
11255 |
|
11256 |
|
11257 |
|
11258 Rosenberg, et. al. Standards Track [Page 201] |
|
11259 |
|
11260 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11261 |
|
11262 |
|
11263 Each user agent that supports S/MIME MUST contain a keyring |
|
11264 specifically for end-users' certificates. This keyring should map |
|
11265 between addresses of record and corresponding certificates. Over |
|
11266 time, users SHOULD use the same certificate when they populate the |
|
11267 originating URI of signaling (the From header field) with the same |
|
11268 address-of-record. |
|
11269 |
|
11270 Any mechanisms depending on the existence of end-user certificates |
|
11271 are seriously limited in that there is virtually no consolidated |
|
11272 authority today that provides certificates for end-user applications. |
|
11273 However, users SHOULD acquire certificates from known public |
|
11274 certificate authorities. As an alternative, users MAY create self- |
|
11275 signed certificates. The implications of self-signed certificates |
|
11276 are explored further in Section 26.4.2. Implementations may also use |
|
11277 pre-configured certificates in deployments in which a previous trust |
|
11278 relationship exists between all SIP entities. |
|
11279 |
|
11280 Above and beyond the problem of acquiring an end-user certificate, |
|
11281 there are few well-known centralized directories that distribute |
|
11282 end-user certificates. However, the holder of a certificate SHOULD |
|
11283 publish their certificate in any public directories as appropriate. |
|
11284 Similarly, UACs SHOULD support a mechanism for importing (manually or |
|
11285 automatically) certificates discovered in public directories |
|
11286 corresponding to the target URIs of SIP requests. |
|
11287 |
|
11288 23.2 S/MIME Key Exchange |
|
11289 |
|
11290 SIP itself can also be used as a means to distribute public keys in |
|
11291 the following manner. |
|
11292 |
|
11293 Whenever the CMS SignedData message is used in S/MIME for SIP, it |
|
11294 MUST contain the certificate bearing the public key necessary to |
|
11295 verify the signature. |
|
11296 |
|
11297 When a UAC sends a request containing an S/MIME body that initiates a |
|
11298 dialog, or sends a non-INVITE request outside the context of a |
|
11299 dialog, the UAC SHOULD structure the body as an S/MIME |
|
11300 'multipart/signed' CMS SignedData body. If the desired CMS service |
|
11301 is EnvelopedData (and the public key of the target user is known), |
|
11302 the UAC SHOULD send the EnvelopedData message encapsulated within a |
|
11303 SignedData message. |
|
11304 |
|
11305 When a UAS receives a request containing an S/MIME CMS body that |
|
11306 includes a certificate, the UAS SHOULD first validate the |
|
11307 certificate, if possible, with any available root certificates for |
|
11308 certificate authorities. The UAS SHOULD also determine the subject |
|
11309 of the certificate (for S/MIME, the SubjectAltName will contain the |
|
11310 appropriate identity) and compare this value to the From header field |
|
11311 |
|
11312 |
|
11313 |
|
11314 Rosenberg, et. al. Standards Track [Page 202] |
|
11315 |
|
11316 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11317 |
|
11318 |
|
11319 of the request. If the certificate cannot be verified, because it is |
|
11320 self-signed, or signed by no known authority, or if it is verifiable |
|
11321 but its subject does not correspond to the From header field of |
|
11322 request, the UAS MUST notify its user of the status of the |
|
11323 certificate (including the subject of the certificate, its signer, |
|
11324 and any key fingerprint information) and request explicit permission |
|
11325 before proceeding. If the certificate was successfully verified and |
|
11326 the subject of the certificate corresponds to the From header field |
|
11327 of the SIP request, or if the user (after notification) explicitly |
|
11328 authorizes the use of the certificate, the UAS SHOULD add this |
|
11329 certificate to a local keyring, indexed by the address-of-record of |
|
11330 the holder of the certificate. |
|
11331 |
|
11332 When a UAS sends a response containing an S/MIME body that answers |
|
11333 the first request in a dialog, or a response to a non-INVITE request |
|
11334 outside the context of a dialog, the UAS SHOULD structure the body as |
|
11335 an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS |
|
11336 service is EnvelopedData, the UAS SHOULD send the EnvelopedData |
|
11337 message encapsulated within a SignedData message. |
|
11338 |
|
11339 When a UAC receives a response containing an S/MIME CMS body that |
|
11340 includes a certificate, the UAC SHOULD first validate the |
|
11341 certificate, if possible, with any appropriate root certificate. The |
|
11342 UAC SHOULD also determine the subject of the certificate and compare |
|
11343 this value to the To field of the response; although the two may very |
|
11344 well be different, and this is not necessarily indicative of a |
|
11345 security breach. If the certificate cannot be verified because it is |
|
11346 self-signed, or signed by no known authority, the UAC MUST notify its |
|
11347 user of the status of the certificate (including the subject of the |
|
11348 certificate, its signator, and any key fingerprint information) and |
|
11349 request explicit permission before proceeding. If the certificate |
|
11350 was successfully verified, and the subject of the certificate |
|
11351 corresponds to the To header field in the response, or if the user |
|
11352 (after notification) explicitly authorizes the use of the |
|
11353 certificate, the UAC SHOULD add this certificate to a local keyring, |
|
11354 indexed by the address-of-record of the holder of the certificate. |
|
11355 If the UAC had not transmitted its own certificate to the UAS in any |
|
11356 previous transaction, it SHOULD use a CMS SignedData body for its |
|
11357 next request or response. |
|
11358 |
|
11359 On future occasions, when the UA receives requests or responses that |
|
11360 contain a From header field corresponding to a value in its keyring, |
|
11361 the UA SHOULD compare the certificate offered in these messages with |
|
11362 the existing certificate in its keyring. If there is a discrepancy, |
|
11363 the UA MUST notify its user of a change of the certificate |
|
11364 (preferably in terms that indicate that this is a potential security |
|
11365 breach) and acquire the user's permission before continuing to |
|
11366 |
|
11367 |
|
11368 |
|
11369 |
|
11370 Rosenberg, et. al. Standards Track [Page 203] |
|
11371 |
|
11372 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11373 |
|
11374 |
|
11375 process the signaling. If the user authorizes this certificate, it |
|
11376 SHOULD be added to the keyring alongside any previous value(s) for |
|
11377 this address-of-record. |
|
11378 |
|
11379 Note well however, that this key exchange mechanism does not |
|
11380 guarantee the secure exchange of keys when self-signed certificates, |
|
11381 or certificates signed by an obscure authority, are used - it is |
|
11382 vulnerable to well-known attacks. In the opinion of the authors, |
|
11383 however, the security it provides is proverbially better than |
|
11384 nothing; it is in fact comparable to the widely used SSH application. |
|
11385 These limitations are explored in greater detail in Section 26.4.2. |
|
11386 |
|
11387 If a UA receives an S/MIME body that has been encrypted with a public |
|
11388 key unknown to the recipient, it MUST reject the request with a 493 |
|
11389 (Undecipherable) response. This response SHOULD contain a valid |
|
11390 certificate for the respondent (corresponding, if possible, to any |
|
11391 address of record given in the To header field of the rejected |
|
11392 request) within a MIME body with a 'certs-only' "smime-type" |
|
11393 parameter. |
|
11394 |
|
11395 A 493 (Undecipherable) sent without any certificate indicates that |
|
11396 the respondent cannot or will not utilize S/MIME encrypted messages, |
|
11397 though they may still support S/MIME signatures. |
|
11398 |
|
11399 Note that a user agent that receives a request containing an S/MIME |
|
11400 body that is not optional (with a Content-Disposition header |
|
11401 "handling" parameter of "required") MUST reject the request with a |
|
11402 415 Unsupported Media Type response if the MIME type is not |
|
11403 understood. A user agent that receives such a response when S/MIME |
|
11404 is sent SHOULD notify its user that the remote device does not |
|
11405 support S/MIME, and it MAY subsequently resend the request without |
|
11406 S/MIME, if appropriate; however, this 415 response may constitute a |
|
11407 downgrade attack. |
|
11408 |
|
11409 If a user agent sends an S/MIME body in a request, but receives a |
|
11410 response that contains a MIME body that is not secured, the UAC |
|
11411 SHOULD notify its user that the session could not be secured. |
|
11412 However, if a user agent that supports S/MIME receives a request with |
|
11413 an unsecured body, it SHOULD NOT respond with a secured body, but if |
|
11414 it expects S/MIME from the sender (for example, because the sender's |
|
11415 From header field value corresponds to an identity on its keychain), |
|
11416 the UAS SHOULD notify its user that the session could not be secured. |
|
11417 |
|
11418 A number of conditions that arise in the previous text call for the |
|
11419 notification of the user when an anomalous certificate-management |
|
11420 event occurs. Users might well ask what they should do under these |
|
11421 circumstances. First and foremost, an unexpected change in a |
|
11422 certificate, or an absence of security when security is expected, are |
|
11423 |
|
11424 |
|
11425 |
|
11426 Rosenberg, et. al. Standards Track [Page 204] |
|
11427 |
|
11428 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11429 |
|
11430 |
|
11431 causes for caution but not necessarily indications that an attack is |
|
11432 in progress. Users might abort any connection attempt or refuse a |
|
11433 connection request they have received; in telephony parlance, they |
|
11434 could hang up and call back. Users may wish to find an alternate |
|
11435 means to contact the other party and confirm that their key has |
|
11436 legitimately changed. Note that users are sometimes compelled to |
|
11437 change their certificates, for example when they suspect that the |
|
11438 secrecy of their private key has been compromised. When their |
|
11439 private key is no longer private, users must legitimately generate a |
|
11440 new key and re-establish trust with any users that held their old |
|
11441 key. |
|
11442 |
|
11443 Finally, if during the course of a dialog a UA receives a certificate |
|
11444 in a CMS SignedData message that does not correspond with the |
|
11445 certificates previously exchanged during a dialog, the UA MUST notify |
|
11446 its user of the change, preferably in terms that indicate that this |
|
11447 is a potential security breach. |
|
11448 |
|
11449 23.3 Securing MIME bodies |
|
11450 |
|
11451 There are two types of secure MIME bodies that are of interest to |
|
11452 SIP: use of these bodies should follow the S/MIME specification [24] |
|
11453 with a few variations. |
|
11454 |
|
11455 o "multipart/signed" MUST be used only with CMS detached |
|
11456 signatures. |
|
11457 |
|
11458 This allows backwards compatibility with non-S/MIME- |
|
11459 compliant recipients. |
|
11460 |
|
11461 o S/MIME bodies SHOULD have a Content-Disposition header field, |
|
11462 and the value of the "handling" parameter SHOULD be "required." |
|
11463 |
|
11464 o If a UAC has no certificate on its keyring associated with the |
|
11465 address-of-record to which it wants to send a request, it |
|
11466 cannot send an encrypted "application/pkcs7-mime" MIME message. |
|
11467 UACs MAY send an initial request such as an OPTIONS message |
|
11468 with a CMS detached signature in order to solicit the |
|
11469 certificate of the remote side (the signature SHOULD be over a |
|
11470 "message/sip" body of the type described in Section 23.4). |
|
11471 |
|
11472 Note that future standardization work on S/MIME may define |
|
11473 non-certificate based keys. |
|
11474 |
|
11475 o Senders of S/MIME bodies SHOULD use the "SMIMECapabilities" |
|
11476 (see Section 2.5.2 of [24]) attribute to express their |
|
11477 capabilities and preferences for further communications. Note |
|
11478 especially that senders MAY use the "preferSignedData" |
|
11479 |
|
11480 |
|
11481 |
|
11482 Rosenberg, et. al. Standards Track [Page 205] |
|
11483 |
|
11484 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11485 |
|
11486 |
|
11487 capability to encourage receivers to respond with CMS |
|
11488 SignedData messages (for example, when sending an OPTIONS |
|
11489 request as described above). |
|
11490 |
|
11491 o S/MIME implementations MUST at a minimum support SHA1 as a |
|
11492 digital signature algorithm, and 3DES as an encryption |
|
11493 algorithm. All other signature and encryption algorithms MAY |
|
11494 be supported. Implementations can negotiate support for these |
|
11495 algorithms with the "SMIMECapabilities" attribute. |
|
11496 |
|
11497 o Each S/MIME body in a SIP message SHOULD be signed with only |
|
11498 one certificate. If a UA receives a message with multiple |
|
11499 signatures, the outermost signature should be treated as the |
|
11500 single certificate for this body. Parallel signatures SHOULD |
|
11501 NOT be used. |
|
11502 |
|
11503 The following is an example of an encrypted S/MIME SDP body |
|
11504 within a SIP message: |
|
11505 |
|
11506 INVITE sip:bob@biloxi.com SIP/2.0 |
|
11507 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
11508 To: Bob <sip:bob@biloxi.com> |
|
11509 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
11510 Call-ID: a84b4c76e66710 |
|
11511 CSeq: 314159 INVITE |
|
11512 Max-Forwards: 70 |
|
11513 Contact: <sip:alice@pc33.atlanta.com> |
|
11514 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; |
|
11515 name=smime.p7m |
|
11516 Content-Disposition: attachment; filename=smime.p7m |
|
11517 handling=required |
|
11518 |
|
11519 ******************************************************* |
|
11520 * Content-Type: application/sdp * |
|
11521 * * |
|
11522 * v=0 * |
|
11523 * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * |
|
11524 * s=- * |
|
11525 * t=0 0 * |
|
11526 * c=IN IP4 pc33.atlanta.com * |
|
11527 * m=audio 3456 RTP/AVP 0 1 3 99 * |
|
11528 * a=rtpmap:0 PCMU/8000 * |
|
11529 ******************************************************* |
|
11530 |
|
11531 |
|
11532 |
|
11533 |
|
11534 |
|
11535 |
|
11536 |
|
11537 |
|
11538 Rosenberg, et. al. Standards Track [Page 206] |
|
11539 |
|
11540 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11541 |
|
11542 |
|
11543 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP |
|
11544 |
|
11545 As a means of providing some degree of end-to-end authentication, |
|
11546 integrity or confidentiality for SIP header fields, S/MIME can |
|
11547 encapsulate entire SIP messages within MIME bodies of type |
|
11548 "message/sip" and then apply MIME security to these bodies in the |
|
11549 same manner as typical SIP bodies. These encapsulated SIP requests |
|
11550 and responses do not constitute a separate dialog or transaction, |
|
11551 they are a copy of the "outer" message that is used to verify |
|
11552 integrity or to supply additional information. |
|
11553 |
|
11554 If a UAS receives a request that contains a tunneled "message/sip" |
|
11555 S/MIME body, it SHOULD include a tunneled "message/sip" body in the |
|
11556 response with the same smime-type. |
|
11557 |
|
11558 Any traditional MIME bodies (such as SDP) SHOULD be attached to the |
|
11559 "inner" message so that they can also benefit from S/MIME security. |
|
11560 Note that "message/sip" bodies can be sent as a part of a MIME |
|
11561 "multipart/mixed" body if any unsecured MIME types should also be |
|
11562 transmitted in a request. |
|
11563 |
|
11564 23.4.1 Integrity and Confidentiality Properties of SIP Headers |
|
11565 |
|
11566 When the S/MIME integrity or confidentiality mechanisms are used, |
|
11567 there may be discrepancies between the values in the "inner" message |
|
11568 and values in the "outer" message. The rules for handling any such |
|
11569 differences for all of the header fields described in this document |
|
11570 are given in this section. |
|
11571 |
|
11572 Note that for the purposes of loose timestamping, all SIP messages |
|
11573 that tunnel "message/sip" SHOULD contain a Date header in both the |
|
11574 "inner" and "outer" headers. |
|
11575 |
|
11576 23.4.1.1 Integrity |
|
11577 |
|
11578 Whenever integrity checks are performed, the integrity of a header |
|
11579 field should be determined by matching the value of the header field |
|
11580 in the signed body with that in the "outer" messages using the |
|
11581 comparison rules of SIP as described in 20. |
|
11582 |
|
11583 Header fields that can be legitimately modified by proxy servers are: |
|
11584 Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- |
|
11585 Authorization. If these header fields are not intact end-to-end, |
|
11586 implementations SHOULD NOT consider this a breach of security. |
|
11587 Changes to any other header fields defined in this document |
|
11588 constitute an integrity violation; users MUST be notified of a |
|
11589 discrepancy. |
|
11590 |
|
11591 |
|
11592 |
|
11593 |
|
11594 Rosenberg, et. al. Standards Track [Page 207] |
|
11595 |
|
11596 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11597 |
|
11598 |
|
11599 23.4.1.2 Confidentiality |
|
11600 |
|
11601 When messages are encrypted, header fields may be included in the |
|
11602 encrypted body that are not present in the "outer" message. |
|
11603 |
|
11604 Some header fields must always have a plaintext version because they |
|
11605 are required header fields in requests and responses - these include: |
|
11606 |
|
11607 To, From, Call-ID, CSeq, Contact. While it is probably not useful to |
|
11608 provide an encrypted alternative for the Call-ID, CSeq, or Contact, |
|
11609 providing an alternative to the information in the "outer" To or From |
|
11610 is permitted. Note that the values in an encrypted body are not used |
|
11611 for the purposes of identifying transactions or dialogs - they are |
|
11612 merely informational. If the From header field in an encrypted body |
|
11613 differs from the value in the "outer" message, the value within the |
|
11614 encrypted body SHOULD be displayed to the user, but MUST NOT be used |
|
11615 in the "outer" header fields of any future messages. |
|
11616 |
|
11617 Primarily, a user agent will want to encrypt header fields that have |
|
11618 an end-to-end semantic, including: Subject, Reply-To, Organization, |
|
11619 Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, |
|
11620 Authentication-Info, Expires, In-Reply-To, Require, Supported, |
|
11621 Unsupported, Retry-After, User-Agent, Server, and Warning. If any of |
|
11622 these header fields are present in an encrypted body, they should be |
|
11623 used instead of any "outer" header fields, whether this entails |
|
11624 displaying the header field values to users or setting internal |
|
11625 states in the UA. They SHOULD NOT however be used in the "outer" |
|
11626 headers of any future messages. |
|
11627 |
|
11628 If present, the Date header field MUST always be the same in the |
|
11629 "inner" and "outer" headers. |
|
11630 |
|
11631 Since MIME bodies are attached to the "inner" message, |
|
11632 implementations will usually encrypt MIME-specific header fields, |
|
11633 including: MIME-Version, Content-Type, Content-Length, Content- |
|
11634 Language, Content-Encoding and Content-Disposition. The "outer" |
|
11635 message will have the proper MIME header fields for S/MIME bodies. |
|
11636 These header fields (and any MIME bodies they preface) should be |
|
11637 treated as normal MIME header fields and bodies received in a SIP |
|
11638 message. |
|
11639 |
|
11640 It is not particularly useful to encrypt the following header fields: |
|
11641 Min-Expires, Timestamp, Authorization, Priority, and WWW- |
|
11642 Authenticate. This category also includes those header fields that |
|
11643 can be changed by proxy servers (described in the preceding section). |
|
11644 UAs SHOULD never include these in an "inner" message if they are not |
|
11645 |
|
11646 |
|
11647 |
|
11648 |
|
11649 |
|
11650 Rosenberg, et. al. Standards Track [Page 208] |
|
11651 |
|
11652 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11653 |
|
11654 |
|
11655 included in the "outer" message. UAs that receive any of these |
|
11656 header fields in an encrypted body SHOULD ignore the encrypted |
|
11657 values. |
|
11658 |
|
11659 Note that extensions to SIP may define additional header fields; the |
|
11660 authors of these extensions should describe the integrity and |
|
11661 confidentiality properties of such header fields. If a SIP UA |
|
11662 encounters an unknown header field with an integrity violation, it |
|
11663 MUST ignore the header field. |
|
11664 |
|
11665 23.4.2 Tunneling Integrity and Authentication |
|
11666 |
|
11667 Tunneling SIP messages within S/MIME bodies can provide integrity for |
|
11668 SIP header fields if the header fields that the sender wishes to |
|
11669 secure are replicated in a "message/sip" MIME body signed with a CMS |
|
11670 detached signature. |
|
11671 |
|
11672 Provided that the "message/sip" body contains at least the |
|
11673 fundamental dialog identifiers (To, From, Call-ID, CSeq), then a |
|
11674 signed MIME body can provide limited authentication. At the very |
|
11675 least, if the certificate used to sign the body is unknown to the |
|
11676 recipient and cannot be verified, the signature can be used to |
|
11677 ascertain that a later request in a dialog was transmitted by the |
|
11678 same certificate-holder that initiated the dialog. If the recipient |
|
11679 of the signed MIME body has some stronger incentive to trust the |
|
11680 certificate (they were able to validate it, they acquired it from a |
|
11681 trusted repository, or they have used it frequently) then the |
|
11682 signature can be taken as a stronger assertion of the identity of the |
|
11683 subject of the certificate. |
|
11684 |
|
11685 In order to eliminate possible confusions about the addition or |
|
11686 subtraction of entire header fields, senders SHOULD replicate all |
|
11687 header fields from the request within the signed body. Any message |
|
11688 bodies that require integrity protection MUST be attached to the |
|
11689 "inner" message. |
|
11690 |
|
11691 If a Date header is present in a message with a signed body, the |
|
11692 recipient SHOULD compare the header field value with its own internal |
|
11693 clock, if applicable. If a significant time discrepancy is detected |
|
11694 (on the order of an hour or more), the user agent SHOULD alert the |
|
11695 user to the anomaly, and note that it is a potential security breach. |
|
11696 |
|
11697 If an integrity violation in a message is detected by its recipient, |
|
11698 the message MAY be rejected with a 403 (Forbidden) response if it is |
|
11699 a request, or any existing dialog MAY be terminated. UAs SHOULD |
|
11700 notify users of this circumstance and request explicit guidance on |
|
11701 how to proceed. |
|
11702 |
|
11703 |
|
11704 |
|
11705 |
|
11706 Rosenberg, et. al. Standards Track [Page 209] |
|
11707 |
|
11708 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11709 |
|
11710 |
|
11711 The following is an example of the use of a tunneled "message/sip" |
|
11712 body: |
|
11713 |
|
11714 INVITE sip:bob@biloxi.com SIP/2.0 |
|
11715 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
11716 To: Bob <sip:bob@biloxi.com> |
|
11717 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
11718 Call-ID: a84b4c76e66710 |
|
11719 CSeq: 314159 INVITE |
|
11720 Max-Forwards: 70 |
|
11721 Date: Thu, 21 Feb 2002 13:02:03 GMT |
|
11722 Contact: <sip:alice@pc33.atlanta.com> |
|
11723 Content-Type: multipart/signed; |
|
11724 protocol="application/pkcs7-signature"; |
|
11725 micalg=sha1; boundary=boundary42 |
|
11726 Content-Length: 568 |
|
11727 |
|
11728 --boundary42 |
|
11729 Content-Type: message/sip |
|
11730 |
|
11731 INVITE sip:bob@biloxi.com SIP/2.0 |
|
11732 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
11733 To: Bob <bob@biloxi.com> |
|
11734 From: Alice <alice@atlanta.com>;tag=1928301774 |
|
11735 Call-ID: a84b4c76e66710 |
|
11736 CSeq: 314159 INVITE |
|
11737 Max-Forwards: 70 |
|
11738 Date: Thu, 21 Feb 2002 13:02:03 GMT |
|
11739 Contact: <sip:alice@pc33.atlanta.com> |
|
11740 Content-Type: application/sdp |
|
11741 Content-Length: 147 |
|
11742 |
|
11743 v=0 |
|
11744 o=UserA 2890844526 2890844526 IN IP4 here.com |
|
11745 s=Session SDP |
|
11746 c=IN IP4 pc33.atlanta.com |
|
11747 t=0 0 |
|
11748 m=audio 49172 RTP/AVP 0 |
|
11749 a=rtpmap:0 PCMU/8000 |
|
11750 |
|
11751 --boundary42 |
|
11752 Content-Type: application/pkcs7-signature; name=smime.p7s |
|
11753 Content-Transfer-Encoding: base64 |
|
11754 Content-Disposition: attachment; filename=smime.p7s; |
|
11755 handling=required |
|
11756 |
|
11757 |
|
11758 |
|
11759 |
|
11760 |
|
11761 |
|
11762 Rosenberg, et. al. Standards Track [Page 210] |
|
11763 |
|
11764 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11765 |
|
11766 |
|
11767 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 |
|
11768 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj |
|
11769 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 |
|
11770 7GhIGfHfYT64VQbnj756 |
|
11771 |
|
11772 --boundary42- |
|
11773 |
|
11774 23.4.3 Tunneling Encryption |
|
11775 |
|
11776 It may also be desirable to use this mechanism to encrypt a |
|
11777 "message/sip" MIME body within a CMS EnvelopedData message S/MIME |
|
11778 body, but in practice, most header fields are of at least some use to |
|
11779 the network; the general use of encryption with S/MIME is to secure |
|
11780 message bodies like SDP rather than message headers. Some |
|
11781 informational header fields, such as the Subject or Organization |
|
11782 could perhaps warrant end-to-end security. Headers defined by future |
|
11783 SIP applications might also require obfuscation. |
|
11784 |
|
11785 Another possible application of encrypting header fields is selective |
|
11786 anonymity. A request could be constructed with a From header field |
|
11787 that contains no personal information (for example, |
|
11788 sip:anonymous@anonymizer.invalid). However, a second From header |
|
11789 field containing the genuine address-of-record of the originator |
|
11790 could be encrypted within a "message/sip" MIME body where it will |
|
11791 only be visible to the endpoints of a dialog. |
|
11792 |
|
11793 Note that if this mechanism is used for anonymity, the From header |
|
11794 field will no longer be usable by the recipient of a message as an |
|
11795 index to their certificate keychain for retrieving the proper |
|
11796 S/MIME key to associated with the sender. The message must first |
|
11797 be decrypted, and the "inner" From header field MUST be used as an |
|
11798 index. |
|
11799 |
|
11800 In order to provide end-to-end integrity, encrypted "message/sip" |
|
11801 MIME bodies SHOULD be signed by the sender. This creates a |
|
11802 "multipart/signed" MIME body that contains an encrypted body and a |
|
11803 signature, both of type "application/pkcs7-mime". |
|
11804 |
|
11805 |
|
11806 |
|
11807 |
|
11808 |
|
11809 |
|
11810 |
|
11811 |
|
11812 |
|
11813 |
|
11814 |
|
11815 |
|
11816 |
|
11817 |
|
11818 Rosenberg, et. al. Standards Track [Page 211] |
|
11819 |
|
11820 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11821 |
|
11822 |
|
11823 In the following example, of an encrypted and signed message, the |
|
11824 text boxed in asterisks ("*") is encrypted: |
|
11825 |
|
11826 INVITE sip:bob@biloxi.com SIP/2.0 |
|
11827 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
11828 To: Bob <sip:bob@biloxi.com> |
|
11829 From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774 |
|
11830 Call-ID: a84b4c76e66710 |
|
11831 CSeq: 314159 INVITE |
|
11832 Max-Forwards: 70 |
|
11833 Date: Thu, 21 Feb 2002 13:02:03 GMT |
|
11834 Contact: <sip:pc33.atlanta.com> |
|
11835 Content-Type: multipart/signed; |
|
11836 protocol="application/pkcs7-signature"; |
|
11837 micalg=sha1; boundary=boundary42 |
|
11838 Content-Length: 568 |
|
11839 |
|
11840 --boundary42 |
|
11841 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; |
|
11842 name=smime.p7m |
|
11843 Content-Transfer-Encoding: base64 |
|
11844 Content-Disposition: attachment; filename=smime.p7m |
|
11845 handling=required |
|
11846 Content-Length: 231 |
|
11847 |
|
11848 *********************************************************** |
|
11849 * Content-Type: message/sip * |
|
11850 * * |
|
11851 * INVITE sip:bob@biloxi.com SIP/2.0 * |
|
11852 * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * |
|
11853 * To: Bob <bob@biloxi.com> * |
|
11854 * From: Alice <alice@atlanta.com>;tag=1928301774 * |
|
11855 * Call-ID: a84b4c76e66710 * |
|
11856 * CSeq: 314159 INVITE * |
|
11857 * Max-Forwards: 70 * |
|
11858 * Date: Thu, 21 Feb 2002 13:02:03 GMT * |
|
11859 * Contact: <sip:alice@pc33.atlanta.com> * |
|
11860 * * |
|
11861 * Content-Type: application/sdp * |
|
11862 * * |
|
11863 * v=0 * |
|
11864 * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * |
|
11865 * s=Session SDP * |
|
11866 * t=0 0 * |
|
11867 * c=IN IP4 pc33.atlanta.com * |
|
11868 * m=audio 3456 RTP/AVP 0 1 3 99 * |
|
11869 * a=rtpmap:0 PCMU/8000 * |
|
11870 *********************************************************** |
|
11871 |
|
11872 |
|
11873 |
|
11874 Rosenberg, et. al. Standards Track [Page 212] |
|
11875 |
|
11876 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11877 |
|
11878 |
|
11879 --boundary42 |
|
11880 Content-Type: application/pkcs7-signature; name=smime.p7s |
|
11881 Content-Transfer-Encoding: base64 |
|
11882 Content-Disposition: attachment; filename=smime.p7s; |
|
11883 handling=required |
|
11884 |
|
11885 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 |
|
11886 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj |
|
11887 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 |
|
11888 7GhIGfHfYT64VQbnj756 |
|
11889 |
|
11890 --boundary42- |
|
11891 |
|
11892 24 Examples |
|
11893 |
|
11894 In the following examples, we often omit the message body and the |
|
11895 corresponding Content-Length and Content-Type header fields for |
|
11896 brevity. |
|
11897 |
|
11898 24.1 Registration |
|
11899 |
|
11900 Bob registers on start-up. The message flow is shown in Figure 9. |
|
11901 Note that the authentication usually required for registration is not |
|
11902 shown for simplicity. |
|
11903 |
|
11904 biloxi.com Bob's |
|
11905 registrar softphone |
|
11906 | | |
|
11907 | REGISTER F1 | |
|
11908 |<---------------| |
|
11909 | 200 OK F2 | |
|
11910 |--------------->| |
|
11911 |
|
11912 Figure 9: SIP Registration Example |
|
11913 |
|
11914 F1 REGISTER Bob -> Registrar |
|
11915 |
|
11916 REGISTER sip:registrar.biloxi.com SIP/2.0 |
|
11917 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 |
|
11918 Max-Forwards: 70 |
|
11919 To: Bob <sip:bob@biloxi.com> |
|
11920 From: Bob <sip:bob@biloxi.com>;tag=456248 |
|
11921 Call-ID: 843817637684230@998sdasdh09 |
|
11922 CSeq: 1826 REGISTER |
|
11923 Contact: <sip:bob@192.0.2.4> |
|
11924 Expires: 7200 |
|
11925 Content-Length: 0 |
|
11926 |
|
11927 |
|
11928 |
|
11929 |
|
11930 Rosenberg, et. al. Standards Track [Page 213] |
|
11931 |
|
11932 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11933 |
|
11934 |
|
11935 The registration expires after two hours. The registrar responds |
|
11936 with a 200 OK: |
|
11937 |
|
11938 F2 200 OK Registrar -> Bob |
|
11939 |
|
11940 SIP/2.0 200 OK |
|
11941 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 |
|
11942 ;received=192.0.2.4 |
|
11943 To: Bob <sip:bob@biloxi.com>;tag=2493k59kd |
|
11944 From: Bob <sip:bob@biloxi.com>;tag=456248 |
|
11945 Call-ID: 843817637684230@998sdasdh09 |
|
11946 CSeq: 1826 REGISTER |
|
11947 Contact: <sip:bob@192.0.2.4> |
|
11948 Expires: 7200 |
|
11949 Content-Length: 0 |
|
11950 |
|
11951 24.2 Session Setup |
|
11952 |
|
11953 This example contains the full details of the example session setup |
|
11954 in Section 4. The message flow is shown in Figure 1. Note that |
|
11955 these flows show the minimum required set of header fields - some |
|
11956 other header fields such as Allow and Supported would normally be |
|
11957 present. |
|
11958 |
|
11959 F1 INVITE Alice -> atlanta.com proxy |
|
11960 |
|
11961 INVITE sip:bob@biloxi.com SIP/2.0 |
|
11962 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
11963 Max-Forwards: 70 |
|
11964 To: Bob <sip:bob@biloxi.com> |
|
11965 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
11966 Call-ID: a84b4c76e66710 |
|
11967 CSeq: 314159 INVITE |
|
11968 Contact: <sip:alice@pc33.atlanta.com> |
|
11969 Content-Type: application/sdp |
|
11970 Content-Length: 142 |
|
11971 |
|
11972 (Alice's SDP not shown) |
|
11973 |
|
11974 |
|
11975 |
|
11976 |
|
11977 |
|
11978 |
|
11979 |
|
11980 |
|
11981 |
|
11982 |
|
11983 |
|
11984 |
|
11985 |
|
11986 Rosenberg, et. al. Standards Track [Page 214] |
|
11987 |
|
11988 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
11989 |
|
11990 |
|
11991 F2 100 Trying atlanta.com proxy -> Alice |
|
11992 |
|
11993 SIP/2.0 100 Trying |
|
11994 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
11995 ;received=192.0.2.1 |
|
11996 To: Bob <sip:bob@biloxi.com> |
|
11997 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
11998 Call-ID: a84b4c76e66710 |
|
11999 CSeq: 314159 INVITE |
|
12000 Content-Length: 0 |
|
12001 |
|
12002 F3 INVITE atlanta.com proxy -> biloxi.com proxy |
|
12003 |
|
12004 INVITE sip:bob@biloxi.com SIP/2.0 |
|
12005 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 |
|
12006 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
12007 ;received=192.0.2.1 |
|
12008 Max-Forwards: 69 |
|
12009 To: Bob <sip:bob@biloxi.com> |
|
12010 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12011 Call-ID: a84b4c76e66710 |
|
12012 CSeq: 314159 INVITE |
|
12013 Contact: <sip:alice@pc33.atlanta.com> |
|
12014 Content-Type: application/sdp |
|
12015 Content-Length: 142 |
|
12016 |
|
12017 (Alice's SDP not shown) |
|
12018 |
|
12019 F4 100 Trying biloxi.com proxy -> atlanta.com proxy |
|
12020 |
|
12021 SIP/2.0 100 Trying |
|
12022 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 |
|
12023 ;received=192.0.2.2 |
|
12024 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
12025 ;received=192.0.2.1 |
|
12026 To: Bob <sip:bob@biloxi.com> |
|
12027 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12028 Call-ID: a84b4c76e66710 |
|
12029 CSeq: 314159 INVITE |
|
12030 Content-Length: 0 |
|
12031 |
|
12032 |
|
12033 |
|
12034 |
|
12035 |
|
12036 |
|
12037 |
|
12038 |
|
12039 |
|
12040 |
|
12041 |
|
12042 Rosenberg, et. al. Standards Track [Page 215] |
|
12043 |
|
12044 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12045 |
|
12046 |
|
12047 F5 INVITE biloxi.com proxy -> Bob |
|
12048 |
|
12049 INVITE sip:bob@192.0.2.4 SIP/2.0 |
|
12050 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 |
|
12051 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 |
|
12052 ;received=192.0.2.2 |
|
12053 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
12054 ;received=192.0.2.1 |
|
12055 Max-Forwards: 68 |
|
12056 To: Bob <sip:bob@biloxi.com> |
|
12057 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12058 Call-ID: a84b4c76e66710 |
|
12059 CSeq: 314159 INVITE |
|
12060 Contact: <sip:alice@pc33.atlanta.com> |
|
12061 Content-Type: application/sdp |
|
12062 Content-Length: 142 |
|
12063 |
|
12064 (Alice's SDP not shown) |
|
12065 |
|
12066 F6 180 Ringing Bob -> biloxi.com proxy |
|
12067 |
|
12068 SIP/2.0 180 Ringing |
|
12069 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 |
|
12070 ;received=192.0.2.3 |
|
12071 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 |
|
12072 ;received=192.0.2.2 |
|
12073 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
12074 ;received=192.0.2.1 |
|
12075 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
12076 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12077 Call-ID: a84b4c76e66710 |
|
12078 Contact: <sip:bob@192.0.2.4> |
|
12079 CSeq: 314159 INVITE |
|
12080 Content-Length: 0 |
|
12081 |
|
12082 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy |
|
12083 |
|
12084 SIP/2.0 180 Ringing |
|
12085 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 |
|
12086 ;received=192.0.2.2 |
|
12087 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
12088 ;received=192.0.2.1 |
|
12089 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
12090 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12091 Call-ID: a84b4c76e66710 |
|
12092 Contact: <sip:bob@192.0.2.4> |
|
12093 CSeq: 314159 INVITE |
|
12094 Content-Length: 0 |
|
12095 |
|
12096 |
|
12097 |
|
12098 Rosenberg, et. al. Standards Track [Page 216] |
|
12099 |
|
12100 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12101 |
|
12102 |
|
12103 F8 180 Ringing atlanta.com proxy -> Alice |
|
12104 |
|
12105 SIP/2.0 180 Ringing |
|
12106 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
12107 ;received=192.0.2.1 |
|
12108 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
12109 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12110 Call-ID: a84b4c76e66710 |
|
12111 Contact: <sip:bob@192.0.2.4> |
|
12112 CSeq: 314159 INVITE |
|
12113 Content-Length: 0 |
|
12114 |
|
12115 F9 200 OK Bob -> biloxi.com proxy |
|
12116 |
|
12117 SIP/2.0 200 OK |
|
12118 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 |
|
12119 ;received=192.0.2.3 |
|
12120 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 |
|
12121 ;received=192.0.2.2 |
|
12122 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
12123 ;received=192.0.2.1 |
|
12124 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
12125 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12126 Call-ID: a84b4c76e66710 |
|
12127 CSeq: 314159 INVITE |
|
12128 Contact: <sip:bob@192.0.2.4> |
|
12129 Content-Type: application/sdp |
|
12130 Content-Length: 131 |
|
12131 |
|
12132 (Bob's SDP not shown) |
|
12133 |
|
12134 F10 200 OK biloxi.com proxy -> atlanta.com proxy |
|
12135 |
|
12136 SIP/2.0 200 OK |
|
12137 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 |
|
12138 ;received=192.0.2.2 |
|
12139 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
12140 ;received=192.0.2.1 |
|
12141 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
12142 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12143 Call-ID: a84b4c76e66710 |
|
12144 CSeq: 314159 INVITE |
|
12145 Contact: <sip:bob@192.0.2.4> |
|
12146 Content-Type: application/sdp |
|
12147 Content-Length: 131 |
|
12148 |
|
12149 (Bob's SDP not shown) |
|
12150 |
|
12151 |
|
12152 |
|
12153 |
|
12154 Rosenberg, et. al. Standards Track [Page 217] |
|
12155 |
|
12156 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12157 |
|
12158 |
|
12159 F11 200 OK atlanta.com proxy -> Alice |
|
12160 |
|
12161 SIP/2.0 200 OK |
|
12162 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 |
|
12163 ;received=192.0.2.1 |
|
12164 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
12165 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12166 Call-ID: a84b4c76e66710 |
|
12167 CSeq: 314159 INVITE |
|
12168 Contact: <sip:bob@192.0.2.4> |
|
12169 Content-Type: application/sdp |
|
12170 Content-Length: 131 |
|
12171 |
|
12172 (Bob's SDP not shown) |
|
12173 |
|
12174 F12 ACK Alice -> Bob |
|
12175 |
|
12176 ACK sip:bob@192.0.2.4 SIP/2.0 |
|
12177 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 |
|
12178 Max-Forwards: 70 |
|
12179 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
12180 From: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12181 Call-ID: a84b4c76e66710 |
|
12182 CSeq: 314159 ACK |
|
12183 Content-Length: 0 |
|
12184 |
|
12185 The media session between Alice and Bob is now established. |
|
12186 |
|
12187 Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq |
|
12188 numbering space, which, in this example, begins with 231. Since Bob |
|
12189 is making the request, the To and From URIs and tags have been |
|
12190 swapped. |
|
12191 |
|
12192 F13 BYE Bob -> Alice |
|
12193 |
|
12194 BYE sip:alice@pc33.atlanta.com SIP/2.0 |
|
12195 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 |
|
12196 Max-Forwards: 70 |
|
12197 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
12198 To: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12199 Call-ID: a84b4c76e66710 |
|
12200 CSeq: 231 BYE |
|
12201 Content-Length: 0 |
|
12202 |
|
12203 |
|
12204 |
|
12205 |
|
12206 |
|
12207 |
|
12208 |
|
12209 |
|
12210 Rosenberg, et. al. Standards Track [Page 218] |
|
12211 |
|
12212 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12213 |
|
12214 |
|
12215 F14 200 OK Alice -> Bob |
|
12216 |
|
12217 SIP/2.0 200 OK |
|
12218 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 |
|
12219 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf |
|
12220 To: Alice <sip:alice@atlanta.com>;tag=1928301774 |
|
12221 Call-ID: a84b4c76e66710 |
|
12222 CSeq: 231 BYE |
|
12223 Content-Length: 0 |
|
12224 |
|
12225 The SIP Call Flows document [40] contains further examples of SIP |
|
12226 messages. |
|
12227 |
|
12228 25 Augmented BNF for the SIP Protocol |
|
12229 |
|
12230 All of the mechanisms specified in this document are described in |
|
12231 both prose and an augmented Backus-Naur Form (BNF) defined in RFC |
|
12232 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that |
|
12233 are used by this specification, and not repeated here. Implementers |
|
12234 need to be familiar with the notation and content of RFC 2234 in |
|
12235 order to understand this specification. Certain basic rules are in |
|
12236 uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle |
|
12237 brackets are used within definitions to clarify the use of rule |
|
12238 names. |
|
12239 |
|
12240 The use of square brackets is redundant syntactically. It is used as |
|
12241 a semantic hint that the specific parameter is optional to use. |
|
12242 |
|
12243 25.1 Basic Rules |
|
12244 |
|
12245 The following rules are used throughout this specification to |
|
12246 describe basic parsing constructs. The US-ASCII coded character set |
|
12247 is defined by ANSI X3.4-1986. |
|
12248 |
|
12249 alphanum = ALPHA / DIGIT |
|
12250 |
|
12251 |
|
12252 |
|
12253 |
|
12254 |
|
12255 |
|
12256 |
|
12257 |
|
12258 |
|
12259 |
|
12260 |
|
12261 |
|
12262 |
|
12263 |
|
12264 |
|
12265 |
|
12266 Rosenberg, et. al. Standards Track [Page 219] |
|
12267 |
|
12268 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12269 |
|
12270 |
|
12271 Several rules are incorporated from RFC 2396 [5] but are updated to |
|
12272 make them compliant with RFC 2234 [10]. These include: |
|
12273 |
|
12274 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" |
|
12275 / "$" / "," |
|
12276 unreserved = alphanum / mark |
|
12277 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" |
|
12278 / "(" / ")" |
|
12279 escaped = "%" HEXDIG HEXDIG |
|
12280 |
|
12281 SIP header field values can be folded onto multiple lines if the |
|
12282 continuation line begins with a space or horizontal tab. All linear |
|
12283 white space, including folding, has the same semantics as SP. A |
|
12284 recipient MAY replace any linear white space with a single SP before |
|
12285 interpreting the field value or forwarding the message downstream. |
|
12286 This is intended to behave exactly as HTTP/1.1 as described in RFC |
|
12287 2616 [8]. The SWS construct is used when linear white space is |
|
12288 optional, generally between tokens and separators. |
|
12289 |
|
12290 LWS = [*WSP CRLF] 1*WSP ; linear whitespace |
|
12291 SWS = [LWS] ; sep whitespace |
|
12292 |
|
12293 To separate the header name from the rest of value, a colon is used, |
|
12294 which, by the above rule, allows whitespace before, but no line |
|
12295 break, and whitespace after, including a linebreak. The HCOLON |
|
12296 defines this construct. |
|
12297 |
|
12298 HCOLON = *( SP / HTAB ) ":" SWS |
|
12299 |
|
12300 The TEXT-UTF8 rule is only used for descriptive field contents and |
|
12301 values that are not intended to be interpreted by the message parser. |
|
12302 Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC |
|
12303 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field |
|
12304 contents that are n t quoted strings, where leading and trailing LWS |
|
12305 is not meaningful. In this regard, SIP differs from HTTP, which uses |
|
12306 the ISO 8859-1 character set. |
|
12307 |
|
12308 TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) |
|
12309 TEXT-UTF8char = %x21-7E / UTF8-NONASCII |
|
12310 UTF8-NONASCII = %xC0-DF 1UTF8-CONT |
|
12311 / %xE0-EF 2UTF8-CONT |
|
12312 / %xF0-F7 3UTF8-CONT |
|
12313 / %xF8-Fb 4UTF8-CONT |
|
12314 / %xFC-FD 5UTF8-CONT |
|
12315 UTF8-CONT = %x80-BF |
|
12316 |
|
12317 |
|
12318 |
|
12319 |
|
12320 |
|
12321 |
|
12322 Rosenberg, et. al. Standards Track [Page 220] |
|
12323 |
|
12324 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12325 |
|
12326 |
|
12327 A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of |
|
12328 a header field continuation. It is expected that the folding LWS |
|
12329 will be replaced with a single SP before interpretation of the TEXT- |
|
12330 UTF8-TRIM value. |
|
12331 |
|
12332 Hexadecimal numeric characters are used in several protocol elements. |
|
12333 Some elements (authentication) force hex alphas to be lower case. |
|
12334 |
|
12335 LHEX = DIGIT / %x61-66 ;lowercase a-f |
|
12336 |
|
12337 Many SIP header field values consist of words separated by LWS or |
|
12338 special characters. Unless otherwise stated, tokens are case- |
|
12339 insensitive. These special characters MUST be in a quoted string to |
|
12340 be used within a parameter value. The word construct is used in |
|
12341 Call-ID to allow most separators to be used. |
|
12342 |
|
12343 token = 1*(alphanum / "-" / "." / "!" / "%" / "*" |
|
12344 / "_" / "+" / "`" / "'" / "~" ) |
|
12345 separators = "(" / ")" / "<" / ">" / "@" / |
|
12346 "," / ";" / ":" / "\" / DQUOTE / |
|
12347 "/" / "[" / "]" / "?" / "=" / |
|
12348 "{" / "}" / SP / HTAB |
|
12349 word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / |
|
12350 "_" / "+" / "`" / "'" / "~" / |
|
12351 "(" / ")" / "<" / ">" / |
|
12352 ":" / "\" / DQUOTE / |
|
12353 "/" / "[" / "]" / "?" / |
|
12354 "{" / "}" ) |
|
12355 |
|
12356 When tokens are used or separators are used between elements, |
|
12357 whitespace is often allowed before or after these characters: |
|
12358 |
|
12359 STAR = SWS "*" SWS ; asterisk |
|
12360 SLASH = SWS "/" SWS ; slash |
|
12361 EQUAL = SWS "=" SWS ; equal |
|
12362 LPAREN = SWS "(" SWS ; left parenthesis |
|
12363 RPAREN = SWS ")" SWS ; right parenthesis |
|
12364 RAQUOT = ">" SWS ; right angle quote |
|
12365 LAQUOT = SWS "<"; left angle quote |
|
12366 COMMA = SWS "," SWS ; comma |
|
12367 SEMI = SWS ";" SWS ; semicolon |
|
12368 COLON = SWS ":" SWS ; colon |
|
12369 LDQUOT = SWS DQUOTE; open double quotation mark |
|
12370 RDQUOT = DQUOTE SWS ; close double quotation mark |
|
12371 |
|
12372 |
|
12373 |
|
12374 |
|
12375 |
|
12376 |
|
12377 |
|
12378 Rosenberg, et. al. Standards Track [Page 221] |
|
12379 |
|
12380 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12381 |
|
12382 |
|
12383 Comments can be included in some SIP header fields by surrounding the |
|
12384 comment text with parentheses. Comments are only allowed in fields |
|
12385 containing "comment" as part of their field value definition. In all |
|
12386 other fields, parentheses are considered part of the field value. |
|
12387 |
|
12388 comment = LPAREN *(ctext / quoted-pair / comment) RPAREN |
|
12389 ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII |
|
12390 / LWS |
|
12391 |
|
12392 ctext includes all chars except left and right parens and backslash. |
|
12393 A string of text is parsed as a single word if it is quoted using |
|
12394 double-quote marks. In quoted strings, quotation marks (") and |
|
12395 backslashes (\) need to be escaped. |
|
12396 |
|
12397 quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE |
|
12398 qdtext = LWS / %x21 / %x23-5B / %x5D-7E |
|
12399 / UTF8-NONASCII |
|
12400 |
|
12401 The backslash character ("\") MAY be used as a single-character |
|
12402 quoting mechanism only within quoted-string and comment constructs. |
|
12403 Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this |
|
12404 mechanism to avoid conflict with line folding and header separation. |
|
12405 |
|
12406 quoted-pair = "\" (%x00-09 / %x0B-0C |
|
12407 / %x0E-7F) |
|
12408 |
|
12409 SIP-URI = "sip:" [ userinfo ] hostport |
|
12410 uri-parameters [ headers ] |
|
12411 SIPS-URI = "sips:" [ userinfo ] hostport |
|
12412 uri-parameters [ headers ] |
|
12413 userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" |
|
12414 user = 1*( unreserved / escaped / user-unreserved ) |
|
12415 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" |
|
12416 password = *( unreserved / escaped / |
|
12417 "&" / "=" / "+" / "$" / "," ) |
|
12418 hostport = host [ ":" port ] |
|
12419 host = hostname / IPv4address / IPv6reference |
|
12420 hostname = *( domainlabel "." ) toplabel [ "." ] |
|
12421 domainlabel = alphanum |
|
12422 / alphanum *( alphanum / "-" ) alphanum |
|
12423 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum |
|
12424 |
|
12425 |
|
12426 |
|
12427 |
|
12428 |
|
12429 |
|
12430 |
|
12431 |
|
12432 |
|
12433 |
|
12434 Rosenberg, et. al. Standards Track [Page 222] |
|
12435 |
|
12436 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12437 |
|
12438 |
|
12439 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT |
|
12440 IPv6reference = "[" IPv6address "]" |
|
12441 IPv6address = hexpart [ ":" IPv4address ] |
|
12442 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] |
|
12443 hexseq = hex4 *( ":" hex4) |
|
12444 hex4 = 1*4HEXDIG |
|
12445 port = 1*DIGIT |
|
12446 |
|
12447 The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, |
|
12448 however, that any characters allowed there that are not allowed in |
|
12449 the user part of the SIP URI MUST be escaped. |
|
12450 |
|
12451 uri-parameters = *( ";" uri-parameter) |
|
12452 uri-parameter = transport-param / user-param / method-param |
|
12453 / ttl-param / maddr-param / lr-param / other-param |
|
12454 transport-param = "transport=" |
|
12455 ( "udp" / "tcp" / "sctp" / "tls" |
|
12456 / other-transport) |
|
12457 other-transport = token |
|
12458 user-param = "user=" ( "phone" / "ip" / other-user) |
|
12459 other-user = token |
|
12460 method-param = "method=" Method |
|
12461 ttl-param = "ttl=" ttl |
|
12462 maddr-param = "maddr=" host |
|
12463 lr-param = "lr" |
|
12464 other-param = pname [ "=" pvalue ] |
|
12465 pname = 1*paramchar |
|
12466 pvalue = 1*paramchar |
|
12467 paramchar = param-unreserved / unreserved / escaped |
|
12468 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" |
|
12469 |
|
12470 headers = "?" header *( "&" header ) |
|
12471 header = hname "=" hvalue |
|
12472 hname = 1*( hnv-unreserved / unreserved / escaped ) |
|
12473 hvalue = *( hnv-unreserved / unreserved / escaped ) |
|
12474 hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" |
|
12475 |
|
12476 SIP-message = Request / Response |
|
12477 Request = Request-Line |
|
12478 *( message-header ) |
|
12479 CRLF |
|
12480 [ message-body ] |
|
12481 Request-Line = Method SP Request-URI SP SIP-Version CRLF |
|
12482 Request-URI = SIP-URI / SIPS-URI / absoluteURI |
|
12483 absoluteURI = scheme ":" ( hier-part / opaque-part ) |
|
12484 hier-part = ( net-path / abs-path ) [ "?" query ] |
|
12485 net-path = "//" authority [ abs-path ] |
|
12486 abs-path = "/" path-segments |
|
12487 |
|
12488 |
|
12489 |
|
12490 Rosenberg, et. al. Standards Track [Page 223] |
|
12491 |
|
12492 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12493 |
|
12494 |
|
12495 opaque-part = uric-no-slash *uric |
|
12496 uric = reserved / unreserved / escaped |
|
12497 uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" |
|
12498 / "&" / "=" / "+" / "$" / "," |
|
12499 path-segments = segment *( "/" segment ) |
|
12500 segment = *pchar *( ";" param ) |
|
12501 param = *pchar |
|
12502 pchar = unreserved / escaped / |
|
12503 ":" / "@" / "&" / "=" / "+" / "$" / "," |
|
12504 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) |
|
12505 authority = srvr / reg-name |
|
12506 srvr = [ [ userinfo "@" ] hostport ] |
|
12507 reg-name = 1*( unreserved / escaped / "$" / "," |
|
12508 / ";" / ":" / "@" / "&" / "=" / "+" ) |
|
12509 query = *uric |
|
12510 SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT |
|
12511 |
|
12512 message-header = (Accept |
|
12513 / Accept-Encoding |
|
12514 / Accept-Language |
|
12515 / Alert-Info |
|
12516 / Allow |
|
12517 / Authentication-Info |
|
12518 / Authorization |
|
12519 / Call-ID |
|
12520 / Call-Info |
|
12521 / Contact |
|
12522 / Content-Disposition |
|
12523 / Content-Encoding |
|
12524 / Content-Language |
|
12525 / Content-Length |
|
12526 / Content-Type |
|
12527 / CSeq |
|
12528 / Date |
|
12529 / Error-Info |
|
12530 / Expires |
|
12531 / From |
|
12532 / In-Reply-To |
|
12533 / Max-Forwards |
|
12534 / MIME-Version |
|
12535 / Min-Expires |
|
12536 / Organization |
|
12537 / Priority |
|
12538 / Proxy-Authenticate |
|
12539 / Proxy-Authorization |
|
12540 / Proxy-Require |
|
12541 / Record-Route |
|
12542 / Reply-To |
|
12543 |
|
12544 |
|
12545 |
|
12546 Rosenberg, et. al. Standards Track [Page 224] |
|
12547 |
|
12548 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12549 |
|
12550 |
|
12551 / Require |
|
12552 / Retry-After |
|
12553 / Route |
|
12554 / Server |
|
12555 / Subject |
|
12556 / Supported |
|
12557 / Timestamp |
|
12558 / To |
|
12559 / Unsupported |
|
12560 / User-Agent |
|
12561 / Via |
|
12562 / Warning |
|
12563 / WWW-Authenticate |
|
12564 / extension-header) CRLF |
|
12565 |
|
12566 INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps |
|
12567 ACKm = %x41.43.4B ; ACK in caps |
|
12568 OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps |
|
12569 BYEm = %x42.59.45 ; BYE in caps |
|
12570 CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps |
|
12571 REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps |
|
12572 Method = INVITEm / ACKm / OPTIONSm / BYEm |
|
12573 / CANCELm / REGISTERm |
|
12574 / extension-method |
|
12575 extension-method = token |
|
12576 Response = Status-Line |
|
12577 *( message-header ) |
|
12578 CRLF |
|
12579 [ message-body ] |
|
12580 |
|
12581 Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF |
|
12582 Status-Code = Informational |
|
12583 / Redirection |
|
12584 / Success |
|
12585 / Client-Error |
|
12586 / Server-Error |
|
12587 / Global-Failure |
|
12588 / extension-code |
|
12589 extension-code = 3DIGIT |
|
12590 Reason-Phrase = *(reserved / unreserved / escaped |
|
12591 / UTF8-NONASCII / UTF8-CONT / SP / HTAB) |
|
12592 |
|
12593 Informational = "100" ; Trying |
|
12594 / "180" ; Ringing |
|
12595 / "181" ; Call Is Being Forwarded |
|
12596 / "182" ; Queued |
|
12597 / "183" ; Session Progress |
|
12598 |
|
12599 |
|
12600 |
|
12601 |
|
12602 Rosenberg, et. al. Standards Track [Page 225] |
|
12603 |
|
12604 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12605 |
|
12606 |
|
12607 Success = "200" ; OK |
|
12608 |
|
12609 Redirection = "300" ; Multiple Choices |
|
12610 / "301" ; Moved Permanently |
|
12611 / "302" ; Moved Temporarily |
|
12612 / "305" ; Use Proxy |
|
12613 / "380" ; Alternative Service |
|
12614 |
|
12615 Client-Error = "400" ; Bad Request |
|
12616 / "401" ; Unauthorized |
|
12617 / "402" ; Payment Required |
|
12618 / "403" ; Forbidden |
|
12619 / "404" ; Not Found |
|
12620 / "405" ; Method Not Allowed |
|
12621 / "406" ; Not Acceptable |
|
12622 / "407" ; Proxy Authentication Required |
|
12623 / "408" ; Request Timeout |
|
12624 / "410" ; Gone |
|
12625 / "413" ; Request Entity Too Large |
|
12626 / "414" ; Request-URI Too Large |
|
12627 / "415" ; Unsupported Media Type |
|
12628 / "416" ; Unsupported URI Scheme |
|
12629 / "420" ; Bad Extension |
|
12630 / "421" ; Extension Required |
|
12631 / "423" ; Interval Too Brief |
|
12632 / "480" ; Temporarily not available |
|
12633 / "481" ; Call Leg/Transaction Does Not Exist |
|
12634 / "482" ; Loop Detected |
|
12635 / "483" ; Too Many Hops |
|
12636 / "484" ; Address Incomplete |
|
12637 / "485" ; Ambiguous |
|
12638 / "486" ; Busy Here |
|
12639 / "487" ; Request Terminated |
|
12640 / "488" ; Not Acceptable Here |
|
12641 / "491" ; Request Pending |
|
12642 / "493" ; Undecipherable |
|
12643 |
|
12644 Server-Error = "500" ; Internal Server Error |
|
12645 / "501" ; Not Implemented |
|
12646 / "502" ; Bad Gateway |
|
12647 / "503" ; Service Unavailable |
|
12648 / "504" ; Server Time-out |
|
12649 / "505" ; SIP Version not supported |
|
12650 / "513" ; Message Too Large |
|
12651 |
|
12652 |
|
12653 |
|
12654 |
|
12655 |
|
12656 |
|
12657 |
|
12658 Rosenberg, et. al. Standards Track [Page 226] |
|
12659 |
|
12660 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12661 |
|
12662 |
|
12663 Global-Failure = "600" ; Busy Everywhere |
|
12664 / "603" ; Decline |
|
12665 / "604" ; Does not exist anywhere |
|
12666 / "606" ; Not Acceptable |
|
12667 |
|
12668 Accept = "Accept" HCOLON |
|
12669 [ accept-range *(COMMA accept-range) ] |
|
12670 accept-range = media-range *(SEMI accept-param) |
|
12671 media-range = ( "*/*" |
|
12672 / ( m-type SLASH "*" ) |
|
12673 / ( m-type SLASH m-subtype ) |
|
12674 ) *( SEMI m-parameter ) |
|
12675 accept-param = ("q" EQUAL qvalue) / generic-param |
|
12676 qvalue = ( "0" [ "." 0*3DIGIT ] ) |
|
12677 / ( "1" [ "." 0*3("0") ] ) |
|
12678 generic-param = token [ EQUAL gen-value ] |
|
12679 gen-value = token / host / quoted-string |
|
12680 |
|
12681 Accept-Encoding = "Accept-Encoding" HCOLON |
|
12682 [ encoding *(COMMA encoding) ] |
|
12683 encoding = codings *(SEMI accept-param) |
|
12684 codings = content-coding / "*" |
|
12685 content-coding = token |
|
12686 |
|
12687 Accept-Language = "Accept-Language" HCOLON |
|
12688 [ language *(COMMA language) ] |
|
12689 language = language-range *(SEMI accept-param) |
|
12690 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) |
|
12691 |
|
12692 Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param) |
|
12693 alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) |
|
12694 |
|
12695 Allow = "Allow" HCOLON [Method *(COMMA Method)] |
|
12696 |
|
12697 Authorization = "Authorization" HCOLON credentials |
|
12698 credentials = ("Digest" LWS digest-response) |
|
12699 / other-response |
|
12700 digest-response = dig-resp *(COMMA dig-resp) |
|
12701 dig-resp = username / realm / nonce / digest-uri |
|
12702 / dresponse / algorithm / cnonce |
|
12703 / opaque / message-qop |
|
12704 / nonce-count / auth-param |
|
12705 username = "username" EQUAL username-value |
|
12706 username-value = quoted-string |
|
12707 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT |
|
12708 digest-uri-value = rquest-uri ; Equal to request-uri as specified |
|
12709 by HTTP/1.1 |
|
12710 message-qop = "qop" EQUAL qop-value |
|
12711 |
|
12712 |
|
12713 |
|
12714 Rosenberg, et. al. Standards Track [Page 227] |
|
12715 |
|
12716 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12717 |
|
12718 |
|
12719 cnonce = "cnonce" EQUAL cnonce-value |
|
12720 cnonce-value = nonce-value |
|
12721 nonce-count = "nc" EQUAL nc-value |
|
12722 nc-value = 8LHEX |
|
12723 dresponse = "response" EQUAL request-digest |
|
12724 request-digest = LDQUOT 32LHEX RDQUOT |
|
12725 auth-param = auth-param-name EQUAL |
|
12726 ( token / quoted-string ) |
|
12727 auth-param-name = token |
|
12728 other-response = auth-scheme LWS auth-param |
|
12729 *(COMMA auth-param) |
|
12730 auth-scheme = token |
|
12731 |
|
12732 Authentication-Info = "Authentication-Info" HCOLON ainfo |
|
12733 *(COMMA ainfo) |
|
12734 ainfo = nextnonce / message-qop |
|
12735 / response-auth / cnonce |
|
12736 / nonce-count |
|
12737 nextnonce = "nextnonce" EQUAL nonce-value |
|
12738 response-auth = "rspauth" EQUAL response-digest |
|
12739 response-digest = LDQUOT *LHEX RDQUOT |
|
12740 |
|
12741 Call-ID = ( "Call-ID" / "i" ) HCOLON callid |
|
12742 callid = word [ "@" word ] |
|
12743 |
|
12744 Call-Info = "Call-Info" HCOLON info *(COMMA info) |
|
12745 info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) |
|
12746 info-param = ( "purpose" EQUAL ( "icon" / "info" |
|
12747 / "card" / token ) ) / generic-param |
|
12748 |
|
12749 Contact = ("Contact" / "m" ) HCOLON |
|
12750 ( STAR / (contact-param *(COMMA contact-param))) |
|
12751 contact-param = (name-addr / addr-spec) *(SEMI contact-params) |
|
12752 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT |
|
12753 addr-spec = SIP-URI / SIPS-URI / absoluteURI |
|
12754 display-name = *(token LWS)/ quoted-string |
|
12755 |
|
12756 contact-params = c-p-q / c-p-expires |
|
12757 / contact-extension |
|
12758 c-p-q = "q" EQUAL qvalue |
|
12759 c-p-expires = "expires" EQUAL delta-seconds |
|
12760 contact-extension = generic-param |
|
12761 delta-seconds = 1*DIGIT |
|
12762 |
|
12763 Content-Disposition = "Content-Disposition" HCOLON |
|
12764 disp-type *( SEMI disp-param ) |
|
12765 disp-type = "render" / "session" / "icon" / "alert" |
|
12766 / disp-extension-token |
|
12767 |
|
12768 |
|
12769 |
|
12770 Rosenberg, et. al. Standards Track [Page 228] |
|
12771 |
|
12772 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12773 |
|
12774 |
|
12775 disp-param = handling-param / generic-param |
|
12776 handling-param = "handling" EQUAL |
|
12777 ( "optional" / "required" |
|
12778 / other-handling ) |
|
12779 other-handling = token |
|
12780 disp-extension-token = token |
|
12781 |
|
12782 Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON |
|
12783 content-coding *(COMMA content-coding) |
|
12784 |
|
12785 Content-Language = "Content-Language" HCOLON |
|
12786 language-tag *(COMMA language-tag) |
|
12787 language-tag = primary-tag *( "-" subtag ) |
|
12788 primary-tag = 1*8ALPHA |
|
12789 subtag = 1*8ALPHA |
|
12790 |
|
12791 Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT |
|
12792 Content-Type = ( "Content-Type" / "c" ) HCOLON media-type |
|
12793 media-type = m-type SLASH m-subtype *(SEMI m-parameter) |
|
12794 m-type = discrete-type / composite-type |
|
12795 discrete-type = "text" / "image" / "audio" / "video" |
|
12796 / "application" / extension-token |
|
12797 composite-type = "message" / "multipart" / extension-token |
|
12798 extension-token = ietf-token / x-token |
|
12799 ietf-token = token |
|
12800 x-token = "x-" token |
|
12801 m-subtype = extension-token / iana-token |
|
12802 iana-token = token |
|
12803 m-parameter = m-attribute EQUAL m-value |
|
12804 m-attribute = token |
|
12805 m-value = token / quoted-string |
|
12806 |
|
12807 CSeq = "CSeq" HCOLON 1*DIGIT LWS Method |
|
12808 |
|
12809 Date = "Date" HCOLON SIP-date |
|
12810 SIP-date = rfc1123-date |
|
12811 rfc1123-date = wkday "," SP date1 SP time SP "GMT" |
|
12812 date1 = 2DIGIT SP month SP 4DIGIT |
|
12813 ; day month year (e.g., 02 Jun 1982) |
|
12814 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |
|
12815 ; 00:00:00 - 23:59:59 |
|
12816 wkday = "Mon" / "Tue" / "Wed" |
|
12817 / "Thu" / "Fri" / "Sat" / "Sun" |
|
12818 month = "Jan" / "Feb" / "Mar" / "Apr" |
|
12819 / "May" / "Jun" / "Jul" / "Aug" |
|
12820 / "Sep" / "Oct" / "Nov" / "Dec" |
|
12821 |
|
12822 Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri) |
|
12823 |
|
12824 |
|
12825 |
|
12826 Rosenberg, et. al. Standards Track [Page 229] |
|
12827 |
|
12828 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12829 |
|
12830 |
|
12831 error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) |
|
12832 |
|
12833 Expires = "Expires" HCOLON delta-seconds |
|
12834 From = ( "From" / "f" ) HCOLON from-spec |
|
12835 from-spec = ( name-addr / addr-spec ) |
|
12836 *( SEMI from-param ) |
|
12837 from-param = tag-param / generic-param |
|
12838 tag-param = "tag" EQUAL token |
|
12839 |
|
12840 In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid) |
|
12841 |
|
12842 Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT |
|
12843 |
|
12844 MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT |
|
12845 |
|
12846 Min-Expires = "Min-Expires" HCOLON delta-seconds |
|
12847 |
|
12848 Organization = "Organization" HCOLON [TEXT-UTF8-TRIM] |
|
12849 |
|
12850 Priority = "Priority" HCOLON priority-value |
|
12851 priority-value = "emergency" / "urgent" / "normal" |
|
12852 / "non-urgent" / other-priority |
|
12853 other-priority = token |
|
12854 |
|
12855 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge |
|
12856 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) |
|
12857 / other-challenge |
|
12858 other-challenge = auth-scheme LWS auth-param |
|
12859 *(COMMA auth-param) |
|
12860 digest-cln = realm / domain / nonce |
|
12861 / opaque / stale / algorithm |
|
12862 / qop-options / auth-param |
|
12863 realm = "realm" EQUAL realm-value |
|
12864 realm-value = quoted-string |
|
12865 domain = "domain" EQUAL LDQUOT URI |
|
12866 *( 1*SP URI ) RDQUOT |
|
12867 URI = absoluteURI / abs-path |
|
12868 nonce = "nonce" EQUAL nonce-value |
|
12869 nonce-value = quoted-string |
|
12870 opaque = "opaque" EQUAL quoted-string |
|
12871 stale = "stale" EQUAL ( "true" / "false" ) |
|
12872 algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" |
|
12873 / token ) |
|
12874 qop-options = "qop" EQUAL LDQUOT qop-value |
|
12875 *("," qop-value) RDQUOT |
|
12876 qop-value = "auth" / "auth-int" / token |
|
12877 |
|
12878 Proxy-Authorization = "Proxy-Authorization" HCOLON credentials |
|
12879 |
|
12880 |
|
12881 |
|
12882 Rosenberg, et. al. Standards Track [Page 230] |
|
12883 |
|
12884 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12885 |
|
12886 |
|
12887 Proxy-Require = "Proxy-Require" HCOLON option-tag |
|
12888 *(COMMA option-tag) |
|
12889 option-tag = token |
|
12890 |
|
12891 Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) |
|
12892 rec-route = name-addr *( SEMI rr-param ) |
|
12893 rr-param = generic-param |
|
12894 |
|
12895 Reply-To = "Reply-To" HCOLON rplyto-spec |
|
12896 rplyto-spec = ( name-addr / addr-spec ) |
|
12897 *( SEMI rplyto-param ) |
|
12898 rplyto-param = generic-param |
|
12899 Require = "Require" HCOLON option-tag *(COMMA option-tag) |
|
12900 |
|
12901 Retry-After = "Retry-After" HCOLON delta-seconds |
|
12902 [ comment ] *( SEMI retry-param ) |
|
12903 |
|
12904 retry-param = ("duration" EQUAL delta-seconds) |
|
12905 / generic-param |
|
12906 |
|
12907 Route = "Route" HCOLON route-param *(COMMA route-param) |
|
12908 route-param = name-addr *( SEMI rr-param ) |
|
12909 |
|
12910 Server = "Server" HCOLON server-val *(LWS server-val) |
|
12911 server-val = product / comment |
|
12912 product = token [SLASH product-version] |
|
12913 product-version = token |
|
12914 |
|
12915 Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM] |
|
12916 |
|
12917 Supported = ( "Supported" / "k" ) HCOLON |
|
12918 [option-tag *(COMMA option-tag)] |
|
12919 |
|
12920 Timestamp = "Timestamp" HCOLON 1*(DIGIT) |
|
12921 [ "." *(DIGIT) ] [ LWS delay ] |
|
12922 delay = *(DIGIT) [ "." *(DIGIT) ] |
|
12923 |
|
12924 To = ( "To" / "t" ) HCOLON ( name-addr |
|
12925 / addr-spec ) *( SEMI to-param ) |
|
12926 to-param = tag-param / generic-param |
|
12927 |
|
12928 Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag) |
|
12929 User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) |
|
12930 |
|
12931 |
|
12932 |
|
12933 |
|
12934 |
|
12935 |
|
12936 |
|
12937 |
|
12938 Rosenberg, et. al. Standards Track [Page 231] |
|
12939 |
|
12940 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12941 |
|
12942 |
|
12943 Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) |
|
12944 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) |
|
12945 via-params = via-ttl / via-maddr |
|
12946 / via-received / via-branch |
|
12947 / via-extension |
|
12948 via-ttl = "ttl" EQUAL ttl |
|
12949 via-maddr = "maddr" EQUAL host |
|
12950 via-received = "received" EQUAL (IPv4address / IPv6address) |
|
12951 via-branch = "branch" EQUAL token |
|
12952 via-extension = generic-param |
|
12953 sent-protocol = protocol-name SLASH protocol-version |
|
12954 SLASH transport |
|
12955 protocol-name = "SIP" / token |
|
12956 protocol-version = token |
|
12957 transport = "UDP" / "TCP" / "TLS" / "SCTP" |
|
12958 / other-transport |
|
12959 sent-by = host [ COLON port ] |
|
12960 ttl = 1*3DIGIT ; 0 to 255 |
|
12961 |
|
12962 Warning = "Warning" HCOLON warning-value *(COMMA warning-value) |
|
12963 warning-value = warn-code SP warn-agent SP warn-text |
|
12964 warn-code = 3DIGIT |
|
12965 warn-agent = hostport / pseudonym |
|
12966 ; the name or pseudonym of the server adding |
|
12967 ; the Warning header, for use in debugging |
|
12968 warn-text = quoted-string |
|
12969 pseudonym = token |
|
12970 |
|
12971 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge |
|
12972 |
|
12973 extension-header = header-name HCOLON header-value |
|
12974 header-name = token |
|
12975 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) |
|
12976 message-body = *OCTET |
|
12977 |
|
12978 26 Security Considerations: Threat Model and Security Usage |
|
12979 Recommendations |
|
12980 |
|
12981 SIP is not an easy protocol to secure. Its use of intermediaries, |
|
12982 its multi-faceted trust relationships, its expected usage between |
|
12983 elements with no trust at all, and its user-to-user operation make |
|
12984 security far from trivial. Security solutions are needed that are |
|
12985 deployable today, without extensive coordination, in a wide variety |
|
12986 of environments and usages. In order to meet these diverse needs, |
|
12987 several distinct mechanisms applicable to different aspects and |
|
12988 usages of SIP will be required. |
|
12989 |
|
12990 |
|
12991 |
|
12992 |
|
12993 |
|
12994 Rosenberg, et. al. Standards Track [Page 232] |
|
12995 |
|
12996 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
12997 |
|
12998 |
|
12999 Note that the security of SIP signaling itself has no bearing on the |
|
13000 security of protocols used in concert with SIP such as RTP, or with |
|
13001 the security implications of any specific bodies SIP might carry |
|
13002 (although MIME security plays a substantial role in securing SIP). |
|
13003 Any media associated with a session can be encrypted end-to-end |
|
13004 independently of any associated SIP signaling. Media encryption is |
|
13005 outside the scope of this document. |
|
13006 |
|
13007 The considerations that follow first examine a set of classic threat |
|
13008 models that broadly identify the security needs of SIP. The set of |
|
13009 security services required to address these threats is then detailed, |
|
13010 followed by an explanation of several security mechanisms that can be |
|
13011 used to provide these services. Next, the requirements for |
|
13012 implementers of SIP are enumerated, along with exemplary deployments |
|
13013 in which these security mechanisms could be used to improve the |
|
13014 security of SIP. Some notes on privacy conclude this section. |
|
13015 |
|
13016 26.1 Attacks and Threat Models |
|
13017 |
|
13018 This section details some threats that should be common to most |
|
13019 deployments of SIP. These threats have been chosen specifically to |
|
13020 illustrate each of the security services that SIP requires. |
|
13021 |
|
13022 The following examples by no means provide an exhaustive list of the |
|
13023 threats against SIP; rather, these are "classic" threats that |
|
13024 demonstrate the need for particular security services that can |
|
13025 potentially prevent whole categories of threats. |
|
13026 |
|
13027 These attacks assume an environment in which attackers can |
|
13028 potentially read any packet on the network - it is anticipated that |
|
13029 SIP will frequently be used on the public Internet. Attackers on the |
|
13030 network may be able to modify packets (perhaps at some compromised |
|
13031 intermediary). Attackers may wish to steal services, eavesdrop on |
|
13032 communications, or disrupt sessions. |
|
13033 |
|
13034 26.1.1 Registration Hijacking |
|
13035 |
|
13036 The SIP registration mechanism allows a user agent to identify itself |
|
13037 to a registrar as a device at which a user (designated by an address |
|
13038 of record) is located. A registrar assesses the identity asserted in |
|
13039 the From header field of a REGISTER message to determine whether this |
|
13040 request can modify the contact addresses associated with the |
|
13041 address-of-record in the To header field. While these two fields are |
|
13042 frequently the same, there are many valid deployments in which a |
|
13043 third-party may register contacts on a user's behalf. |
|
13044 |
|
13045 |
|
13046 |
|
13047 |
|
13048 |
|
13049 |
|
13050 Rosenberg, et. al. Standards Track [Page 233] |
|
13051 |
|
13052 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13053 |
|
13054 |
|
13055 The From header field of a SIP request, however, can be modified |
|
13056 arbitrarily by the owner of a UA, and this opens the door to |
|
13057 malicious registrations. An attacker that successfully impersonates |
|
13058 a party authorized to change contacts associated with an address-of- |
|
13059 record could, for example, de-register all existing contacts for a |
|
13060 URI and then register their own device as the appropriate contact |
|
13061 address, thereby directing all requests for the affected user to the |
|
13062 attacker's device. |
|
13063 |
|
13064 This threat belongs to a family of threats that rely on the absence |
|
13065 of cryptographic assurance of a request's originator. Any SIP UAS |
|
13066 that represents a valuable service (a gateway that interworks SIP |
|
13067 requests with traditional telephone calls, for example) might want to |
|
13068 control access to its resources by authenticating requests that it |
|
13069 receives. Even end-user UAs, for example SIP phones, have an |
|
13070 interest in ascertaining the identities of originators of requests. |
|
13071 |
|
13072 This threat demonstrates the need for security services that enable |
|
13073 SIP entities to authenticate the originators of requests. |
|
13074 |
|
13075 26.1.2 Impersonating a Server |
|
13076 |
|
13077 The domain to which a request is destined is generally specified in |
|
13078 the Request-URI. UAs commonly contact a server in this domain |
|
13079 directly in order to deliver a request. However, there is always a |
|
13080 possibility that an attacker could impersonate the remote server, and |
|
13081 that the UA's request could be intercepted by some other party. |
|
13082 |
|
13083 For example, consider a case in which a redirect server at one |
|
13084 domain, chicago.com, impersonates a redirect server at another |
|
13085 domain, biloxi.com. A user agent sends a request to biloxi.com, but |
|
13086 the redirect server at chicago.com answers with a forged response |
|
13087 that has appropriate SIP header fields for a response from |
|
13088 biloxi.com. The forged contact addresses in the redirection response |
|
13089 could direct the originating UA to inappropriate or insecure |
|
13090 resources, or simply prevent requests for biloxi.com from succeeding. |
|
13091 |
|
13092 This family of threats has a vast membership, many of which are |
|
13093 critical. As a converse to the registration hijacking threat, |
|
13094 consider the case in which a registration sent to biloxi.com is |
|
13095 intercepted by chicago.com, which replies to the intercepted |
|
13096 registration with a forged 301 (Moved Permanently) response. This |
|
13097 response might seem to come from biloxi.com yet designate chicago.com |
|
13098 as the appropriate registrar. All future REGISTER requests from the |
|
13099 originating UA would then go to chicago.com. |
|
13100 |
|
13101 Prevention of this threat requires a means by which UAs can |
|
13102 authenticate the servers to whom they send requests. |
|
13103 |
|
13104 |
|
13105 |
|
13106 Rosenberg, et. al. Standards Track [Page 234] |
|
13107 |
|
13108 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13109 |
|
13110 |
|
13111 26.1.3 Tampering with Message Bodies |
|
13112 |
|
13113 As a matter of course, SIP UAs route requests through trusted proxy |
|
13114 servers. Regardless of how that trust is established (authentication |
|
13115 of proxies is discussed elsewhere in this section), a UA may trust a |
|
13116 proxy server to route a request, but not to inspect or possibly |
|
13117 modify the bodies contained in that request. |
|
13118 |
|
13119 Consider a UA that is using SIP message bodies to communicate session |
|
13120 encryption keys for a media session. Although it trusts the proxy |
|
13121 server of the domain it is contacting to deliver signaling properly, |
|
13122 it may not want the administrators of that domain to be capable of |
|
13123 decrypting any subsequent media session. Worse yet, if the proxy |
|
13124 server were actively malicious, it could modify the session key, |
|
13125 either acting as a man-in-the-middle, or perhaps changing the |
|
13126 security characteristics requested by the originating UA. |
|
13127 |
|
13128 This family of threats applies not only to session keys, but to most |
|
13129 conceivable forms of content carried end-to-end in SIP. These might |
|
13130 include MIME bodies that should be rendered to the user, SDP, or |
|
13131 encapsulated telephony signals, among others. Attackers might |
|
13132 attempt to modify SDP bodies, for example, in order to point RTP |
|
13133 media streams to a wiretapping device in order to eavesdrop on |
|
13134 subsequent voice communications. |
|
13135 |
|
13136 Also note that some header fields in SIP are meaningful end-to-end, |
|
13137 for example, Subject. UAs might be protective of these header fields |
|
13138 as well as bodies (a malicious intermediary changing the Subject |
|
13139 header field might make an important request appear to be spam, for |
|
13140 example). However, since many header fields are legitimately |
|
13141 inspected or altered by proxy servers as a request is routed, not all |
|
13142 header fields should be secured end-to-end. |
|
13143 |
|
13144 For these reasons, the UA might want to secure SIP message bodies, |
|
13145 and in some limited cases header fields, end-to-end. The security |
|
13146 services required for bodies include confidentiality, integrity, and |
|
13147 authentication. These end-to-end services should be independent of |
|
13148 the means used to secure interactions with intermediaries such as |
|
13149 proxy servers. |
|
13150 |
|
13151 26.1.4 Tearing Down Sessions |
|
13152 |
|
13153 Once a dialog has been established by initial messaging, subsequent |
|
13154 requests can be sent that modify the state of the dialog and/or |
|
13155 session. It is critical that principals in a session can be certain |
|
13156 that such requests are not forged by attackers. |
|
13157 |
|
13158 |
|
13159 |
|
13160 |
|
13161 |
|
13162 Rosenberg, et. al. Standards Track [Page 235] |
|
13163 |
|
13164 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13165 |
|
13166 |
|
13167 Consider a case in which a third-party attacker captures some initial |
|
13168 messages in a dialog shared by two parties in order to learn the |
|
13169 parameters of the session (To tag, From tag, and so forth) and then |
|
13170 inserts a BYE request into the session. The attacker could opt to |
|
13171 forge the request such that it seemed to come from either |
|
13172 participant. Once the BYE is received by its target, the session |
|
13173 will be torn down prematurely. |
|
13174 |
|
13175 Similar mid-session threats include the transmission of forged re- |
|
13176 INVITEs that alter the session (possibly to reduce session security |
|
13177 or redirect media streams as part of a wiretapping attack). |
|
13178 |
|
13179 The most effective countermeasure to this threat is the |
|
13180 authentication of the sender of the BYE. In this instance, the |
|
13181 recipient needs only know that the BYE came from the same party with |
|
13182 whom the corresponding dialog was established (as opposed to |
|
13183 ascertaining the absolute identity of the sender). Also, if the |
|
13184 attacker is unable to learn the parameters of the session due to |
|
13185 confidentiality, it would not be possible to forge the BYE. However, |
|
13186 some intermediaries (like proxy servers) will need to inspect those |
|
13187 parameters as the session is established. |
|
13188 |
|
13189 26.1.5 Denial of Service and Amplification |
|
13190 |
|
13191 Denial-of-service attacks focus on rendering a particular network |
|
13192 element unavailable, usually by directing an excessive amount of |
|
13193 network traffic at its interfaces. A distributed denial-of-service |
|
13194 attack allows one network user to cause multiple network hosts to |
|
13195 flood a target host with a large amount of network traffic. |
|
13196 |
|
13197 In many architectures, SIP proxy servers face the public Internet in |
|
13198 order to accept requests from worldwide IP endpoints. SIP creates a |
|
13199 number of potential opportunities for distributed denial-of-service |
|
13200 attacks that must be recognized and addressed by the implementers and |
|
13201 operators of SIP systems. |
|
13202 |
|
13203 Attackers can create bogus requests that contain a falsified source |
|
13204 IP address and a corresponding Via header field that identify a |
|
13205 targeted host as the originator of the request and then send this |
|
13206 request to a large number of SIP network elements, thereby using |
|
13207 hapless SIP UAs or proxies to generate denial-of-service traffic |
|
13208 aimed at the target. |
|
13209 |
|
13210 Similarly, attackers might use falsified Route header field values in |
|
13211 a request that identify the target host and then send such messages |
|
13212 to forking proxies that will amplify messaging sent to the target. |
|
13213 |
|
13214 |
|
13215 |
|
13216 |
|
13217 |
|
13218 Rosenberg, et. al. Standards Track [Page 236] |
|
13219 |
|
13220 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13221 |
|
13222 |
|
13223 Record-Route could be used to similar effect when the attacker is |
|
13224 certain that the SIP dialog initiated by the request will result in |
|
13225 numerous transactions originating in the backwards direction. |
|
13226 |
|
13227 A number of denial-of-service attacks open up if REGISTER requests |
|
13228 are not properly authenticated and authorized by registrars. |
|
13229 Attackers could de-register some or all users in an administrative |
|
13230 domain, thereby preventing these users from being invited to new |
|
13231 sessions. An attacker could also register a large number of contacts |
|
13232 designating the same host for a given address-of-record in order to |
|
13233 use the registrar and any associated proxy servers as amplifiers in a |
|
13234 denial-of-service attack. Attackers might also attempt to deplete |
|
13235 available memory and disk resources of a registrar by registering |
|
13236 huge numbers of bindings. |
|
13237 |
|
13238 The use of multicast to transmit SIP requests can greatly increase |
|
13239 the potential for denial-of-service attacks. |
|
13240 |
|
13241 These problems demonstrate a general need to define architectures |
|
13242 that minimize the risks of denial-of-service, and the need to be |
|
13243 mindful in recommendations for security mechanisms of this class of |
|
13244 attacks. |
|
13245 |
|
13246 26.2 Security Mechanisms |
|
13247 |
|
13248 From the threats described above, we gather that the fundamental |
|
13249 security services required for the SIP protocol are: preserving the |
|
13250 confidentiality and integrity of messaging, preventing replay attacks |
|
13251 or message spoofing, providing for the authentication and privacy of |
|
13252 the participants in a session, and preventing denial-of-service |
|
13253 attacks. Bodies within SIP messages separately require the security |
|
13254 services of confidentiality, integrity, and authentication. |
|
13255 |
|
13256 Rather than defining new security mechanisms specific to SIP, SIP |
|
13257 reuses wherever possible existing security models derived from the |
|
13258 HTTP and SMTP space. |
|
13259 |
|
13260 Full encryption of messages provides the best means to preserve the |
|
13261 confidentiality of signaling - it can also guarantee that messages |
|
13262 are not modified by any malicious intermediaries. However, SIP |
|
13263 requests and responses cannot be naively encrypted end-to-end in |
|
13264 their entirety because message fields such as the Request-URI, Route, |
|
13265 and Via need to be visible to proxies in most network architectures |
|
13266 so that SIP requests are routed correctly. Note that proxy servers |
|
13267 need to modify some features of messages as well (such as adding Via |
|
13268 header field values) in order for SIP to function. Proxy servers |
|
13269 must therefore be trusted, to some degree, by SIP UAs. To this |
|
13270 purpose, low-layer security mechanisms for SIP are recommended, which |
|
13271 |
|
13272 |
|
13273 |
|
13274 Rosenberg, et. al. Standards Track [Page 237] |
|
13275 |
|
13276 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13277 |
|
13278 |
|
13279 encrypt the entire SIP requests or responses on the wire on a hop- |
|
13280 by-hop basis, and that allow endpoints to verify the identity of |
|
13281 proxy servers to whom they send requests. |
|
13282 |
|
13283 SIP entities also have a need to identify one another in a secure |
|
13284 fashion. When a SIP endpoint asserts the identity of its user to a |
|
13285 peer UA or to a proxy server, that identity should in some way be |
|
13286 verifiable. A cryptographic authentication mechanism is provided in |
|
13287 SIP to address this requirement. |
|
13288 |
|
13289 An independent security mechanism for SIP message bodies supplies an |
|
13290 alternative means of end-to-end mutual authentication, as well as |
|
13291 providing a limit on the degree to which user agents must trust |
|
13292 intermediaries. |
|
13293 |
|
13294 26.2.1 Transport and Network Layer Security |
|
13295 |
|
13296 Transport or network layer security encrypts signaling traffic, |
|
13297 guaranteeing message confidentiality and integrity. |
|
13298 |
|
13299 Oftentimes, certificates are used in the establishment of lower-layer |
|
13300 security, and these certificates can also be used to provide a means |
|
13301 of authentication in many architectures. |
|
13302 |
|
13303 Two popular alternatives for providing security at the transport and |
|
13304 network layer are, respectively, TLS [25] and IPSec [26]. |
|
13305 |
|
13306 IPSec is a set of network-layer protocol tools that collectively can |
|
13307 be used as a secure replacement for traditional IP (Internet |
|
13308 Protocol). IPSec is most commonly used in architectures in which a |
|
13309 set of hosts or administrative domains have an existing trust |
|
13310 relationship with one another. IPSec is usually implemented at the |
|
13311 operating system level in a host, or on a security gateway that |
|
13312 provides confidentiality and integrity for all traffic it receives |
|
13313 from a particular interface (as in a VPN architecture). IPSec can |
|
13314 also be used on a hop-by-hop basis. |
|
13315 |
|
13316 In many architectures IPSec does not require integration with SIP |
|
13317 applications; IPSec is perhaps best suited to deployments in which |
|
13318 adding security directly to SIP hosts would be arduous. UAs that |
|
13319 have a pre-shared keying relationship with their first-hop proxy |
|
13320 server are also good candidates to use IPSec. Any deployment of |
|
13321 IPSec for SIP would require an IPSec profile describing the protocol |
|
13322 tools that would be required to secure SIP. No such profile is given |
|
13323 in this document. |
|
13324 |
|
13325 |
|
13326 |
|
13327 |
|
13328 |
|
13329 |
|
13330 Rosenberg, et. al. Standards Track [Page 238] |
|
13331 |
|
13332 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13333 |
|
13334 |
|
13335 TLS provides transport-layer security over connection-oriented |
|
13336 protocols (for the purposes of this document, TCP); "tls" (signifying |
|
13337 TLS over TCP) can be specified as the desired transport protocol |
|
13338 within a Via header field value or a SIP-URI. TLS is most suited to |
|
13339 architectures in which hop-by-hop security is required between hosts |
|
13340 with no pre-existing trust association. For example, Alice trusts |
|
13341 her local proxy server, which after a certificate exchange decides to |
|
13342 trust Bob's local proxy server, which Bob trusts, hence Bob and Alice |
|
13343 can communicate securely. |
|
13344 |
|
13345 TLS must be tightly coupled with a SIP application. Note that |
|
13346 transport mechanisms are specified on a hop-by-hop basis in SIP, thus |
|
13347 a UA that sends requests over TLS to a proxy server has no assurance |
|
13348 that TLS will be used end-to-end. |
|
13349 |
|
13350 The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at |
|
13351 a minimum by implementers when TLS is used in a SIP application. For |
|
13352 purposes of backwards compatibility, proxy servers, redirect servers, |
|
13353 and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. |
|
13354 Implementers MAY also support any other ciphersuite. |
|
13355 |
|
13356 26.2.2 SIPS URI Scheme |
|
13357 |
|
13358 The SIPS URI scheme adheres to the syntax of the SIP URI (described |
|
13359 in 19), although the scheme string is "sips" rather than "sip". The |
|
13360 semantics of SIPS are very different from the SIP URI, however. SIPS |
|
13361 allows resources to specify that they should be reached securely. |
|
13362 |
|
13363 A SIPS URI can be used as an address-of-record for a particular user |
|
13364 - the URI by which the user is canonically known (on their business |
|
13365 cards, in the From header field of their requests, in the To header |
|
13366 field of REGISTER requests). When used as the Request-URI of a |
|
13367 request, the SIPS scheme signifies that each hop over which the |
|
13368 request is forwarded, until the request reaches the SIP entity |
|
13369 responsible for the domain portion of the Request-URI, must be |
|
13370 secured with TLS; once it reaches the domain in question it is |
|
13371 handled in accordance with local security and routing policy, quite |
|
13372 possibly using TLS for any last hop to a UAS. When used by the |
|
13373 originator of a request (as would be the case if they employed a SIPS |
|
13374 URI as the address-of-record of the target), SIPS dictates that the |
|
13375 entire request path to the target domain be so secured. |
|
13376 |
|
13377 The SIPS scheme is applicable to many of the other ways in which SIP |
|
13378 URIs are used in SIP today in addition to the Request-URI, including |
|
13379 in addresses-of-record, contact addresses (the contents of Contact |
|
13380 headers, including those of REGISTER methods), and Route headers. In |
|
13381 each instance, the SIPS URI scheme allows these existing fields to |
|
13382 |
|
13383 |
|
13384 |
|
13385 |
|
13386 Rosenberg, et. al. Standards Track [Page 239] |
|
13387 |
|
13388 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13389 |
|
13390 |
|
13391 designate secure resources. The manner in which a SIPS URI is |
|
13392 dereferenced in any of these contexts has its own security properties |
|
13393 which are detailed in [4]. |
|
13394 |
|
13395 The use of SIPS in particular entails that mutual TLS authentication |
|
13396 SHOULD be employed, as SHOULD the ciphersuite |
|
13397 TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the |
|
13398 authentication process SHOULD be validated with root certificates |
|
13399 held by the client; failure to validate a certificate SHOULD result |
|
13400 in the failure of the request. |
|
13401 |
|
13402 Note that in the SIPS URI scheme, transport is independent of TLS, |
|
13403 and thus "sips:alice@atlanta.com;transport=tcp" and |
|
13404 "sips:alice@atlanta.com;transport=sctp" are both valid (although |
|
13405 note that UDP is not a valid transport for SIPS). The use of |
|
13406 "transport=tls" has consequently been deprecated, partly because |
|
13407 it was specific to a single hop of the request. This is a change |
|
13408 since RFC 2543. |
|
13409 |
|
13410 Users that distribute a SIPS URI as an address-of-record may elect to |
|
13411 operate devices that refuse requests over insecure transports. |
|
13412 |
|
13413 26.2.3 HTTP Authentication |
|
13414 |
|
13415 SIP provides a challenge capability, based on HTTP authentication, |
|
13416 that relies on the 401 and 407 response codes as well as header |
|
13417 fields for carrying challenges and credentials. Without significant |
|
13418 modification, the reuse of the HTTP Digest authentication scheme in |
|
13419 SIP allows for replay protection and one-way authentication. |
|
13420 |
|
13421 The usage of Digest authentication in SIP is detailed in Section 22. |
|
13422 |
|
13423 26.2.4 S/MIME |
|
13424 |
|
13425 As is discussed above, encrypting entire SIP messages end-to-end for |
|
13426 the purpose of confidentiality is not appropriate because network |
|
13427 intermediaries (like proxy servers) need to view certain header |
|
13428 fields in order to route messages correctly, and if these |
|
13429 intermediaries are excluded from security associations, then SIP |
|
13430 messages will essentially be non-routable. |
|
13431 |
|
13432 However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, |
|
13433 securing these bodies end-to-end without affecting message headers. |
|
13434 S/MIME can provide end-to-end confidentiality and integrity for |
|
13435 message bodies, as well as mutual authentication. It is also |
|
13436 possible to use S/MIME to provide a form of integrity and |
|
13437 confidentiality for SIP header fields through SIP message tunneling. |
|
13438 |
|
13439 |
|
13440 |
|
13441 |
|
13442 Rosenberg, et. al. Standards Track [Page 240] |
|
13443 |
|
13444 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13445 |
|
13446 |
|
13447 The usage of S/MIME in SIP is detailed in Section 23. |
|
13448 |
|
13449 26.3 Implementing Security Mechanisms |
|
13450 |
|
13451 26.3.1 Requirements for Implementers of SIP |
|
13452 |
|
13453 Proxy servers, redirect servers, and registrars MUST implement TLS, |
|
13454 and MUST support both mutual and one-way authentication. It is |
|
13455 strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also |
|
13456 be capable of acting as a TLS server. Proxy servers, redirect |
|
13457 servers, and registrars SHOULD possess a site certificate whose |
|
13458 subject corresponds to their canonical hostname. UAs MAY have |
|
13459 certificates of their own for mutual authentication with TLS, but no |
|
13460 provisions are set forth in this document for their use. All SIP |
|
13461 elements that support TLS MUST have a mechanism for validating |
|
13462 certificates received during TLS negotiation; this entails possession |
|
13463 of one or more root certificates issued by certificate authorities |
|
13464 (preferably well-known distributors of site certificates comparable |
|
13465 to those that issue root certificates for web browsers). |
|
13466 |
|
13467 All SIP elements that support TLS MUST also support the SIPS URI |
|
13468 scheme. |
|
13469 |
|
13470 Proxy servers, redirect servers, registrars, and UAs MAY also |
|
13471 implement IPSec or other lower-layer security protocols. |
|
13472 |
|
13473 When a UA attempts to contact a proxy server, redirect server, or |
|
13474 registrar, the UAC SHOULD initiate a TLS connection over which it |
|
13475 will send SIP messages. In some architectures, UASs MAY receive |
|
13476 requests over such TLS connections as well. |
|
13477 |
|
13478 Proxy servers, redirect servers, registrars, and UAs MUST implement |
|
13479 Digest Authorization, encompassing all of the aspects required in 22. |
|
13480 Proxy servers, redirect servers, and registrars SHOULD be configured |
|
13481 with at least one Digest realm, and at least one "realm" string |
|
13482 supported by a given server SHOULD correspond to the server's |
|
13483 hostname or domainname. |
|
13484 |
|
13485 UAs MAY support the signing and encrypting of MIME bodies, and |
|
13486 transference of credentials with S/MIME as described in Section 23. |
|
13487 If a UA holds one or more root certificates of certificate |
|
13488 authorities in order to validate certificates for TLS or IPSec, it |
|
13489 SHOULD be capable of reusing these to verify S/MIME certificates, as |
|
13490 appropriate. A UA MAY hold root certificates specifically for |
|
13491 validating S/MIME certificates. |
|
13492 |
|
13493 |
|
13494 |
|
13495 |
|
13496 |
|
13497 |
|
13498 Rosenberg, et. al. Standards Track [Page 241] |
|
13499 |
|
13500 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13501 |
|
13502 |
|
13503 Note that is it anticipated that future security extensions may |
|
13504 upgrade the normative strength associated with S/MIME as S/MIME |
|
13505 implementations appear and the problem space becomes better |
|
13506 understood. |
|
13507 |
|
13508 26.3.2 Security Solutions |
|
13509 |
|
13510 The operation of these security mechanisms in concert can follow the |
|
13511 existing web and email security models to some degree. At a high |
|
13512 level, UAs authenticate themselves to servers (proxy servers, |
|
13513 redirect servers, and registrars) with a Digest username and |
|
13514 password; servers authenticate themselves to UAs one hop away, or to |
|
13515 another server one hop away (and vice versa), with a site certificate |
|
13516 delivered by TLS. |
|
13517 |
|
13518 On a peer-to-peer level, UAs trust the network to authenticate one |
|
13519 another ordinarily; however, S/MIME can also be used to provide |
|
13520 direct authentication when the network does not, or if the network |
|
13521 itself is not trusted. |
|
13522 |
|
13523 The following is an illustrative example in which these security |
|
13524 mechanisms are used by various UAs and servers to prevent the sorts |
|
13525 of threats described in Section 26.1. While implementers and network |
|
13526 administrators MAY follow the normative guidelines given in the |
|
13527 remainder of this section, these are provided only as example |
|
13528 implementations. |
|
13529 |
|
13530 26.3.2.1 Registration |
|
13531 |
|
13532 When a UA comes online and registers with its local administrative |
|
13533 domain, it SHOULD establish a TLS connection with its registrar |
|
13534 (Section 10 describes how the UA reaches its registrar). The |
|
13535 registrar SHOULD offer a certificate to the UA, and the site |
|
13536 identified by the certificate MUST correspond with the domain in |
|
13537 which the UA intends to register; for example, if the UA intends to |
|
13538 register the address-of-record 'alice@atlanta.com', the site |
|
13539 certificate must identify a host within the atlanta.com domain (such |
|
13540 as sip.atlanta.com). When it receives the TLS Certificate message, |
|
13541 the UA SHOULD verify the certificate and inspect the site identified |
|
13542 by the certificate. If the certificate is invalid, revoked, or if it |
|
13543 does not identify the appropriate party, the UA MUST NOT send the |
|
13544 REGISTER message and otherwise proceed with the registration. |
|
13545 |
|
13546 When a valid certificate has been provided by the registrar, the |
|
13547 UA knows that the registrar is not an attacker who might redirect |
|
13548 the UA, steal passwords, or attempt any similar attacks. |
|
13549 |
|
13550 |
|
13551 |
|
13552 |
|
13553 |
|
13554 Rosenberg, et. al. Standards Track [Page 242] |
|
13555 |
|
13556 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13557 |
|
13558 |
|
13559 The UA then creates a REGISTER request that SHOULD be addressed to a |
|
13560 Request-URI corresponding to the site certificate received from the |
|
13561 registrar. When the UA sends the REGISTER request over the existing |
|
13562 TLS connection, the registrar SHOULD challenge the request with a 401 |
|
13563 (Proxy Authentication Required) response. The "realm" parameter |
|
13564 within the Proxy-Authenticate header field of the response SHOULD |
|
13565 correspond to the domain previously given by the site certificate. |
|
13566 When the UAC receives the challenge, it SHOULD either prompt the user |
|
13567 for credentials or take an appropriate credential from a keyring |
|
13568 corresponding to the "realm" parameter in the challenge. The |
|
13569 username of this credential SHOULD correspond with the "userinfo" |
|
13570 portion of the URI in the To header field of the REGISTER request. |
|
13571 Once the Digest credentials have been inserted into an appropriate |
|
13572 Proxy-Authorization header field, the REGISTER should be resubmitted |
|
13573 to the registrar. |
|
13574 |
|
13575 Since the registrar requires the user agent to authenticate |
|
13576 itself, it would be difficult for an attacker to forge REGISTER |
|
13577 requests for the user's address-of-record. Also note that since |
|
13578 the REGISTER is sent over a confidential TLS connection, attackers |
|
13579 will not be able to intercept the REGISTER to record credentials |
|
13580 for any possible replay attack. |
|
13581 |
|
13582 Once the registration has been accepted by the registrar, the UA |
|
13583 SHOULD leave this TLS connection open provided that the registrar |
|
13584 also acts as the proxy server to which requests are sent for users in |
|
13585 this administrative domain. The existing TLS connection will be |
|
13586 reused to deliver incoming requests to the UA that has just completed |
|
13587 registration. |
|
13588 |
|
13589 Because the UA has already authenticated the server on the other |
|
13590 side of the TLS connection, all requests that come over this |
|
13591 connection are known to have passed through the proxy server - |
|
13592 attackers cannot create spoofed requests that appear to have been |
|
13593 sent through that proxy server. |
|
13594 |
|
13595 26.3.2.2 Interdomain Requests |
|
13596 |
|
13597 Now let's say that Alice's UA would like to initiate a session with a |
|
13598 user in a remote administrative domain, namely "bob@biloxi.com". We |
|
13599 will also say that the local administrative domain (atlanta.com) has |
|
13600 a local outbound proxy. |
|
13601 |
|
13602 The proxy server that handles inbound requests for an administrative |
|
13603 domain MAY also act as a local outbound proxy; for simplicity's sake |
|
13604 we'll assume this to be the case for atlanta.com (otherwise the user |
|
13605 agent would initiate a new TLS connection to a separate server at |
|
13606 this point). Assuming that the client has completed the registration |
|
13607 |
|
13608 |
|
13609 |
|
13610 Rosenberg, et. al. Standards Track [Page 243] |
|
13611 |
|
13612 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13613 |
|
13614 |
|
13615 process described in the preceding section, it SHOULD reuse the TLS |
|
13616 connection to the local proxy server when it sends an INVITE request |
|
13617 to another user. The UA SHOULD reuse cached credentials in the |
|
13618 INVITE to avoid prompting the user unnecessarily. |
|
13619 |
|
13620 When the local outbound proxy server has validated the credentials |
|
13621 presented by the UA in the INVITE, it SHOULD inspect the Request-URI |
|
13622 to determine how the message should be routed (see [4]). If the |
|
13623 "domainname" portion of the Request-URI had corresponded to the local |
|
13624 domain (atlanta.com) rather than biloxi.com, then the proxy server |
|
13625 would have consulted its location service to determine how best to |
|
13626 reach the requested user. |
|
13627 |
|
13628 Had "alice@atlanta.com" been attempting to contact, say, |
|
13629 "alex@atlanta.com", the local proxy would have proxied to the |
|
13630 request to the TLS connection Alex had established with the |
|
13631 registrar when he registered. Since Alex would receive this |
|
13632 request over his authenticated channel, he would be assured that |
|
13633 Alice's request had been authorized by the proxy server of the |
|
13634 local administrative domain. |
|
13635 |
|
13636 However, in this instance the Request-URI designates a remote domain. |
|
13637 The local outbound proxy server at atlanta.com SHOULD therefore |
|
13638 establish a TLS connection with the remote proxy server at |
|
13639 biloxi.com. Since both of the participants in this TLS connection |
|
13640 are servers that possess site certificates, mutual TLS authentication |
|
13641 SHOULD occur. Each side of the connection SHOULD verify and inspect |
|
13642 the certificate of the other, noting the domain name that appears in |
|
13643 the certificate for comparison with the header fields of SIP |
|
13644 messages. The atlanta.com proxy server, for example, SHOULD verify |
|
13645 at this stage that the certificate received from the remote side |
|
13646 corresponds with the biloxi.com domain. Once it has done so, and TLS |
|
13647 negotiation has completed, resulting in a secure channel between the |
|
13648 two proxies, the atlanta.com proxy can forward the INVITE request to |
|
13649 biloxi.com. |
|
13650 |
|
13651 The proxy server at biloxi.com SHOULD inspect the certificate of the |
|
13652 proxy server at atlanta.com in turn and compare the domain asserted |
|
13653 by the certificate with the "domainname" portion of the From header |
|
13654 field in the INVITE request. The biloxi proxy MAY have a strict |
|
13655 security policy that requires it to reject requests that do not match |
|
13656 the administrative domain from which they have been proxied. |
|
13657 |
|
13658 Such security policies could be instituted to prevent the SIP |
|
13659 equivalent of SMTP 'open relays' that are frequently exploited to |
|
13660 generate spam. |
|
13661 |
|
13662 |
|
13663 |
|
13664 |
|
13665 |
|
13666 Rosenberg, et. al. Standards Track [Page 244] |
|
13667 |
|
13668 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13669 |
|
13670 |
|
13671 This policy, however, only guarantees that the request came from the |
|
13672 domain it ascribes to itself; it does not allow biloxi.com to |
|
13673 ascertain how atlanta.com authenticated Alice. Only if biloxi.com |
|
13674 has some other way of knowing atlanta.com's authentication policies |
|
13675 could it possibly ascertain how Alice proved her identity. |
|
13676 biloxi.com might then institute an even stricter policy that forbids |
|
13677 requests that come from domains that are not known administratively |
|
13678 to share a common authentication policy with biloxi.com. |
|
13679 |
|
13680 Once the INVITE has been approved by the biloxi proxy, the proxy |
|
13681 server SHOULD identify the existing TLS channel, if any, associated |
|
13682 with the user targeted by this request (in this case |
|
13683 "bob@biloxi.com"). The INVITE should be proxied through this channel |
|
13684 to Bob. Since the request is received over a TLS connection that had |
|
13685 previously been authenticated as the biloxi proxy, Bob knows that the |
|
13686 From header field was not tampered with and that atlanta.com has |
|
13687 validated Alice, although not necessarily whether or not to trust |
|
13688 Alice's identity. |
|
13689 |
|
13690 Before they forward the request, both proxy servers SHOULD add a |
|
13691 Record-Route header field to the request so that all future requests |
|
13692 in this dialog will pass through the proxy servers. The proxy |
|
13693 servers can thereby continue to provide security services for the |
|
13694 lifetime of this dialog. If the proxy servers do not add themselves |
|
13695 to the Record-Route, future messages will pass directly end-to-end |
|
13696 between Alice and Bob without any security services (unless the two |
|
13697 parties agree on some independent end-to-end security such as |
|
13698 S/MIME). In this respect the SIP trapezoid model can provide a nice |
|
13699 structure where conventions of agreement between the site proxies can |
|
13700 provide a reasonably secure channel between Alice and Bob. |
|
13701 |
|
13702 An attacker preying on this architecture would, for example, be |
|
13703 unable to forge a BYE request and insert it into the signaling |
|
13704 stream between Bob and Alice because the attacker has no way of |
|
13705 ascertaining the parameters of the session and also because the |
|
13706 integrity mechanism transitively protects the traffic between |
|
13707 Alice and Bob. |
|
13708 |
|
13709 26.3.2.3 Peer-to-Peer Requests |
|
13710 |
|
13711 Alternatively, consider a UA asserting the identity |
|
13712 "carol@chicago.com" that has no local outbound proxy. When Carol |
|
13713 wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate |
|
13714 a TLS connection with the biloxi proxy directly (using the mechanism |
|
13715 described in [4] to determine how to best to reach the given |
|
13716 Request-URI). When her UA receives a certificate from the biloxi |
|
13717 proxy, it SHOULD be verified normally before she passes her INVITE |
|
13718 across the TLS connection. However, Carol has no means of proving |
|
13719 |
|
13720 |
|
13721 |
|
13722 Rosenberg, et. al. Standards Track [Page 245] |
|
13723 |
|
13724 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13725 |
|
13726 |
|
13727 her identity to the biloxi proxy, but she does have a CMS-detached |
|
13728 signature over a "message/sip" body in the INVITE. It is unlikely in |
|
13729 this instance that Carol would have any credentials in the biloxi.com |
|
13730 realm, since she has no formal association with biloxi.com. The |
|
13731 biloxi proxy MAY also have a strict policy that precludes it from |
|
13732 even bothering to challenge requests that do not have biloxi.com in |
|
13733 the "domainname" portion of the From header field - it treats these |
|
13734 users as unauthenticated. |
|
13735 |
|
13736 The biloxi proxy has a policy for Bob that all non-authenticated |
|
13737 requests should be redirected to the appropriate contact address |
|
13738 registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>. |
|
13739 Carol receives the redirection response over the TLS connection she |
|
13740 established with the biloxi proxy, so she trusts the veracity of the |
|
13741 contact address. |
|
13742 |
|
13743 Carol SHOULD then establish a TCP connection with the designated |
|
13744 address and send a new INVITE with a Request-URI containing the |
|
13745 received contact address (recomputing the signature in the body as |
|
13746 the request is readied). Bob receives this INVITE on an insecure |
|
13747 interface, but his UA inspects and, in this instance, recognizes the |
|
13748 From header field of the request and subsequently matches a locally |
|
13749 cached certificate with the one presented in the signature of the |
|
13750 body of the INVITE. He replies in similar fashion, authenticating |
|
13751 himself to Carol, and a secure dialog begins. |
|
13752 |
|
13753 Sometimes firewalls or NATs in an administrative domain could |
|
13754 preclude the establishment of a direct TCP connection to a UA. In |
|
13755 these cases, proxy servers could also potentially relay requests |
|
13756 to UAs in a way that has no trust implications (for example, |
|
13757 forgoing an existing TLS connection and forwarding the request |
|
13758 over cleartext TCP) as local policy dictates. |
|
13759 |
|
13760 26.3.2.4 DoS Protection |
|
13761 |
|
13762 In order to minimize the risk of a denial-of-service attack against |
|
13763 architectures using these security solutions, implementers should |
|
13764 take note of the following guidelines. |
|
13765 |
|
13766 When the host on which a SIP proxy server is operating is routable |
|
13767 from the public Internet, it SHOULD be deployed in an administrative |
|
13768 domain with defensive operational policies (blocking source-routed |
|
13769 traffic, preferably filtering ping traffic). Both TLS and IPSec can |
|
13770 also make use of bastion hosts at the edges of administrative domains |
|
13771 that participate in the security associations to aggregate secure |
|
13772 tunnels and sockets. These bastion hosts can also take the brunt of |
|
13773 denial-of-service attacks, ensuring that SIP hosts within the |
|
13774 administrative domain are not encumbered with superfluous messaging. |
|
13775 |
|
13776 |
|
13777 |
|
13778 Rosenberg, et. al. Standards Track [Page 246] |
|
13779 |
|
13780 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13781 |
|
13782 |
|
13783 No matter what security solutions are deployed, floods of messages |
|
13784 directed at proxy servers can lock up proxy server resources and |
|
13785 prevent desirable traffic from reaching its destination. There is a |
|
13786 computational expense associated with processing a SIP transaction at |
|
13787 a proxy server, and that expense is greater for stateful proxy |
|
13788 servers than it is for stateless proxy servers. Therefore, stateful |
|
13789 proxies are more susceptible to flooding than stateless proxy |
|
13790 servers. |
|
13791 |
|
13792 UAs and proxy servers SHOULD challenge questionable requests with |
|
13793 only a single 401 (Unauthorized) or 407 (Proxy Authentication |
|
13794 Required), forgoing the normal response retransmission algorithm, and |
|
13795 thus behaving statelessly towards unauthenticated requests. |
|
13796 |
|
13797 Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication |
|
13798 Required) status response amplifies the problem of an attacker |
|
13799 using a falsified header field value (such as Via) to direct |
|
13800 traffic to a third party. |
|
13801 |
|
13802 In summary, the mutual authentication of proxy servers through |
|
13803 mechanisms such as TLS significantly reduces the potential for rogue |
|
13804 intermediaries to introduce falsified requests or responses that can |
|
13805 deny service. This commensurately makes it harder for attackers to |
|
13806 make innocent SIP nodes into agents of amplification. |
|
13807 |
|
13808 26.4 Limitations |
|
13809 |
|
13810 Although these security mechanisms, when applied in a judicious |
|
13811 manner, can thwart many threats, there are limitations in the scope |
|
13812 of the mechanisms that must be understood by implementers and network |
|
13813 operators. |
|
13814 |
|
13815 26.4.1 HTTP Digest |
|
13816 |
|
13817 One of the primary limitations of using HTTP Digest in SIP is that |
|
13818 the integrity mechanisms in Digest do not work very well for SIP. |
|
13819 Specifically, they offer protection of the Request-URI and the method |
|
13820 of a message, but not for any of the header fields that UAs would |
|
13821 most likely wish to secure. |
|
13822 |
|
13823 The existing replay protection mechanisms described in RFC 2617 also |
|
13824 have some limitations for SIP. The next-nonce mechanism, for |
|
13825 example, does not support pipelined requests. The nonce-count |
|
13826 mechanism should be used for replay protection. |
|
13827 |
|
13828 Another limitation of HTTP Digest is the scope of realms. Digest is |
|
13829 valuable when a user wants to authenticate themselves to a resource |
|
13830 with which they have a pre-existing association, like a service |
|
13831 |
|
13832 |
|
13833 |
|
13834 Rosenberg, et. al. Standards Track [Page 247] |
|
13835 |
|
13836 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13837 |
|
13838 |
|
13839 provider of which the user is a customer (which is quite a common |
|
13840 scenario and thus Digest provides an extremely useful function). By |
|
13841 way of contrast, the scope of TLS is interdomain or multirealm, since |
|
13842 certificates are often globally verifiable, so that the UA can |
|
13843 authenticate the server with no pre-existing association. |
|
13844 |
|
13845 26.4.2 S/MIME |
|
13846 |
|
13847 The largest outstanding defect with the S/MIME mechanism is the lack |
|
13848 of a prevalent public key infrastructure for end users. If self- |
|
13849 signed certificates (or certificates that cannot be verified by one |
|
13850 of the participants in a dialog) are used, the SIP-based key exchange |
|
13851 mechanism described in Section 23.2 is susceptible to a man-in-the- |
|
13852 middle attack with which an attacker can potentially inspect and |
|
13853 modify S/MIME bodies. The attacker needs to intercept the first |
|
13854 exchange of keys between the two parties in a dialog, remove the |
|
13855 existing CMS-detached signatures from the request and response, and |
|
13856 insert a different CMS-detached signature containing a certificate |
|
13857 supplied by the attacker (but which seems to be a certificate for the |
|
13858 proper address-of-record). Each party will think they have exchanged |
|
13859 keys with the other, when in fact each has the public key of the |
|
13860 attacker. |
|
13861 |
|
13862 It is important to note that the attacker can only leverage this |
|
13863 vulnerability on the first exchange of keys between two parties - on |
|
13864 subsequent occasions, the alteration of the key would be noticeable |
|
13865 to the UAs. It would also be difficult for the attacker to remain in |
|
13866 the path of all future dialogs between the two parties over time (as |
|
13867 potentially days, weeks, or years pass). |
|
13868 |
|
13869 SSH is susceptible to the same man-in-the-middle attack on the first |
|
13870 exchange of keys; however, it is widely acknowledged that while SSH |
|
13871 is not perfect, it does improve the security of connections. The use |
|
13872 of key fingerprints could provide some assistance to SIP, just as it |
|
13873 does for SSH. For example, if two parties use SIP to establish a |
|
13874 voice communications session, each could read off the fingerprint of |
|
13875 the key they received from the other, which could be compared against |
|
13876 the original. It would certainly be more difficult for the man-in- |
|
13877 the-middle to emulate the voices of the participants than their |
|
13878 signaling (a practice that was used with the Clipper chip-based |
|
13879 secure telephone). |
|
13880 |
|
13881 The S/MIME mechanism allows UAs to send encrypted requests without |
|
13882 preamble if they possess a certificate for the destination address- |
|
13883 of-record on their keyring. However, it is possible that any |
|
13884 particular device registered for an address-of-record will not hold |
|
13885 the certificate that has been previously employed by the device's |
|
13886 current user, and that it will therefore be unable to process an |
|
13887 |
|
13888 |
|
13889 |
|
13890 Rosenberg, et. al. Standards Track [Page 248] |
|
13891 |
|
13892 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13893 |
|
13894 |
|
13895 encrypted request properly, which could lead to some avoidable error |
|
13896 signaling. This is especially likely when an encrypted request is |
|
13897 forked. |
|
13898 |
|
13899 The keys associated with S/MIME are most useful when associated with |
|
13900 a particular user (an address-of-record) rather than a device (a UA). |
|
13901 When users move between devices, it may be difficult to transport |
|
13902 private keys securely between UAs; how such keys might be acquired by |
|
13903 a device is outside the scope of this document. |
|
13904 |
|
13905 Another, more prosaic difficulty with the S/MIME mechanism is that it |
|
13906 can result in very large messages, especially when the SIP tunneling |
|
13907 mechanism described in Section 23.4 is used. For that reason, it is |
|
13908 RECOMMENDED that TCP should be used as a transport protocol when |
|
13909 S/MIME tunneling is employed. |
|
13910 |
|
13911 26.4.3 TLS |
|
13912 |
|
13913 The most commonly voiced concern about TLS is that it cannot run over |
|
13914 UDP; TLS requires a connection-oriented underlying transport |
|
13915 protocol, which for the purposes of this document means TCP. |
|
13916 |
|
13917 It may also be arduous for a local outbound proxy server and/or |
|
13918 registrar to maintain many simultaneous long-lived TLS connections |
|
13919 with numerous UAs. This introduces some valid scalability concerns, |
|
13920 especially for intensive ciphersuites. Maintaining redundancy of |
|
13921 long-lived TLS connections, especially when a UA is solely |
|
13922 responsible for their establishment, could also be cumbersome. |
|
13923 |
|
13924 TLS only allows SIP entities to authenticate servers to which they |
|
13925 are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, |
|
13926 nor any other mechanism specified in this document, allows clients to |
|
13927 authenticate proxy servers to whom they cannot form a direct TCP |
|
13928 connection. |
|
13929 |
|
13930 26.4.4 SIPS URIs |
|
13931 |
|
13932 Actually using TLS on every segment of a request path entails that |
|
13933 the terminating UAS must be reachable over TLS (perhaps registering |
|
13934 with a SIPS URI as a contact address). This is the preferred use of |
|
13935 SIPS. Many valid architectures, however, use TLS to secure part of |
|
13936 the request path, but rely on some other mechanism for the final hop |
|
13937 to a UAS, for example. Thus SIPS cannot guarantee that TLS usage |
|
13938 will be truly end-to-end. Note that since many UAs will not accept |
|
13939 incoming TLS connections, even those UAs that do support TLS may be |
|
13940 required to maintain persistent TLS connections as described in the |
|
13941 TLS limitations section above in order to receive requests over TLS |
|
13942 as a UAS. |
|
13943 |
|
13944 |
|
13945 |
|
13946 Rosenberg, et. al. Standards Track [Page 249] |
|
13947 |
|
13948 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
13949 |
|
13950 |
|
13951 Location services are not required to provide a SIPS binding for a |
|
13952 SIPS Request-URI. Although location services are commonly populated |
|
13953 by user registrations (as described in Section 10.2.1), various other |
|
13954 protocols and interfaces could conceivably supply contact addresses |
|
13955 for an AOR, and these tools are free to map SIPS URIs to SIP URIs as |
|
13956 appropriate. When queried for bindings, a location service returns |
|
13957 its contact addresses without regard for whether it received a |
|
13958 request with a SIPS Request-URI. If a redirect server is accessing |
|
13959 the location service, it is up to the entity that processes the |
|
13960 Contact header field of a redirection to determine the propriety of |
|
13961 the contact addresses. |
|
13962 |
|
13963 Ensuring that TLS will be used for all of the request segments up to |
|
13964 the target domain is somewhat complex. It is possible that |
|
13965 cryptographically authenticated proxy servers along the way that are |
|
13966 non-compliant or compromised may choose to disregard the forwarding |
|
13967 rules associated with SIPS (and the general forwarding rules in |
|
13968 Section 16.6). Such malicious intermediaries could, for example, |
|
13969 retarget a request from a SIPS URI to a SIP URI in an attempt to |
|
13970 downgrade security. |
|
13971 |
|
13972 Alternatively, an intermediary might legitimately retarget a request |
|
13973 from a SIP to a SIPS URI. Recipients of a request whose Request-URI |
|
13974 uses the SIPS URI scheme thus cannot assume on the basis of the |
|
13975 Request-URI alone that SIPS was used for the entire request path |
|
13976 (from the client onwards). |
|
13977 |
|
13978 To address these concerns, it is RECOMMENDED that recipients of a |
|
13979 request whose Request-URI contains a SIP or SIPS URI inspect the To |
|
13980 header field value to see if it contains a SIPS URI (though note that |
|
13981 it does not constitute a breach of security if this URI has the same |
|
13982 scheme but is not equivalent to the URI in the To header field). |
|
13983 Although clients may choose to populate the Request-URI and To header |
|
13984 field of a request differently, when SIPS is used this disparity |
|
13985 could be interpreted as a possible security violation, and the |
|
13986 request could consequently be rejected by its recipient. Recipients |
|
13987 MAY also inspect the Via header chain in order to double-check |
|
13988 whether or not TLS was used for the entire request path until the |
|
13989 local administrative domain was reached. S/MIME may also be used by |
|
13990 the originating UAC to help ensure that the original form of the To |
|
13991 header field is carried end-to-end. |
|
13992 |
|
13993 If the UAS has reason to believe that the scheme of the Request-URI |
|
13994 has been improperly modified in transit, the UA SHOULD notify its |
|
13995 user of a potential security breach. |
|
13996 |
|
13997 |
|
13998 |
|
13999 |
|
14000 |
|
14001 |
|
14002 Rosenberg, et. al. Standards Track [Page 250] |
|
14003 |
|
14004 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14005 |
|
14006 |
|
14007 As a further measure to prevent downgrade attacks, entities that |
|
14008 accept only SIPS requests MAY also refuse connections on insecure |
|
14009 ports. |
|
14010 |
|
14011 End users will undoubtedly discern the difference between SIPS and |
|
14012 SIP URIs, and they may manually edit them in response to stimuli. |
|
14013 This can either benefit or degrade security. For example, if an |
|
14014 attacker corrupts a DNS cache, inserting a fake record set that |
|
14015 effectively removes all SIPS records for a proxy server, then any |
|
14016 SIPS requests that traverse this proxy server may fail. When a user, |
|
14017 however, sees that repeated calls to a SIPS AOR are failing, they |
|
14018 could on some devices manually convert the scheme from SIPS to SIP |
|
14019 and retry. Of course, there are some safeguards against this (if the |
|
14020 destination UA is truly paranoid it could refuse all non-SIPS |
|
14021 requests), but it is a limitation worth noting. On the bright side, |
|
14022 users might also divine that 'SIPS' would be valid even when they are |
|
14023 presented only with a SIP URI. |
|
14024 |
|
14025 26.5 Privacy |
|
14026 |
|
14027 SIP messages frequently contain sensitive information about their |
|
14028 senders - not just what they have to say, but with whom they |
|
14029 communicate, when they communicate and for how long, and from where |
|
14030 they participate in sessions. Many applications and their users |
|
14031 require that this sort of private information be hidden from any |
|
14032 parties that do not need to know it. |
|
14033 |
|
14034 Note that there are also less direct ways in which private |
|
14035 information can be divulged. If a user or service chooses to be |
|
14036 reachable at an address that is guessable from the person's name and |
|
14037 organizational affiliation (which describes most addresses-of- |
|
14038 record), the traditional method of ensuring privacy by having an |
|
14039 unlisted "phone number" is compromised. A user location service can |
|
14040 infringe on the privacy of the recipient of a session invitation by |
|
14041 divulging their specific whereabouts to the caller; an implementation |
|
14042 consequently SHOULD be able to restrict, on a per-user basis, what |
|
14043 kind of location and availability information is given out to certain |
|
14044 classes of callers. This is a whole class of problem that is |
|
14045 expected to be studied further in ongoing SIP work. |
|
14046 |
|
14047 In some cases, users may want to conceal personal information in |
|
14048 header fields that convey identity. This can apply not only to the |
|
14049 From and related headers representing the originator of the request, |
|
14050 but also the To - it may not be appropriate to convey to the final |
|
14051 destination a speed-dialing nickname, or an unexpanded identifier for |
|
14052 a group of targets, either of which would be removed from the |
|
14053 Request-URI as the request is routed, but not changed in the To |
|
14054 |
|
14055 |
|
14056 |
|
14057 |
|
14058 Rosenberg, et. al. Standards Track [Page 251] |
|
14059 |
|
14060 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14061 |
|
14062 |
|
14063 header field if the two were initially identical. Thus it MAY be |
|
14064 desirable for privacy reasons to create a To header field that |
|
14065 differs from the Request-URI. |
|
14066 |
|
14067 27 IANA Considerations |
|
14068 |
|
14069 All method names, header field names, status codes, and option tags |
|
14070 used in SIP applications are registered with IANA through |
|
14071 instructions in an IANA Considerations section in an RFC. |
|
14072 |
|
14073 The specification instructs the IANA to create four new sub- |
|
14074 registries under http://www.iana.org/assignments/sip-parameters: |
|
14075 Option Tags, Warning Codes (warn-codes), Methods and Response Codes, |
|
14076 added to the sub-registry of Header Fields that is already present |
|
14077 there. |
|
14078 |
|
14079 27.1 Option Tags |
|
14080 |
|
14081 This specification establishes the Option Tags sub-registry under |
|
14082 http://www.iana.org/assignments/sip-parameters. |
|
14083 |
|
14084 Option tags are used in header fields such as Require, Supported, |
|
14085 Proxy-Require, and Unsupported in support of SIP compatibility |
|
14086 mechanisms for extensions (Section 19.2). The option tag itself is a |
|
14087 string that is associated with a particular SIP option (that is, an |
|
14088 extension). It identifies the option to SIP endpoints. |
|
14089 |
|
14090 Option tags are registered by the IANA when they are published in |
|
14091 standards track RFCs. The IANA Considerations section of the RFC |
|
14092 must include the following information, which appears in the IANA |
|
14093 registry along with the RFC number of the publication. |
|
14094 |
|
14095 o Name of the option tag. The name MAY be of any length, but |
|
14096 SHOULD be no more than twenty characters long. The name MUST |
|
14097 consist of alphanum (Section 25) characters only. |
|
14098 |
|
14099 o Descriptive text that describes the extension. |
|
14100 |
|
14101 27.2 Warn-Codes |
|
14102 |
|
14103 This specification establishes the Warn-codes sub-registry under |
|
14104 http://www.iana.org/assignments/sip-parameters and initiates its |
|
14105 population with the warn-codes listed in Section 20.43. Additional |
|
14106 warn-codes are registered by RFC publication. |
|
14107 |
|
14108 |
|
14109 |
|
14110 |
|
14111 |
|
14112 |
|
14113 |
|
14114 Rosenberg, et. al. Standards Track [Page 252] |
|
14115 |
|
14116 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14117 |
|
14118 |
|
14119 The descriptive text for the table of warn-codes is: |
|
14120 |
|
14121 Warning codes provide information supplemental to the status code in |
|
14122 SIP response messages when the failure of the transaction results |
|
14123 from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. |
|
14124 |
|
14125 The "warn-code" consists of three digits. A first digit of "3" |
|
14126 indicates warnings specific to SIP. Until a future specification |
|
14127 describes uses of warn-codes other than 3xx, only 3xx warn-codes may |
|
14128 be registered. |
|
14129 |
|
14130 Warnings 300 through 329 are reserved for indicating problems with |
|
14131 keywords in the session description, 330 through 339 are warnings |
|
14132 related to basic network services requested in the session |
|
14133 description, 370 through 379 are warnings related to quantitative QoS |
|
14134 parameters requested in the session description, and 390 through 399 |
|
14135 are miscellaneous warnings that do not fall into one of the above |
|
14136 categories. |
|
14137 |
|
14138 27.3 Header Field Names |
|
14139 |
|
14140 This obsoletes the IANA instructions about the header sub-registry |
|
14141 under http://www.iana.org/assignments/sip-parameters. |
|
14142 |
|
14143 The following information needs to be provided in an RFC publication |
|
14144 in order to register a new header field name: |
|
14145 |
|
14146 o The RFC number in which the header is registered; |
|
14147 |
|
14148 o the name of the header field being registered; |
|
14149 |
|
14150 o a compact form version for that header field, if one is |
|
14151 defined; |
|
14152 |
|
14153 Some common and widely used header fields MAY be assigned one-letter |
|
14154 compact forms (Section 7.3.3). Compact forms can only be assigned |
|
14155 after SIP working group review, followed by RFC publication. |
|
14156 |
|
14157 27.4 Method and Response Codes |
|
14158 |
|
14159 This specification establishes the Method and Response-Code sub- |
|
14160 registries under http://www.iana.org/assignments/sip-parameters and |
|
14161 initiates their population as follows. The initial Methods table is: |
|
14162 |
|
14163 |
|
14164 |
|
14165 |
|
14166 |
|
14167 |
|
14168 |
|
14169 |
|
14170 Rosenberg, et. al. Standards Track [Page 253] |
|
14171 |
|
14172 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14173 |
|
14174 |
|
14175 INVITE [RFC3261] |
|
14176 ACK [RFC3261] |
|
14177 BYE [RFC3261] |
|
14178 CANCEL [RFC3261] |
|
14179 REGISTER [RFC3261] |
|
14180 OPTIONS [RFC3261] |
|
14181 INFO [RFC2976] |
|
14182 |
|
14183 The response code table is initially populated from Section 21, the |
|
14184 portions labeled Informational, Success, Redirection, Client-Error, |
|
14185 Server-Error, and Global-Failure. The table has the following |
|
14186 format: |
|
14187 |
|
14188 Type (e.g., Informational) |
|
14189 Number Default Reason Phrase [RFC3261] |
|
14190 |
|
14191 The following information needs to be provided in an RFC publication |
|
14192 in order to register a new response code or method: |
|
14193 |
|
14194 o The RFC number in which the method or response code is |
|
14195 registered; |
|
14196 |
|
14197 o the number of the response code or name of the method being |
|
14198 registered; |
|
14199 |
|
14200 o the default reason phrase for that response code, if |
|
14201 applicable; |
|
14202 |
|
14203 27.5 The "message/sip" MIME type. |
|
14204 |
|
14205 This document registers the "message/sip" MIME media type in order to |
|
14206 allow SIP messages to be tunneled as bodies within SIP, primarily for |
|
14207 end-to-end security purposes. This media type is defined by the |
|
14208 following information: |
|
14209 |
|
14210 Media type name: message |
|
14211 Media subtype name: sip |
|
14212 Required parameters: none |
|
14213 |
|
14214 Optional parameters: version |
|
14215 version: The SIP-Version number of the enclosed message (e.g., |
|
14216 "2.0"). If not present, the version defaults to "2.0". |
|
14217 Encoding scheme: SIP messages consist of an 8-bit header |
|
14218 optionally followed by a binary MIME data object. As such, SIP |
|
14219 messages must be treated as binary. Under normal circumstances |
|
14220 SIP messages are transported over binary-capable transports, no |
|
14221 special encodings are needed. |
|
14222 |
|
14223 |
|
14224 |
|
14225 |
|
14226 Rosenberg, et. al. Standards Track [Page 254] |
|
14227 |
|
14228 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14229 |
|
14230 |
|
14231 Security considerations: see below |
|
14232 Motivation and examples of this usage as a security mechanism |
|
14233 in concert with S/MIME are given in 23.4. |
|
14234 |
|
14235 27.6 New Content-Disposition Parameter Registrations |
|
14236 |
|
14237 This document also registers four new Content-Disposition header |
|
14238 "disposition-types": alert, icon, session and render. The authors |
|
14239 request that these values be recorded in the IANA registry for |
|
14240 Content-Dispositions. |
|
14241 |
|
14242 Descriptions of these "disposition-types", including motivation and |
|
14243 examples, are given in Section 20.11. |
|
14244 |
|
14245 Short descriptions suitable for the IANA registry are: |
|
14246 |
|
14247 alert the body is a custom ring tone to alert the user |
|
14248 icon the body is displayed as an icon to the user |
|
14249 render the body should be displayed to the user |
|
14250 session the body describes a communications session, for |
|
14251 example, as RFC 2327 SDP body |
|
14252 |
|
14253 28 Changes From RFC 2543 |
|
14254 |
|
14255 This RFC revises RFC 2543. It is mostly backwards compatible with |
|
14256 RFC 2543. The changes described here fix many errors discovered in |
|
14257 RFC 2543 and provide information on scenarios not detailed in RFC |
|
14258 2543. The protocol has been presented in a more cleanly layered |
|
14259 model here. |
|
14260 |
|
14261 We break the differences into functional behavior that is a |
|
14262 substantial change from RFC 2543, which has impact on |
|
14263 interoperability or correct operation in some cases, and functional |
|
14264 behavior that is different from RFC 2543 but not a potential source |
|
14265 of interoperability problems. There have been countless |
|
14266 clarifications as well, which are not documented here. |
|
14267 |
|
14268 28.1 Major Functional Changes |
|
14269 |
|
14270 o When a UAC wishes to terminate a call before it has been answered, |
|
14271 it sends CANCEL. If the original INVITE still returns a 2xx, the |
|
14272 UAC then sends BYE. BYE can only be sent on an existing call leg |
|
14273 (now called a dialog in this RFC), whereas it could be sent at any |
|
14274 time in RFC 2543. |
|
14275 |
|
14276 o The SIP BNF was converted to be RFC 2234 compliant. |
|
14277 |
|
14278 |
|
14279 |
|
14280 |
|
14281 |
|
14282 Rosenberg, et. al. Standards Track [Page 255] |
|
14283 |
|
14284 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14285 |
|
14286 |
|
14287 o SIP URL BNF was made more general, allowing a greater set of |
|
14288 characters in the user part. Furthermore, comparison rules were |
|
14289 simplified to be primarily case-insensitive, and detailed handling |
|
14290 of comparison in the presence of parameters was described. The |
|
14291 most substantial change is that a URI with a parameter with the |
|
14292 default value does not match a URI without that parameter. |
|
14293 |
|
14294 o Removed Via hiding. It had serious trust issues, since it relied |
|
14295 on the next hop to perform the obfuscation process. Instead, Via |
|
14296 hiding can be done as a local implementation choice in stateful |
|
14297 proxies, and thus is no longer documented. |
|
14298 |
|
14299 o In RFC 2543, CANCEL and INVITE transactions were intermingled. |
|
14300 They are separated now. When a user sends an INVITE and then a |
|
14301 CANCEL, the INVITE transaction still terminates normally. A UAS |
|
14302 needs to respond to the original INVITE request with a 487 |
|
14303 response. |
|
14304 |
|
14305 o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 |
|
14306 allowed the UAS not to send a response to INVITE when a BYE was |
|
14307 received. That is disallowed here. The original INVITE needs a |
|
14308 response. |
|
14309 |
|
14310 o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs |
|
14311 need to support both UDP and TCP. |
|
14312 |
|
14313 o In RFC 2543, a forking proxy only passed up one challenge from |
|
14314 downstream elements in the event of multiple challenges. In this |
|
14315 RFC, proxies are supposed to collect all challenges and place them |
|
14316 into the forwarded response. |
|
14317 |
|
14318 o In Digest credentials, the URI needs to be quoted; this is unclear |
|
14319 from RFC 2617 and RFC 2069 which are both inconsistent on it. |
|
14320 |
|
14321 o SDP processing has been split off into a separate specification |
|
14322 [13], and more fully specified as a formal offer/answer exchange |
|
14323 process that is effectively tunneled through SIP. SDP is allowed |
|
14324 in INVITE/200 or 200/ACK for baseline SIP implementations; RFC |
|
14325 2543 alluded to the ability to use it in INVITE, 200, and ACK in a |
|
14326 single transaction, but this was not well specified. More complex |
|
14327 SDP usages are allowed in extensions. |
|
14328 |
|
14329 |
|
14330 |
|
14331 |
|
14332 |
|
14333 |
|
14334 |
|
14335 |
|
14336 |
|
14337 |
|
14338 Rosenberg, et. al. Standards Track [Page 256] |
|
14339 |
|
14340 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14341 |
|
14342 |
|
14343 o Added full support for IPv6 in URIs and in the Via header field. |
|
14344 Support for IPv6 in Via has required that its header field |
|
14345 parameters allow the square bracket and colon characters. These |
|
14346 characters were previously not permitted. In theory, this could |
|
14347 cause interop problems with older implementations. However, we |
|
14348 have observed that most implementations accept any non-control |
|
14349 ASCII character in these parameters. |
|
14350 |
|
14351 o DNS SRV procedure is now documented in a separate specification |
|
14352 [4]. This procedure uses both SRV and NAPTR resource records and |
|
14353 no longer combines data from across SRV records as described in |
|
14354 RFC 2543. |
|
14355 |
|
14356 o Loop detection has been made optional, supplanted by a mandatory |
|
14357 usage of Max-Forwards. The loop detection procedure in RFC 2543 |
|
14358 had a serious bug which would report "spirals" as an error |
|
14359 condition when it was not. The optional loop detection procedure |
|
14360 is more fully and correctly specified here. |
|
14361 |
|
14362 o Usage of tags is now mandatory (they were optional in RFC 2543), |
|
14363 as they are now the fundamental building blocks of dialog |
|
14364 identification. |
|
14365 |
|
14366 o Added the Supported header field, allowing for clients to indicate |
|
14367 what extensions are supported to a server, which can apply those |
|
14368 extensions to the response, and indicate their usage with a |
|
14369 Require in the response. |
|
14370 |
|
14371 o Extension parameters were missing from the BNF for several header |
|
14372 fields, and they have been added. |
|
14373 |
|
14374 o Handling of Route and Record-Route construction was very |
|
14375 underspecified in RFC 2543, and also not the right approach. It |
|
14376 has been substantially reworked in this specification (and made |
|
14377 vastly simpler), and this is arguably the largest change. |
|
14378 Backwards compatibility is still provided for deployments that do |
|
14379 not use "pre-loaded routes", where the initial request has a set |
|
14380 of Route header field values obtained in some way outside of |
|
14381 Record-Route. In those situations, the new mechanism is not |
|
14382 interoperable. |
|
14383 |
|
14384 o In RFC 2543, lines in a message could be terminated with CR, LF, |
|
14385 or CRLF. This specification only allows CRLF. |
|
14386 |
|
14387 |
|
14388 |
|
14389 |
|
14390 |
|
14391 |
|
14392 |
|
14393 |
|
14394 Rosenberg, et. al. Standards Track [Page 257] |
|
14395 |
|
14396 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14397 |
|
14398 |
|
14399 o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. |
|
14400 It is now well specified; if a request had a Route header field, |
|
14401 its CANCEL or ACK for a non-2xx response to the request need to |
|
14402 carry the same Route header field values. ACKs for 2xx responses |
|
14403 use the Route values learned from the Record-Route of the 2xx |
|
14404 responses. |
|
14405 |
|
14406 o RFC 2543 allowed multiple requests in a single UDP packet. This |
|
14407 usage has been removed. |
|
14408 |
|
14409 o Usage of absolute time in the Expires header field and parameter |
|
14410 has been removed. It caused interoperability problems in elements |
|
14411 that were not time synchronized, a common occurrence. Relative |
|
14412 times are used instead. |
|
14413 |
|
14414 o The branch parameter of the Via header field value is now |
|
14415 mandatory for all elements to use. It now plays the role of a |
|
14416 unique transaction identifier. This avoids the complex and bug- |
|
14417 laden transaction identification rules from RFC 2543. A magic |
|
14418 cookie is used in the parameter value to determine if the previous |
|
14419 hop has made the parameter globally unique, and comparison falls |
|
14420 back to the old rules when it is not present. Thus, |
|
14421 interoperability is assured. |
|
14422 |
|
14423 o In RFC 2543, closure of a TCP connection was made equivalent to a |
|
14424 CANCEL. This was nearly impossible to implement (and wrong) for |
|
14425 TCP connections between proxies. This has been eliminated, so |
|
14426 that there is no coupling between TCP connection state and SIP |
|
14427 processing. |
|
14428 |
|
14429 o RFC 2543 was silent on whether a UA could initiate a new |
|
14430 transaction to a peer while another was in progress. That is now |
|
14431 specified here. It is allowed for non-INVITE requests, disallowed |
|
14432 for INVITE. |
|
14433 |
|
14434 o PGP was removed. It was not sufficiently specified, and not |
|
14435 compatible with the more complete PGP MIME. It was replaced with |
|
14436 S/MIME. |
|
14437 |
|
14438 o Added the "sips" URI scheme for end-to-end TLS. This scheme is |
|
14439 not backwards compatible with RFC 2543. Existing elements that |
|
14440 receive a request with a SIPS URI scheme in the Request-URI will |
|
14441 likely reject the request. This is actually a feature; it ensures |
|
14442 that a call to a SIPS URI is only delivered if all path hops can |
|
14443 be secured. |
|
14444 |
|
14445 |
|
14446 |
|
14447 |
|
14448 |
|
14449 |
|
14450 Rosenberg, et. al. Standards Track [Page 258] |
|
14451 |
|
14452 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14453 |
|
14454 |
|
14455 o Additional security features were added with TLS, and these are |
|
14456 described in a much larger and complete security considerations |
|
14457 section. |
|
14458 |
|
14459 o In RFC 2543, a proxy was not required to forward provisional |
|
14460 responses from 101 to 199 upstream. This was changed to MUST. |
|
14461 This is important, since many subsequent features depend on |
|
14462 delivery of all provisional responses from 101 to 199. |
|
14463 |
|
14464 o Little was said about the 503 response code in RFC 2543. It has |
|
14465 since found substantial use in indicating failure or overload |
|
14466 conditions in proxies. This requires somewhat special treatment. |
|
14467 Specifically, receipt of a 503 should trigger an attempt to |
|
14468 contact the next element in the result of a DNS SRV lookup. Also, |
|
14469 503 response is only forwarded upstream by a proxy under certain |
|
14470 conditions. |
|
14471 |
|
14472 o RFC 2543 defined, but did no sufficiently specify, a mechanism for |
|
14473 UA authentication of a server. That has been removed. Instead, |
|
14474 the mutual authentication procedures of RFC 2617 are allowed. |
|
14475 |
|
14476 o A UA cannot send a BYE for a call until it has received an ACK for |
|
14477 the initial INVITE. This was allowed in RFC 2543 but leads to a |
|
14478 potential race condition. |
|
14479 |
|
14480 o A UA or proxy cannot send CANCEL for a transaction until it gets a |
|
14481 provisional response for the request. This was allowed in RFC |
|
14482 2543 but leads to potential race conditions. |
|
14483 |
|
14484 o The action parameter in registrations has been deprecated. It was |
|
14485 insufficient for any useful services, and caused conflicts when |
|
14486 application processing was applied in proxies. |
|
14487 |
|
14488 o RFC 2543 had a number of special cases for multicast. For |
|
14489 example, certain responses were suppressed, timers were adjusted, |
|
14490 and so on. Multicast now plays a more limited role, and the |
|
14491 protocol operation is unaffected by usage of multicast as opposed |
|
14492 to unicast. The limitations as a result of that are documented. |
|
14493 |
|
14494 o Basic authentication has been removed entirely and its usage |
|
14495 forbidden. |
|
14496 |
|
14497 |
|
14498 |
|
14499 |
|
14500 |
|
14501 |
|
14502 |
|
14503 |
|
14504 |
|
14505 |
|
14506 Rosenberg, et. al. Standards Track [Page 259] |
|
14507 |
|
14508 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14509 |
|
14510 |
|
14511 o Proxies no longer forward a 6xx immediately on receiving it. |
|
14512 Instead, they CANCEL pending branches immediately. This avoids a |
|
14513 potential race condition that would result in a UAC getting a 6xx |
|
14514 followed by a 2xx. In all cases except this race condition, the |
|
14515 result will be the same - the 6xx is forwarded upstream. |
|
14516 |
|
14517 o RFC 2543 did not address the problem of request merging. This |
|
14518 occurs when a request forks at a proxy and later rejoins at an |
|
14519 element. Handling of merging is done only at a UA, and procedures |
|
14520 are defined for rejecting all but the first request. |
|
14521 |
|
14522 28.2 Minor Functional Changes |
|
14523 |
|
14524 o Added the Alert-Info, Error-Info, and Call-Info header fields for |
|
14525 optional content presentation to users. |
|
14526 |
|
14527 o Added the Content-Language, Content-Disposition and MIME-Version |
|
14528 header fields. |
|
14529 |
|
14530 o Added a "glare handling" mechanism to deal with the case where |
|
14531 both parties send each other a re-INVITE simultaneously. It uses |
|
14532 the new 491 (Request Pending) error code. |
|
14533 |
|
14534 o Added the In-Reply-To and Reply-To header fields for supporting |
|
14535 the return of missed calls or messages at a later time. |
|
14536 |
|
14537 o Added TLS and SCTP as valid SIP transports. |
|
14538 |
|
14539 o There were a variety of mechanisms described for handling failures |
|
14540 at any time during a call; those are now generally unified. BYE |
|
14541 is sent to terminate. |
|
14542 |
|
14543 o RFC 2543 mandated retransmission of INVITE responses over TCP, but |
|
14544 noted it was really only needed for 2xx. That was an artifact of |
|
14545 insufficient protocol layering. With a more coherent transaction |
|
14546 layer defined here, that is no longer needed. Only 2xx responses |
|
14547 to INVITEs are retransmitted over TCP. |
|
14548 |
|
14549 o Client and server transaction machines are now driven based on |
|
14550 timeouts rather than retransmit counts. This allows the state |
|
14551 machines to be properly specified for TCP and UDP. |
|
14552 |
|
14553 o The Date header field is used in REGISTER responses to provide a |
|
14554 simple means for auto-configuration of dates in user agents. |
|
14555 |
|
14556 o Allowed a registrar to reject registrations with expirations that |
|
14557 are too short in duration. Defined the 423 response code and the |
|
14558 Min-Expires for this purpose. |
|
14559 |
|
14560 |
|
14561 |
|
14562 Rosenberg, et. al. Standards Track [Page 260] |
|
14563 |
|
14564 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14565 |
|
14566 |
|
14567 29 Normative References |
|
14568 |
|
14569 [1] Handley, M. and V. Jacobson, "SDP: Session Description |
|
14570 Protocol", RFC 2327, April 1998. |
|
14571 |
|
14572 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement |
|
14573 Levels", BCP 14, RFC 2119, March 1997. |
|
14574 |
|
14575 [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. |
|
14576 |
|
14577 [4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers", |
|
14578 RFC 3263, June 2002. |
|
14579 |
|
14580 [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource |
|
14581 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. |
|
14582 |
|
14583 [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for |
|
14584 Transport Layer Security (TLS)", RFC 3268, June 2002. |
|
14585 |
|
14586 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC |
|
14587 2279, January 1998. |
|
14588 |
|
14589 [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., |
|
14590 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- |
|
14591 HTTP/1.1", RFC 2616, June 1999. |
|
14592 |
|
14593 [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April |
|
14594 2000. |
|
14595 |
|
14596 [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax |
|
14597 Specifications: ABNF", RFC 2234, November 1997. |
|
14598 |
|
14599 [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail |
|
14600 Extensions (MIME) Part Two: Media Types", RFC 2046, November |
|
14601 1996. |
|
14602 |
|
14603 [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness |
|
14604 Recommendations for Security", RFC 1750, December 1994. |
|
14605 |
|
14606 [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with |
|
14607 SDP", RFC 3264, June 2002. |
|
14608 |
|
14609 [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August |
|
14610 1980. |
|
14611 |
|
14612 [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC |
|
14613 761, January 1980. |
|
14614 |
|
14615 |
|
14616 |
|
14617 |
|
14618 Rosenberg, et. al. Standards Track [Page 261] |
|
14619 |
|
14620 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14621 |
|
14622 |
|
14623 [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, |
|
14624 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, |
|
14625 "Stream Control Transmission Protocol", RFC 2960, October 2000. |
|
14626 |
|
14627 [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., |
|
14628 Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: |
|
14629 Basic and Digest Access Authentication", RFC 2617, June 1999. |
|
14630 |
|
14631 [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation |
|
14632 Information in Internet Messages: The Content-Disposition Header |
|
14633 Field", RFC 2183, August 1997. |
|
14634 |
|
14635 [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., |
|
14636 Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG |
|
14637 Objects", RFC 3204, December 2001. |
|
14638 |
|
14639 [20] Braden, R., "Requirements for Internet Hosts - Application and |
|
14640 Support", STD 3, RFC 1123, October 1989. |
|
14641 |
|
14642 [21] Alvestrand, H., "IETF Policy on Character Sets and Languages", |
|
14643 BCP 18, RFC 2277, January 1998. |
|
14644 |
|
14645 [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security |
|
14646 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", |
|
14647 RFC 1847, October 1995. |
|
14648 |
|
14649 [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June |
|
14650 1999. |
|
14651 |
|
14652 [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, |
|
14653 June 1999. |
|
14654 |
|
14655 [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC |
|
14656 2246, January 1999. |
|
14657 |
|
14658 [26] Kent, S. and R. Atkinson, "Security Architecture for the |
|
14659 Internet Protocol", RFC 2401, November 1998. |
|
14660 |
|
14661 30 Informative References |
|
14662 |
|
14663 [27] R. Pandya, "Emerging mobile and personal communication systems," |
|
14664 IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. |
|
14665 |
|
14666 [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, |
|
14667 "RTP: A Transport Protocol for Real-Time Applications", RFC |
|
14668 1889, January 1996. |
|
14669 |
|
14670 |
|
14671 |
|
14672 |
|
14673 |
|
14674 Rosenberg, et. al. Standards Track [Page 262] |
|
14675 |
|
14676 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14677 |
|
14678 |
|
14679 [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming |
|
14680 Protocol (RTSP)", RFC 2326, April 1998. |
|
14681 |
|
14682 [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and |
|
14683 J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November |
|
14684 2000. |
|
14685 |
|
14686 [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, |
|
14687 "SIP: Session Initiation Protocol", RFC 2543, March 1999. |
|
14688 |
|
14689 [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL |
|
14690 scheme", RFC 2368, July 1998. |
|
14691 |
|
14692 [33] E. M. Schooler, "A multicast user directory service for |
|
14693 synchronous rendezvous," Master's Thesis CS-TR-96-18, Department |
|
14694 of Computer Science, California Institute of Technology, |
|
14695 Pasadena, California, Aug. 1996. |
|
14696 |
|
14697 [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. |
|
14698 |
|
14699 [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April |
|
14700 1992. |
|
14701 |
|
14702 [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC |
|
14703 2426, September 1998. |
|
14704 |
|
14705 [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical |
|
14706 Specification", RFC 2849, June 2000. |
|
14707 |
|
14708 [38] Palme, J., "Common Internet Message Headers", RFC 2076, |
|
14709 February 1997. |
|
14710 |
|
14711 [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., |
|
14712 Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: |
|
14713 Digest Access Authentication", RFC 2069, January 1997. |
|
14714 |
|
14715 [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, |
|
14716 D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call |
|
14717 Flow Examples", Work in Progress. |
|
14718 |
|
14719 [41] E. M. Schooler, "Case study: multimedia conference control in a |
|
14720 packet-switched teleconferencing system," Journal of |
|
14721 Internetworking: Research and Experience, Vol. 4, pp. 99--120, |
|
14722 June 1993. ISI reprint series ISI/RS-93-359. |
|
14723 |
|
14724 |
|
14725 |
|
14726 |
|
14727 |
|
14728 |
|
14729 |
|
14730 Rosenberg, et. al. Standards Track [Page 263] |
|
14731 |
|
14732 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14733 |
|
14734 |
|
14735 [42] H. Schulzrinne, "Personal mobility for multimedia services in |
|
14736 the Internet," in European Workshop on Interactive Distributed |
|
14737 Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. |
|
14738 1996. |
|
14739 |
|
14740 [43] Floyd, S., "Congestion Control Principles", RFC 2914, September |
|
14741 2000. |
|
14742 |
|
14743 |
|
14744 |
|
14745 |
|
14746 |
|
14747 |
|
14748 |
|
14749 |
|
14750 |
|
14751 |
|
14752 |
|
14753 |
|
14754 |
|
14755 |
|
14756 |
|
14757 |
|
14758 |
|
14759 |
|
14760 |
|
14761 |
|
14762 |
|
14763 |
|
14764 |
|
14765 |
|
14766 |
|
14767 |
|
14768 |
|
14769 |
|
14770 |
|
14771 |
|
14772 |
|
14773 |
|
14774 |
|
14775 |
|
14776 |
|
14777 |
|
14778 |
|
14779 |
|
14780 |
|
14781 |
|
14782 |
|
14783 |
|
14784 |
|
14785 |
|
14786 Rosenberg, et. al. Standards Track [Page 264] |
|
14787 |
|
14788 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14789 |
|
14790 |
|
14791 A Table of Timer Values |
|
14792 |
|
14793 Table 4 summarizes the meaning and defaults of the various timers |
|
14794 used by this specification. |
|
14795 |
|
14796 Timer Value Section Meaning |
|
14797 ---------------------------------------------------------------------- |
|
14798 T1 500ms default Section 17.1.1.1 RTT Estimate |
|
14799 T2 4s Section 17.1.2.2 The maximum retransmit |
|
14800 interval for non-INVITE |
|
14801 requests and INVITE |
|
14802 responses |
|
14803 T4 5s Section 17.1.2.2 Maximum duration a |
|
14804 message will |
|
14805 remain in the network |
|
14806 Timer A initially T1 Section 17.1.1.2 INVITE request retransmit |
|
14807 interval, for UDP only |
|
14808 Timer B 64*T1 Section 17.1.1.2 INVITE transaction |
|
14809 timeout timer |
|
14810 Timer C > 3min Section 16.6 proxy INVITE transaction |
|
14811 bullet 11 timeout |
|
14812 Timer D > 32s for UDP Section 17.1.1.2 Wait time for response |
|
14813 0s for TCP/SCTP retransmits |
|
14814 Timer E initially T1 Section 17.1.2.2 non-INVITE request |
|
14815 retransmit interval, |
|
14816 UDP only |
|
14817 Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction |
|
14818 timeout timer |
|
14819 Timer G initially T1 Section 17.2.1 INVITE response |
|
14820 retransmit interval |
|
14821 Timer H 64*T1 Section 17.2.1 Wait time for |
|
14822 ACK receipt |
|
14823 Timer I T4 for UDP Section 17.2.1 Wait time for |
|
14824 0s for TCP/SCTP ACK retransmits |
|
14825 Timer J 64*T1 for UDP Section 17.2.2 Wait time for |
|
14826 0s for TCP/SCTP non-INVITE request |
|
14827 retransmits |
|
14828 Timer K T4 for UDP Section 17.1.2.2 Wait time for |
|
14829 0s for TCP/SCTP response retransmits |
|
14830 |
|
14831 Table 4: Summary of timers |
|
14832 |
|
14833 |
|
14834 |
|
14835 |
|
14836 |
|
14837 |
|
14838 |
|
14839 |
|
14840 |
|
14841 |
|
14842 Rosenberg, et. al. Standards Track [Page 265] |
|
14843 |
|
14844 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14845 |
|
14846 |
|
14847 Acknowledgments |
|
14848 |
|
14849 We wish to thank the members of the IETF MMUSIC and SIP WGs for their |
|
14850 comments and suggestions. Detailed comments were provided by Ofir |
|
14851 Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, |
|
14852 Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John |
|
14853 Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, |
|
14854 Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders |
|
14855 Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William |
|
14856 Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe |
|
14857 J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick |
|
14858 Workman. |
|
14859 |
|
14860 Brian Rosen provided the compiled BNF. |
|
14861 |
|
14862 Jean Mahoney provided technical writing assistance. |
|
14863 |
|
14864 This work is based, inter alia, on [41,42]. |
|
14865 |
|
14866 |
|
14867 |
|
14868 |
|
14869 |
|
14870 |
|
14871 |
|
14872 |
|
14873 |
|
14874 |
|
14875 |
|
14876 |
|
14877 |
|
14878 |
|
14879 |
|
14880 |
|
14881 |
|
14882 |
|
14883 |
|
14884 |
|
14885 |
|
14886 |
|
14887 |
|
14888 |
|
14889 |
|
14890 |
|
14891 |
|
14892 |
|
14893 |
|
14894 |
|
14895 |
|
14896 |
|
14897 |
|
14898 Rosenberg, et. al. Standards Track [Page 266] |
|
14899 |
|
14900 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14901 |
|
14902 |
|
14903 Authors' Addresses |
|
14904 |
|
14905 Authors addresses are listed alphabetically for the editors, the |
|
14906 writers, and then the original authors of RFC 2543. All listed |
|
14907 authors actively contributed large amounts of text to this document. |
|
14908 |
|
14909 Jonathan Rosenberg |
|
14910 dynamicsoft |
|
14911 72 Eagle Rock Ave |
|
14912 East Hanover, NJ 07936 |
|
14913 USA |
|
14914 |
|
14915 EMail: jdrosen@dynamicsoft.com |
|
14916 |
|
14917 |
|
14918 Henning Schulzrinne |
|
14919 Dept. of Computer Science |
|
14920 Columbia University |
|
14921 1214 Amsterdam Avenue |
|
14922 New York, NY 10027 |
|
14923 USA |
|
14924 |
|
14925 EMail: schulzrinne@cs.columbia.edu |
|
14926 |
|
14927 |
|
14928 Gonzalo Camarillo |
|
14929 Ericsson |
|
14930 Advanced Signalling Research Lab. |
|
14931 FIN-02420 Jorvas |
|
14932 Finland |
|
14933 |
|
14934 EMail: Gonzalo.Camarillo@ericsson.com |
|
14935 |
|
14936 |
|
14937 Alan Johnston |
|
14938 WorldCom |
|
14939 100 South 4th Street |
|
14940 St. Louis, MO 63102 |
|
14941 USA |
|
14942 |
|
14943 EMail: alan.johnston@wcom.com |
|
14944 |
|
14945 |
|
14946 |
|
14947 |
|
14948 |
|
14949 |
|
14950 |
|
14951 |
|
14952 |
|
14953 |
|
14954 Rosenberg, et. al. Standards Track [Page 267] |
|
14955 |
|
14956 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
14957 |
|
14958 |
|
14959 Jon Peterson |
|
14960 NeuStar, Inc |
|
14961 1800 Sutter Street, Suite 570 |
|
14962 Concord, CA 94520 |
|
14963 USA |
|
14964 |
|
14965 EMail: jon.peterson@neustar.com |
|
14966 |
|
14967 |
|
14968 Robert Sparks |
|
14969 dynamicsoft, Inc. |
|
14970 5100 Tennyson Parkway |
|
14971 Suite 1200 |
|
14972 Plano, Texas 75024 |
|
14973 USA |
|
14974 |
|
14975 EMail: rsparks@dynamicsoft.com |
|
14976 |
|
14977 |
|
14978 Mark Handley |
|
14979 International Computer Science Institute |
|
14980 1947 Center St, Suite 600 |
|
14981 Berkeley, CA 94704 |
|
14982 USA |
|
14983 |
|
14984 EMail: mjh@icir.org |
|
14985 |
|
14986 |
|
14987 Eve Schooler |
|
14988 AT&T Labs-Research |
|
14989 75 Willow Road |
|
14990 Menlo Park, CA 94025 |
|
14991 USA |
|
14992 |
|
14993 EMail: schooler@research.att.com |
|
14994 |
|
14995 |
|
14996 |
|
14997 |
|
14998 |
|
14999 |
|
15000 |
|
15001 |
|
15002 |
|
15003 |
|
15004 |
|
15005 |
|
15006 |
|
15007 |
|
15008 |
|
15009 |
|
15010 Rosenberg, et. al. Standards Track [Page 268] |
|
15011 |
|
15012 RFC 3261 SIP: Session Initiation Protocol June 2002 |
|
15013 |
|
15014 |
|
15015 Full Copyright Statement |
|
15016 |
|
15017 Copyright (C) The Internet Society (2002). All Rights Reserved. |
|
15018 |
|
15019 This document and translations of it may be copied and furnished to |
|
15020 others, and derivative works that comment on or otherwise explain it |
|
15021 or assist in its implementation may be prepared, copied, published |
|
15022 and distributed, in whole or in part, without restriction of any |
|
15023 kind, provided that the above copyright notice and this paragraph are |
|
15024 included on all such copies and derivative works. However, this |
|
15025 document itself may not be modified in any way, such as by removing |
|
15026 the copyright notice or references to the Internet Society or other |
|
15027 Internet organizations, except as needed for the purpose of |
|
15028 developing Internet standards in which case the procedures for |
|
15029 copyrights defined in the Internet Standards process must be |
|
15030 followed, or as required to translate it into languages other than |
|
15031 English. |
|
15032 |
|
15033 The limited permissions granted above are perpetual and will not be |
|
15034 revoked by the Internet Society or its successors or assigns. |
|
15035 |
|
15036 This document and the information contained herein is provided on an |
|
15037 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
|
15038 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
|
15039 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
|
15040 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
|
15041 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
|
15042 |
|
15043 Acknowledgement |
|
15044 |
|
15045 Funding for the RFC Editor function is currently provided by the |
|
15046 Internet Society. |
|
15047 |
|
15048 |
|
15049 |
|
15050 |
|
15051 |
|
15052 |
|
15053 |
|
15054 |
|
15055 |
|
15056 |
|
15057 |
|
15058 |
|
15059 |
|
15060 |
|
15061 |
|
15062 |
|
15063 |
|
15064 |
|
15065 |
|
15066 Rosenberg, et. al. Standards Track [Page 269] |
|
15067 |