idnits 2.17.1 draft-ietf-sipcore-199-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 30, 2011) is 4833 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track January 30, 2011 5 Expires: August 3, 2011 7 Session Initiation Protocol (SIP) Response Code for Indication of 8 Terminated Dialog 9 draft-ietf-sipcore-199-04.txt 11 Abstract 13 This specification defines a new Session Initiation Protocol (SIP) 14 response code, 199 Early Dialog Terminated, that a SIP forking proxy 15 and a User Agent Server (UAS) can use to indicate towards upstream 16 SIP entities (including the User Agent Client (UAC)) that an early 17 dialog has been terminated, before a final response is sent towards 18 the SIP entities. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 3, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Applicability and Limitation . . . . . . . . . . . . . . . . . 4 57 4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 5 58 5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 6 59 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 9 61 8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9 62 9. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 10 63 10. Message Flow Examples . . . . . . . . . . . . . . . . . . . . 10 64 10.1. Example with a forking proxy which generates 199 . . . . 10 65 10.2. Example with a forking proxy which receives 200 OK . . . 11 66 10.3. Example with two forking proxies, of which one 67 generates 199 . . . . . . . . . . . . . . . . . . . . . . 12 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 12.1. IANA Registration of the 199 response code . . . . . . . 14 71 12.2. IANA Registration of the 199 option-tag . . . . . . . . . 14 72 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 73 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 15.2. Informational References . . . . . . . . . . . . . . . . 16 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP) 82 early dialog is created when a non-100 provisional response is sent 83 to the initial dialog initiation request (e.g. INVITE, outside an 84 existing dialog). The dialog is considered to be in early state 85 until a final response is sent. 87 When a proxy receives an initial dialog initiation request, it can 88 forward the request towards multiple remote destinations. When the 89 proxy does that, it performs forking [RFC3261]. 91 When a forking proxy receives a non-100 provisional response, or a 92 2xx final response, it forwards the response upstream towards the 93 sender of the associated request. After a forking proxy has 94 forwarded a 2xx final response, it normally generates and sends 95 CANCEL requests downstream towards all remote destinations where it 96 previously forked the request associated with the 2xx final response 97 and from which it has yet not received a final response. The CANCEL 98 requests are sent in order to terminate any outstanding early dialogs 99 associated with the request. 101 Upstream SIP entities might receive multiple 2xx final responses. 102 When a SIP entity receives the first 2xx final response, and it does 103 not intend to accept any subsequent 2xx final response, it will 104 automatically terminate any other outstanding early dialog associated 105 with the request. If the SIP entity receives a subsequent 2xx final 106 response, it will normally generate and send an ACK request, followed 107 with a BYE request, using the dialog identifier retrieved from the 108 2xx final response. 110 NOTE: A User Agent Client (UAC) can use the Request-Disposition 111 header field [RFC3841] to request that proxies do not generate and 112 send CANCEL requests downstream once they have received the first 2xx 113 final response. 115 When a forking proxy receives a non-2xx final response, it does not 116 always immediately forward the response upstream towards the sender 117 of the associated request. Instead, the proxy "stores" the response 118 and waits for subsequent final responses from other remote 119 destinations where the associated request was forked. At some point 120 the proxy uses a specified mechanism to determine the "best" final 121 response code, and forwards a final response using that response code 122 upstream towards the sender of the associated request. When an 123 upstream SIP entity receives the non-2xx final response it will 124 release resources associated with the session. The UAC will 125 terminate, or retry, the session setup. 127 Since the forking proxy does not always immediately forward non-2xx 128 final responses, upstream SIP entities (including the UAC that 129 initiated the request) are not immediately informed that an early 130 dialog has been terminated, and will therefore maintain resources 131 associated with the early dialog reserved until a final response is 132 sent by the proxy, even if the early dialog has already been 133 terminated. A SIP entity could use the resources for other things, 134 e.g. to accept subsequent early dialogs that it otherwise would 135 reject. 137 This specification defines a new SIP response code, 199 Early Dialog 138 Terminated. A forking proxy can send a 199 provisional response to 139 inform upstream SIP entities that an early dialog has been 140 terminated. A UAS can send a 199 response code, prior to sending a 141 non-2xx final response, for the same purpose. SIP entities that 142 receive the 199 response can use it to trigger the release of 143 resources associated with the terminated early dialog. In addition, 144 SIP entities might also use the 199 response to make policy related 145 decisions related to early dialogs. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 3. Applicability and Limitation 155 The 199 response code is an optimization, and it only optimizes how 156 quickly recipients might be informed about terminated early dialogs. 157 The achieved optimization is limited. Since the response is normally 158 not sent reliably by an UAS, and can not be sent reliably when 159 generated and sent by a proxy, it is possible that some or all of the 160 199 responses get lost before they reach the recipients. In such 161 cases, recipients will behave the same as if the 199 response code 162 were not used at all. 164 One example for which a UAC could use the 199 response, is that when 165 it receives a 199 response it releases resources associated with the 166 terminated early dialog. The UAC could also use the 199 response to 167 make policy related decisions related to early dialogs. For example, 168 if a UAC is playing media associated with an early dialog, and the it 169 receives a 199 response indicating the early dialog has been 170 terminated, it could start playing media associated with a different 171 early dialog. 173 Applications designers utilizing the 199 response code MUST ensure 174 that the application's user experience is acceptable if all 199 175 responses are lost, and not delivered to the recipients. 177 4. User Agent Client behavior 179 When a UAC sends an initial dialog initiation request, and if it is 180 willing to receive 199 responses, it MUST insert an "199" option-tag 181 in the Supported header field [RFC3261] of the request. The option- 182 tag indicates that the UAC supports, and is willing to receive, 199 183 responses. A UAC SHOULD NOT insert an "199" option-tag in the 184 Require or the Proxy-Require header field [RFC3261] of the request, 185 since in many cases it would result in unnecessary session 186 establishment failures. 188 NOTE: The UAC always needs to insert an "199" option-tag in the 189 Supported header field, in order to indicate that it supports, and is 190 willing to receive, 199 responses, even if it also inserts the 191 option-tag in the Require or Proxy-Require header field. 193 It is RECOMMENDED that a UAC does not insert an "100rel" option-tag 194 [RFC3262] in the Require header field when it also indicates support 195 of 199 responses, unless the UAC also uses some other SIP extension 196 or procedure that mandates it to do so. The reason is that proxies 197 are not allowed to generate and send 199 responses when the UAC has 198 required provisional responses to be sent reliably. 200 When a UAC receives a 199 response, it might release resources 201 associated with the terminated early dialog. A UAC might also use 202 the 199 response to make policy related decisions related to early 203 dialogs. 205 NOTE: The 199 response indicates that the early dialog has been 206 terminated, so there is no need for the UAC to send a BYE request in 207 order to terminate the early dialog when it receives the 199 208 response. 210 NOTE: The 199 response does not affect other early dialogs associated 211 with the session establishment. For those the normal SIP rules, 212 regarding transaction timeout etc, still apply. 214 Once a UAC has received and accepted a 199 response, it MUST NOT send 215 or process any media associated with the early dialog that was 216 terminated. 218 If multiple usages [RFC5057] are used within an early dialog, and it 219 is not clear which dialog usage the 199 response terminates, SIP 220 entities that keep dialog state SHALL NOT release resources 221 associated with the early dialog when they receive the 199 response. 223 If a UAC receives an unreliably sent 199 response on a dialog which 224 has not previously been established (this can happen if a 199 225 response reaches the client before the 18x response that would 226 establish the early dialog) it SHALL discard the 199 responses. If a 227 UAC receives a reliably sent 199 response on a dialog which has not 228 previously been created, it MUST acknowledge the 199 response, as 229 described in RFC 3262 [RFC3262]. 231 If a UAC has received a 199 response for all early dialogs, and no 232 early dialog associated session establishment remains, it maintains 233 the "Proceeding" state [RFC3261] and waits for possible subsequent 234 early dialogs to be established, and eventually for a final response 235 to be received. 237 5. User Agent Server behavior 239 If a UAS receives an initial dialog initiation request, with a 240 Supported header field that contains a "199" option-tag, it SHOULD 241 NOT send a 199 response on an early dialog associated with the 242 request, on which it intends to send a final response, unless it e.g. 243 has been configured to do so due to lack of support of the 199 244 response code by forking proxies or other intermediate SIP entities, 245 or it is used in an environment that specifies that it shall send a 246 199 response. 248 NOTE: If a UAS has created multiple early dialogs associated with an 249 initial dialog initiation request (the UAS is acting similar to a 250 forking proxy), it does not always intend to send a final response on 251 all of those early dialogs. 253 NOTE: If the Require header field of an initial dialog initiation 254 request contains a "100rel" option-tag, proxies will not be able to 255 generate and send 199 responses. In such cases the UAS might choose 256 to send a 199 response on an early dialog on which it intends to send 257 a final response, even if it would not do it in other cases. 259 If the Supported header field of an initial dialog initiation request 260 does not contain an "199" option-tag, the UAC MUST NOT send a 199 261 response on any early dialog associated with the request. 263 When a UAS generates a 199 response, the response MUST contain a To 264 header field tag parameter [RFC3261], in order for other entities to 265 identify the early dialog that has been terminated. The UAS MUST 266 also insert a Reason header field [RFC3326] that contains a response 267 code which describes the reason why the early dialog was terminated. 268 The UAS MUST NOT insert a "199" option-tag in the Supported, Require 269 or Proxy-Require header field of the 199 response. 271 If a UAS intends to send 199 responses, and if it supports the 272 procedures defined in RFC 3840 [RFC3840], it MAY during the 273 registration procedure use the sip.extensions feature tag [RFC3840] 274 to indicate support of the 199 response code. 276 A 199 response SHOULD NOT contain an SDP offer/answer message body, 277 unless required by the rules in RFC 3264 [RFC3264]. 279 According to RFC 3264, if an INVITE request does not contain an SDP 280 offer, and the 199 response is the first reliably sent response 281 associated with the request, the 199 response is required to contain 282 an SDP offer. In this case the UAS SHOULD send the 199 response 283 unreliably, or send the 199 response reliably and include an SDP 284 offer with no m- lines in the response. 286 Since a 199 response is only used for information purpose, the UAS 287 SHOULD send it unreliably, unless the "100rel" option-tag is present 288 in the Require header field of the associated request. 290 Once a UAS has sent a 199 response, it MUST NOT send or process any 291 media associated with the terminated early dialog. 293 6. Proxy behavior 295 When a proxy receives a 199 response to an initial dialog initiation 296 request, it MUST process the response as any other non-100 297 provisional response. The proxy will forward the response upstream 298 towards the sender of the associated request. The proxy MAY release 299 resources it has reserved associated with the early dialog that is 300 terminated. If a proxy receives a 199 response out of dialog, it 301 MUST process it as other non-100 provisional responses received out 302 of dialog. 304 When a forking proxy receives a non-2xx final response to an initial 305 dialog initiation request, that it recognizes as terminating one or 306 more early dialogs associated with the request, it MUST generate and 307 send a 199 response upstream for each of the terminated early dialogs 308 that satisfy each of the following conditions: 310 - the forking proxy does not intend to forward the final response 311 immediately (in accordance with rules for a forking proxy) 313 - the UAC has indicated support (by inserting the "199" option-tag in 314 a Supported header field) of the 199 response code in the associated 315 request 317 - the UAC has not required provisional responses to be sent reliably 318 (by inserting the "100rel" option-tag in a Require or Proxy-Require 319 header field) in the associated request 321 - the forking proxy has not already received and forwarded a 199 322 response for the early dialog 324 - the forking proxy has not already sent a final response for any of 325 the early dialogs 327 As a consequence, once a final response to an initial dialog 328 initiation request has been issued by the proxy, no further 199 329 responses associated with the request will be generated or forwarded 330 by the proxy. 332 When a forking proxy forks an initial dialog initiation request, it 333 generates a unique Via header branch parameter value for each forked 334 leg. A proxy can determine whether additional forking has occurred 335 downstream of the proxy by storing the top Via branch value from each 336 response which creates an early dialog. If the same top Via branch 337 value is received for multiple early dialogs, the proxy knows that 338 additional forking has occurred downstream of the proxy. A non-2xx 339 final response received for a specific early dialog also terminates 340 all other early dialog for which the same top Via branch value was 341 received in the responses which created those early dialogs. 343 Based on implementation policy, a forking proxy MAY wait before 344 sending the 199 response, e.g. if it expects to receive a 2xx final 345 response on another dialog shortly after it received the non-2xx 346 final response which triggered the 199 response. 348 When a forking proxy generates a 199 response, the response MUST 349 contain a To header field tag parameter, that identifies the 350 terminated early dialog. A proxy MUST also insert a Reason header 351 field that contains the SIP response code of the response that 352 triggered the 199 response. The SIP response code in the Reason 353 header field informs the receiver of the 199 response about the SIP 354 response code that was used by the UAS to terminate the early dialog, 355 and the receiver might use that information for triggering different 356 types of actions and procedures. The proxy MUST NOT insert a "199" 357 option-tag in the Supported, Require or Proxy-Require header field of 358 the 199 response. 360 A forking proxy that supports generating of 199 responses MUST keep 361 track of early dialogs, in order to determine whether to generate a 362 199 response when the proxy receives a non-2xx final response. In 363 addition, a proxy MUST keep track on which early dialogs it has 364 received and forwarded 199 responses, in order to not generate 365 additional 199 responses for those early dialogs. 367 If a forking proxy receives a reliably sent 199 response for a 368 dialog, for which it has previously generated and sent a 199 369 response, it MUST forward the 199 response. If a proxy receives an 370 unreliably sent 199 response, for which it has previously generated 371 and sent a 199 response, it MAY forward the response, or it MAY 372 discard it. 374 When a forking proxy generates and sends a 199 response, the response 375 SHOULD NOT contain a Contact header field or a Record-Route header 376 field [RFC3261]. 378 If the Require header field of an initial dialog initiation request 379 contains an "100rel" option-tag, a proxy MUST NOT generate and send 380 send 199 responses associated with that request. The reason is that 381 a proxy is not allowed to generate and send 199 responses reliably. 383 7. Backward compatibility 385 Since all SIP entities involved in a session setup do not necessarily 386 support the specific meaning of the 199 Early Dialog Terminated 387 provisional response, the sender of the response MUST be prepared to 388 receive SIP requests and responses associated with the dialog for 389 which the 199 response was sent (a proxy can receive SIP messages 390 from either direction). If such request is received by a UA, it MUST 391 act in the same way as if it had received the request after sending 392 the final non-2xx response to the INVITE request, as specified in RFC 393 3261. A UAC that receives a 199 response for an early dialog MUST 394 NOT send any further requests on that dialog, except for requests 395 which acknowledge reliable responses. A proxy MUST forward requests 396 according to RFC 3261, even if the proxy has knowledge that the early 397 dialog has been terminated. 399 A 199 response does not "replace" a final response. RFC 3261 400 specifies when a final response is sent. 402 8. Usage with SDP offer/answer 404 A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264] 405 message body, unless required by the rules in RFC 3264. 407 If an INVITE request does not contain an SDP offer, and the 199 408 response is the first reliably sent response, the 199 response is 409 required to contain an SDP offer. In this case the UAS SHOULD send 410 the 199 response unreliable, or include an SDP offer with no m- lines 411 in a reliable 199 response. 413 9. Usage with 100rel 415 Since the 199 response is only used for information purpose, a UAS 416 SHOULD send it unreliably, unless the Require header field of the 417 associated request contains an "100rel" option-tag. 419 When a forking proxy generates and sends a 199 response, it MUST NOT 420 send the response reliably. A forking proxy MUST NOT send a 199 421 response if the Require header field of the associated request 422 contains an "100rel" option-tag. 424 NOTE: If a forking proxy would generate and send a 199 response 425 reliably, it would have to terminate the associated PRACK request 426 [RFC3262]. 428 10. Message Flow Examples 430 10.1. Example with a forking proxy which generates 199 432 The figure shows an example, where a proxy (P1) forks an INVITE 433 received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4, 434 which send 18x provisional responses in order to establish early 435 dialogs between themselves and the UAC. UAS_2 and UAS_3 reject the 436 INVITE by sending a 4xx error response each. When P1 receives the 437 4xx responses it immediately sends 199 responses towards the UAC, to 438 indicate that the early dialogs for which it received the 4xx 439 responses have been terminated. The early dialog leg is shown in 440 parenthesis. 442 UAC P1 UAS_2 UAS_3 UAS_4 443 | | | | | 444 |-- INVITE -->| | | | 445 | |--- INVITE (2) ->| | | 446 | |--- INVITE (3) --------->| | 447 | |--- INVITE (4) ----------------->| 448 | |<-- 18x (2) -----| | | 449 |<- 18x (2) --| | | | 450 | |<-- 18x (3) -------------| | 451 |<- 18x (3) --| | | | 452 | |<-- 18x (4) ---------------------| 453 |<- 18x (4) --| | | | 454 | |<-- 4xx (2) -----| | | 455 | |--- ACK (2) ---->| | | 456 |<- 199 (2) --| | | | 457 | |<-- 4xx (3) -------------| | 458 | |--- ACK (3) ------------>| | 459 |<- 199 (3) --| | | | 460 | |<-- 200 (4) ---------------------| 461 |<- 200 (4) --| | | | 462 |-- ACK (4) ->| | | | 463 | |--- ACK (4) -------------------->| 464 | | | | | 466 Figure 1: Example call flow 468 10.2. Example with a forking proxy which receives 200 OK 470 The figure shows an example, where a proxy (P1) forks an INVITE 471 request received from UAC. The forked request reaches UAS_2, UAS_3 472 and UAS_4, that all send 18x provisional responses in order to 473 establish early dialogs between themselves and the UAC. Later UAS_4 474 accepts the session and sends a 200 OK final response. When P1 475 receives the 200 OK responses it immediately forwards it towards the 476 UAC. P1 does not send 199 responses for the early dialogs from UAS_2 477 and UAS_3, since P1 has yet not received any final responses on those 478 early dialogs (even if P1 sends CANCEL requests to UAS_2 and UAS_3 P1 479 may still receive 200 OK final response from UAS_2 or UAS_3, that P1 480 would have to forward towards the UAC. The early dialog leg is shown 481 in parenthesis. 483 UAC P1 UAS_2 UAS_3 UAS_4 484 | | | | | 485 |-- INVITE -->| | | | 486 | |--- INVITE (2) ->| | | 487 | |--- INVITE (3) --------->| | 488 | |--- INVITE (4) ----------------->| 489 | |<-- 18x (2) -----| | | 490 |<- 18x (2) --| | | | 491 | |<-- 18x (3) -------------| | 492 |<- 18x (3) --| | | | 493 | |<-- 18x (4) ---------------------| 494 |<- 18x (4) --| | | | 495 | |<-- 200 (4) ---------------------| 496 |<- 200 (4) --| | | | 497 |-- ACK (4) ->| | | | 498 | |--- ACK (4) -------------------->| 499 | | | | | 501 Figure 2: Example call flow 503 10.3. Example with two forking proxies, of which one generates 199 505 The figure shows an example, where a proxy (P1) forks an INVITE 506 request received from UAC. One of the forked requests reaches UAS_2. 507 The other requests reach another proxy (P2), that forks the request 508 to UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses 509 in order to establish early dialogs between themselves and UAC. 510 Later UAS_3 and UAS_4 reject the INVITE request by sending a 4xx 511 error response each. P2 does not support the 199 response code, and 512 forwards a single 4xx response. P1 supports the 199 response code, 513 and when it receives the 4xx response from P2, it also manages to 514 associate the early dialogs from both UAS_3 and UAS_4 with the 515 response. Therefore it generates and sends two 199 responses to 516 indicate that the early dialogs from UAS_3 and UAS_4 have been 517 terminated. The early dialog leg is shown in parenthesis. 519 UAC P1 P2 UAS_2 UAS_3 UAS_4 520 | | | | | | 521 |-- INVITE -->| | | | | 522 | |-- INVITE (2) ------------------>| | | 523 | |-- INVITE ---->| | | | 524 | | |--- INVITE (3) --------->| | 525 | | |--- INVITE (4) ----------------->| 526 | | |<-- 18x (3) -------------| | 527 | |<- 18x (3) ----| | | | 528 |<- 18x (3) --| | | | | 529 | | |<-- 18x (4) ---------------------| 530 | |<- 18x (4) ----| | | | 531 |<- 18x (4) --| | | | | 532 | | |<-- 4xx (3) -------------| | 533 | | |--- ACK (3) ------------>| | 534 | | |<-- 4xx (4) ---------------------| 535 | | |--- ACK (4) -------------------->| 536 | |<- 4xx (3) ----| | | | 537 | |-- ACK (3) --->| | | | 538 |<- 199 (3) --| | | | | 539 |<- 199 (4) --| | | | | 540 | |<- 200 (2) ----------------------| | | 541 |<- 200 (2) --| | | | | 542 |-- ACK (2) ->| | | | | 543 | |-- ACK (2) --------------------->| | | 544 | | | | | | 546 Figure 3: Example call flow 548 11. Security Considerations 550 General security issues related to SIP responses are described in RFC 551 3261. Due to the nature of the 199 response, it may be attractive to 552 use it for launching attacks in order to terminate specific early 553 dialogs (other early dialogs will not be affected). In addition, if 554 a man-in-the-middle generates and sends a 199 response, which 555 terminates a specific dialog, towards the UAC, it can take a while 556 until the UAS finds out that the UAC, and possible stateful 557 intermediates, have terminated the dialog. SIP security mechanisms 558 (e.g. hop-to-hop TLS) can be used to minimize, or eliminate, the risk 559 for such attacks. 561 12. IANA Considerations 563 This section registers a new SIP response code and a new option-tag, 564 according to the procedures of RFC 3261. 566 12.1. IANA Registration of the 199 response code 568 This section registers a new SIP response code, 199. The required 569 information for this registration, as specified in RFC 3261, is: 571 RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 572 RFC number of this specification]] 574 Response Code Number: 199 576 Default Reason Phrase: Early Dialog Terminated 578 12.2. IANA Registration of the 199 option-tag 580 This section registers a new SIP option-tag, 199. The required 581 information for this registration, as specified in RFC 3261, is: 583 Name: 199 585 Description: This option-tag is for indicating support of the 199 586 Early Dialog Terminated provisional response code. When present 587 in a Supported header of a request, it indicates that the UAC 588 supports the 199 response code. When present in a Require or 589 Proxy-Require header field of a request, it indicates that the 590 UAS, or proxies, MUST support the 199 response code. It does 591 not require the UAS, or proxies, to actually send 199 592 responses. 594 13. Acknowledgements 596 Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet, 597 Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan, 598 Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo 599 Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith 600 Drage, Hans Erik van Elburg and Cullen Jennings for their feedback 601 and suggestions. 603 14. Change Log 605 [RFC EDITOR NOTE: Please remove this section when publishing] 607 Changes from draft-ietf-sipcore-199-03 608 o RFC 3262 update removed 609 o Functional modification: proxy must not send 199 in case of 610 Require:100rel 611 o Recommendation that UAC does not require reliable provisional 612 responses with 199 613 o Clarification that Require:199 does not mandate the UAS to send a 614 199 response 615 o Clarification that a UAC needs to insert the 199 option-tag in a 616 Supported header field, even if it also inserts the option-tag in 617 a Require or Proxy-Require header field 618 o Editorial corrections 620 Changes from draft-ietf-sipcore-199-02 621 o Usage example section rewritten and clarified 622 o Requirement has been removed 623 o SIP has been added to document title 624 o Acronyms expanded in the abstract and throughout the document 625 o Editorial fixes throughout the document 626 o Indication added that document is aimed for standards track 627 o Some references made informative 628 o Additional text added regarding the usage of the Reason header 629 o SBC latching text has been removed 630 o Usage of Require/Proxy-Require header removed 631 o Additional text added regarding sending SDP offer in 199 632 o Note added, which clarifies that 199 does not affect other early 633 dialogs 634 o References added to Security Considerations 635 o Clarification of local ringing tone 636 o Clarification that media must not be sent or processed after 199 637 o Text regarding sending media on terminated dialogs added to 638 security section 639 o Change: UAS must send 199 reliably in case of Require:100rel 640 o Change: Section 4 of RFC 3262 updated 642 15. References 644 15.1. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 650 A., Peterson, J., Sparks, R., Handley, M., and E. 651 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 652 June 2002. 654 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 655 Provisional Responses in Session Initiation Protocol 656 (SIP)", RFC 3262, June 2002. 658 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 659 with Session Description Protocol (SDP)", RFC 3264, 660 June 2002. 662 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 663 Header Field for the Session Initiation Protocol (SIP)", 664 RFC 3326, December 2002. 666 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 667 "Indicating User Agent Capabilities in the Session 668 Initiation Protocol (SIP)", RFC 3840, August 2004. 670 15.2. Informational References 672 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 673 Preferences for the Session Initiation Protocol (SIP)", 674 RFC 3841, August 2004. 676 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 677 Initiation Protocol", RFC 5057, November 2007. 679 [3GPP.24.182] 680 3GPP, "IP Multimedia Subsystem (IMS) Customized Alerting 681 Tones (CAT); Protocol specification", 3GPP TS 24.182. 683 [3GPP.24.628] 684 3GPP, "Common Basic Communication procedures using IP 685 Multimedia (IM)Core Network (CN) subsystem; Protocol 686 specification", 3GPP TS 24.628. 688 Author's Address 690 Christer Holmberg 691 Ericsson 692 Hirsalantie 11 693 Jorvas 02420 694 Finland 696 Email: christer.holmberg@ericsson.com