idnits 2.17.1 draft-ietf-sipcore-199-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 32 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2009) is 5242 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 Expires: June 12, 2010 December 9, 2009 6 Response Code for Indication of Terminated Dialog 7 draft-ietf-sipcore-199-02.txt 9 Abstract 11 This specification defines a new SIP response code, 199 Early Dialog 12 Terminated, which a SIP forking proxy and a UAS can use to indicate 13 upstream towards the UAC that an early dialog has been terminated, 14 before a final response is sent towards the UAC. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 12, 2010. 39 Copyright Notice 41 Copyright (c) 2009 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 BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 4 60 4.1. Examples of resource types . . . . . . . . . . . . . . . . 5 61 4.2. Examples of policy procedures . . . . . . . . . . . . . . 6 62 5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 7 63 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 9 65 8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9 66 9. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 10 67 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 10.1. Example with a forking proxy which generates 199 . . . . . 10 69 10.2. Example with a forking proxy which receives 200 OK . . . . 11 70 10.3. Example with two forking proxies, of which one 71 generates 199 . . . . . . . . . . . . . . . . . . . . . . 12 72 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 12.1. IANA Registration of the 199 response code . . . . . . . . 14 75 12.2. IANA Registration of the 199 Option Tag . . . . . . . . . 14 76 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 14.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 14.2. Informational References . . . . . . . . . . . . . . . . . 15 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 As defined in SIP (Session Initiation Protocol) specification 85 [RFC3261], an early SIP dialog is created when a non-100 provisional 86 response is sent to the dialog initiation request (e.g. INVITE). 87 The dialog is considered to be in early state until a final response 88 is sent. 90 When a proxy receives an initial request (outside an existing dialog, 91 and without a pre-defined route set), it can forward it towards 92 multiple remote destinations. When the proxy does that, it performs 93 forking. 95 When a forking proxy receives non-100 provisional responses, it 96 forwards the responses upstream towards the sender of the associated 97 request. When a forking proxy receives a 2xx final response, it 98 forwards the response upstream towards the sender of the associated 99 request. At that point the proxy normally sends a CANCEL request 100 downstream towards all remote destinations where it previously sent 101 the request associated with the 2xx final response, and from which it 102 has yet not received a final response, in order to terminate 103 associated outstanding early dialogs. It is possible to receive 104 multiple 2xx final responses. When SIP entities upstream receive the 105 first 2xx final response, and they do not to intend to accept 106 subsequent 2xx final responses, they will automatically terminate 107 other associated outstanding early dialogs. If additional 2xx final 108 responses are received, those SIP entities will normally send a BYE 109 request using the dialog identifier retrieved from the subsequent 2xx 110 final response. 112 NOTE: A UAC can use the Request-Disposition header [RFC3841] to 113 request that proxies do not send CANCEL requests downstream once they 114 have received the first final 2xx response. 116 When a forking proxy receives a non-2xx final response, it does not 117 always immediately forward the response upstream towards the sender 118 of the associated request. Instead, the forking proxy "stores" it 119 and waits for further final responses from remote destinations where 120 the forked request was forwarded. At some point the proxy uses a 121 specified mechanism to determine the "best" final response code, and 122 forwards that final response upstream towards the sender of the 123 associated request. When SIP entities upstream receive the non-2xx 124 final response they will release resources associated with the 125 session, and the UAC will terminate, or retry, the session setup. 127 Since the forking proxy does not always immediately forward non-2xx 128 final responses, SIP entities upstream (including the UAC that 129 initiated the request) do not know that a specific early dialog has 130 been terminated, and the SIP entities keep possible resources 131 associated with the early dialog until they receive a final response 132 from the forking proxy. 134 This specification defines a new SIP response code, 199 Early Dialog 135 Terminated, which a forking proxy and a UAS can use to indicate 136 upstream that an early dialog has been terminated. The 199 response 137 can also be sent by a UAS, prior to sending a non-2xx final response. 138 SIP entities that receive the 199 provisional response can release 139 resources associated with the specific early dialog. The SIP 140 entities can also use the 199 provisional response to make policy 141 related decisions related to early dialogs. 143 The 199 response code is an optimization, which allows the UAC to be 144 informed about terminated early dialogs. However, since the support 145 of the 199 response is optional, a UAC cannot assume that it will 146 always receive a 199 provisional response for all terminated early 147 dialogs. 149 2. Conventions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in BCP 14, RFC 2119 154 [RFC2119]. 156 3. Requirements 158 REQ 1: It must be possible to indicate to the UAC that an early 159 dialog has been terminated before a final response is sent. 161 4. User Agent Client behavior 163 When a UAC sends an initial request, and if it wants to receive 199 164 responses, it MUST insert the 199 option-tag in the Supported header, 165 which indicates that the client supports the 199 Early Dialog 166 Terminated response code. The UAC SHOULD NOT insert the 199 option- 167 tag in the Require header, unless the particular session usage 168 requires the UAS to support the response code. Also, the UAC SHOULD 169 NOT insert the 199 option-tag in the Proxy-Require header, unless the 170 particular session usage requires every proxy on the path to support 171 the response code. Using Require or Proxy-Require with the 199 172 option-tag will in many cases result in unnecessary session 173 establishment failures. 175 When a UAC receives a 199 response it MAY release resources and 176 procedures associated with the early dialog on which the 199 response 177 is received. Examples of resources and procedures are e.g. 178 procedures for the establishment of media plane resources (bandwidth, 179 radio, codecs etc), media security procedures or procedures related 180 to NAT traversal. In addition, the UAC may use the 199 response for 181 policy decisions related to early dialogs, e.g. when choosing to 182 process media associated with a particular early dialog. 184 If multiple usages [RFC5057] are used within an early dialog, and it 185 is not clear which dialog usage the 199 response terminates, SIP 186 entities that keep dialog state SHALL NOT release resources 187 associated with the early dialog when they receive the 199 response. 189 If a client receives an unreliable 199 response on a dialog which has 190 not previously been created (this can happen if a 199 response 191 reaches the client before a 18x response) the client SHALL discard 192 the 199 responses. If a client receives a reliable 199 response on a 193 dialog which has not previously been created the UAC SHOULD 194 acknowledge the 199 response, as described in [RFC3262]. 196 4.1. Examples of resource types 198 Examples which benefit from resource-release are: 200 1. Codec release - when resources for a specific codec has been 201 reserved only for the stream that is terminated. In that case the 202 resources associated with that codec can be released. 204 2. Pre-conditions - when the dialog is terminated, procedures and 205 resources associated to the pre-conditions for that dialog can be 206 released. 208 3. In-band security negotiation - when the dialog is terminated, 209 procedures and resources associated with the in-band security 210 negotiation for that dialog can be released. 212 4. ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is 213 terminated, procedures and resources associated with the ICE related 214 in-band procedures for that dialog can be released. 216 5. Limited access resources - in case of forking and multiple stream 217 it may not be possible to allow early media on all dialogs, so media 218 sessions associated with some dialogs may e.g. be set to "inactive". 219 When a dialog is terminated, media sessions associated with other 220 dialogs can be allowed. 222 6. Secure media selection - when SRTP is used to encrypt the media. 224 In some cases SIP entities are only able to render media associated 225 with a single early dialog. If a 199 response is received on a 226 dialog, and media associated with that media has been rendered, the 227 SIP entity can start rendering media associated with another early 228 dialog. 230 If the client is able to associate the 199 response with a specific 231 media stream, it MAY choose to discard media on that specific media 232 stream, it MAY release all resources associated with that media 233 stream and it MAY start to process media streams received on other 234 early dialogs. When the P-Early-Media header [RFC5009] is used, a UA 235 MAY trigger different actions depending on whether the header has 236 been used for the terminated dialog. How the association between the 237 dialog and the associated media stream is done is outside the scope 238 of this document. 240 NOTE: When using SRTP [RFC3711], the secure media stream is bound to 241 the crypto context setup for the dialog, and can be identified using 242 the MKI (if used) of SRTP. 244 If the client only has a single early dialog (other early dialogs MAY 245 not have been established, or they MAY have been established and 246 later terminated) and a 199 response is received for that early 247 dialog, the client terminates the early dialog. Afterwards, the 248 client SHOULD act as before the first early dialog was established. 250 4.2. Examples of policy procedures 252 1. UAC early media selection - when media associated with multiple 253 early dialogs is received, SIP endpoint normally chooses to process 254 media associated with a single early dialog (e.g. the recently 255 established early dialog). If a 199 response is received on such 256 early dialog, the SIP endpoint can start processing media associated 257 with another early dialog. For example, an early dialog may be used 258 for an announcement message, and when the message is finished a 199 259 response will be sent on that dialog, in order for the SIP endpoint 260 to stop processing media associated with that early dialog. This 261 kind of policy is normal especially in PSTN gateways, where the 262 calling user cannot control which media is processed. 264 2. SBC early media selection - when an SBC is used to control which 265 media is processed and forwarded. In many cases, the SBC only 266 processes media associated with a single early dialog. Typical for 267 NAT traversal, the SBC often "latches" onto a media stream. If a 199 268 response is received, the SBC can choose to start processing media 269 associated with another dialog. If the SBC performs latching, it can 270 trigger a "re-latch" onto a new media stream when the 199 response is 271 received. 273 3. UAC ringing tone generation - when a UAC receives a 180 response, 274 it may choose to generate a local ringing tone. If early media is 275 received, the UAC may stop the local ringing tone generation and play 276 the incoming early media packets. If a 199 response is received on 277 the early dialog associated with the early media, and the UAC has 278 previously received a 180 response for another early dialog, it can 279 start to generate local ringing tone again. Having knowledge that 280 the early dialog associated with early media has been terminated, the 281 UAC can also start generating local ringing tone if a 180 is received 282 on another early dialog after the early dialog has been terminated. 284 5. User Agent Server behavior 286 If the received initial request contains an 199 option tag, the UAS 287 SHOULD NOT send a 199 response on a dialog on which it intends to 288 send a final response, unless it e.g. has been configured to do so 289 due to lack of 199 support by forking proxies or other intermediate 290 SIP entities. 292 NOTE: If the UAS has created multiple early dialogs (the UAS is 293 acting similar to a forking proxy), it does not always intend to send 294 a final response for all of those dialogs. 296 When a UAS generates a 199 response, the response MUST contain a To 297 header tag parameter, which identifies the early dialog that has been 298 terminated. The UAS MUST also insert a Reason header [RFC3326] which 299 contains a response code which describes the reason why the dialog 300 was terminated. 302 If the UAS intends to send 199 responses, and if it supports the 303 procedures defined in [RFC3840], it MAY during the registration 304 procedure use the sip.extensions feature tag [RFC3840] to indicate 305 support of the 199 response code. 307 A 199 response SHOULD NOT contain an SDP offer/answer message body, 308 unless required by the rules in [RFC3264]. 310 If the INVITE request did not contain an SDP offer, and the 199 311 response is the first reliably sent response, the 199 response is 312 required to contain an SDP offer. In this case the UAS SHOULD send 313 the 199 response unreliable, or include an SDP offer with no m- lines 314 in the reliable 199 response. 316 When a 199 response is sent by a UAS, since the provisional response 317 is only used for information purpose, the UAS SHOULD send it 318 unreliably even if the 100rel option tag [RFC3262] is present in the 319 Require header of the associated request. 321 6. Proxy behavior 323 When a proxy receives a 199 response, it MUST process the response as 324 any other non-100 provisional responses. The proxy will forward the 325 response upstream towards the sender of the associated request. The 326 proxy MAY release resources it has reserved associated with the 327 dialog on which the response is received. If a proxy receives a 199 328 response out of dialog, it processes it as other non-100 provisional 329 responses received out of dialog. 331 When a forking proxy receives a non-2xx final response that it 332 recognizes as terminating one or more early dialogs, it SHOULD 333 generate and send a 199 response upstream for each of the terminated 334 early dialogs that satisfy each of the following conditions: 336 - the forking proxy does not intend to forward the final response 337 immediately (in accordance with rules for a forking proxy) 339 - the UAC has indicated support (using the 199 option tag) for the 340 199 response code 342 - the forking proxy has not already received and forwarded a 199 343 response for that early dialog 345 - the forking proxy has not already sent a final response for any of 346 the early dialogs 348 As a consequence, once a final response to the INVITE has been issued 349 by the proxy, no further 199 responses associated with the INVITE 350 request will be generated or forwarded by the proxy. 352 When the forking proxy forks the initial request, it generates a 353 unique Via header branch parameter value for each forked leg. The 354 proxy can determine whether additional forking has occurred 355 downstream of the proxy by storing the top Via branch value from each 356 response which creates an early dialog. If the same top Via branch 357 value is received for multiple early dialogs, the proxy knows that 358 additional forking has occured downstream of the proxy. A non-2xx 359 final response received for a specific early dialog also terminates 360 all other early dialog for which the same top Via branch value was 361 received in the responses which created those early dialogs. 363 Based on implementation policy, the forking proxy MAY wait before 364 sending the 199 response, e.g. if it expects to receive a 2xx final 365 response on another dialog shortly after it received the non-2xx 366 final response which triggered the 199 response. 368 When a forking proxy generates a 199 response, the response MUST 369 contain a To header tag parameter, which identifies the early dialog 370 that has been terminated. The proxy MUST also insert a Reason header 371 [RFC3326] which contains the response code of the response that 372 triggered the 199 response. 374 A forking proxy which supports generating of 199 responses MUST keep 375 track of early dialogs, in order to determine whether to generate a 376 199 response when the proxy receives a non-2xx final response. In 377 addition, the proxy MUST keep track on which early dialogs it has 378 received and forwarded 199 responses, in order to not generate 379 additional 199 responses for those early dialogs. 381 If a forking proxy receives a reliably sent 199 response for a 382 dialog, for which it has previously generated and sent a 199 383 response, it MUST forward the 199 response. In case of a unreliably 384 sent 199 response, the proxy MAY forward the 199 response, or it MAY 385 discard it. 387 When a forking proxy generates a 199 response, the response MUST NOT 388 be sent reliably. 390 7. Backward compatibility 392 Since all SIP entities involved in a session setup do not necessarily 393 support the specific meaning of the 199 Early Dialog Terminated 394 provisional response, the sender of the response MUST be prepared to 395 receive SIP requests and responses associated with the dialog for 396 which the 199 response was sent (a proxy can receive SIP messages 397 from either direction). If such request is received by a UA, it MUST 398 act in the same way as if it had received the request after sending 399 the final non-2xx response to the INVITE, as specified in [RFC3261]. 400 A UAC that receives a 199 response for an early dialog MUST NOT send 401 any further requests on that dialog, except for requests which 402 acknowledge reliable responses. A proxy MUST forward requests 403 according to [RFC3261], even if the proxy has knowledge that the 404 early dialog has been terminated. 406 The 199 Early Dialog Terminated response code does not "replace" a 407 final response. RFC 3261 [RFC3261] specifies when a final response 408 is sent. 410 8. Usage with SDP offer/answer 412 A 199 Early Dialog Terminated provisional response SHOULD NOT contain 413 an SDP offer/answer message body, unless required by the rules in 414 [RFC3264]. 416 If the INVITE request did not contain an SDP offer, and the 199 417 response is the first reliably sent response, the 199 response is 418 required to contain an SDP offer. In this case the UAS SHOULD send 419 the 199 response unreliable, or include an SDP offer with no m- lines 420 in the reliable 199 response. 422 9. Usage with 100rel 424 When a 199 Early Dialog Terminated provisional response is sent by a 425 UAS, since the provisional response is only used for information 426 purpose, the UAS SHOULD send it unreliably even if the 100rel option 427 tag [RFC3262] is present in the Require header of the associated 428 request. 430 When a forking proxy generates a 199 response, the response MUST NOT 431 be sent reliably. 433 10. Examples 435 10.1. Example with a forking proxy which generates 199 437 The figure shows an example, where a proxy (P1) forks an INVITE 438 received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4, 439 which send 18x provisional responses in order to create early dialogs 440 between themselves and the UAC. UAS_2 and UAS_3 reject the INVITE by 441 sending a 4xx error response each. When P1 receives the 4xx 442 responses it immediately sends 199 responses, associated with the 443 dialogs where the 4xx responses were received, towards the UAC. The 444 early dialog leg is shown in parenthesis. 446 UAC P1 UAS_2 UAS_3 UAS_4 447 | | | | | 448 |-- INVITE -->| | | | 449 | |--- INVITE (2) ->| | | 450 | |--- INVITE (3) --------->| | 451 | |--- INVITE (4) ----------------->| 452 | |<-- 18x (2) -----| | | 453 |<- 18x (2) --| | | | 454 | |<-- 18x (3) -------------| | 455 |<- 18x (3) --| | | | 456 | |<-- 18x (4) ---------------------| 457 |<- 18x (4) --| | | | 458 | |<-- 4xx (2) -----| | | 459 | |--- ACK (2) ---->| | | 460 |<- 199 (2) --| | | | 461 | |<-- 4xx (3) -------------| | 462 | |--- ACK (3) ------------>| | 463 |<- 199 (3) --| | | | 464 | |<-- 200 (4) ---------------------| 465 |<- 200 (4) --| | | | 466 |-- ACK (4) ->| | | | 467 | |--- ACK (4) -------------------->| 468 | | | | | 470 Figure 1: Example call flow 472 10.2. Example with a forking proxy which receives 200 OK 474 The figure shows an example, where a proxy (P1) forks an INVITE 475 received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4, 476 which send 18x provisional responses in order to create early dialogs 477 between themselves and the UAC. UAS_4 accepts the session by sending 478 a 200 OK final response. When P1 receives the 200 OK responses it 479 immediately forwards it towards the UAC. P1 does not send 199 480 responses for the early dialogs from UAS_2 and UAS_3, since P1 has 481 yet not received any final responses on those early dialogs (even if 482 P1 sends CANCEL request to UAS_2 and UAS_3 P1 may still receive 200 483 OK final response from UAS_2 or UAS_3, which P1 would have to forward 484 towards the UAC. The early dialog leg is shown in parenthesis. 486 UAC P1 UAS_2 UAS_3 UAS_4 487 | | | | | 488 |-- INVITE -->| | | | 489 | |--- INVITE (2) ->| | | 490 | |--- INVITE (3) --------->| | 491 | |--- INVITE (4) ----------------->| 492 | |<-- 18x (2) -----| | | 493 |<- 18x (2) --| | | | 494 | |<-- 18x (3) -------------| | 495 |<- 18x (3) --| | | | 496 | |<-- 18x (4) ---------------------| 497 |<- 18x (4) --| | | | 498 | |<-- 200 (4) ---------------------| 499 |<- 200 (4) --| | | | 500 |-- ACK (4) ->| | | | 501 | |--- ACK (4) -------------------->| 502 | | | | | 504 Figure 2: Example call flow 506 10.3. Example with two forking proxies, of which one generates 199 508 The figure shows an example, where a proxy (P1) forks an INVITE 509 received from UAC. One of the forked INVITEs reaches UAS_2. The 510 other forked INVITE reaches another proxy (P2), which forks the 511 INVITE to UAS_3 and UAS_4, which send 18x provisional responses in 512 order to create early dialogs between themselves and the UAC. UAS_3 513 and UAS_4 reject the INVITE by sending a 4xx error response each. P2 514 does not support the 199 response code, and forwards a single 4xx 515 response. When P1 receives the 4xx responses from P2, it manages to 516 associate the response with the early dialogs from both UAS_3 and 517 UAS_4, so it generates and sends two 199 response to indicate that 518 the early dialogs from UAS_3 and UAS_4 have been terminated. The 519 early dialog leg is shown in parenthesis. 521 UAC P1 P2 UAS_2 UAS_3 UAS_4 522 | | | | | | 523 |-- INVITE -->| | | | | 524 | |-- INVITE (2) ------------------>| | | 525 | |-- INVITE ---->| | | | 526 | | |--- INVITE (3) --------->| | 527 | | |--- INVITE (4) ----------------->| 528 | | |<-- 18x (3) -------------| | 529 | |<- 18x (3) ----| | | | 530 |<- 18x (3) --| | | | | 531 | | |<-- 18x (4) ---------------------| 532 | |<- 18x (4) ----| | | | 533 |<- 18x (4) --| | | | | 534 | | |<-- 4xx (3) -------------| | 535 | | |--- ACK (3) ------------>| | 536 | | |<-- 4xx (4) ---------------------| 537 | | |--- ACK (4) -------------------->| 538 | |<- 4xx (3) ----| | | | 539 | |-- ACK (3) --->| | | | 540 |<- 199 (3) --| | | | | 541 |<- 199 (4) --| | | | | 542 | |<- 200 (2) ----------------------| | | 543 |<- 200 (2) --| | | | | 544 |-- ACK (2) ->| | | | | 545 | |-- ACK (2) --------------------->| | | 546 | | | | | | 548 Figure 3: Example call flow 550 11. Security Considerations 552 General security issues related to SIP responses are described in 553 [RFC3261]. Due to the nature of the 199 response, it may be 554 attractive to use it for launching attacks in order to terminate 555 specific early dialogs (other early dialogs will not be affected). 556 In addition, if a man-in-the-middle sends a 199 response to the UAC, 557 which terminates a specific dialog, it can take a while until the UAS 558 finds out that the UAC, and possbile stateful intermediates, have 559 terminated the dialog. SIP security mechanisms (e.g. hop-to-hop TLS) 560 can be used to minimize, or eliminate, the risk for such attacks. 562 12. IANA Considerations 564 This section registers a new SIP response code and a new option tag, 565 according to the procedures of RFC 3261. 567 12.1. IANA Registration of the 199 response code 569 This section registers a new SIP response code, 199. The required 570 information for this registration, as specified in RFC 3261, is: 572 RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 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, it indicates that the UA supports the 588 response code. When present in a Require header in a request, 589 it indicates that the UAS MUST support the sending of the 590 response code. 592 13. Acknowledgements 594 Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet, 595 Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan, 596 Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo 597 Camarillo, Adam Roach, Bob Penfield,Tom Taylor, Ya Ching Tan, Keith 598 Drage and Hans Erik van Elburg for their feedback and suggestions. 600 14. References 602 14.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 608 A., Peterson, J., Sparks, R., Handley, M., and E. 609 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 610 June 2002. 612 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 613 Provisional Responses in Session Initiation Protocol 614 (SIP)", RFC 3262, June 2002. 616 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 617 with Session Description Protocol (SDP)", RFC 3264, 618 June 2002. 620 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 621 Header Field for the Session Initiation Protocol (SIP)", 622 RFC 3326, December 2002. 624 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 625 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 626 RFC 3711, March 2004. 628 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 629 "Indicating User Agent Capabilities in the Session 630 Initiation Protocol (SIP)", RFC 3840, August 2004. 632 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 633 Preferences for the Session Initiation Protocol (SIP)", 634 RFC 3841, August 2004. 636 [I-D.ietf-mmusic-ice] 637 Rosenberg, J., "Interactive Connectivity Establishment 638 (ICE): A Protocol for Network Address Translator (NAT) 639 Traversal for Offer/Answer Protocols", 640 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 642 14.2. Informational References 644 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 645 Initiation Protocol", RFC 5057, November 2007. 647 [RFC5009] Ejza, R., "Private Header (P-Header) Extension to the 648 Session Initiation Protocol (SIP) for Authorization of 649 Early Media", RFC 5009, September 2007. 651 Author's Address 653 Christer Holmberg 654 Ericsson 655 Hirsalantie 11 656 Jorvas 02420 657 Finland 659 Email: christer.holmberg@ericsson.com