idnits 2.17.1 draft-ietf-sip-199-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 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 (April 9, 2009) is 5489 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) ** Downref: Normative reference to an Informational RFC: RFC 5009 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Expires: October 11, 2009 April 9, 2009 6 Response Code for Indication of Terminated Dialog 7 draft-ietf-sip-199-08.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 11, 2009. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 This specification defines a new SIP response code, 199 Early Dialog 46 Terminated, which a SIP forking proxy and a UAS can use to indicate 47 upstream towards the UAC that an early dialog has been terminated, 48 before a final response is sent towards the UAC. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 4 56 4.1. Examples of resource types . . . . . . . . . . . . . . . . 5 57 4.2. Examples of policy procedures . . . . . . . . . . . . . . 6 58 5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 7 59 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 60 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 9 61 8. 199 Early Dialog Terminated . . . . . . . . . . . . . . . . . 9 62 9. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 10 63 10. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 10 64 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 11.1. Example with a forking proxy which generates 199 . . . . . 10 66 11.2. Example with a forking proxy which receives 200 OK . . . . 11 67 11.3. Example with two forking proxies, of which one 68 generates 199 . . . . . . . . . . . . . . . . . . . . . . 12 69 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 13.1. IANA Registration of the 199 response code . . . . . . . . 14 72 13.2. IANA Registration of the 199 Option Tag . . . . . . . . . 14 73 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 74 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 15.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 15.2. Informational References . . . . . . . . . . . . . . . . . 15 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 As defined in SIP (Session Initiation Protocol) specification 82 [RFC3261], an early SIP dialog is created when a non-100 provisional 83 response is sent to the dialog initiation request (e.g. INVITE). 84 The dialog is considered to be in early state until a final response 85 is sent. 87 When a proxy receives an initial request (outside an existing dialog, 88 and without a pre-defined route set), it can forward it towards 89 multiple remote destinations. When the proxy does that, it performs 90 forking. 92 When a forking proxy receives non-100 provisional responses, it 93 forwards the responses upstream towards the sender of the associated 94 request. When a forking proxy receives a 2xx final response, it 95 forwards the response upstream towards the sender of the associated 96 request. At that point the proxy normally sends a CANCEL request 97 downstream towards all remote destinations where it previously sent 98 the request associated with the 2xx final response, and from which it 99 has yet not received a final response, in order to terminate 100 associated outstanding early dialogs. It is possible to receive 101 multiple 2xx final responses. When SIP entities upstream receive the 102 first 2xx final response, and they do not to intend to accept 103 subsequent 2xx final responses, they will automatically terminate 104 other associated outstanding early dialogs. If additional 2xx final 105 responses are received, those SIP entities will normally send a BYE 106 request using the dialog identifier retrieved from the subsequent 2xx 107 final response. 109 NOTE: A UAC can use the Request-Disposition header [RFC3841] to 110 request that proxies do not send CANCEL requests downstream once they 111 have received the first final 2xx response. 113 When a forking proxy receives a non-2xx final response, it does not 114 always immediately forward the response upstream towards the sender 115 of the associated request. Instead, the forking proxy "stores" it 116 and waits for further final responses from remote destinations where 117 the forked request was forwarded. At some point the proxy uses a 118 specified mechanism to determine the "best" final response code, and 119 forwards that final response upstream towards the sender of the 120 associated request. When SIP entities upstream receive the non-2xx 121 final response they will release resources associated with the 122 session, and the UAC will terminate the session setup. 124 Since the forking proxy does not always immediately forward non-2xx 125 final responses, SIP entities upstream (including the UAC that 126 initiated the request) do not know that a specific early dialog has 127 been terminated, and the SIP entities keep possible resources 128 associated with the early dialog until they receive a final response 129 from the forking proxy. 131 This specification defines a new SIP response code, 199 Early Dialog 132 Terminated, which a forking proxy and a UAS can use to indicate 133 upstream that an early dialog has been terminated. The 199 response 134 can also be sent by a UAS, prior to sending a non-2xx final response. 135 SIP entities that receive the 199 provisional response MAY release 136 resources associated with the specific early dialog. The SIP 137 entities MAY also use the 199 provisional response to make policy 138 related decisions related to early dialogs. 140 The 199 response code is an optimization, which allows the UAC to be 141 informed about terminated early dialogs. However, since the support 142 of the 199 response is optional, a UAC cannot assume that it will 143 always receive a 199 provisional response for all terminated early 144 dialogs. 146 2. Conventions 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in BCP 14, RFC 2119 151 [RFC2119]. 153 3. Requirements 155 REQ 1: It must be possible to indicate to the UAC that an early 156 dialog has been terminated before a final response is sent. 158 4. User Agent Client behavior 160 When a UAC sends an initial request, and if it wants to receive 199 161 responses, it MUST insert the 199 option-tag in the Supported header, 162 which indicates that the client supports the 199 Early Dialog 163 Terminated response code. The UAC SHOULD NOT insert the 199 option- 164 tag in the Require header, unless the particular session usage 165 requires the UAS to support the response code. Also, the UAC SHOULD 166 NOT insert the 199 option-tag in the Proxy-Require header, unless the 167 particular session usage requires every proxy on the path to support 168 the response code. Using Require or Proxy-Require with the 199 169 option-tag will in many cases result in unnecessary session 170 establishment failures. 172 When a UAC receives a 199 response it MAY release resources and 173 procedures associated with the early dialog on which the 199 response 174 is received. Examples of resources and procedures are e.g. 175 procedures for the establishment of media plane resources (bandwidth, 176 radio, codecs etc), media security procedures or procedures related 177 to NAT traversal. In addition, the UAC may use the 199 response for 178 policy decisions related to early dialogs, e.g. when choosing to 179 process media associated with a particular early dialog. 181 If multiple usages [RFC5057] are used within an early dialog, and it 182 is not clear which dialog usage the 199 response terminates, SIP 183 entities that keep dialog state shall not release resources 184 associated with the early dialog when they receive the 199 response. 186 If a client receives an unreliable 199 response on a dialog which has 187 not previously been created (this can happen if a 199 response 188 reaches the client before a 18x response) the client SHALL discard 189 the 199 responses. If a client receives a reliable 199 response on a 190 dialog which has not previously been created the UAC SHOULD 191 acknowledge the 199 response, as described in [RFC3262]. 193 4.1. Examples of resource types 195 Examples which benefit from resource-release are: 197 1. Codec release - when resources for a specific codec has been 198 reserved only for the stream that is terminated. In that case the 199 resources associated with that codec can be released. 201 2. Pre-conditions - when the dialog is terminated, procedures and 202 resources associated to the pre-conditions for that dialog can be 203 released. 205 3. In-band security negotiation - when the dialog is terminated, 206 procedures and resources associated with the in-band security 207 negotiation for that dialog can be released. 209 4. ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is 210 terminated, procedures and resources associated with the ICE related 211 in-band procedures for that dialog can be released. 213 5. Limited access resources - in case of forking and multiple stream 214 it may not be possible to allow early media on all dialogs, so media 215 sessions associated with some dialogs may e.g. be set to "inactive". 216 When a dialog is terminated, media sessions associated with other 217 dialogs can be allowed. 219 6. Secure media selection - when SRTP is used to encrypt the media. 221 In some cases SIP entities are only able to render media associated 222 with a single early dialog. If a 199 response is received on a 223 dialog, and media associated with that media has been rendered, the 224 SIP entity can start rendering media associated with another early 225 dialog. 227 If the client is able to associate the 199 response with a specific 228 media stream, it MAY choose to discard media on that specific media 229 stream, it MAY release all resources associated with that media 230 stream and it MAY start to process media streams received on other 231 early dialogs. When the P-Early-Media header [RFC5009] is used, a UA 232 MAY trigger different actions depending on whether the header has 233 been used for the terminated dialog. How the association between the 234 dialog and the associated media stream is done is outside the scope 235 of this document. 237 NOTE: When using SRTP [RFC3711], the secure media stream is bound to 238 the crypto context setup for the dialog, and can be identified using 239 the MKI (if used) of SRTP. 241 If the client only has a single early dialog (other early dialogs MAY 242 not have been established, or they MAY have been established and 243 later terminated) and a 199 response is received for that early 244 dialog, the client terminates the early dialog. Afterwards, the 245 client SHOULD act as before the first early dialog was established. 247 4.2. Examples of policy procedures 249 1. UAC early media selection - when media associated with multiple 250 early dialogs is received, SIP endpoint normally chooses to process 251 media associated with a single early dialog (e.g. the recently 252 established early dialog). If a 199 response is received on such 253 early dialog, the SIP endpoint can start processing media associated 254 with another early dialog. For example, an early dialog may be used 255 for an announcement message, and when the message is finished a 199 256 response will be sent on that dialog, in order for the SIP endpoint 257 to stop processing media associated with that early dialog. This 258 kind of policy is normal especially in PSTN gateways, where the 259 calling user cannot control which media is processed. 261 2. SBC early media selection - when an SBC is used to control which 262 media is processed and forwarded. In many cases, the SBC only 263 processes media associated with a single early dialog. Typical for 264 NAT traversal, the SBC often "latches" onto a media stream. If a 199 265 response is received, the SBC can choose to start processing media 266 associated with another dialog. If the SBC performs latching, it can 267 trigger a "re-latch" onto a new media stream when the 199 response is 268 received. 270 3. UAC ringing tone generation - when a UAC receives a 180 response, 271 it may choose to generate a local ringing tone. If early media is 272 received, the UAC may stop the local ringing tone generation and play 273 the incoming early media packets. If a 199 response is received on 274 the early dialog associated with the early media, and the UAC has 275 previously received a 180 response for another early dialog, it can 276 start to generate local ringing tone again. Having knowledge that 277 the early dialog associated with early media has been terminated, the 278 UAC can also start generating local ringing tone if a 180 is received 279 on another early dialog after the early dialog has been terminated." 281 5. User Agent Server behavior 283 If the received initial request contains an 199 option tag, the UAS 284 SHOULD NOT send a 199 response on a dialog on which it intends to 285 send a final response, unless it e.g. has been configured to do so 286 due to lack of 199 support by forking proxies or other intermediate 287 SIP entities. 289 NOTE: If the UAS has created multiple early dialogs (the UAS is 290 acting similar to a forking proxy), it does not always intend to send 291 a final response for all of those dialogs. 293 When a UAS generates a 199 response, the response MUST contain a To 294 header tag parameter, which identifies the early dialog that has been 295 terminated. The UAS MUST also insert a Reason header [RFC3326] which 296 contains a response code which describes the reason why the dialog 297 was terminated. 299 If the UAS intends to send 199 responses, and if it supports the 300 procedures defined in [RFC3840], it MAY during the registration 301 procedure use the sip.extensions feature tag [RFC3840] to indicate 302 support of the 199 response code. 304 A 199 response SHOULD NOT contain an SDP offer/answer message body, 305 unless required by the rules in [RFC3264]. 307 NOTE: If the INVITE request did not contain an SDP offer, and the 199 308 response is the first reliably sent response, the 199 response is 309 required to contain an SDP offer. 311 When a 199 response is sent by a UAS, since the provisional response 312 is only used for information purpose, the UAS SHOULD send it 313 unreliably even if the 100rel option tag [RFC3262] is present in the 314 Require header of the associated request. 316 6. Proxy behavior 318 When a proxy receives a 199 response on an early dialog, it MUST 319 process the response as any other non-100 provisional responses. The 320 proxy will forward the response upstream towards the sender of the 321 associated request. The proxy MAY release resources it has reserved 322 associated with the early dialog on which the response is received. 323 If a proxy receives a 199 response out of dialog, it processes it as 324 other non-100 provisional responses received out of dialog. 326 When a forking proxy receives a non-2xx final response that it 327 recognizes as terminating one or more early dialogs, it SHOULD 328 generate and send a 199 response upstream for each of the terminated 329 early dialogs that satisfy each of the following conditions: 331 - the forking proxy does not intend to forward the final response 332 immediately (in accordance with rules for a forking proxy) 334 - the UAC has indicated support (using the 199 option tag) for the 335 199 response code 337 - the forking proxy has not already received and forwarded a 199 338 response for that early dialog 340 - the forking proxy has not already sent a final response for any of 341 the early dialogs 343 When the forking proxy forks the initial request, it generates a 344 unique Via header branch parameter value for each forked leg. The 345 proxy can determine whether additional forking has occurred 346 downstream of the proxy by storing the top Via branch value from each 347 response which creates an early dialog. If the same top Via branch 348 value is received for multiple early dialogs, the proxy knows that 349 additional forking has occured downstream of the proxy. A non-2xx 350 final response received for a specific early dialog also terminates 351 all other early dialog for which the same top Via branch value was 352 received in the responses which created those early dialogs. 354 Based on implementation policy, the forking proxy MAY wait before 355 sending the 199 response, e.g. if it expects to receive a 2xx final 356 response on another dialog shortly after it received the non-2xx 357 final response which triggered the 199 response. 359 When a forking proxy generates a 199 response, the response MUST 360 contain a To header tag parameter, which identifies the early dialog 361 that has been terminated. The proxy MUST also insert a Reason header 362 [RFC3326] which contains the response code of the response that 363 triggered the 199 response. If the proxy has stored the Contact and 364 Record-Route header fields received in the responses that created 365 early dialogs, it SHALL insert those header fields in the 199 366 responses. 368 A forking proxy which supports generating of 199 responses MUST keep 369 track of early dialogs, in order to determine whether to generate a 370 199 response when the proxy receives a non-2xx final response. In 371 addition, the proxy MUST keep track on which early dialogs it has 372 received and forwarded 199 responses, in order to not generate 373 additional 199 responses for those early dialogs. 375 If a forking proxy receives a reliably sent 199 response for a 376 dialog, for which it has previously generated and sent a 199 377 response, it MUST forward the 199 response. In case of a unreliably 378 sent 199 response, the proxy MAY forward the 199 response, or it MAY 379 discard it. 381 When a forking proxy generates a 199 response, the response MUST NOT 382 be sent reliably. 384 7. Backward compatibility 386 Since all SIP entities involved in a session setup do not necessarily 387 support the specific meaning of the 199 Early Dialog Terminated 388 provisional response, the sender of the response MUST be prepared to 389 receive SIP requests and responses associated with the dialog for 390 which the 199 response was sent (a proxy can receive SIP messages 391 from either direction). If such request is received by a UA, it MUST 392 act in the same way as if it had received the request after sending 393 the final non-2xx response to the INVITE, as specified in [RFC3261]. 394 A UAC that receives a 199 response for an early dialog MUST NOT send 395 any further requests on that dialog, except for requests which 396 acknowledge reliable responses. A proxy MUST forward requests 397 according to [RFC3261], even if the proxy has knowledge that the 398 early dialog has been terminated. 400 The 199 Early Dialog Terminated response code does not "replace" a 401 final response. RFC 3261 [RFC3261] specifies when a final response 402 is sent. 404 8. 199 Early Dialog Terminated 406 The 199 Early Dialog Terminated response code allows a SIP entity to 407 indicate upstream that a specific dialog has been terminated, before 408 a final response is sent by the entity. The To header tag value is 409 used to identify the dialog. 411 9. Usage with SDP offer/answer 413 A 199 Early Dialog Terminated provisional response SHOULD NOT contain 414 an SDP offer/answer message body, unless required by the rules in 415 [RFC3264]. 417 NOTE: If the INVITE request did not contain an SDP offer, and the 199 418 response is the first reliably sent response, the 199 response is 419 required to contain an SDP offer. 421 10. Usage with 100rel 423 When a 199 Early Dialog Terminated provisional response is sent by a 424 UAS, since the provisional response is only used for information 425 purpose, the UAS SHOULD send it unreliably even if the 100rel option 426 tag [RFC3262] is present in the Require header of the associated 427 request. 429 When a forking proxy generates a 199 response, the response MUST NOT 430 be sent reliably. 432 11. Examples 434 11.1. Example with a forking proxy which generates 199 436 The figure shows an example, where a proxy (P1) forks an INVITE 437 received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4, 438 which send 18x provisional responses in order to create early dialogs 439 between themselves and the UAC. UAS_2 and UAS_3 reject the INVITE by 440 sending a 4xx error response each. When P1 receives the 4xx 441 responses it immediately sends 199 responses, associated with the 442 dialogs where the 4xx responses were received, towards the UAC. The 443 early dialog leg is shown in parenthesis. 445 UAC P1 UAS_2 UAS_3 UAS_4 446 | | | | | 447 |-- INVITE -->| | | | 448 | |--- INVITE (2) ->| | | 449 | |--- INVITE (3) --------->| | 450 | |--- INVITE (4) ----------------->| 451 | |<-- 18x (2) -----| | | 452 |<- 18x (2) --| | | | 453 | |<-- 18x (3) -------------| | 454 |<- 18x (3) --| | | | 455 | |<-- 18x (4) ---------------------| 456 |<- 18x (4) --| | | | 457 | |<-- 4xx (2) -----| | | 458 | |--- ACK (2) ---->| | | 459 |<- 199 (2) --| | | | 460 | |<-- 4xx (3) -------------| | 461 | |--- ACK (3) ------------>| | 462 |<- 199 (3) --| | | | 463 | |<-- 200 (4) ---------------------| 464 |<- 200 (4) --| | | | 465 |-- ACK (4) ->| | | | 466 | |--- ACK (4) -------------------->| 467 | | | | | 469 Figure 1: Example call flow 471 11.2. Example with a forking proxy which receives 200 OK 473 The figure shows an example, where a proxy (P1) forks an INVITE 474 received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4, 475 which send 18x provisional responses in order to create early dialogs 476 between themselves and the UAC. UAS_4 accepts the session by sending 477 a 200 OK final response. When P1 receives the 200 OK responses it 478 immediately forwards it towards the UAC. P1 does not send 199 479 responses for the early dialogs from UAS_2 and UAS_3, since P1 has 480 yet not received any final responses on those early dialogs (even if 481 P1 sends CANCEL request to UAS_2 and UAS_3 P1 may still receive 200 482 OK final response from UAS_2 or UAS_3, which P1 would have to forward 483 towards the UAC. The early dialog leg is shown in parenthesis. 485 UAC P1 UAS_2 UAS_3 UAS_4 486 | | | | | 487 |-- INVITE -->| | | | 488 | |--- INVITE (2) ->| | | 489 | |--- INVITE (3) --------->| | 490 | |--- INVITE (4) ----------------->| 491 | |<-- 18x (2) -----| | | 492 |<- 18x (2) --| | | | 493 | |<-- 18x (3) -------------| | 494 |<- 18x (3) --| | | | 495 | |<-- 18x (4) ---------------------| 496 |<- 18x (4) --| | | | 497 | |<-- 200 (4) ---------------------| 498 |<- 200 (4) --| | | | 499 |-- ACK (4) ->| | | | 500 | |--- ACK (4) -------------------->| 501 | | | | | 503 Figure 2: Example call flow 505 11.3. Example with two forking proxies, of which one generates 199 507 The figure shows an example, where a proxy (P1) forks an INVITE 508 received from UAC. One of the forked INVITEs reaches UAS_2. The 509 other forked INVITE reaches another proxy (P2), which forks the 510 INVITE to UAS_3 and UAS_4, which send 18x provisional responses in 511 order to create early dialogs between themselves and the UAC. UAS_3 512 and UAS_4 reject the INVITE by sending a 4xx error response each. P2 513 does not support the 199 response code, and forwards a single 4xx 514 response. When P1 receives the 4xx responses from P2, it manages to 515 associate the response with the early dialogs from both UAS_3 and 516 UAS_4, so it generates and sends two 199 response to indicate that 517 the early dialogs from UAS_3 and UAS_4 have been terminated. The 518 early dialog leg is shown in parenthesis. 520 UAC P1 P2 UAS_2 UAS_3 UAS_4 521 | | | | | | 522 |-- INVITE -->| | | | | 523 | |-- INVITE (2) ------------------>| | | 524 | |-- INVITE ---->| | | | 525 | | |--- INVITE (3) --------->| | 526 | | |--- INVITE (4) ----------------->| 527 | | |<-- 18x (3) -------------| | 528 | |<- 18x (3) ----| | | | 529 |<- 18x (3) --| | | | | 530 | | |<-- 18x (4) ---------------------| 531 | |<- 18x (4) ----| | | | 532 |<- 18x (4) --| | | | | 533 | | |<-- 4xx (3) -------------| | 534 | | |--- ACK (3) ------------>| | 535 | | |<-- 4xx (4) ---------------------| 536 | | |--- ACK (4) -------------------->| 537 | |<- 4xx (3) ----| | | | 538 | |-- ACK (3) --->| | | | 539 |<- 199 (3) --| | | | | 540 |<- 199 (4) --| | | | | 541 | |<- 200 (2) ----------------------| | | 542 |<- 200 (2) --| | | | | 543 |-- ACK (2) ->| | | | | 544 | |-- ACK (2) --------------------->| | | 545 | | | | | | 547 Figure 3: Example call flow 549 12. Security Considerations 551 General security issues related to SIP responses are described in 552 [RFC3261]. Due to the nature of the 199 response, it may be 553 attractive to use it for launching attacks in order to terminate 554 specific early dialogs. SIP security mechanisms (e.g. hop-to-hop 555 TLS) can be used to minimize, or eliminate, the risk for such 556 attacks. 558 13. IANA Considerations 560 This section registers a new SIP response code and a new option tag, 561 according to the procedures of RFC 3261. 563 13.1. IANA Registration of the 199 response code 565 This section registers a new SIP response code, 199. The required 566 information for this registration, as specified in RFC 3261, is: 568 RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC number of this specification]] 570 Response Code Number: 199 572 Default Reason Phrase: Early Dialog Terminated 574 13.2. IANA Registration of the 199 Option Tag 576 This section registers a new SIP option tag, 199. The required 577 information for this registration, as specified in RFC 3261, is: 579 Name: 199 581 Description: This option tag is for indicating support of the 199 582 Early Dialog Terminated provisional response code. When present 583 in a Supported header, it indicates that the UA supports the 584 response code. When present in a Require header in a request, 585 it indicates that the UAS MUST support the sending of the 586 response code. 588 14. Acknowledgements 590 Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet, 591 Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan, 592 Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo 593 Camarillo, Adam Roach, Bob Penfield,Tom Taylor, Ya Ching Tan, Keith 594 Drage and Hans Erik van Elburg for their feedback and suggestions. 596 15. References 598 15.1. Normative References 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 604 A., Peterson, J., Sparks, R., Handley, M., and E. 605 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 606 June 2002. 608 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 609 Provisional Responses in Session Initiation Protocol 610 (SIP)", RFC 3262, June 2002. 612 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 613 with Session Description Protocol (SDP)", RFC 3264, 614 June 2002. 616 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 617 Header Field for the Session Initiation Protocol (SIP)", 618 RFC 3326, December 2002. 620 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 621 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 622 RFC 3711, March 2004. 624 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 625 "Indicating User Agent Capabilities in the Session 626 Initiation Protocol (SIP)", RFC 3840, August 2004. 628 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 629 Preferences for the Session Initiation Protocol (SIP)", 630 RFC 3841, August 2004. 632 [RFC5009] Ejza, R., "Private Header (P-Header) Extension to the 633 Session Initiation Protocol (SIP) for Authorization of 634 Early Media", RFC 5009, September 2007. 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 15.2. Informational References 644 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 645 Initiation Protocol", RFC 5057, November 2007. 647 Author's Address 649 Christer Holmberg 650 Ericsson 651 Hirsalantie 11 652 Jorvas 02420 653 Finland 655 Email: christer.holmberg@ericsson.com