|
0
|
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 |
|