idnits 2.17.1 draft-ietf-sipcore-199-03.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3262, but the abstract doesn't seem to directly say this. It does mention RFC3262 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3262, updated by this document, for RFC5378 checks: 2000-01-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 9, 2010) is 4887 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 (==), 3 comments (--). 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 Updates: 3262 (if approved) December 9, 2010 5 Intended status: Standards Track 6 Expires: June 12, 2011 8 Session Initiation Protocol (SIP) Response Code for Indication of 9 Terminated Dialog 10 draft-ietf-sipcore-199-03.txt 12 Abstract 14 This specification defines a new Session Initiation Protocol (SIP) 15 response code, 199 Early Dialog Terminated, that a SIP forking proxy 16 and a User Agent Server (UAS) can use to indicate towards upstream 17 SIP entities (including the User Agent Client (UAC)) that an early 18 dialog has been terminated, before a final response is sent towards 19 the SIP entities. In addition, this specification updates section 4 20 of RFC 3262. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 12, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Applicability and Limitation . . . . . . . . . . . . . . . . . 4 59 4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 5 60 5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 6 61 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 8 63 8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9 64 9. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 9 65 10. Normative update of RFC 3262 . . . . . . . . . . . . . . . . . 9 66 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.2. RFC3262: 4. UAC Behavior . . . . . . . . . . . . . . . . 9 68 11. Message Flow Examples . . . . . . . . . . . . . . . . . . . . 10 69 11.1. Example with a forking proxy which generates 199 . . . . 10 70 11.2. Example with a forking proxy which receives 200 OK . . . 10 71 11.3. Example with two forking proxies, of which one 72 generates 199 . . . . . . . . . . . . . . . . . . . . . . 11 73 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 13.1. IANA Registration of the 199 response code . . . . . . . 13 76 13.2. IANA Registration of the 199 option-tag . . . . . . . . . 13 77 13.3. RFC 3262 Update . . . . . . . . . . . . . . . . . . . . . 13 78 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 79 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 16.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 16.2. Informational References . . . . . . . . . . . . . . . . 15 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP) 88 early dialog is created when a non-100 provisional response is sent 89 to the initial dialog initiation request (e.g. INVITE, outside an 90 existing dialog). The dialog is considered to be in early state 91 until a final response is sent. 93 When a proxy receives an initial dialog initiation request, it can 94 forward the request towards multiple remote destinations. When the 95 proxy does that, it performs forking [RFC3261]. 97 When a forking proxy receives a non-100 provisional response, or a 98 2xx final response, it forwards the response upstream towards the 99 sender of the associated request. After a forking proxy has 100 forwarded a 2xx final response, it normally generates and sends 101 CANCEL requests downstream towards all remote destinations where it 102 previously forked the request associated with the 2xx final response 103 and from which it has yet not received a final response. The CANCEL 104 requests are sent in order to terminate any outstanding early dialogs 105 associated with the request. 107 Upstream SIP entities might receive multiple 2xx final responses. 108 When a SIP entity receives the first 2xx final response, and it does 109 not intend to accept any subsequent 2xx final response, it will 110 automatically terminate any other outstanding early dialog associated 111 with the request. If the SIP entity receives a subsequent 2xx final 112 response, it will normally generate and send an ACK request, followed 113 with a BYE request, using the dialog identifier retrieved from the 114 2xx final response. 116 NOTE: A User Agent Client (UAC) can use the Request-Disposition 117 header field [RFC3841] to request that proxies do not generate and 118 send CANCEL requests downstream once they have received the first 2xx 119 final response. 121 When a forking proxy receives a non-2xx final response, it does not 122 always immediately forward the response upstream towards the sender 123 of the associated request. Instead, the proxy "stores" the response 124 and waits for subsequent final responses from other remote 125 destinations where the associated request was forked. At some point 126 the proxy uses a specified mechanism to determine the "best" final 127 response code, and forwards a final response using that response code 128 upstream towards the sender of the associated request. When an 129 upstream SIP entity receives the non-2xx final response it will 130 release resources associated with the session. The UAC will 131 terminate, or retry, the session setup. 133 Since the forking proxy does not always immediately forward non-2xx 134 final responses, upstream SIP entities (including the UAC that 135 initiated the request) are not immediately informed that an early 136 dialog has been terminated, and will therefor maintain resources 137 associated with the early dialog reserved until a final response is 138 sent by the proxy, even if the early dialog has already been 139 terminated. A SIP entity could use the resources for other things, 140 e.g. to accept subsequent early dialogs that it otherwise would 141 reject. 143 This specification defines a new SIP response code, 199 Early Dialog 144 Terminated. A forking proxy can send a 199 provisional response to 145 inform upstream SIP entities that an early dialog has been 146 terminated. A UAS can send a 199 response code, prior to sending a 147 non-2xx final response, for the same purpose. SIP entities that 148 receive the 199 response can use it to release resources associated 149 with the terminated early dialog. In addition, SIP entities might 150 also use the 199 provisional response to make policy related 151 decisions related to early dialogs. 153 This specification updates RFC 3262 [RFC3841], by mandating a UAC to 154 be prepared to receive unreliably sent provisional responses even if 155 it has required provisional responses to be sent reliably. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 3. Applicability and Limitation 165 The 199 response code is an optimization, and it only optimizes how 166 quickly receipients might be informed about terminated early dialogs. 167 The achieved optimization is limited. Since the response is normally 168 not sent reliably by an UAS, and can not be sent reliably when 169 generated and sent by a proxy, it is possible that some or all of the 170 199 responses get lost before they reach the receipients. In such 171 cases, recipients will behave the same as if the 199 response code 172 were not used at all. 174 One example for which a UA could use the 199 response, is that when 175 it receives a 199 response it releases resources associated with the 176 terminated early dialog. It could also use the 199 response to make 177 policy related decisions related to early dialogs. For example, if a 178 UAC is playing media associated with an early dialog, and the it 179 receives a 199 response indicating the early dialog has been 180 terminated, it could start playing media associated with a different 181 early dialog. 183 Applications designers utilizing the 199 response code MUST ensure 184 that the application's user experience is acceptable if all 199 185 responses are lost, and not delivered to the receipients. 187 4. User Agent Client behavior 189 When a UAC sends an initial request, and if it is willing to receive 190 199 responses, it MUST insert the "199" option-tag in the Supported 191 header field. The option-tag indicates that the UAC supports 199 192 responses. The UAC SHOULD NOT insert the "199" option-tag in the 193 Require or the Proxy-Require header fields, since in many cases it 194 would result in unnecessary session establishment failures. 196 When a UAC receives a 199 response it might release resources 197 associated with the terminated early dialog. It might also use the 198 199 response to make policy related decisions related to early 199 dialogs. 201 NOTE: The 199 response indicates that the early dialog has been 202 terminated, so there is no need for the UAC to send a BYE request in 203 order to terminate the early dialog when it receives the 199 204 response. 206 NOTE: The 199 response does not affect other early dialogs associated 207 with the session establishment. For those the normal SIP rules, 208 regarding transaction timeout etc, still apply. 210 Once the UAC has received and accepted the 199 provisional response, 211 it MUST NOT send or process any media associated with the early 212 dialog that was terminated. 214 If multiple usages [RFC5057] are used within an early dialog, and it 215 is not clear which dialog usage the 199 response terminates, SIP 216 entities that keep dialog state SHALL NOT release resources 217 associated with the early dialog when they receive the 199 response. 219 If a SIP entity receives an unreliable 199 response on a dialog which 220 has not previously been established (this can happen if a 199 221 response reaches the client before the 18x response that would 222 establish the early dialog) it SHALL discard the 199 responses. If a 223 SIP entity receives a reliable 199 response on a dialog which has not 224 previously been created the UAC MUST acknowledge the 199 response, as 225 described in RFC 3262. 227 If the UAC has received a 199 response for all early dialogs, and no 228 early dialog associatd session establisment remains, the UAC 229 maintains the "Procedding" state [RFC3261] and waits for possible 230 subsequent early dialogs to be established, and eventually for a 231 final response to be received. 233 5. User Agent Server behavior 235 If a UAS receives an initial request that contains an "199" option- 236 tag, it SHOULD NOT send a 199 response on an early dialog on which it 237 intends to send a final response, unless it e.g. has been configured 238 to do so due to lack of 199 support by forking proxies or other 239 intermediate SIP entities. 241 NOTE: If the UAS has created multiple early dialogs (the UAS is 242 acting similar to a forking proxy), it does not always intend to send 243 a final response for all of those dialogs. 245 When a UAS generates a 199 response, the response MUST contain a To 246 header field tag parameter, in order to identify the early dialog 247 that has been terminated. The UAS MUST also insert a Reason header 248 field [RFC3326] that contains a response code which describes the 249 reason why the early dialog was terminated. 251 If the UAS intends to send 199 responses, and if it supports the 252 procedures defined in RFC 3840 [RFC3840], it MAY during the 253 registration procedure use the sip.extensions feature tag [RFC3840] 254 to indicate support of the 199 response code. 256 A 199 response SHOULD NOT contain an SDP offer/answer message body, 257 unless required by the rules in RFC 3264 [RFC3264]. 259 According to RFC 3264, if the INVITE request does not contain an SDP 260 offer, and the 199 response is the first reliably sent response, the 261 199 response is required to contain an SDP offer. In this case the 262 UAS SHOULD send the 199 response unreliably, or include an SDP offer 263 with no m- lines in the reliable 199 response. 265 Since the provisional response is only used for information purpose, 266 the UAS SHOULD send it unreliably, unless the "100rel" option-tag 267 [RFC3262] is present in the Require header field of the associated 268 request. 270 Once the UAS has sent a 199 response, it MUST NOT send or process any 271 media associated with the terminated early dialog. 273 6. Proxy behavior 275 When a proxy receives a 199 response, it MUST process the response as 276 any other non-100 provisional responses. The proxy will forward the 277 response upstream towards the sender of the associated request. The 278 proxy MAY release resources it has reserved associated with the early 279 dialog that is terminated. If a proxy receives a 199 response out of 280 dialog, it processes it as other non-100 provisional responses 281 received out of dialog. 283 When a forking proxy receives a non-2xx final response that it 284 recognizes as terminating one or more early dialogs, it MUST generate 285 and send a 199 response upstream for each of the terminated early 286 dialogs that satisfy each of the following conditions: 288 - the forking proxy does not intend to forward the final response 289 immediately (in accordance with rules for a forking proxy) 291 - the UAC has indicated support (using the "199" option-tag) for the 292 199 response code 294 - the forking proxy has not already received and forwarded a 199 295 response for the early dialog 297 - the forking proxy has not already sent a final response for any of 298 the early dialogs 300 As a consequence, once a final response to the INVITE has been issued 301 by the proxy, no further 199 responses associated with the INVITE 302 request will be generated or forwarded by the proxy. 304 When the forking proxy forks the initial request, it generates a 305 unique Via header branch parameter value for each forked leg. The 306 proxy can determine whether additional forking has occurred 307 downstream of the proxy by storing the top Via branch value from each 308 response which creates an early dialog. If the same top Via branch 309 value is received for multiple early dialogs, the proxy knows that 310 additional forking has occurred downstream of the proxy. A non-2xx 311 final response received for a specific early dialog also terminates 312 all other early dialog for which the same top Via branch value was 313 received in the responses which created those early dialogs. 315 Based on implementation policy, the forking proxy MAY wait before 316 sending the 199 response, e.g. if it expects to receive a 2xx final 317 response on another dialog shortly after it received the non-2xx 318 final response which triggered the 199 response. 320 When a forking proxy generates a 199 response, the response MUST 321 contain a To header field tag parameter, that identifies the 322 terminated early dialog. The proxy MUST also insert a Reason header 323 field that contains the SIP response code of the response that 324 triggered the 199 response. The SIP response code in the Reason 325 header field informs the receiver of the 199 response about the SIP 326 response code that was used by the UAS to terminate the early dialog, 327 and the receiver might use that information for triggering different 328 types of actions and procedures. 330 A forking proxy that supports generating of 199 responses MUST keep 331 track of early dialogs, in order to determine whether to generate a 332 199 response when the proxy receives a non-2xx final response. In 333 addition, the proxy MUST keep track on which early dialogs it has 334 received and forwarded 199 responses, in order to not generate 335 additional 199 responses for those early dialogs. 337 If a forking proxy receives a reliably sent 199 response for a 338 dialog, for which it has previously generated and sent a 199 339 response, it MUST forward the 199 response. If the proxy recieves an 340 unreliably sent 199 response, for which it has previously generated 341 and sent a 199 response,it MAY forward the response, or it MAY 342 discard it. 344 When a forking proxy generates and sends a 199 response, it MUST NOT 345 send the response reliably. 347 When a forking proxy generates and sends a 199 response, the response 348 SHOULD NOT contain a Contact header field or a Record-Route header 349 field [RFC3261]. 351 7. Backward compatibility 353 Since all SIP entities involved in a session setup do not necessarily 354 support the specific meaning of the 199 Early Dialog Terminated 355 provisional response, the sender of the response MUST be prepared to 356 receive SIP requests and responses associated with the dialog for 357 which the 199 response was sent (a proxy can receive SIP messages 358 from either direction). If such request is received by a UA, it MUST 359 act in the same way as if it had received the request after sending 360 the final non-2xx response to the INVITE request, as specified in RFC 361 3261. A UAC that receives a 199 response for an early dialog MUST 362 NOT send any further requests on that dialog, except for requests 363 which acknowledge reliable responses. A proxy MUST forward requests 364 according to RFC 3261, even if the proxy has knowledge that the early 365 dialog has been terminated. 367 A 199 response does not "replace" a final response. RFC 3261 368 specifies when a final response is sent. 370 8. Usage with SDP offer/answer 372 A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264] 373 message body, unless required by the rules in RFC 3264. 375 If an INVITE request does not contain an SDP offer, and the 199 376 response is the first reliably sent response, the 199 response is 377 required to contain an SDP offer. In this case the UAS SHOULD send 378 the 199 response unreliable, or include an SDP offer with no m- lines 379 in a reliable 199 response. 381 9. Usage with 100rel 383 Since the provisional response is only used for information purpose, 384 the UAS SHOULD send it unreliably, unless the "100rel" option-tag 385 [RFC3262] is present in the Require header field of the associated 386 request. 388 NOTE: Implementors need to ensure that a 199 response that is sent 389 unreliably, even if the associated INVITE request contained a Require 390 header filed with an "100rel" option-tag, does not trigger errors or 391 rejection of the 199 response. 393 When a forking proxy generates and sends a 199 response, it MUST NOT 394 send the response reliably. 396 NOTE: If the forking proxy would generate a reliable 199 response, it 397 would have to terminate the associated PRACK [RFC3262] request. 399 10. Normative update of RFC 3262 401 10.1. General 403 The paragraph in this section is added to section 4 of RFC 3262. 405 10.2. RFC3262: 4. UAC Behavior 407 The UAC MUST support reception of all provisional responses, sent 408 reliably or unreliably; use of the option tag value "100rel" in a 409 Require header field does not change this requirement. 411 11. Message Flow Examples 413 11.1. Example with a forking proxy which generates 199 415 The figure shows an example, where a proxy (P1) forks an INVITE 416 received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4, 417 which send 18x provisional responses in order to establish early 418 dialogs between themselves and the UAC. UAS_2 and UAS_3 reject the 419 INVITE by sending a 4xx error response each. When P1 receives the 420 4xx responses it immediately sends 199 responses towards the UAC, to 421 indicate that the early dialogs for which it received the 4xx 422 responses have been terminated. The early dialog leg is shown in 423 parenthesis. 425 UAC P1 UAS_2 UAS_3 UAS_4 426 | | | | | 427 |-- INVITE -->| | | | 428 | |--- INVITE (2) ->| | | 429 | |--- INVITE (3) --------->| | 430 | |--- INVITE (4) ----------------->| 431 | |<-- 18x (2) -----| | | 432 |<- 18x (2) --| | | | 433 | |<-- 18x (3) -------------| | 434 |<- 18x (3) --| | | | 435 | |<-- 18x (4) ---------------------| 436 |<- 18x (4) --| | | | 437 | |<-- 4xx (2) -----| | | 438 | |--- ACK (2) ---->| | | 439 |<- 199 (2) --| | | | 440 | |<-- 4xx (3) -------------| | 441 | |--- ACK (3) ------------>| | 442 |<- 199 (3) --| | | | 443 | |<-- 200 (4) ---------------------| 444 |<- 200 (4) --| | | | 445 |-- ACK (4) ->| | | | 446 | |--- ACK (4) -------------------->| 447 | | | | | 449 Figure 1: Example call flow 451 11.2. Example with a forking proxy which receives 200 OK 453 The figure shows an example, where a proxy (P1) forks an INVITE 454 request received from UAC. The forked request reaches UAS_2, UAS_3 455 and UAS_4, that all send 18x provisional responses in order to 456 establish early dialogs between themselves and the UAC. Later UAS_4 457 accepts the session and sends a 200 OK final response. When P1 458 receives the 200 OK responses it immediately forwards it towards the 459 UAC. P1 does not send 199 responses for the early dialogs from UAS_2 460 and UAS_3, since P1 has yet not received any final responses on those 461 early dialogs (even if P1 sends CANCEL requests to UAS_2 and UAS_3 P1 462 may still receive 200 OK final response from UAS_2 or UAS_3, that P1 463 would have to forward towards the UAC. The early dialog leg is shown 464 in parenthesis. 466 UAC P1 UAS_2 UAS_3 UAS_4 467 | | | | | 468 |-- INVITE -->| | | | 469 | |--- INVITE (2) ->| | | 470 | |--- INVITE (3) --------->| | 471 | |--- INVITE (4) ----------------->| 472 | |<-- 18x (2) -----| | | 473 |<- 18x (2) --| | | | 474 | |<-- 18x (3) -------------| | 475 |<- 18x (3) --| | | | 476 | |<-- 18x (4) ---------------------| 477 |<- 18x (4) --| | | | 478 | |<-- 200 (4) ---------------------| 479 |<- 200 (4) --| | | | 480 |-- ACK (4) ->| | | | 481 | |--- ACK (4) -------------------->| 482 | | | | | 484 Figure 2: Example call flow 486 11.3. Example with two forking proxies, of which one generates 199 488 The figure shows an example, where a proxy (P1) forks an INVITE 489 request received from UAC. One of the forked requests reaches UAS_2. 490 The other requests reach another proxy (P2), that forks the request 491 to UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses 492 in order to establish early dialogs between themselves and UAC. 493 Later UAS_3 and UAS_4 reject the INVITE request by sending a 4xx 494 error response each. P2 does not support the 199 response code, and 495 forwards a single 4xx response. P1 supports the 199 response code, 496 and when it receives the 4xx response from P2, it also manages to 497 associate the early dialogs from both both UAS_3 and UAS_4 with the 498 response. Therefor it generates and sends two 199 responses to 499 indiccate that the early dialogs from UAS_3 and UAS_4 have been 500 terminated. The early dialog leg is shown in parenthesis. 502 UAC P1 P2 UAS_2 UAS_3 UAS_4 503 | | | | | | 504 |-- INVITE -->| | | | | 505 | |-- INVITE (2) ------------------>| | | 506 | |-- INVITE ---->| | | | 507 | | |--- INVITE (3) --------->| | 508 | | |--- INVITE (4) ----------------->| 509 | | |<-- 18x (3) -------------| | 510 | |<- 18x (3) ----| | | | 511 |<- 18x (3) --| | | | | 512 | | |<-- 18x (4) ---------------------| 513 | |<- 18x (4) ----| | | | 514 |<- 18x (4) --| | | | | 515 | | |<-- 4xx (3) -------------| | 516 | | |--- ACK (3) ------------>| | 517 | | |<-- 4xx (4) ---------------------| 518 | | |--- ACK (4) -------------------->| 519 | |<- 4xx (3) ----| | | | 520 | |-- ACK (3) --->| | | | 521 |<- 199 (3) --| | | | | 522 |<- 199 (4) --| | | | | 523 | |<- 200 (2) ----------------------| | | 524 |<- 200 (2) --| | | | | 525 |-- ACK (2) ->| | | | | 526 | |-- ACK (2) --------------------->| | | 527 | | | | | | 529 Figure 3: Example call flow 531 12. Security Considerations 533 General security issues related to SIP responses are described in 534 [RFC3261]. Due to the nature of the 199 response, it may be 535 attractive to use it for launching attacks in order to terminate 536 specific early dialogs (other early dialogs will not be affected). 537 In addition, if a man-in-the-middle sends a 199 response to the UAC, 538 which terminates a specific dialog, it can take a while until the UAS 539 finds out that the UAC, and possbile stateful intermediates, have 540 terminated the dialog. SIP security mechanisms (e.g. hop-to-hop TLS) 541 can be used to minimize, or eliminate, the risk for such attacks. 543 13. IANA Considerations 545 This section registers a new SIP response code and a new option-tag, 546 according to the procedures of RFC 3261, and updates section 4 of RFC 547 3262. 549 13.1. IANA Registration of the 199 response code 551 This section registers a new SIP response code, 199. The required 552 information for this registration, as specified in RFC 3261, is: 554 RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 555 RFC number of this specification]] 557 Response Code Number: 199 559 Default Reason Phrase: Early Dialog Terminated 561 13.2. IANA Registration of the 199 option-tag 563 This section registers a new SIP option-tag, 199. The required 564 information for this registration, as specified in RFC 3261, is: 566 Name: 199 568 Description: This option-tag is for indicating support of the 199 569 Early Dialog Terminated provisional response code. When present 570 in a Supported header, it indicates that the UA supports the 571 response code. When present in a Require header in a request, 572 it indicates that the UAS MUST support the sending of the 573 response code. 575 13.3. RFC 3262 Update 577 This document updates section 4 of RFC 3262. 579 14. Acknowledgements 581 Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet, 582 Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan, 583 Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo 584 Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith 585 Drage, Hans Erik van Elburg and Cullen Jennings for their feedback 586 and suggestions. 588 15. Change Log 590 [RFC EDITOR NOTE: Please remove this section when publishing] 592 Changes from draft-ietf-sipcore-199-02 593 o Usage example section rewritten and clarified 594 o Requirement has been removed 595 o SIP has been added to document title 596 o Acronyms expanded in the abstract and throughout the document 597 o Editorial fixes throughout the document 598 o Indication added that document is aimed for standards track 599 o Some references made informative 600 o Additional text added regarding the usage of the Reason header 601 o SBC latching text has been removed 602 o Usage of Require/Proxy-Require header removed 603 o Additional text added regarding sending SDP offer in 199 604 o Note added, which clarifies that 199 does not affect other early 605 dialogs 606 o References added to Security Considerations 607 o Clarification of local ringing tone 608 o Clarification that media must not be sent or processed after 199 609 o Text regarding sending media on terminated dialogs added to 610 security section 611 o Change: UAS must send 199 reliably in case of Require:100rel 612 o Change: Section 4 of RFC 3262 updated 614 16. References 616 16.1. Normative References 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 622 A., Peterson, J., Sparks, R., Handley, M., and E. 623 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 624 June 2002. 626 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 627 Provisional Responses in Session Initiation Protocol 628 (SIP)", RFC 3262, June 2002. 630 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 631 with Session Description Protocol (SDP)", RFC 3264, 632 June 2002. 634 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 635 Header Field for the Session Initiation Protocol (SIP)", 636 RFC 3326, December 2002. 638 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 639 "Indicating User Agent Capabilities in the Session 640 Initiation Protocol (SIP)", RFC 3840, August 2004. 642 16.2. Informational References 644 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 645 Preferences for the Session Initiation Protocol (SIP)", 646 RFC 3841, August 2004. 648 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 649 Initiation Protocol", RFC 5057, November 2007. 651 [3GPP.24.182] 652 3GPP, "IP Multimedia Subsystem (IMS) Customized Alerting 653 Tones (CAT); Protocol specification", 3GPP TS 24.182. 655 [3GPP.24.628] 656 3GPP, "Common Basic Communication procedures using IP 657 Multimedia (IM)Core Network (CN) subsystem; Protocol 658 specification", 3GPP TS 24.628. 660 Author's Address 662 Christer Holmberg 663 Ericsson 664 Hirsalantie 11 665 Jorvas 02420 666 Finland 668 Email: christer.holmberg@ericsson.com