idnits 2.17.1 draft-ietf-sipping-race-examples-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2567. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. HASEBE 3 Internet-Draft J. KOSHIKO 4 Intended status: Best Current Practice Y. SUZUKI 5 Expires: Dec 30, 2007 T. YOSHIKAWA 6 NTT-East 7 P. Kyzivat 8 Cisco Systems, Inc. 9 Jun 30th, 2007 11 Examples call flow in race condition on Session Initiation Protocol 12 draft-ietf-sipping-race-examples-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of 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 December 30, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document gives examples of the Session Initiation Protocol (SIP) 46 call flows in race condition. Call flows in race condition are 47 confusing, and this document shows the best practice to handle them. 48 The elements in these call flows include SIP User Agents and SIP 49 Proxies. Call flow diagrams and message details are shown. 51 Table of Contents 53 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 54 1.1 General Assumptions. . . . . . . . . . . . . . . . . . . . .3 55 1.2 Legend for Message Flows . . . . . . . . . . . . . . . . . .3 56 1.3 SIP Protocol Assumptions . . . . . . . . . . . . . . . . . .3 57 2. The Dialog State Machine for INVITE dialog usage . . . . . . . .4 58 3. Race Conditions. . . . . . . . . . . . . . . . . . . . . . . . .9 59 3.1 Receiving message in the Moratorium State. . . . . . . . . .9 60 3.1.1 Receiving Initial INVITE retransmission. . . . . . . . .10 61 3.1.2 Receiving CANCEL(Early state). . . . . . . . . . . . . .11 62 3.1.3 Receiving BYE (Early state). . . . . . . . . . . . . . .13 63 3.1.4 Receiving re-INVITE (Established state)(case 1). . . . .15 64 3.1.5 Receiving re-INVITE (Established state)(case 2). . . . .19 65 3.1.6 Receiving BYE (Established state). . . . . . . . . . . .22 66 3.2 Receiving message in the Mortal State. . . . . . . . . . . .24 67 3.2.1 Receiving BYE(Established state) . . . . . . . . . . . .24 68 3.2.2 Receiving re-INVITE(Established state) . . . . . . . . .26 69 3.2.3 Receiving 200 OK for re-INVITE(Established state). . . .28 70 3.2.4 Receiving ACK (Moratorium state) . . . . . . . . . . . .31 71 3.3 Other race conditions. . . . . . . . . . . . . . . . . . . .32 72 3.3.1 Re-INVITE crossover. . . . . . . . . . . . . . . . . . .32 73 3.3.2 UPDATE and re-INVITE crossover . . . . . . . . . . . . .36 74 3.3.3 Receiving REFER(Established state) . . . . . . . . . . .40 75 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . .42 76 5. Security Considerations. . . . . . . . . . . . . . . . . . . . .42 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .42 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . .42 79 7.1 Normative References . . . . . . . . . . . . . . . . . . . .42 80 7.2 Informative References . . . . . . . . . . . . . . . . . . .42 81 Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . .43 82 Appendix B. BYE request overlapped on re-INVITE . . . . . . . . . .44 83 Appendix C. UA's behavior for CANCEL. . . . . . . . . . . . . . . .46 84 Appendix D. Notes on the request in Mortal state. . . . . . . . . .48 85 Appendix E. Forking and receiving new To tags . . . . . . . . . . .49 86 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . . .53 87 Intellectual Property and Copyright Statements. . . . . . . . . . .54 89 1. Overview 91 The call flows shown in this document were developed in the design of 92 a SIP IP communications network. These examples are of race 93 condition, which stems from the dialog state transition mainly 94 established by INVITE. 96 When implementing SIP, various complex situations may arise. 97 Therefore, it will be helpful to provide implementors of the protocol 98 with examples of recommended terminal and server behavior. 100 This document clarifies SIP UA behaviors when messages cross each 101 other as race conditions. By clarifying operation under race 102 conditions, inconsistent interpretations between implementations are 103 avoided and interoperability is expected to be promoted. 105 It is the hope of the authors that this document will be useful for 106 SIP implementors, designers, and protocol researchers and will help 107 them achieve the goal of a standard implementation of RFC 3261 [1]. 109 These call flows are based on the version 2.0 of SIP defined in RFC 110 3261 [1] with SDP usage described in RFC 3264 [2]. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in BCP 14, RFC 2119 [3]. 116 1.1 General Assumptions 118 A number of architecture, network, and protocol assumptions underlie 119 the call flows in this document. Note that these assumptions are not 120 requirements. They are outlined in this section so that they may be 121 taken into consideration and help understanding the call flow 122 examples. 124 These flows do not assume specific underlying transport protocols 125 such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for 126 details on the transport issues for SIP. 128 1.2 Legend for Message Flows 130 Dashed lines (---) and slash lines (/, \) represent signaling 131 messages that are mandatory to the call scenario. (X) represents 132 crossover of signaling messages. (->x, x<-) indicate that the packet 133 is lost. The arrow indicates the direction of message flow. Double 134 dashed lines (===) represent media paths between network elements. 136 Messages are identified in the figures as F1, F2, etc. These numbers 137 are used for references to the message details that follow the 138 Figure. 139 Comments in the message details are shown in the following form: 141 /* Comments. */ 143 1.3 SIP Protocol Assumptions 145 This document does not prescribe the flows precisely as they are 146 shown, but rather illustrates the principles for best practice. 148 They are best practice usages (orderings, syntax, selection of 149 features for the purpose, or handling of error) of SIP methods, 150 headers and parameters. Note: The flows in this document must not 151 be copied as they are by implementors because additional 152 characteristics were incorporated into the document for ease of 153 explanation. To sum up, the procedures described in this document 154 represent well-reviewed examples of SIP usage, which are best common 155 practice according to IETF consensus. 157 For simplicity in reading and editing the document, there are a 158 number of differences between some of the examples and actual SIP 159 messages. For instance, Call-IDs are often repeated, CSeq often 160 begins at 1, header fields are usually shown in the same order, 161 usually only the minimum required header field set is shown, and 162 other headers which would usually be included such as Accept, Allow, 163 etc. are not shown. 165 Actors: 167 Element Display Name URI IP Address 168 ------- ------------ --- ---------- 170 User Agent Alice sip:alice@atlanta.example.com 192.0.2.101 171 User Agent Bob sip:bob@biloxi.example.com 192.0.2.201 172 User Agent Carol sip:carol@chicago.example.com 192.0.2.202 173 Proxy Server ss.atlanta.example.com 192.0.2.111 175 2. The Dialog State Machine for INVITE dialog usage 177 Race conditions are generated when the dialog state of the receiving 178 side differs from that of the sending side. 180 For instance, a race condition occurs when UAC (User Agent Client) 181 sends a CANCEL in the Early state while UAS (User Agent Server) is 182 transiting from the Early state to the Confirmed state by sending a 183 200 OK to initial INVITE (indicated as "ini-INVITE" hereafter). 184 The DSM (dialog state machine) for the INVITE dialog usage is 185 presented as follows to help understanding UA's behavior in race 186 conditions. 188 The DSM clarifies UA's behavior by subdividing the dialog state shown 189 in RFC 3261 [1] into some internal states. We call the state before 190 a dialog establishment the Preparative state. The Confirmed state is 191 subdivided into two substates, the Moratorium and Established states, 192 and the Terminated state is subdivided into the Mortal and Morgue 193 states. Messages which are the triggers of the state transitions 194 between these states are indicated with arrows. In this figure, 195 messages which are not related to state transition are omitted. 197 Below are the DSMs for UAC and UAS respectively. 199 INV +-----------------------------------------------+ 200 --->| Preparative | 201 +-----------------------------------------------+ 202 | | | 203 | 3xx-6xx | 1xx-tag | 2xx 204 | | | 205 | | 1xx-tag | 206 | V w/new tag | 207 | +-----------------+ [new DSM] | 208 | 3xx-6xx | | | (new DSM | 209 +<--------| Early | | instance | 210 | | |<--+ created) | 211 | +-----------------+ | 212 | | | | 2xx w/new tag 213 | | BYE | 2xx | [new DSM] 214 | | +------------>+<-+ | (new DSM 215 | | | | instance 216 +-----C------------C-----+ +-----------C------+ | created) 217 | | Terminated | | | Confirmed | | | 218 | | +<----C---------| | | | 219 | | | | BYE(sr) | | | | 220 | | V | | V | | 221 | 2xx | +-----------+ | | +-----------+ | | 222 | +---C--| |---C-+ | | | | | 223 | | | | Mortal | | | BYE(r)| | Moratorium|<-C--+ 224 | +---C->| |<--C-+ | | | | 225 | ACK | +-----------+ | | +-----------+ | 226 | | | | | | | 227 | | | Timeout | | | ACK | 228 | | | | | | | 229 | V V | | V | 230 | +---------------+ | | +-----------+ | 231 | | | | | | |--C-+ 232 | | Morgue | | | |Established| | | 2xx,ACK 233 | | | | | | |<-C-+ 234 | +---------------+ | | +-----------+ | 235 | | | | 236 +------------------------+ +------------------+ 238 (r): indicates only reception is allowed. 239 Where (r) is not indicated, response means receive, request 240 means send. 242 Figure 1. DSM for INVITE dialog usage (Caller) 244 Figure 1 represents the caller's DSM for the INVITE dialog usage. 245 Caller MAY send a BYE in the Early state, even though this behavior 246 is NOT RECOMMENDED. The BYE sent in the Early state terminates the 247 early dialog with a specific To tag. That is, when a proxy is 248 performing forking, the BYE is only able to terminate the early 249 dialog with a particular UA. If caller wants to terminate all early 250 dialogs instead of that with a particular UA, it needs to send 251 CANCEL, not BYE. However, it is not illegal to send BYE in the Early 252 state to terminate a specific early dialog according to the caller's 253 intent. Moreover, until caller receives a final response and 254 terminates the INVITE transaction, the caller MUST be prepared to 255 establish a dialog by receiving a new response to the INVITE even 256 though it had sent a CANCEL or BYE and terminated the dialog (see 257 Appendix A). 259 INV +-----------------------------------------------+ 260 --->| Preparative | 261 +-----------------------------------------------+ 262 | | | 263 | 3xx-6xx | 1xx-tag | 2xx 264 | | | 265 | V | 266 | +------------------+ | 267 | 3xx-6xx | | | 268 +<--------| Early | | 269 | | | | 270 | +------------------+ | 271 | | | | 272 | | BYE | 2xx | 273 | | +------------>+<-+ 274 | | | 275 +-----C------------C-----+ +-----------C------+ 276 | | Terminated | | | Confirmed | | 277 | | +<----C---------| | | 278 | | | | BYE(sr) | | | 279 | | V | | V | 280 | | +------------+ | | +-----------+ | 281 | | | |---C-+ | | |--C-+ 282 | | | Mortal | | | BYE | | Moratorium| | | 2xx 283 | | | |<--C-+ | | |<-C-+ if ACK not 284 | | +------------+ | | +-----------+ | received 285 | | | | | | | 286 | | | Timeout | | | ACK | 287 | | | | | | | 288 | V V | | V | 289 | +---------------+ | | +-----------+ | 290 | | | | | | | | 291 | | Morgue | | | |Established| | 292 | | | | | | | | 293 | +---------------+ | | +-----------+ | 294 | | | | 295 +------------------------+ +------------------+ 297 (sr): indicates that both sending and reception are allowed. 298 Where (sr) is not indicated, response means send, 299 request means receive. 301 Figure 2. DSM for INVITE dialog usage (Callee) 303 Figure 2 represents callee's DSM for the INVITE dialog usage. 304 The figure does not illustrate the state transition related to 305 CANCEL request. CANCEL request does not cause a dialog state 306 transition. However, the callee terminates the dialog and triggers 307 the dialog transition by sending 487 immediately after the reception 308 of the CANCEL. Considering this, the behavior upon the reception of 309 the CANCEL request is further explained in Appendix C. 311 Following are UA's behaviors in each state. 313 Preparative (Pre): The Preparative state is a state until the 314 early dialog is established by sending or receiving a 315 provisional response with To tag after an ini-INVITE is sent or 316 received. The dialog has not existed yet in the Preparative 317 state. If UA sends or receives a 2xx response, the dialog 318 state transit from the Preparative to the Moratorium state 319 which is a substate of the Confirmed state. 320 In addition, if UA sends or receives a 3xx-6xx response the 321 dialog state transit to the Morgue state which is a substate of 322 the Terminated state. Sending an ACK for a 3xx-6xx response 323 and retransmissions of 3xx-6xx are not expressed on the DSMs 324 because they are sent by the INVITE transaction. 326 Early (Ear): The early dialog is established by sending or 327 receiving a provisional response with To tag. The early dialog 328 exists though the dialog does not exist in this state yet. 329 The dialog state transits from the Early to Moratorium state, a 330 substate of the Confirmed state, by sending or receiving a 2xx 331 response. In addition, the dialog state transits to the Morgue 332 state, a substate of the Terminated state, by sending or 333 receiving a 3xx-6xx response. Sending an ACK for a 3xx-6xx 334 response and retransmissions of 3xx-6xx are not expressed on 335 this DSM because they are automatically processed on 336 transaction layer and don't influence the dialog state. UAC 337 may send CANCEL in the Early state. UAC may send BYE 338 (although it is not recommended). UAS may send a 1xx-6xx 339 response. Sending or receiving of a CANCEL request does not 340 have direct influences on dialog state. The UA's behavior upon 341 the reception of the CANCEL request is further explained in 342 Appendix C. 344 Confirmed (Con): Sending or receiving of a 2xx final response 345 establishes a dialog. Dialog exists in this state. The 346 Confirmed state transits to the Mortal state, a substate of the 347 Terminated state, by sending or receiving a BYE request. The 348 Confirmed state has two substates, the Moratorium and 349 Established state, which are different in messages UAs are 350 allowed to send. 352 Moratorium (Mora): The Moratorium state is a substate of the 353 Confirmed state and inherits the behavior of the superstate. 354 The Moratorium state transits to the Established state by 355 sending or receiving an ACK request. UAC may send ACK and UAS 356 may send a 2xx final response. 358 Established (Est): The Established state is a substate of the 359 Confirmed state and inherits the behavior of superstate. Both 360 caller and callee may send various messages which influence a 361 dialog. Caller supports the transmission of ACK in response to 362 retransmission of a 2xx response to an ini-INVITE. 364 Terminated (Ter): The Terminated state is divided into two 365 substates, the Mortal and Morgue states, to cover the behavior 366 when a dialog is being terminated. In this state, UAs hold 367 information about the dialog which is being terminated. 369 Mortal (Mort): Caller and callee enter the Mortal state by sending 370 or receiving a BYE. UA MUST NOT send any new requests within 371 the dialog because there is no dialog. (Here the new requests 372 do not include ACK for 2xx and BYE for 401 or 407 as further 373 explained in Appendix D below.) 374 In this state, only BYE or its response can be handled, and no 375 other messages can be received. This addresses the case where 376 BYE is sent by both a caller and a callee to exchange reports 377 about the session when it is being terminated. Therefore the 378 UA possesses dialog information for internal processing but the 379 dialog shouldn't be externally visible. The UA stops managing 380 its dialog state and changes it to the Morgue state, when the 381 BYE transaction is terminated. 383 Morgue (Morg): The dialog no longer exists in this state. 384 Sending or receiving of signaling which influences a dialog is 385 not performed. (A dialog is literally terminated.) 386 Caller and callee enter the Morgue state via the termination of 387 the BYE or INVITE transaction. 389 3. Race conditions 391 This section details race condition between two SIP UAs, Alice and 392 Bob. Alice (sip:alice@atlanta.example.com) and Bob 393 (sip:bob@biloxi.example.com) are assumed to be SIP phones or 394 SIP-enabled devices. Only significant signaling is illustrated. 395 Dialog state transitions caused by sending or receiving of SIP 396 messages as well as '*race*', which indicates race condition, are 397 shown. (For abbreviations for the dialog state transitions, refer to 398 Section 2.) 399 '*race*' indicates the moment when a race condition occurs. 401 Examples of race conditions are shown below. 403 3.1 Receiving message in the Moratorium State 405 This section shows some examples of call flow in race condition when 406 receiving the message from other states in the Moratorium state. 408 3.1.1 Receiving Initial INVITE retransmission (Preparative state) 409 in Moratorium state 411 State Alice Bob State 412 | | 413 | ini-INVITE F1 | 414 |------------------------------------>| 415 Pre | 180 F2(Packet loss) | Pre 416 | x<-----------------------| 417 | | Ear 418 | ini-INVITE F4(=F1) 200 F3 | 419 |------------------ --------------| 420 | \ / | Mora 421 | X | 422 | / \ | 423 |<----------------- ------------->| *race* 424 Mora | ACK F5 | 425 |------------------------------------>| 426 Est | | Est 427 | | 429 This scenario illustrates the race condition which occurs when UAS 430 receives a Preparative message in the Moratorium state. All 431 provisional responses to the initial INVITE (ini-INVITE F1) are lost, 432 and UAC retransmits an ini-INVITE (F4). At the same time as 433 retransmission, UAS generates a 200 OK (F3) to the ini-INVITE and it 434 terminates an INVITE server transaction, according to Section 435 13.3.1.4 of RFC 3261 [1]. 436 However, it is reported that terminating an INVITE server transaction 437 by 200 OK is a SIP bug. (http://bugs.sipit.net/, #769) 438 Therefore, the INVITE server transaction is not terminated at F3, and 439 the F4 MUST be properly handled as a retransmission. 440 (UAs that do not deal with this bug still need to recognize the 441 dialog relying on its From tag and Call-ID, and the retransmitted 442 request relying on the CSeq header field value even though it does 443 not match the transaction.) 445 In RFC 3261 [1], it is not specified whether UAS retransmits 200 to 446 the retransmission of ini-INVITE. Considering the retransmission of 447 200 triggered by timer (TU keeps retransmitting 200 based on T1 and 448 T2 until it receives an ACK), according to Section 13.3.1.4 of RFC 449 3261 [1], it seems unnecessary to retransmit 200 when the UAS 450 receives the retransmission of ini-INVITE. (For implementation, it 451 does not matter if the UAS sends the retransmission of 200, since the 452 200 does not cause any problem.) 453 Message Details 455 F1 INVITE Alice -> Bob 457 F2 180 Ringing Bob -> Alice 459 /* 180 response is lost and does not reach Alice. */ 461 F3 200 OK Bob -> Alice 463 /* According to 13.3.1.4 of RFC 3261, an INVITE server transaction is 464 terminated at this point. However, this has been reported as a 465 SIP bug, and the UAS MUST correctly recognize the ini-INVITE (F4) 466 as a retransmission. */ 468 F4 INVITE (retransmission) Alice -> Bob 470 /* F4 is a retransmission of F1. They are exactly the same INVITE 471 request. For UAs do not deal with the bug reported in #769 (an 472 INVITE server transaction is terminated by 200 to INVITE), this 473 request does not match the transaction as well as the dialog 474 since it does not have a To tag. 475 However, Bob have to recognize the retransmitted INVITE correctly, 476 without treating it as a new INVITE. */ 478 F5 ACK Alice -> Bob 480 3.1.2 Receiving CANCEL (Early state) 481 in Moratorium state 483 State Alice Bob State 484 | | 485 | INVITE F1 | 486 |----------------------------->| 487 Pre | 180 Ringing F2 | Pre 488 |<-----------------------------| 489 Ear | | Ear 490 |CANCEL F3 200(INVITE) F4| 491 |------------ -------------| 492 | \ / | Mora 493 | X | 494 | / \ | 495 |<----------- ------------>| *race* 496 Mora | | 497 | ACK F6 200(CANCEL) F5| 498 |------------ -------------| 499 Est | \ / | 500 | X | 501 | / \ | 502 |<----------- ------------>| 503 | | Est 504 | One Way RTP Media | 505 | (Two Way RTP Media possible) | 506 |<=============================| 507 | BYE F7 | 508 |----------------------------->| 509 Mort | 200 F8 | Mort 510 |<-----------------------------| 511 | ^ ^ | 512 | | Timer K | | 513 | V | | 514 Morg | Timer J | | 515 | V | 516 | | Morg 517 | | 519 This scenario illustrates the race condition which occurs when UAS 520 receives an Early message, CANCEL, in the Moratorium state. Alice 521 sends a CANCEL and Bob sends a 200 OK response to the initial INVITE 522 message at the same time. As described in the previous section, 523 according to RFC 3261, an INVITE server transaction is supposed to be 524 terminated by a 200 response, but this has been reported as a bug 525 #769. 527 This section describes a case in which an INVITE server transaction 528 is not terminated by a 200 response to the INVITE request. In this 529 case, there is an INVITE transaction which the CANCEL request 530 matches, so a 200 response is sent to the request. This 200 response 531 simply means that the next hop received the CANCEL request 532 (Successful CANCEL (200) does not mean an INVITE failure). When UAS 533 does not deal with #769, UAC MAY receive a 481 response for CANCEL 534 since there is no transaction which the CANCEL request matches. This 535 481 simply means that there is no matching INVITE server transaction 536 and CANCEL is not sent to the next hop. 537 Regardless of the success/failure of the CANCEL, Alice checks the 538 final response to INVITE, and if she receives 200 to the INVITE 539 request she immediately sends a BYE and terminates the dialog. 540 (Section 15, RFC 3261 [1]) 542 From the time F1 is received by Bob until the time that F8 is sent by 543 Bob, media may be flowing one way from Bob to Alice. From the time 544 that an answer is received by Alice from Bob there is the possibility 545 that media may flow from Alice to Bob as well. However, once Alice 546 has decided to cancel the call, she presumably will not send media, 547 so practically speaking the media stream will remain one way. 549 Message Details 551 F1 INVITE Alice -> Bob 553 F2 180 Ringing Bob -> Alice 555 F3 CANCEL Alice -> Bob 557 /* Alice sends a CANCEL in the Early state. */ 559 F4 200 OK (INVITE) Bob -> Alice 561 /* Alice receives a 200 to INVITE (F1) in the Moratorium state. 562 Alice has the potential to send as well as receive media, but in 563 practice will not send because there is an intent to end the 564 call. */ 566 F5 200 OK (CANCEL) Bob -> Alice 568 /* 200 to CANCEL simply means that the CANCEL was received. 569 The 200 response is sent, since this document deals with the bug 570 reported in #769. When an INVITE server transaction is terminated 571 as the procedure stated in RFC 3261, UAC MAY receive 481 response 572 instead of 200. */ 574 F6 ACK Alice -> Bob 576 /* INVITE is successful, and the CANCEL becomes invalid. Bob 577 establishes RTP streams. 578 However, the next BYE request immediately terminates the dialog 579 and session. */ 581 F7 BYE Alice -> Bob 583 F8 200 OK Bob -> Alice 585 3.1.3 Receiving BYE (Early state) 586 in Moratorium state 588 State Alice Bob State 589 | | 590 | ini-INVITE F1 | 591 |------------------------------->| 592 Pre | 180 F2 | Pre 593 |<-------------------------------| 594 Ear | | Ear 595 | BYE F4 200(INVITE) F3| 596 |------------- --------------| 597 Mort | \ / | Mora 598 | X | 599 | / \ | 600 |<------------ ------------->| *race* 601 | | Mort 602 | ACK F5 200(BYE) F6 | 603 |------------- --------------| 604 | \ / ^ | 605 | X | | 606 | / \ | | 607 |<------------ ------------->| 608 | ^ | | 609 | | Timer K | | 610 | V | | 611 Morg | Timer J | | 612 | V | 613 | | Morg 614 | | 616 This scenario illustrates the race condition which occurs when UAS 617 receives an Early message, BYE, in the Moratorium state. Alice sends 618 a BYE in the Early state and Bob sends a 200 OK response to the 619 initial INVITE request at the same time. Bob receives the BYE in the 620 Confirmed dialog state though Alice sent the request in the Early 621 state (As explained in Section 2 and Appendix A, this behavior is NOT 622 RECOMMENDED). When a proxy is performing forking, the BYE is only 623 able to terminate the early dialog with a particular UA. If caller 624 wants to terminate all early dialogs instead of that with a 625 particular UA, it needs to send CANCEL, not BYE. However, it is not 626 illegal to send BYE in the Early state to terminate a specific early 627 dialog according to the caller's intent. 629 The BYE functions normally even if it is received after the INVITE 630 transaction termination because BYE differs from CANCEL, and is sent 631 not to the request but to the dialog. Alice gets into the Mortal 632 state on sending the BYE request, and remains Mortal until the 633 Timer K timeout occurs. In the Mortal state, UAC does not establish 634 a session, even though it receives a 200 response to INVITE. Even 635 so, the UAC sends an ACK to 200 for the completion of INVITE 636 transaction. The ACK is always sent to complete the three-way 637 handshake of INVITE transaction (Further explained in Appendix D 638 below). 640 Message Details 642 F1 INVITE Alice -> Bob 644 F2 180 Ringing Bob -> Alice 645 F3 200 OK (ini-INVITE) Bob -> Alice 647 F4 BYE Alice -> Bob 649 /* Alice transits to the Mortal state upon sending BYE. 650 Therefore, after this, she does not begin a session even though 651 she receives a 200 response with an answer. */ 653 F5 ACK Alice -> Bob 655 F6 200 OK (BYE) Bob -> Alice 657 3.1.4 Receiving re-INVITE (Established state) 658 in Moratorium state (case 1) 660 State Alice Bob State 661 | | 662 | ini-INVITE w/offer1 F1 | 663 |------------------------------->| 664 Pre | 180 F2 | Pre 665 |<-------------------------------| 666 Ear | | Ear 667 | 200(ini-INV) w/answer1 F3 | 668 |<-------------------------------| 669 Mora | ACK F4(packet loss) | Mora 670 |-------------------->x | 671 Est | | 672 | re-INVITE F6 200 F5(=F3) | 673 | w/offer2 w/answer1 | 674 |------------- --------------| 675 | \ / | 676 | X | 677 | / \ | 678 |<------------ ------------->| *race* 679 | 200(re-INV) F8| 680 | ACK F7(=F4) w/answer2 | 681 |------------- --------------| 682 | \ / | 683 | X | 684 | / \ | 685 |<------------ ------------->| 686 | ACK (re-INV) F9 | Est 687 |------------------------------->| 688 | | 689 | | 691 This scenario illustrates the race condition which occurs when UAS 692 receives re-INVITE request sent from the Established state, in the 693 Moratorium state. 695 UAS receives a re-INVITE (w/offer2) before receiving an ACK for 696 ini-INVITE (w/offer1). UAS sends a 200 OK (w/answer2) to the 697 re-INVITE (F8) because it has sent a 200 OK (w/answer1) to the 698 ini-INVITE (F3, F5) and the dialog has already been established. 699 (Because F5 is a retransmission of F3, SDP negotiation is not 700 performed here.) 702 If a 200 OK to the ini-INVITE has an offer and the answer is in the 703 ACK, it is recommended that UA return a 491 to the re-INVITE (refer 704 to 3.1.5). (Note: 500 with Retry-After header may be returned, if 705 the 491 response is understood to indicate request collision. 706 However, 491 is recommended here because 500 applies to so many cases 707 that it is difficult to determine what the real problem was.) 708 As it can be seen in Section 3.3.2 below, the 491 response seems to 709 be closely related to session establishment, even in cases other than 710 INVITE cross-over. This example recommends 200 be sent instead of 711 491 because it does not have influence on session. However, a 491 712 response can also lead to the same outcome, so the either response 713 can be used. 715 Moreover, if UAS doesn't receive an ACK for a long time, it should 716 send a BYE and terminate the dialog. Note that ACK F7 has the same 717 CSeq number as ini-INVITE F1 (See Section 13.2.2.4 of RFC 3261). 718 The UA should not reject or drop the ACK on grounds of CSeq number. 720 Note: There is a hint for implementation to avoid the race conditions 721 of this type. That is for the caller to delay sending re-INVITE F6 722 for some period of time (2 seconds, perhaps), from which the caller 723 is reasonably able to assume that its ACK has been received. 724 Implementors can decouple the actions of the user (e.g. pressing the 725 hold button) from the actions of the protocol (the sending of 726 re-INVITE F6), so the UA can behave as such. In this case, it is 727 dependent on the implementor's choice how long it waits. In most 728 cases, such implementation may be useful to prevent a type of race 729 condition shown in this section. 731 Message Details 733 F1 INVITE Alice -> Bob 735 INVITE sip:bob@biloxi.example.com SIP/2.0 736 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 737 Max-Forwards: 70 738 From: Alice ;tag=9fxced76sl 739 To: Bob 740 Call-ID: 3848276298220188511@atlanta.example.com 741 CSeq: 1 INVITE 742 Contact: 743 Content-Type: application/sdp 744 Content-Length: 137 746 v=0 747 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 748 s=- 749 c=IN IP4 192.0.2.101 750 t=0 0 751 m=audio 49172 RTP/AVP 0 752 a=rtpmap:0 PCMU/8000 754 /* Detailed messages are shown for the sequence to illustrate offer 755 and answer examples. */ 757 F2 180 Ringing Bob -> Alice 759 SIP/2.0 180 Ringing 760 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 761 ;received=192.0.2.101 762 From: Alice ;tag=9fxced76sl 763 To: Bob ;tag=8321234356 764 Call-ID: 3848276298220188511@atlanta.example.com 765 CSeq: 1 INVITE 766 Contact: 767 Content-Length: 0 769 F3 200 OK Bob -> Alice 771 SIP/2.0 200 OK 772 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 773 ;received=192.0.2.101 774 From: Alice ;tag=9fxced76sl 775 To: Bob ;tag=8321234356 776 Call-ID: 3848276298220188511@atlanta.example.com 777 CSeq: 1 INVITE 778 Contact: 779 Content-Type: application/sdp 780 Content-Length: 133 782 v=0 783 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 784 s=- 785 c=IN IP4 192.0.2.201 786 t=0 0 787 m=audio 3456 RTP/AVP 0 788 a=rtpmap:0 PCMU/8000 789 F4 ACK Alice -> Bob 791 ACK sip:bob@client.biloxi.example.com SIP/2.0 792 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 793 Max-Forwards: 70 794 From: Alice ;tag=9fxced76sl 795 To: Bob ;tag=8321234356 796 Call-ID: 3848276298220188511@atlanta.example.com 797 CSeq: 1 ACK 798 Content-Length: 0 800 /* ACK request is lost. */ 802 F5(=F3) 200 OK Bob -> Alice (retransmission) 804 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 805 received an ACK. */ 807 F6 re-INVITE Alice -> Bob 809 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 810 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 811 Max-Forwards: 70 812 From: Alice ;tag=9fxced76sl 813 To: Bob ;tag=8321234356 814 Call-ID: 3848276298220188511@atlanta.example.com 815 CSeq: 2 INVITE 816 Content-Length: 147 818 v=0 819 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 820 s=- 821 c=IN IP4 192.0.2.101 822 t=0 0 823 m=audio 49172 RTP/AVP 0 824 a=rtpmap:0 PCMU/8000 825 a=sendonly 827 F7(=F4) ACK Alice -> Bob (retransmission) 829 F8 200 OK (re-INVITE) Bob -> Alice 831 SIP/2.0 200 OK 832 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 833 Max-Forwards: 70 834 From: Alice ;tag=9fxced76sl 835 To: Bob ;tag=8321234356 836 Call-ID: 3848276298220188511@atlanta.example.com 837 CSeq: 2 INVITE 838 Content-Length: 143 840 v=0 841 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com 842 s=- 843 c=IN IP4 192.0.2.201 844 t=0 0 845 m=audio 3456 RTP/AVP 0 846 a=rtpmap:0 PCMU/8000 847 a=recvonly 849 F9 ACK (re-INVITE) Alice -> Bob 851 ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 852 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21 853 Max-Forwards: 70 854 From: Alice ;tag=9fxced76sl 855 To: Bob ;tag=8321234356 856 Call-ID: 3848276298220188511@atlanta.example.com 857 CSeq: 2 ACK 858 Content-Length: 0 860 3.1.5 Receiving re-INVITE (Established state) 861 in Moratorium state (case 2) 863 State Alice Bob State 864 | | 865 | ini-INVITE (no offer) F1 | 866 |------------------------------->| 867 Pre | 180 F2 | Pre 868 |<-------------------------------| 869 Ear | | Ear 870 | 200(ini-INV) w/offer1 F3 | 871 |<-------------------------------| 872 Mora | ACK w/answer1 F4(packet loss) | Mora 873 |-------------------->x | 874 Est | | 875 | re-INVITE F6 200 F5(=F3) | 876 | w/offer2 w/offer1 | 877 |------------- --------------| 878 | \ / | 879 | X | 880 | / \ | 881 |<------------ ------------->| 882 | ACK F7(=F4) 491(re-INV) F8| 883 |------------- --------------| 884 | \ / | 885 | X | 886 | / \ | 887 |<------------ ------------->| 888 | ACK (re-INV) F9 | Est 889 |------------------------------->| 890 | | 891 | | 893 This scenario is basically the same as that of Section 3.1.4, but 894 differs in sending an offer in 200 and an answer in ACK. Different 895 to the previous case, the offer in the 200 (F3) and the offer in the 896 re-INVITE (F6) collide with each other. 898 Bob sends 491 to re-INVITE (F6) since he is not able to properly 899 handle a new request until he receives an answer. (Note: 500 with 900 Retry-After header may be returned, if the 491 response is understood 901 to indicate request collision. However, 491 is recommended here 902 because 500 applies to so many cases that it is difficult to 903 determine what the real problem was.) 904 Even if F6 is UPDATE with offer, it will reach the same result. 906 Note: As noted in Section 3.1.4, it may be useful for the caller to 907 delay sending re-INVITE F6 for some period of time (2 seconds, 908 perhaps), from which the caller is reasonably able to assume that its 909 ACK has been received, to prevent a type of race condition shown in 910 this section. 912 Message Details 914 F1 INVITE Alice -> Bob 916 INVITE sip:bob@biloxi.example.com SIP/2.0 917 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 918 Max-Forwards: 70 919 From: Alice ;tag=9fxced76sl 920 To: Bob 921 Call-ID: 3848276298220188511@atlanta.example.com 922 CSeq: 1 INVITE 923 Contact: 924 Content-Length: 0 926 /* The request does not contain an offer. Detailed messages are 927 shown for the sequence to illustrate offer and answer 928 examples. */ 930 F2 180 Ringing Bob -> Alice 931 F3 200 OK Bob -> Alice 933 SIP/2.0 200 OK 934 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 935 ;received=192.0.2.101 936 From: Alice ;tag=9fxced76sl 937 To: Bob ;tag=8321234356 938 Call-ID: 3848276298220188511@atlanta.example.com 939 CSeq: 1 INVITE 940 Contact: 941 Content-Type: application/sdp 942 Content-Length: 133 944 v=0 945 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 946 s=- 947 c=IN IP4 192.0.2.201 948 t=0 0 949 m=audio 3456 RTP/AVP 0 950 a=rtpmap:0 PCMU/8000 952 /* An offer is made in 200. */ 954 F4 ACK Alice -> Bob 956 ACK sip:bob@client.biloxi.example.com SIP/2.0 957 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 958 Max-Forwards: 70 959 From: Alice ;tag=9fxced76sl 960 To: Bob ;tag=8321234356 961 Call-ID: 3848276298220188511@atlanta.example.com 962 CSeq: 1 ACK 963 Content-Type: application/sdp 964 Content-Length: 137 966 v=0 967 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 968 s=- 969 c=IN IP4 192.0.2.101 970 t=0 0 971 m=audio 49172 RTP/AVP 0 972 a=rtpmap:0 PCMU/8000 974 /* The request contains an answer, but the request is lost. */ 976 F5(=F3) 200 OK Bob -> Alice (retransmission) 978 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 979 received an ACK. */ 981 F6 re-INVITE Alice -> Bob 983 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 985 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 986 Max-Forwards: 70 987 From: Alice ;tag=9fxced76sl 988 To: Bob ;tag=8321234356 989 Call-ID: 3848276298220188511@atlanta.example.com 990 CSeq: 2 INVITE 991 Content-Length: 147 993 v=0 994 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 995 s=- 996 c=IN IP4 192.0.2.101 997 t=0 0 998 m=audio 49172 RTP/AVP 0 999 a=rtpmap:0 PCMU/8000 1000 a=sendonly 1002 /* The request contains an offer. */ 1004 F7(=F4) ACK Alice -> Bob (retransmission) 1006 /* A retransmission triggered by the reception of a retransmitted 1007 200. */ 1009 F8 491 (re-INVITE) Bob -> Alice 1011 /* Bob sends 491 (Request Pending), since Bob has a pending 1012 offer. */ 1014 F9 ACK (re-INVITE) Alice -> Bob 1016 3.1.6 Receiving BYE (Established state) 1017 in Moratorium state 1019 State Alice Bob State 1020 | | 1021 | INVITE F1 | 1022 |-------------------------->| 1023 Pre | 180 Ringing F2 | Pre 1024 |<--------------------------| 1026 Ear | | Ear 1027 | 200 OK F3 | 1028 |<--------------------------| 1029 Mora | ACK F4(packet loss) | Mora 1030 |--------------->x | 1031 Est | Both Way RTP Media | 1032 |<=========================>| 1033 | BYE F6 200 F5(=F3)| 1034 |----------- -----------| 1035 Mort | \ / | 1036 | X | 1037 | / \ | 1038 |<---------- ---------->| *race* 1039 |ACK F7(=F4) 200(BYE) F8| Mort 1040 |----------- -----------| 1041 | \ / | 1042 | X | 1043 | / \ | 1044 |<---------- ---------->| 1045 | ^ ^ | 1046 | | Timer K | | 1047 | V | | 1048 Morg | Timer J | | 1049 | V | 1050 | | Morg 1051 | | 1053 This scenario illustrates the race condition which occurs when UAS 1054 receives an Established message, BYE, in the Moratorium state. 1055 An ACK request for a 200 OK response is lost (or delayed). 1056 Immediately after Bob retransmits the 200 OK to ini-INVITE, and Alice 1057 sends a BYE request at the same time. Depending on the 1058 implementation of a SIP UA, Alice may start a session again by the 1059 reception of the retransmitted 200 OK with SDP since she has already 1060 terminated a session by sending a BYE. In that case, when UAC 1061 receives a retransmitted 200 OK after sending a BYE, a session should 1062 not be started again since the session which is not associated with 1063 dialog still remains. Moreover, in the case where UAS sends an offer 1064 in a 200 OK , UAS should not start a session again for the same 1065 reason if UAS receives a retransmitted ACK after receiving a BYE. 1067 Note: As noted in Section 3.1.4, there is a hint for implementation 1068 to avoid the race conditions of this type. That is for the caller to 1069 delay sending BYE F6 for some period of time (2 seconds, perhaps), 1070 from which the caller is reasonably able to assume that its ACK has 1071 been received. Implementors can decouple the actions of the user 1072 (e.g. hanging up) from the actions of the protocol (the sending of 1073 BYE F6), so the UA can behave as such. In this case, it is dependent 1074 on the implementor's choice how long it waits. In most cases, such 1075 implementation may be useful to prevent a type of race condition 1076 shown in this section. 1078 Message Details 1080 F1 INVITE Alice -> Bob 1082 F2 180 Ringing Bob -> Alice 1084 F3 200 OK Bob -> Alice 1086 F4 ACK Alice -> Bob 1088 /* ACK request is lost. */ 1090 F5(=F3) 200 OK Bob -> Alice 1092 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 1093 received an ACK. */ 1095 F6 BYE Alice -> Bob 1097 /* Bob retransmits a 200 OK and Alice sends a BYE at the same time. 1098 Alice transits to the Mortal state, so she does not begin a 1099 session after this even though she receives a 200 response to 1100 the re-INVITE. */ 1102 F7(=F4) ACK Alice -> Bob 1104 F8 200 OK (BYE) Bob -> Alice 1106 /* Bob sends a 200 OK to the BYE. */ 1108 3.2 Receiving message in the Mortal State 1110 This section shows some examples of call flow in race condition 1111 when receiving the message from other states in the Mortal state. 1113 3.2.1 Receiving BYE (Establish state) 1114 in Mortal state 1116 State Alice Bob State 1117 | | 1118 | INVITE F1 | 1119 |----------------------->| 1121 Pre | 180 Ringing F2 | Pre 1122 |<-----------------------| 1123 Ear | | Ear 1124 | 200 OK F3 | 1125 |<-----------------------| 1126 Mora | ACK F4 | Mora 1127 |----------------------->| 1128 Est | Both Way RTP Media | Est 1129 |<======================>| 1130 | | 1131 | BYE F5 BYE F6 | 1132 |--------- ----------| 1133 Mort | \ / | Mort 1134 | X | 1135 | / \ | 1136 |<-------- --------->| *race* 1137 | | 1138 | 200 F8 200 F7 | 1139 |--------- ----------| 1140 | \ / | 1141 | X | 1142 | / \ | 1143 |<-------- --------->| 1144 | ^ ^ | 1145 | | Timer K | | 1146 | V | | 1147 Morg | Timer J | | 1148 | V | 1149 | | Morg 1150 | | 1152 This scenario illustrates the race condition which occurs when UAS 1153 receives an Established message, BYE, in the Mortal state. 1154 Alice and Bob send a BYE at the same time. A dialog and session are 1155 ended shortly after a BYE request is passed to a client transaction. 1156 As shown in Section 2, UA remains in the Mortal state. 1158 UAs in the Mortal state return error responses to the requests that 1159 operate dialog or session, such as re-INVITE, UPDATE, or REFER. 1160 However, UA shall return 200 OK to the BYE taking the use case into 1161 consideration where BYE request is sent by both a caller and a callee 1162 to exchange reports about the session when it is being terminated. 1163 (Since the dialogue and the session both terminate when a BYE is 1164 sent, the choice of sending 200 or an error response upon receiving 1165 BYE in the Mortal state does not affect the resulting termination. 1166 Therefore, even though this example uses a 200 response, other 1167 responses can also be used.) 1168 Message Details 1170 F1 INVITE Alice -> Bob 1172 F2 180 Ringing Bob -> Alice 1174 F3 200 OK Bob -> Alice 1176 F4 ACK Alice -> Bob 1178 F5 BYE Alice -> Bob 1180 /* The session is terminated at the moment Alice sends a BYE. 1181 The dialog still exists then, but it is certain to be terminated 1182 in a short period of time. The dialog is completely 1183 terminated when the timeout of the BYE request occurs. */ 1185 F6 BYE Bob -> Alice 1187 /* Bob has also transmitted a BYE simultaneously with Alice. 1188 Bob terminates the session and the dialog. */ 1190 F7 200 OK Bob -> Alice 1192 /* Since the dialog is in the Moratorium state, Bob responds with 1193 a 200 to the BYE request. */ 1195 F8 200 OK Alice -> Bob 1197 /* Since Alice has transited from the Established state to the Mortal 1198 state by sending BYE, Alice responds with a 200 to the BYE 1199 request. */ 1201 3.2.2 Receiving re-INVITE (Establish state) 1202 in Mortal state 1204 State Alice Bob State 1205 | | 1206 | INVITE F1 | 1207 |----------------------->| 1208 Pre | 180 Ringing F2 | Pre 1209 |<-----------------------| 1210 Ear | | Ear 1211 | 200 OK F3 | 1212 |<-----------------------| 1213 Mora | ACK F4 | Mora 1214 |----------------------->| 1216 Est | Both Way RTP Media | Est 1217 |<======================>| 1218 | | 1219 | BYE F5 re-INVITE F6| 1220 |--------- ----------| 1221 Mort | \ / | 1222 | X | 1223 | / \ | 1224 *race* |<-------- --------->| 1225 | | Mort 1226 | 481 F8 200 F7 | 1227 | (re-INV) (BYE) | 1228 |--------- ----------| 1229 | \ / |^ 1230 | X || 1231 | / \ ||Timer J 1232 |<-------- --------->|| 1233 ^| ACK (re-INV) F9 || 1234 ||<-----------------------|| 1235 Timer K|| || 1236 V| || 1237 Morg | |V 1238 | | Morg 1239 | | 1241 This scenario illustrates the race condition which occurs when UAS 1242 receives an Established message, re-INVITE, in the Mortal state. 1243 Bob sends a re-INVITE, and Alice sends a BYE at the same time. 1244 The re-INVITE is responded by a 481, since the TU of Alice has 1245 transited from the Established state to the Mortal state by sending 1246 BYE. Bob sends ACK for the 481 response, because the ACK for error 1247 responses is handled by the transaction layer and at the point of 1248 receiving the 481 the INVITE client transaction still remains (even 1249 though the dialog has been terminated). 1251 Message Details 1253 F1 INVITE Alice -> Bob 1255 F2 180 Ringing Bob -> Alice 1257 F3 200 OK Bob -> Alice 1259 F4 ACK Alice -> Bob 1261 F5 BYE Alice -> Bob 1263 /* Alice sends a BYE and terminates the session, and transits from 1264 the Established state to the Mortal state. */ 1266 F6 re-INVITE Bob -> Alice 1268 /* Alice sends a BYE, and Bob sends a re-INVITE at the same time. 1269 The dialog state transits to the Mortal state at the moment 1270 Alice sends the BYE, but Bob does not know it until he receives 1271 the BYE. Therefore, the dialog is in the Terminated state from 1272 Alice's point of view, but it is the Confirmed state 1273 from Bob's point of view. A race condition occurs. */ 1275 F7 200 OK (BYE) Bob -> Alice 1277 F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob 1279 /* Since Alice is in the Mortal state, she responds with a 481 to the 1280 re-INVITE. */ 1282 F9 ACK (re-INVITE) Bob -> Alice 1284 /* ACK for an error response is handled by Bob's INVITE client 1285 transaction. */ 1287 3.2.3 Receiving 200OK for re-INVITE (Established state) 1288 in Mortal state 1290 State Alice Bob State 1291 | | 1292 | INVITE F1 | 1293 |----------------------->| 1294 Pre | 180 Ringing F2 | Pre 1295 |<-----------------------| 1296 Ear | | Ear 1297 | 200 OK F3 | 1298 |<-----------------------| 1299 Mora | ACK F4 | Mora 1300 |----------------------->| 1301 Est | Both Way RTP Media | Est 1302 |<======================>| 1303 | | 1304 | re-INVITE F5 | 1305 |<-----------------------| 1306 | 200 F7 BYE F6 | 1307 |--------- ----------| 1308 | \ / | Mort 1309 | X | 1310 | / \ | 1311 |<-------- --------->| *race* 1312 Mort | 200 F8 ACK F9 | 1313 | (BYE) (re-INV) | 1314 |--------- ----------| 1315 | ^ \ / | 1316 | | X | 1317 | | / \ | 1318 |<-------- --------->| 1319 | | ^ | 1320 | | Timer K | | 1321 | | V | 1322 | | Timer J | Morg 1323 | V | 1324 Morg | | 1325 | | 1327 This scenario illustrates the race condition which occurs when UAS 1328 receives an Established message, 200 to re-INVITE, in the Mortal 1329 state. Bob sends a BYE immediately after sending a re-INVITE. 1330 (A user is not conscious that refresher sends re-INVITE 1331 automatically. For example, in the case of a telephone application, 1332 it is possible that a user places a receiver immediately after 1333 refresher.) 1334 Bob sends ACK for a 200 response to INVITE in the Mortal state, so 1335 that he completes the INVITE transaction. 1337 Note: As noted in Section 3.1.4, there is a hint for implementation 1338 to avoid the race conditions of this type. That is for the UAC to 1339 delay sending BYE F6 until re-INVITE F5 transaction completes. 1340 Implementors can decouple the actions of the user (e.g. hanging up) 1341 from the actions of the protocol (the sending of BYE F6), so the UA 1342 can behave as such. In this case, it is dependent on the 1343 implementor's choice how long it waits. In most cases, such 1344 implementation may be useful to prevent a type of race condition 1345 shown in this section. 1347 Message Details 1349 F1 INVITE Alice -> Bob 1351 F2 180 Ringing Bob -> Alice 1353 F3 200 OK Bob -> Alice 1355 F4 ACK Alice -> Bob 1357 F5 re-INVITE Bob -> Alice 1359 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1360 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1361 Session-Expires: 300;refresher=uac 1362 Supported: timer 1363 Max-Forwards: 70 1364 From: Bob ;tag=8321234356 1365 To: Alice ;tag=9fxced76sl 1366 Call-ID: 3848276298220188511@atlanta.example.com 1367 CSeq: 1 INVITE 1368 Content-Length: 0 1370 /* Some detailed messages are shown for the sequence to illustrate 1371 that the re-INVITE is handled in the usual manner in the Mortal 1372 state. */ 1374 F6 BYE Bob -> Alice 1376 /* Bob sends BYE immediately after sending the re-INVITE. 1377 Bob terminates the session and transits from the Established 1378 state to the Mortal state. */ 1380 F7 200 OK (re-INVITE) Alice -> Bob 1382 SIP/2.0 200 OK 1383 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7 1384 ;received=192.0.2.201 1385 Require: timer 1386 Session-Expires: 300;refresher=uac 1387 From: Bob ;tag=8321234356 1388 To: Alice ;tag=9fxced76sl 1389 Call-ID: 3848276298220188511@atlanta.example.com 1390 CSeq: 1 INVITE 1391 Content-Length: 0 1393 /* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE. 1394 A race condition occurs. */ 1396 F8 200 OK (BYE) Alice -> Bob 1398 F9 ACK (re-INVITE) Bob -> Alice 1400 ACK sip:alice@client.atlanta.example.com SIP/2.0 1401 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44 1402 Max-Forwards: 70 1403 From: Bob ;tag=8321234356 1404 To: Alice ;tag=9fxced76sl 1405 Call-ID: 3848276298220188511@atlanta.example.com 1406 CSeq: 2 ACK 1407 Content-Length: 0 1409 /* Bob sends ACK in the Mortal state to complete the three-way 1410 handshake of the INVITE transaction. */ 1412 3.2.4 Receiving ACK (Moratorium state) 1413 in Mortal state 1415 State Alice Bob State 1416 | | 1417 | ini-INVITE F1 | 1418 |------------------------------->| 1419 Pre | 180 F2 | Pre 1420 |<-------------------------------| 1421 Ear | 200 F3 | Ear 1422 |<-------------------------------| 1423 Mora | | Mora 1424 | ACK F4 BYE F5 | 1425 |------------- --------------| 1426 Est | \ / | Mort 1427 | X | 1428 | / \ | 1429 |<------------ ------------->| *race* 1430 Mort | 200 F6 | 1431 |------------------------------->| 1432 | ^ ^ | 1433 | | Timer K | | 1434 | | V | 1435 | | Timer J | Morg 1436 | V | 1437 Morg | | 1438 | | 1440 This scenario illustrates the race condition which occurs when UAS 1441 receives an Established message, ACK to 200, in the Mortal state. 1442 Alice sends an ACK and Bob sends a BYE at the same time. When the 1443 offer is in a 2xx, and the answer is in an ACK, this example is in 1444 a race condition. The session is not started by receiving the ACK 1445 because Bob has already terminated the session by sending the BYE. 1446 The answer in the ACK request is just ignored. 1448 Note: As noted in Section 3.1.4, there is a hint for implementation 1449 to avoid the race conditions of this type. Implementors can decouple 1450 the actions of the user (e.g. hanging up) from the actions of the 1451 protocol (the sending of BYE F5), so the UA can behave as such. In 1452 this case, it is dependent on the implementor's choice how long it 1453 waits. In most cases, such implementation may be useful to prevent a 1454 type of race condition shown in this section. 1456 Message Details 1458 F1 INVITE Alice -> Bob 1460 F2 180 Ringing Bob -> Alice 1462 F3 200 OK Bob -> Alice 1464 F4 ACK Alice -> Bob 1466 /* RTP streams are established between Alice and Bob */ 1468 F5 BYE Alice -> Bob 1470 F6 200 OK Bob -> Alice 1472 /* Alice sends a BYE and terminates the session and dialog. */ 1474 3.3 Other race conditions 1476 This section shows the examples in race condition that are not 1477 directly related to the dialog state transition. In SIP, processing 1478 functions are deployed in three layers, dialog, session, and 1479 transaction. There are related each other, but have to be treated 1480 separately. Section 17 of RFC 3261 [1] details the processing on 1481 transactions. This draft has tried so far to clarify the processing 1482 on dialogs. This section explains race conditions which are related 1483 to sessions established by SIP. 1485 3.3.1 Re-INVITE crossover 1487 Alice Bob 1488 | | 1489 | INVITE F1 | 1490 |--------------------------->| 1491 | 180 Ringing F2 | 1492 |<---------------------------| 1493 | 200 OK F3 | 1494 |<---------------------------| 1495 | ACK F4 | 1496 |--------------------------->| 1497 | Both Way RTP Media | 1498 |<==========================>| 1499 | | 1500 |re-INVITE F5 re-INVITE F6 | 1501 |------------ -------------| 1502 | \ / | 1503 | X | 1504 | / \ | 1505 |<----------- ------------>| 1506 | 491 F8 491 F7 | 1507 |------------ -------------| 1508 | \ / | 1509 | X | 1510 | / \ | 1511 |<----------- ------------>| 1512 | ^ ACK F9 ^ ACK F10| 1513 |--|--------- ----|--------| 1514 | | \ / | | 1515 | | X | | 1516 | | / \ | | 1517 |<-|---------- ---|------->| 1518 | | | | 1519 | |0-2.0 sec | | 1520 | | | | 1521 | v re-INVITE F11(=F6) | 1522 |<------------------|--------| 1523 | 200 OK F12 | | 1524 |-------------------|------->| 1525 | ACK F13 | | 1526 |<------------------|--------| 1527 | | | 1528 | |2.1-4.0 sec 1529 | | | 1530 |re-INVITE F14(=F5) v | 1531 |--------------------------->| 1532 | 200 OK F15 | 1533 |<---------------------------| 1534 | ACK F16 | 1535 |--------------------------->| 1536 | | 1537 | | 1539 In this scenario, Alice and Bob send re-INVITE at the same time. 1540 When two re-INVITEs cross in the same dialog, they resend re-INVITEs 1541 after different interval for each, according to Section 14.1, of 1542 RFC 3261 [1]. When Alice sends the re-INVITE and it crosses, the 1543 re-INVITE will be sent again after 2.1-4.0 seconds because she owns 1544 the Call-ID (she generated it). Bob will send an INVITE again after 1545 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID. 1546 Therefore, each user agent must remember whether it has generated the 1547 Call-ID of the dialog or not, in case an INVITE may cross with 1548 another INVITE. 1550 In this example, Alice's re-INVITE is for session modification and 1551 Bob's re-INVITE is for session refresh. In this case, after the 491 1552 responses, Bob retransmits the re-INVITE for session refresh earlier 1553 than Alice. If Alice was to retransmit her re-INVITE (that is, if 1554 she was not the owner of Call-ID), the request would refresh and 1555 modify the session at the same time. Then Bob would know that he 1556 would not need to retransmit his re-INVITE to refresh the session. 1558 In another instance where two re-INVITEs for session modification, 1559 cross over, retransmitting the same re-INVITE again after 491 by the 1560 Call-ID owner (the UA which retransmits its re-INVITE after the other 1561 UA) may result in a behavior different from what the user originally 1562 intended to, so the UA needs to decide if the retransmission of the 1563 re-INVITE is necessary. 1564 (For example, when a call hold and an addition of video media cross 1565 over, mere retransmission of the re-INVITE at the firing of the timer 1566 may result in the situation where the video is transmitted 1567 immediately after the holding of the audio. This behavior is 1568 probably not intended by the users.) 1570 Message Details 1572 F1 INVITE Alice -> Bob 1574 F2 180 Ringing Bob -> Alice 1576 F3 200 OK Bob -> Alice 1578 F4 ACK Alice -> Bob 1580 F5 re-INVITE Alice -> Bob 1582 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1583 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1584 Max-Forwards: 70 1585 From: Alice ;tag=9fxced76sl 1586 To: Bob ;tag=8321234356 1587 Call-ID: 3848276298220188511@atlanta.example.com 1588 CSeq: 2 INVITE 1589 Content-Length: 147 1591 v=0 1592 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1593 s=- 1594 c=IN IP4 192.0.2.101 1595 t=0 0 1596 m=audio 49172 RTP/AVP 0 1597 a=rtpmap:0 PCMU/8000 1598 a=sendonly 1600 /* Some detailed messages are shown for the sequence to illustrate 1601 what sort of INVITE requests crossed over each other. */ 1603 F6 re-INVITE Bob -> Alice 1605 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1606 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1607 Session-Expires: 300;refresher=uac 1608 Supported: timer 1609 Max-Forwards: 70 1610 From: Bob ;tag=8321234356 1611 To: Alice ;tag=9fxced76sl 1612 Call-ID: 3848276298220188511@atlanta.example.com 1613 CSeq: 1 INVITE 1614 Content-Length: 0 1616 /* A re-INVITE request for a session refresh and that for a call hold 1617 are sent at the same time. */ 1619 F7 491 Request Pending Bob -> Alice 1621 /* Since a re-INVITE is in progress, a 491 response is returned. */ 1623 F8 491 Request Pending Alice -> Bob 1625 F9 ACK (INVITE) Alice -> Bob 1627 F10 ACK (INVITE) Bob -> Alice 1629 F11 re-INVITE Bob -> Alice 1631 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1632 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 1633 Session-Expires: 300;refresher=uac 1634 Supported: timer 1635 Max-Forwards: 70 1636 From: Bob ;tag=8321234356 1637 To: Alice ;tag=9fxced76sl 1638 Call-ID: 3848276298220188511@atlanta.example.com 1639 CSeq: 2 INVITE 1640 Content-Type: application/sdp 1641 Content-Length: 133 1643 v=0 1644 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1645 s=- 1646 c=IN IP4 192.0.2.201 1647 t=0 0 1648 m=audio 3456 RTP/AVP 0 1649 a=rtpmap:0 PCMU/8000 1651 /* Since Bob is not the owner of the Call-ID, he sends a re-INVITE 1652 again after 0.0-2.0 seconds. */ 1654 F12 200 OK Alice -> Bob 1656 F13 ACK Bob -> Alice 1658 F14 re-INVITE Alice -> Bob 1660 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1661 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1662 Max-Forwards: 70 1663 From: Alice ;tag=9fxced76sl 1664 To: Bob ;tag=8321234356 1665 Call-ID: 3848276298220188511@atlanta.example.com 1666 CSeq: 3 INVITE 1667 Content-Length: 147 1669 v=0 1670 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1671 s=- 1672 c=IN IP4 192.0.2.101 1673 t=0 0 1674 m=audio 49172 RTP/AVP 0 1675 a=rtpmap:0 PCMU/8000 1676 a=sendonly 1678 /* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE 1679 again after 2.1-4.0 seconds. */ 1681 F15 200 OK Bob -> Alice 1683 F16 ACK Alice -> Bob 1685 3.3.2 UPDATE and re-INVITE crossover 1687 Alice Bob 1688 | | 1689 | INVITE F1 | 1690 |--------------------------->| 1691 | 180 Ringing F2 | 1692 |<---------------------------| 1693 | | 1694 | 200 OK F3 | 1695 |<---------------------------| 1696 | ACK F4 | 1697 |--------------------------->| 1698 | Both Way RTP Media | 1699 |<==========================>| 1700 | | 1701 | UPDATE F5 re-INVITE F6 | 1702 |------------ -------------| 1703 | \ / | 1704 | X | 1705 | / \ | 1706 |<----------- ------------>| 1707 | 491 F8 491 F7 | 1708 | (re-INVITE) (UPDATE) | 1709 |------------ -------------| 1710 | \ / | 1711 | X | 1712 | / \ | 1713 |<----------- ------------>| 1714 | ^ ACK F9 ^ | 1715 |<-|----------------|--------| 1716 | | | | 1717 | |0-2.0 sec | | 1718 | | | | 1719 | v re-INVITE F10 | | 1720 |<------------------|--------| 1721 | 200 OK F11 | | 1722 |-------------------|------->| 1723 | ACK F12 | | 1724 |<------------------|--------| 1725 | | | 1726 | |2.1-4.0 sec 1727 | | | 1728 | UPDATE F13 v | 1729 |--------------------------->| 1730 | 200 OK F14 | 1731 |<---------------------------| 1732 | | 1733 | | 1735 In this scenario, the UPDATE contains a SDP offer, therefore the 1736 UPDATE and re-INVITE are responded with 491 as in the case of 1737 "re-INVITE crossover". When an UPDATE for refresher which doesn't 1738 contain a session description and a re-INVITE crossed each other, 1739 both requests succeed with 200 (491 means that UA have a pending 1740 request). Moreover, the same is equally true for UPDATE crossover. 1741 In the former case where either UPDATE contains a session description 1742 the requests fail with 491, and in the latter cases succeed with 200. 1744 Editor's Note: 1745 A 491 response is sent because SDP offer is pending, and 491 is an 1746 error which is related to matters that behave on the session 1747 established by SIP. 1749 Message Details 1751 F1 INVITE Alice -> Bob 1753 F2 180 Ringing Bob -> Alice 1755 F3 200 OK Bob -> Alice 1757 F4 ACK Alice -> Bob 1759 F5 UPDATE Alice -> Bob 1761 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1762 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1763 Max-Forwards: 70 1764 From: Alice ;tag=9fxced76sl 1765 To: Bob ;tag=8321234356 1766 Call-ID: 3848276298220188511@atlanta.example.com 1767 CSeq: 2 UPDATE 1768 Content-Length: 147 1770 v=0 1771 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1772 s=- 1773 c=IN IP4 192.0.2.101 1774 t=0 0 1775 m=audio 49172 RTP/AVP 0 1776 a=rtpmap:0 PCMU/8000 1777 a=sendonly 1779 /* Some detailed messages are shown for the sequence to illustrate 1780 the example messages crossed over each other. */ 1782 F6 re-INVITE Bob -> Alice 1784 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1785 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1786 Session-Expires: 300;refresher=uac 1787 Supported: timer 1788 Max-Forwards: 70 1789 From: Bob ;tag=8321234356 1790 To: Alice ;tag=9fxced76sl 1791 Call-ID: 3848276298220188511@atlanta.example.com 1792 CSeq: 1 INVITE 1793 Content-Length: 0 1795 /* A case where a re-INVITE for a session refresh and a UPDATE for a 1796 call hold are sent at the same time. */ 1798 F7 491 Request Pending (UPDATE) Bob -> Alice 1800 /* Since a re-INVITE is in process, a 491 response are returned. */ 1802 F8 491 Request Pending (re-INVITE) Alice -> Bob 1804 F9 ACK (re-INVITE) Alice -> Bob 1806 F10 re-INVITE Bob -> Alice 1808 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1809 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 1810 Session-Expires: 300;refresher=uac 1811 Supported: timer 1812 Max-Forwards: 70 1813 From: Bob ;tag=8321234356 1814 To: Alice ;tag=9fxced76sl 1815 Call-ID: 3848276298220188511@atlanta.example.com 1816 CSeq: 2 INVITE 1817 Content-Type: application/sdp 1818 Content-Length: 133 1820 v=0 1821 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1822 s=- 1823 c=IN IP4 192.0.2.201 1824 t=0 0 1825 m=audio 3456 RTP/AVP 0 1826 a=rtpmap:0 PCMU/8000 1828 /* Since Bob is not the owner of Call-ID, Bob sends an INVITE again 1829 after 0.0-2.0 seconds. */ 1831 F11 200 OK Alice -> Bob 1833 F12 ACK Bob -> Alice 1835 F13 UPDATE Alice -> Bob 1837 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1838 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1839 Max-Forwards: 70 1840 From: Alice ;tag=9fxced76sl 1841 To: Bob ;tag=8321234356 1842 Call-ID: 3848276298220188511@atlanta.example.com 1843 CSeq: 3 UPDATE 1844 Content-Length: 147 1846 v=0 1847 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1848 s=- 1849 c=IN IP4 192.0.2.101 1850 t=0 0 1851 m=audio 49172 RTP/AVP 0 1852 a=rtpmap:0 PCMU/8000 1853 a=sendonly 1855 /* Since Alice is the owner of the Call-ID, Alice sends the UPDATE 1856 again after 2.1-4.0 seconds. */ 1858 F14 200 OK Bob -> Alice 1860 3.3.3 Receiving REFER (Establish state) 1861 in Mortal state 1863 State Alice Bob State 1864 | | 1865 | INVITE F1 | 1866 |----------------------->| 1867 Pre | 180 Ringing F2 | Pre 1868 |<-----------------------| 1869 Ear | | Ear 1870 | 200 OK F3 | 1871 |<-----------------------| 1872 Mora | ACK F4 | Mora 1873 |----------------------->| 1874 Est | Both Way RTP Media | Est 1875 |<======================>| 1876 | | 1877 | BYE F5 REFER F6 | 1878 |--------- ----------| 1879 Mort | \ / | 1880 | X | 1881 | / \ | 1882 *race* |<-------- --------->| 1883 | | Mort 1884 | 481 F8 200 F7 | 1885 | (REFER) (BYE) | 1886 |--------- ----------| 1887 | \ / ^ | 1888 | X | | 1889 | / \ | | 1890 |<-------- --------->| 1891 | ^ | | 1892 | | Timer K | | 1893 | V Timer J | | 1894 Morg | V | 1895 | | Morg 1896 | | 1898 This scenario illustrates the race condition which occurs when UAS 1899 receives an Established message, REFER, in the Mortal state. 1900 Bob sends a REFER, and Alice sends a BYE at the same time. Bob send 1901 the REFER in the same dialog. Alice's dialog state moves to the 1902 Mortal state at the point of sending BYE. In the Mortal state, UA 1903 possesses dialog information for internal process but dialog 1904 shouldn't exist outwardly. Therefore, UA sends an error response to 1905 a REFER which is transmitted as a mid-dialog request. So, Alice in 1906 the Mortal state sends an error response to the REFER. 1907 However, Bob has already started the SUBSCRIBE usage with REFER, so 1908 the dialog continues until the SUBSCRIBE usage terminates, even 1909 though the INVITE dialog usage terminates by receiving BYE. Bob's 1910 behavior in this case needs to follow the procedure in the dialog 1911 usage draft [6]. (For handling of dialogs with multiple usages see 1912 the dialog usage draft [6].) 1914 Message Details 1916 F1 INVITE Alice -> Bob 1918 F2 180 Ringing Bob -> Alice 1920 F3 200 OK Bob -> Alice 1922 F4 ACK Alice -> Bob 1924 F5 BYE Alice -> Bob 1926 /* Alice sends a BYE request and terminates the session, and transits 1927 from the Confirmed state to Terminated state. */ 1929 F6 REFER Bob -> Alice 1931 /* Alice sends a BYE, and Bob sends a REFER at the same time. Bob 1932 sends the REFER on the INVITE dialog. The dialog state transits 1933 to the Mortal state at the moment Alice sends the BYE, but Bob 1934 doesn't know it until he receives the BYE. A race condition 1935 occurs. */ 1937 F7 200 OK (BYE) Bob -> Alice 1939 F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob 1941 /* Alice in the Mortal state sends a 481 to the REFER. */ 1943 4. IANA Considerations 1945 This document has no actions for IANA. 1947 5. Security Considerations 1949 This document contains clarifications of behavior specified in RFCs 1950 3261 [1], 3264 [2], and 3515 [4]. The security considerations of 1951 those documents continue to apply after the application of these 1952 clarifications. 1954 6. Acknowledgements 1956 The authors would like to thank Robert Sparks, Dean Willis, 1957 Cullen Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, 1958 Akihiro Shimizu, Mayumi Munakata, Yasunori Inagaki, 1959 Tadaatsu Kidokoro, Kenichi Hiragi, Dale Worley, Vijay K. Gurbani 1960 and Anders Kristensen for their comments on this document. 1962 7. References 1964 7.1 Normative References 1966 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1967 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1968 Session Initiation Protocol", RFC 3261, June 2002. 1970 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1971 the Session Description Protocol (SDP)", RFC 3264, June 2002. 1973 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1974 Levels", BCP 14, RFC 2119, March 1997. 1976 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1977 Method", RFC 3515, April 2003. 1979 [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 1980 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 1981 June 2002. 1983 7.2 Informative References 1985 [6] Sparks, R., "Multiple Dialog Usages in the Session Initiation 1986 Protocol", draft-ietf-sipping-dialogusage-06 (work in progress), 1987 February 16, 2007. 1989 Appendix A - BYE on the Early Dialog 1991 This section, related to Section 3.1.3, explains why BYE is not 1992 recommended in the Early state, illustrating the case in which BYE in 1993 the early dialog triggers confusion. 1995 Alice Proxy Bob Carol 1996 | | | | 1997 | INVITE F1 | | | 1998 |--------------->| INVITE F2 | | 1999 | 100 F3 |----------------->| | 2000 |<---------------| 180(To tag=A) F4 | | 2001 | 180(A) F5 |<-----------------| | 2002 |<---------------| | | 2003 | | INVITE(Fork) F6 | 2004 | |------------------------>| 2005 | | 100 F7 | 2006 | BYE(A) F8 |<------------------------| 2007 |--------------->| BYE(A) F9 | | 2008 | |----------------->| | 2009 | | 200(A,BYE) F10 | | 2010 | 200(A,BYE) F11 |<-----------------| | 2011 |<---------------| 487(A,INV) F12 | | 2012 | |<-----------------| | 2013 | | ACK(A) F13 | | 2014 | |----------------->| | 2015 | | | | 2016 | | | 2017 | | 200(To tag=B) F13 | 2018 | 200(B) F14 |<------------------------| 2019 |<---------------| | 2020 | ACK(B) F15 | | 2021 |--------------->| ACK(B) F16 | 2022 | |------------------------>| 2023 | BYE(B) F17 | | 2024 |--------------->| BYE(B) F18 | 2025 | |------------------------>| 2026 | | 200(B) F19 | 2027 | 200(B) F20 |<------------------------| 2028 |<---------------| | 2029 | | | 2030 | | | 2032 Care is advised in sending BYE in the Early state when forking by a 2033 proxy is expected. In this example, the BYE request progresses 2034 normally, and it succeeds in correctly terminating the dialog with 2035 Bob. After Bob terminates the dialog by receiving the BYE, he sends 2036 487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261 [1], 2037 it is RECOMMENDED for UAS to generate 487 to any pending requests 2038 after receiving BYE. In the example, Bob sends 487 to ini-INVITE 2039 since he receives BYE while the ini-INVITE is in pending state. 2041 However, Alice receives a final response to INVITE (a 200 from Carol) 2042 even though she has successfully terminated the dialog with Bob. 2043 This means that, regardless of the success/failure of the BYE in the 2044 Early state, Alice MUST be prepared for the establishment of a new 2045 dialog until receiving the final response for the INVITE and 2046 terminating the INVITE transaction. 2048 It is not illegal to send BYE in the Early state to terminate a 2049 specific early dialog according to the caller's intent. However, the 2050 choice of BYE or CANCEL in the Early state must be made carefully. 2051 CANCEL is appropriate when the goal is to abandon the call attempt 2052 entirely. BYE is appropriate when the goal is to abandon a 2053 particular early dialog while allowing the call to be completed with 2054 other destinations. When using either BYE or CANCEL the UAC must be 2055 prepared for the possibility that a call may still be established to 2056 one (or more) destinations. 2058 Appendix B - BYE request overlapped on re-INVITE 2060 UAC UAS 2061 | | 2062 The session has been already established 2063 ========================== 2064 | re-INVITE F1 | 2065 |--------------------->| 2066 | BYE F2 | 2067 |--------------------->| 2068 | 200(BYE) F3 | 2069 |<---------------------| 2070 | INVITE F4(=F1) | 2071 |--------------------->| 2072 | | 2073 | | 2075 This case could look similar to the one in Section 3.2.3. However, 2076 it is not a race condition. This case describes the behavior where 2077 there is no response for INVITE for some reasons. The appendix 2078 explains the behavior in such case and its rationale behind, since 2079 this case is likely to cause confusion. 2081 First of all, it is important not to confuse the behavior of the 2082 transaction layer and that of the dialog layer. RFC 3261 [1] details 2083 the transaction layer behavior. The dialog layer behavior is 2084 explained in this document. It has to be noted that these behaviors 2085 are independent of each other, even though the both layers change 2086 their states triggered by sending or receiving of the same SIP 2087 messages (A dialog can be terminated even though a transaction still 2088 remain, and vice versa). 2090 In the sequence above, there is no response for F1, and F2 (BYE) is 2091 sent immediately after F1 (F1 is a mid-dialog request. If F1 was 2092 ini-INVITE, BYE could not be sent before UAC received a provisional 2093 response to the request with To tag). 2095 Below is a figure which illustrates UAC's dialog state and 2096 transaction state. 2098 BYE INV dialog UAC UAS 2099 : | | 2100 : | | 2101 | | re-INVITE F1 | 2102 o | |--------------------->| 2103 | | | BYE F2 | 2104 o | (Mortal) |--------------------->| 2105 | | | | 200(BYE) F3 | 2106 | | | |<---------------------| 2107 | | | | INVITE F4(=F1) | 2108 | | | |--------------------->| 2109 | | | | 481(INV) F5 | 2110 | | | |<---------------------| 2111 | | | | ACK(INV) F6 | 2112 | | | |--------------------->| 2113 | | | | | 2114 o | o | | 2115 | | | 2116 o | | 2117 | | 2119 For UAC, the INVITE client transaction begins at the point F1 is 2120 sent. The UAC sends BYE (F2) immediately after F1. This is a 2121 legitimate behavior. (Usually the usage of each SIP method is 2122 independent, for BYE and others. However, it should be noted that it 2123 is prohibited to send a request with a SDP offer while the previous 2124 offer is in progress.) 2126 After that, F2 triggers the BYE client transaction. At the same 2127 time, the dialog state transits to the Mortal state and then only a 2128 BYE or its response can be handled. 2130 It is permitted to send F4 (a retransmission of INVITE) in the Mortal 2131 state, because the retransmission of F1 is handled by the transaction 2132 layer, and the INVITE transaction has not yet transited to the 2133 Terminated state. As it is mentioned above, the dialog and the 2134 transaction behave independently each other. 2135 Therefore the transaction handling has to be continued even though 2136 the dialog moved to the Terminated state. 2138 Next, UAS's state is shown below. 2140 UAC UAS dialog INV BYE 2141 | | : 2142 | | : 2143 | re-INVITE F1 | | 2144 |-------------->x | | 2145 | BYE F2 | | 2146 |--------------------->| | o 2147 | 200(BYE) F3 | (Mortal) | 2148 |<---------------------| | |<-Start TimerJ 2149 | INVITE F4(=F1) | | | 2150 |--------------------->| | o | 2151 | 4xx/5xx(INV) F5 | o | o 2152 |<---------------------| | 2153 | ACK(INV) F6 | | 2154 |--------------------->| |<-Start TimerI 2155 | | | 2156 | | | 2157 | | o 2158 | | 2160 For UAS, it can be regarded that F1 packet is lost or delayed (Here 2161 the behavior is explained for the case UAS receives F2 BYE before F1 2162 INVITE). Therefore, F2 triggers the BYE transaction for UAS, and 2163 simultaneously the dialog moves to the Mortal state. 2164 Then, upon the reception of F4 the INVITE server transaction begins. 2165 (It is allowed to start the INVITE server transaction in the Mortal 2166 state. The INVITE server transaction begins to handle received SIP 2167 request regardless of the dialog state.) 2168 UAS's TU sends an appropriate error response for F4 INVITE, either 2169 481 (because the TU knows that the dialog which matches to the 2170 INVITE is in the Terminated state) or 500 (because the re-sent F4 has 2171 an out-of-order CSeq). 2172 (It is mentioned above that F4 (and F1) INVITE is a mid-dialog 2173 request. Mid-dialog requests have a To tag. It should be noted that 2174 UAS's TU does not begin a new dialog upon the reception of INVITE 2175 with a To tag.) 2177 Appendix C - UA's behavior for CANCEL 2179 This section explains the CANCEL behaviors which indirectly involve 2180 in the dialog state transition in the Early state. CANCEL does not 2181 have any influence on UAC's dialog state. However, the request has 2182 indirect influence on the dialog state transition because it has a 2183 significant effect on ini-INVITE. For UAS the CANCEL request has 2184 more direct effects on the dialog than the sending of CANCEL by UAC, 2185 because they can be a trigger to send the 487 response. Figure 3 2186 explains UAS's behavior in the Early state. This flow diagram is 2187 only an explanatory figure, and the actual dialog state transition is 2188 as illustrated in Figure 1 and 2. 2190 In the flow, full lines are related to dialog state transition, and 2191 dotted lines are involved with CANCEL. (r) represents the reception 2192 of signaling, and (s) means sending. There is no dialog state for 2193 CANCEL, but here the Cancelled state is virtually handled just for 2194 the ease of understanding of the UA's behavior when it sends and 2195 receives CANCEL. 2197 Below, UAS's flow is explained. 2199 +-------------+ 2200 | Preparative |---+ 2201 +-------------+ | 2202 : | 1xx(s) | 2203 : V | 2204 : +-------+ | 2xx(s) 2205 : | Early |-----+------+ 2206 : +-------+ | 2207 : : V 2208 : : +-----------+ 2209 : : | Confirmed |<... 2210 :.....: +-----------+ : 2211 : | : : 2212 : BYE(r)| : : 2213 : CANCEL(r) | :.......: 2214 V | CANCEL(r) 2215 ............. | 2216 : Cancelled : | 2217 :...........: | 2218 | 487(s) | 2219 | | 2220 +--------------------+ 2221 | 2222 V 2223 +------------+ 2224 | Terminated | 2225 +------------+ 2227 Figure 3. CANCEL flow diagram for UAS 2229 There are two behaviors for UAS depending on the state when it 2230 receives CANCEL. 2232 One is when UAS receives CANCEL in the Early states. In this case 2233 the UAS immediately sends 487 for the INVITE, and the dialog transits 2234 to the Terminated state. 2236 The other is the case in which UAS receives CANCEL in the Confirmed 2237 state. In this case the dialog state transition does not occur 2238 because UAS has already sent a final response to the INVITE to which 2239 the CANCEL is targeted. 2240 (Note that, because of UAC's behavior, a UAS that receives a CANCEL 2241 in the Confirmed state can expect to receive a BYE immediately and 2242 move to the Terminated state. However, the UAS's state does not 2243 transit until it actually receives BYE.) 2245 Appendix D - Notes on the request in Mortal state 2247 This section describes UA's behavior in the Mortal state which needs 2248 careful attention. Note that every transaction completes independent 2249 of others, following the principle of RFC 3261 [1]. 2251 In the Mortal state, BYE can be accepted, and the other messages in 2252 the INVITE dialog usage are responded with an error. However, 2253 sending of ACK and the authentication procedure for BYE are conducted 2254 in this state. (The handling of messages concerning multiple dialog 2255 usages is out of the scope of this document. Refer to [6] for 2256 further information.) 2258 ACK for error responses is handled by the transaction layer, so the 2259 handling is not related to the dialog state. Unlike the ACK for 2260 error responses, ACK for 2xx responses is a request newly generated 2261 by TU. However, the ACK for 2xx and the ACK for error responses are 2262 both a part of the INVITE transaction, even though their handling 2263 differs (Section 17.1.1.1, RFC 3261 [1]). 2264 Therefore, the INVITE transaction is completed by the three-way 2265 handshake, which includes ACK, even in the Mortal state. 2267 Considering actual implementation, UA needs to keep the INVITE dialog 2268 usage until the Mortal state finishes, so that it is able to ACK for 2269 a 2xx response in the Mortal state. 2270 If a 2xx to INVITE is received in the Mortal state, the duration of 2271 the INVITE dialog usage will be extended to 64*T1 seconds after the 2272 receiving of the 2xx, to cope with the possible 2xx retransmission. 2273 (The duration of the 2xx retransmission is 64*T1, so the UA need to 2274 be prepared to handle the retransmission for this duration.) 2275 However, the UA shall send error response to other requests, since 2276 the INVITE dialog usage in the Mortal state is kept only for the 2277 sending of ACK for 2xx. 2279 BYE authentication procedure shall be processed in the Mortal state. 2280 When authentication is requested by 401 or 407 response, UAC resends 2281 BYE with an appropriate credentials. Also UAS handles the 2282 retransmission of the BYE which it requested authentication itself. 2284 Appendix E - Forking and receiving new To tags 2286 This section details the behavior of TU when it receives multiple 2287 responses with a different To tag to ini-INVITE. 2289 When an INVITE is forked inside a SIP network, there is a possibility 2290 that the TU receives multiple responses with a different To tag to 2291 ini-INVITE (See Section 12.1, 13.1, 13.2.2.4, 16.7, 19.3, etc. of RFC 2292 3261). If the TU receives multiple 1xx responses with a different 2293 To tag, the original DSM forks and a new DSM instance is created. As 2294 a consequence multiple early dialogs are generated. 2296 If one of the multiple early dialogs receives a 2xx response, it 2297 naturally transits to the Confirmed state. No DSM state transition 2298 occurs for the other early dialogs, and their sessions (early media) 2299 terminate. The TU of the UAC terminates the INVITE transaction after 2300 64*T1 seconds starting at the point of receiving the first 2xx 2301 response. Moreover, all mortal early dialogs which do not transit to 2302 the Established state are terminated (See Section 13.2.2.4 of 2303 RFC 3261). By "mortal early dialog" we mean any early dialog that 2304 the UA will terminate when another early dialog is confirmed. 2306 Below is an example sequence in which two 180 responses with a 2307 different To tag are received, and then a 200 response for one of the 2308 early dialogs (dialog A) is received. Dot lines (..) in sequences 2309 are auxiliary lines to represent the influence on dialog B. 2311 UAC 2312 dialog(A) | INVITE F1 2313 Pre o |-------------------------> 2314 | | 100 F2 2315 | |<------------------------- 2316 | | 180(To tag=A) F3 2317 Ear | |<------------------------- 2318 dialog(B) | | 2319 forked new DSM | | 180(To tag=B) F4 2320 Ear o..........|..........|<------------------------- 2321 | | | 2322 | | | 200(A) F5 2323 terminate->|.....Mora |..........|<------------------------- 2324 early | | ^ | ACK(A) F6 2325 media | Est | | |-------------------------> 2326 | | | | 2327 | | |64*T1 | 2328 | | |(13.2.2.4 of RFC 3261) 2329 | | | | 2330 | | | | 2331 | | V | 2332 o..........|.(terminate INVITE transaction) 2333 terminated | | 2334 dialog(B) | | 2335 | | 2337 Figure 4. Receiving 1xx responses with different To tags 2339 The figure above shows the DSM inside a SIP TU. Triggered by the 2340 reception of a provisional response with a different To tag 2341 (F4 180(To tag=B)), DSM forks and the early dialog B is generated. 2342 After 64*T1 seconds after the dialog A receives 200 OK response, the 2343 dialog B, which does not transit to the Established state, 2344 terminates. 2346 Next, the behavior of a TU which receives multiple 2xx responses with 2347 a different To tag is explained. When a mortal early dialog, which 2348 did not match the first 2xx response the TU received, receives 2349 another 2xx response which matches its To tag before 64*T1 INVITE 2350 transaction timeout, its DSM state transits to the Confirmed state. 2351 However, the session on the mortal early dialog is terminated when 2352 the TU receives the first 2xx to establish a dialog, so no session is 2353 established for the mortal early dialog. Therefore, when the mortal 2354 early dialog receives a 2xx response, the TU send an ACK and, 2355 immediately after, the TU usually sends a BYE to terminate DSM. (In 2356 special cases, e.g. a UA intends to establish multiple dialogs, the 2357 TU may not send the BYE.) 2359 The handling of the second early dialog after receiving the 200 for 2360 the first dialog is quite appropriate for a typical device, such as a 2361 phone. It is important to note that what is being shown is a 2362 typically useful action and not the only valid one. Some devices 2363 might want to handle things differently. For instance, a conference 2364 focus that has sent out an INVITE that forks may want to accept and 2365 mix all the dialogs it gets. In that case, no early dialog is 2366 treated as mortal. 2368 Below is an example sequence in which two 180 responses with a 2369 different To tag are received and then a 200 response for each of the 2370 early dialogs is received. 2372 UAC 2373 dialog(A) | INVITE F1 2374 Pre o |-----------------------> 2375 | | 100 F2 2376 | |<----------------------- 2377 | | 180(To tag=A) F3 2378 dialog(B) Ear | |<----------------------- 2379 forked new DSM | | 180(To tag=B) F4 2380 Ear o..........|..........|<----------------------- 2381 | | | 2382 | | | 200(A) F5 2383 terminate->|.....Mora |..........|<----------------------- 2384 early | | ^ | ACK(A) F6 2385 media | Est | | |-----------------------> 2386 | | |64*T1 | 2387 | | | | 200(B) F7 2388 Mora |..........|.|........|<----------------------- 2389 | | | | ACK(B) F8 2390 Est |..........|.|........|-----------------------> 2391 | | | | BYE(B) F9 2392 Mort |..........|.|........|-----------------------> 2393 ^ | | | | 200(B) F10 2394 | | | | |<----------------------- 2395 |Timer K | | | 2396 | | | V | 2397 | | | (terminate INVITE transaction) 2398 V | | | 2399 Morg o | | 2400 | | 2402 Figure 5. Receiving 1xx and 2xx responses with different To tags 2404 Below is an example sequence when a TU receives multiple 200 2405 responses with a different To tag before 64*T1 timeout of the INVITE 2406 transaction, even though a TU does not receive provisional response, 2407 the TU needs to respond to the 2xx responses (See Section 13.2.2.4 of 2408 RFC 3261). In that case, the DSM state is forked at the Confirmed 2409 state, and then the TU sends an ACK for the 2xx response and, 2410 immediately after, the TU usually sends a BYE. (In special cases, 2411 e.g. a UA intends to establish multiple dialogs, the TU may not send 2412 the BYE.) 2414 UAC 2415 dialog(A) | INVITE F1 2416 Pre o |-----------------------> 2417 | | 100 F2 2418 | |<----------------------- 2419 | | 180(To tag=A) F3 2420 Ear | |<----------------------- 2421 | | 2422 | | 200(A) F4 2423 Mora |..........|<----------------------- 2424 | ^ | ACK(A) F5 2425 Est | | |-----------------------> 2426 | | | 2427 dialog(B) | |64*T1 | 2428 forked new DSM | | | 200(To tag=B) F6 2429 Mora o..........|.|........|<----------------------- 2430 | | | | ACK(B) F7 2431 Est |..........|.|........|-----------------------> 2432 | | | | BYE(B) F8 2433 Mort |..........|.|........|-----------------------> 2434 ^ | | | | 200(B) F9 2435 | | | | |<----------------------- 2436 | | | V | 2437 |Timer K | (terminate INVITE transaction) 2438 | | | | 2439 V | | | 2440 Morg o | | 2441 | | 2443 Figure 6. Receiving 2xx responses with different To tags 2445 Below is an example sequence in which the option tag 100rel (RFC 3262 2446 [5]) is required by a 180. 2448 If a forking proxy supports 100rel, it transparently transmits to the 2449 UAC a provisional response which contains a Require header with the 2450 value of 100rel. Upon receiving a provisional response with 100rel, 2451 the UAC establishes the early dialog (B) and send PRACK. (Here, also 2452 every transaction completes independent of others".) 2454 As Figure. 4, the early dialog (B) terminates at the same time the 2455 INVITE transaction terminates. In the case where a proxy does not 2456 support 100rel, the provisional response will be handled in the usual 2457 way (a provisional response with 100rel is discarded by the proxy, 2458 not to be transmitted to the UAC). 2460 UAC 2461 dialog(A) | INVITE F1 2462 Pre o |-------------------------> 2463 | | 100 F2 2464 | |<------------------------- 2465 | | 180(To tag=A) F3 2466 Ear | |<------------------------- 2467 | | 200(A) F4 2468 Mora |..........|<------------------------- 2469 | ^ | ACK(A) F5 2470 Est | | |-------------------------> 2471 dialog(B) | | | 2472 forked new DSM | | | 180(To tag=B) w/100rel F6 2473 Ear o..........|.|........|<------------------------- 2474 | | | | PRACK(B) F7 2475 | | | |-------------------------> 2476 | | | | 200(B,PRACK) F8 2477 | | | |<------------------------- 2478 | | |64*T1 | 2479 | | |(13.2.2.4 of RFC 3261) 2480 | | | | 2481 | | | | 2482 | | | | 2483 | | V | 2484 o..........|.(terminate INVITE transaction) 2485 terminated | | 2486 dialog(B) | | 2487 | | 2489 Figure 7. Receiving 1xx responses with different To tags (with 100rel) 2491 Author's Addresses 2493 All listed authors actively contributed large amounts of text to this 2494 document. 2496 Miki Hasebe 2497 NTT-east Corporation 2498 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2500 EMail: hasebe.miki@east.ntt.co.jp 2502 Jun Koshiko 2503 NTT-east Corporation 2504 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2506 EMail: j.koshiko@east.ntt.co.jp 2508 Yasushi Suzuki 2509 NTT-east Corporation 2510 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2512 EMail: suzuki.yasushi@east.ntt.co.jp 2514 Tomoyuki Yoshikawa 2515 NTT-east Corporation 2516 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2518 EMail: tomoyuki.yoshikawa@east.ntt.co.jp 2520 Paul H. Kyzivat 2521 Cisco Systems, Inc. 2522 1414 Massachusetts Avenue 2523 Boxborough, MA 01719 2524 USA 2526 Email: pkyzivat@cisco.com 2528 Full Copyright Statement 2530 Copyright (C) The IETF Trust (2007). 2532 This document is subject to the rights, licenses and restrictions 2533 contained in BCP 78, and except as set forth therein, the authors 2534 retain all their rights. 2536 This document and the information contained herein are provided on an 2537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, 2539 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 2540 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 2541 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 2542 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 2543 PURPOSE. 2545 Intellectual Property 2547 The IETF takes no position regarding the validity or scope of any 2548 Intellectual Property Rights or other rights that might be claimed to 2549 pertain to the implementation or use of the technology described in 2550 this document or the extent to which any license under such rights 2551 might or might not be available; nor does it represent that it has 2552 made any independent effort to identify any such rights. Information 2553 on the procedures with respect to rights in RFC documents can be 2554 found in BCP 78 and BCP 79. 2556 Copies of IPR disclosures made to the IETF Secretariat and any 2557 assurances of licenses to be made available, or the result of an 2558 attempt made to obtain a general license or permission for the use of 2559 such proprietary rights by implementers or users of this 2560 specification can be obtained from the IETF on-line IPR repository at 2561 http://www.ietf.org/ipr. 2563 The IETF invites any interested party to bring to its attention any 2564 copyrights, patents or patent applications, or other proprietary 2565 rights that may cover technology that may be required to implement 2566 this standard. Please address the information to the IETF at 2567 ietf-ipr@ietf.org. 2569 Acknowledgement 2571 Funding for the RFC Editor function is provided by the IETF 2572 Administrative Support Activity (IASA).