idnits 2.17.1 draft-ietf-sipping-race-examples-03.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 3978, Section 5.5, updated by RFC 4748 on line 2522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2546. 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 2 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 == Line 67 has weird spacing: '...atorium state...' == Line 855 has weird spacing: '...atorium state...' == 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.) -- The document date (August 10, 2007) is 6103 days in the past. Is this intentional? -- 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: 1 error (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 sipping M. Hasebe 3 Internet-Draft J. Koshiko 4 Intended status: Best Current Y. Suzuki 5 Practice T. Yoshikawa 6 Expires: February 11, 2008 NTT-east Corporation 7 P. Kyzivat 8 Cisco Systems, Inc. 9 August 10, 2007 11 Examples call flow in race condition on Session Initiation Protocol 12 draft-ietf-sipping-race-examples-03 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 February 11, 2008. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 3 55 1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 3 56 1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 4 57 2. The Dialog State Machine for INVITE dialog usage . . . . . . . 4 58 3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 10 59 3.1. Receiving message in the Moratorium State . . . . . . . . 11 60 3.1.1. Receiving Initial INVITE retransmission 61 (Preparative state) in Moratorium state . . . . . . . 11 62 3.1.2. Receiving CANCEL (Early state) in Moratorium state . . 13 63 3.1.3. Receiving BYE (Early state) in Moratorium state . . . 15 64 3.1.4. Receiving re-INVITE (Established state) in 65 Moratorium state (case 1) . . . . . . . . . . . . . . 17 66 3.1.5. Receiving re-INVITE (Established state) in 67 Moratorium state (case 2) . . . . . . . . . . . . . . 22 68 3.1.6. Receiving BYE (Established state) in Moratorium 69 state . . . . . . . . . . . . . . . . . . . . . . . . 26 70 3.2. Receiving message in the Mortal State . . . . . . . . . . 28 71 3.2.1. Receiving BYE (Establish state) in Mortal state . . . 28 72 3.2.2. Receiving re-INVITE (Establish state) in Mortal 73 state . . . . . . . . . . . . . . . . . . . . . . . . 31 74 3.2.3. Receiving 200 OK for re-INVITE (Established state) 75 in Mortal state . . . . . . . . . . . . . . . . . . . 33 76 3.2.4. Receiving ACK (Moratorium state) in Mortal state . . . 36 77 3.3. Other race conditions . . . . . . . . . . . . . . . . . . 37 78 3.3.1. Re-INVITE crossover . . . . . . . . . . . . . . . . . 37 79 3.3.2. UPDATE and re-INVITE crossover . . . . . . . . . . . . 43 80 3.3.3. Receiving REFER (Establish state) in Mortal state . . 47 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 49 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 49 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 49 87 Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . 49 88 Appendix B. BYE request overlapped on re-INVITE . . . . . . . . . 51 89 Appendix C. UA's behavior for CANCEL . . . . . . . . . . . . . . 53 90 Appendix D. Notes on the request in Mortal state . . . . . . . . 55 91 Appendix E. Forking and receiving new To tags . . . . . . . . . . 56 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 93 Intellectual Property and Copyright Statements . . . . . . . . . . 62 95 1. Overview 97 The call flows shown in this document were developed in the design of 98 a SIP IP communications network. These examples are of race 99 condition, which stems from the dialog state transition mainly 100 established by INVITE. 102 When implementing SIP, various complex situations may arise. 103 Therefore, it will be helpful to provide implementors of the protocol 104 with examples of recommended terminal and server behavior. 106 This document clarifies SIP UA behaviors when messages cross each 107 other as race conditions. By clarifying operation under race 108 conditions, inconsistent interpretations between implementations are 109 avoided and interoperability is expected to be promoted. 111 It is the hope of the authors that this document will be useful for 112 SIP implementors, designers, and protocol researchers and will help 113 them achieve the goal of a standard implementation of RFC 3261 [1]. 115 These call flows are based on the version 2.0 of SIP defined in RFC 116 3261 [1] with SDP usage described in RFC 3264 [2]. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in BCP 14, RFC 2119 [3]. 122 1.1. General Assumptions 124 A number of architecture, network, and protocol assumptions underlie 125 the call flows in this document. Note that these assumptions are not 126 requirements. They are outlined in this section so that they may be 127 taken into consideration and help understanding the call flow 128 examples. 130 These flows do not assume specific underlying transport protocols 131 such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for 132 details on the transport issues for SIP. 134 1.2. Legend for Message Flows 136 Dashed lines (---) and slash lines (/, \) represent signaling 137 messages that are mandatory to the call scenario. (X) represents 138 crossover of signaling messages. (->x, x<-) indicate that the packet 139 is lost. The arrow indicates the direction of message flow. Double 140 dashed lines (===) represent media paths between network elements. 142 Messages are identified in the figures as F1, F2, etc. These numbers 143 are used for references to the message details that follow the 144 Figure. Comments in the message details are shown in the following 145 form: 147 /* Comments. */ 149 1.3. SIP Protocol Assumptions 151 This document does not prescribe the flows precisely as they are 152 shown, but rather illustrates the principles for best practice. They 153 are best practice usages (orderings, syntax, selection of features 154 for the purpose, or handling of error) of SIP methods, headers and 155 parameters. Note: The flows in this document must not be copied as 156 they are by implementors because additional characteristics were 157 incorporated into the document for ease of explanation. To sum up, 158 the procedures described in this document represent well-reviewed 159 examples of SIP usage, which are best common practice according to 160 IETF consensus. 162 For simplicity in reading and editing the document, there are a 163 number of differences between some of the examples and actual SIP 164 messages. For instance, Call-IDs are often repeated, CSeq often 165 begins at 1, header fields are usually shown in the same order, 166 usually only the minimum required header field set is shown, and 167 other headers which would usually be included such as Accept, Allow, 168 etc. are not shown. 170 Actors: 172 Element Display Name URI IP Address 173 ------- ------------ --- ---------- 175 User Agent Alice sip:alice@atlanta.example.com 192.0.2.101 176 User Agent Bob sip:bob@biloxi.example.com 192.0.2.201 177 User Agent Carol sip:carol@chicago.example.com 192.0.2.202 178 Proxy Server ss.atlanta.example.com 192.0.2.111 180 2. The Dialog State Machine for INVITE dialog usage 182 Race conditions are generated when the dialog state of the receiving 183 side differs from that of the sending side. 185 For instance, a race condition occurs when UAC (User Agent Client) 186 sends a CANCEL in the Early state while UAS (User Agent Server) is 187 transiting from the Early state to the Confirmed state by sending a 188 200 OK to initial INVITE (indicated as "ini-INVITE" hereafter). The 189 DSM (dialog state machine) for the INVITE dialog usage is presented 190 as follows to help understanding UA's behavior in race conditions. 192 The DSM clarifies UA's behavior by subdividing the dialog state shown 193 in RFC 3261 [1] into some internal states. We call the state before 194 a dialog establishment the Preparative state. The Confirmed state is 195 subdivided into two substates, the Moratorium and Established states, 196 and the Terminated state is subdivided into the Mortal and Morgue 197 states. Messages which are the triggers of the state transitions 198 between these states are indicated with arrows. In this figure, 199 messages which are not related to state transition are omitted. 201 Below are the DSMs for UAC and UAS respectively. 203 INV +-----------------------------------------------+ 204 --->| Preparative | 205 +-----------------------------------------------+ 206 | | | 207 | 3xx-6xx | 1xx-tag | 2xx 208 | | | 209 | | 1xx-tag | 210 | V w/new tag | 211 | +-----------------+ [new DSM] | 212 | 3xx-6xx | | | (new DSM | 213 +<--------| Early | | instance | 214 | | |<--+ created) | 215 | +-----------------+ | 216 | | | | 2xx w/new tag 217 | | BYE | 2xx | [new DSM] 218 | | +------------>+<-+ | (new DSM 219 | | | | instance 220 +-----C------------C-----+ +-----------C------+ | created) 221 | | Terminated | | | Confirmed | | | 222 | | +<----C---------| | | | 223 | | | | BYE(sr) | | | | 224 | | V | | V | | 225 | 2xx | +-----------+ | | +-----------+ | | 226 | +---C--| |---C-+ | | | | | 227 | | | | Mortal | | | BYE(r)| | Moratorium|<-C--+ 228 | +---C->| |<--C-+ | | | | 229 | ACK | +-----------+ | | +-----------+ | 230 | | | | | | | 231 | | | Timeout | | | ACK | 232 | | | | | | | 233 | V V | | V | 234 | +---------------+ | | +-----------+ | 235 | | | | | | |--C-+ 236 | | Morgue | | | |Established| | | 2xx,ACK 237 | | | | | | |<-C-+ 238 | +---------------+ | | +-----------+ | 239 | | | | 240 +------------------------+ +------------------+ 242 (r): indicates only reception is allowed. 243 Where (r) is not indicated, response means receive, request 244 means send. 246 Figure 1. DSM for INVITE dialog usage (Caller) 248 Figure 1 represents the caller's DSM for the INVITE dialog usage. 249 Caller MAY send a BYE in the Early state, even though this behavior 250 is NOT RECOMMENDED. The BYE sent in the Early state terminates the 251 early dialog with a specific To tag. That is, when a proxy is 252 performing forking, the BYE is only able to terminate the early 253 dialog with a particular UA. If caller wants to terminate all early 254 dialogs instead of that with a particular UA, it needs to send 255 CANCEL, not BYE. However, it is not illegal to send BYE in the Early 256 state to terminate a specific early dialog according to the caller's 257 intent. Moreover, until caller receives a final response and 258 terminates the INVITE transaction, the caller MUST be prepared to 259 establish a dialog by receiving a new response to the INVITE even 260 though it had sent a CANCEL or BYE and terminated the dialog (see 261 Appendix A). 263 INV +-----------------------------------------------+ 264 --->| Preparative | 265 +-----------------------------------------------+ 266 | | | 267 | 3xx-6xx | 1xx-tag | 2xx 268 | | | 269 | V | 270 | +------------------+ | 271 | 3xx-6xx | | | 272 +<--------| Early | | 273 | | | | 274 | +------------------+ | 275 | | | | 276 | | BYE | 2xx | 277 | | +------------>+<-+ 278 | | | 279 +-----C------------C-----+ +-----------C------+ 280 | | Terminated | | | Confirmed | | 281 | | +<----C---------| | | 282 | | | | BYE(sr) | | | 283 | | V | | V | 284 | | +------------+ | | +-----------+ | 285 | | | |---C-+ | | |--C-+ 286 | | | Mortal | | | BYE | | Moratorium| | | 2xx 287 | | | |<--C-+ | | |<-C-+ if ACK not 288 | | +------------+ | | +-----------+ | received 289 | | | | | | | 290 | | | Timeout | | | ACK | 291 | | | | | | | 292 | V V | | V | 293 | +---------------+ | | +-----------+ | 294 | | | | | | | | 295 | | Morgue | | | |Established| | 296 | | | | | | | | 297 | +---------------+ | | +-----------+ | 298 | | | | 299 +------------------------+ +------------------+ 301 (sr): indicates that both sending and reception are allowed. 302 Where (sr) is not indicated, response means send, 303 request means receive. 305 Figure 2. DSM for INVITE dialog usage (Callee) 307 Figure 2 represents callee's DSM for the INVITE dialog usage. The 308 figure does not illustrate the state transition related to CANCEL 309 request. CANCEL request does not cause a dialog state transition. 310 However, the callee terminates the dialog and triggers the dialog 311 transition by sending 487 immediately after the reception of the 312 CANCEL. Considering this, the behavior upon the reception of the 313 CANCEL request is further explained in Appendix C. 315 Following are UA's behaviors in each state. 317 Preparative (Pre): The Preparative state is a state until the early 318 dialog is established by sending or receiving a provisional 319 response with To tag after an ini-INVITE is sent or received. The 320 dialog has not existed yet in the Preparative state. If UA sends 321 or receives a 2xx response, the dialog state transit from the 322 Preparative to the Moratorium state which is a substate of the 323 Confirmed state. In addition, if UA sends or receives a 3xx-6xx 324 response the dialog state transit to the Morgue state which is a 325 substate of the Terminated state. Sending an ACK for a 3xx-6xx 326 response and retransmissions of 3xx-6xx are not expressed on the 327 DSMs because they are sent by the INVITE transaction. 329 Early (Ear): The early dialog is established by sending or receiving 330 a provisional response with To tag. The early dialog exists 331 though the dialog does not exist in this state yet. The dialog 332 state transits from the Early to Moratorium state, a substate of 333 the Confirmed state, by sending or receiving a 2xx response. In 334 addition, the dialog state transits to the Morgue state, a 335 substate of the Terminated state, by sending or receiving a 3xx- 336 6xx response. Sending an ACK for a 3xx-6xx response and 337 retransmissions of 3xx-6xx are not expressed on this DSM because 338 they are automatically processed on transaction layer and don't 339 influence the dialog state. UAC may send CANCEL in the Early 340 state. UAC may send BYE (although it is not recommended). UAS 341 may send a 1xx-6xx response. Sending or receiving of a CANCEL 342 request does not have direct influences on dialog state. The UA's 343 behavior upon the reception of the CANCEL request is further 344 explained in Appendix C. 346 Confirmed (Con): Sending or receiving of a 2xx final response 347 establishes a dialog. Dialog exists in this state. The Confirmed 348 state transits to the Mortal state, a substate of the Terminated 349 state, by sending or receiving a BYE request. The Confirmed state 350 has two substates, the Moratorium and Established state, which are 351 different in messages UAs are allowed to send. 353 Moratorium (Mora): The Moratorium state is a substate of the 354 Confirmed state and inherits the behavior of the superstate. The 355 Moratorium state transits to the Established state by sending or 356 receiving an ACK request. UAC may send ACK and UAS may send a 2xx 357 final response. 359 Established (Est): The Established state is a substate of the 360 Confirmed state and inherits the behavior of superstate. Both 361 caller and callee may send various messages which influence a 362 dialog. Caller supports the transmission of ACK in response to 363 retransmission of a 2xx response to an ini-INVITE. 365 Terminated (Ter): The Terminated state is divided into two 366 substates, the Mortal and Morgue states, to cover the behavior 367 when a dialog is being terminated. In this state, UAs hold 368 information about the dialog which is being terminated. 370 Mortal (Mort): Caller and callee enter the Mortal state by sending 371 or receiving a BYE. UA MUST NOT send any new requests within the 372 dialog because there is no dialog. (Here the new requests do not 373 include ACK for 2xx and BYE for 401 or 407 as further explained in 374 Appendix D below.) In this state, only BYE or its response can be 375 handled, and no other messages can be received. This addresses 376 the case where BYE is sent by both a caller and a callee to 377 exchange reports about the session when it is being terminated. 378 Therefore the UA possesses dialog information for internal 379 processing but the dialog shouldn't be externally visible. The UA 380 stops managing its dialog state and changes it to the Morgue 381 state, when the BYE transaction is terminated. 383 Morgue (Morg): The dialog no longer exists in this state. Sending 384 or receiving of signaling which influences a dialog is not 385 performed. (A dialog is literally terminated.) Caller and callee 386 enter the Morgue state via the termination of the BYE or INVITE 387 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 SIP- 394 enabled devices. Only significant signaling is illustrated. Dialog 395 state transitions caused by sending or receiving of SIP messages as 396 well as '*race*', which indicates race condition, are shown. (For 397 abbreviations for the dialog state transitions, refer to Section 2.) 398 '*race*' indicates the moment when a race condition occurs. 400 Examples of race conditions are shown below. 402 3.1. Receiving message in the Moratorium State 404 This section shows some examples of call flow in race condition when 405 receiving the message from other states in the Moratorium state. 407 3.1.1. Receiving Initial INVITE retransmission (Preparative state) in 408 Moratorium state 410 State Alice Bob State 411 | | 412 | ini-INVITE F1 | 413 |------------------------------------>| 414 Pre | 180 F2(Packet loss) | Pre 415 | x<-----------------------| 416 | | Ear 417 | ini-INVITE F4(=F1) 200 F3 | 418 |------------------ --------------| 419 | \ / | Mora 420 | X | 421 | / \ | 422 |<----------------- ------------->| *race* 423 Mora | ACK F5 | 424 |------------------------------------>| 425 Est | | Est 426 | | 428 This scenario illustrates the race condition which occurs when UAS 429 receives a Preparative message in the Moratorium state. All 430 provisional responses to the initial INVITE (ini-INVITE F1) are lost, 431 and UAC retransmits an ini-INVITE (F4). At the same time as 432 retransmission, UAS generates a 200 OK (F3) to the ini-INVITE and it 433 terminates an INVITE server transaction, according to Section 434 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) Therefore, the 438 INVITE server transaction is not terminated at F3, and the F4 MUST be 439 properly handled as a retransmission. (UAs that do not deal with 440 this bug still need to recognize the dialog relying on its From tag 441 and Call-ID, and the retransmitted request relying on the CSeq header 442 field value even though it does not match the transaction.) 444 In RFC 3261 [1], it is not specified whether UAS retransmits 200 to 445 the retransmission of ini-INVITE. Considering the retransmission of 446 200 triggered by timer (TU keeps retransmitting 200 based on T1 and 447 T2 until it receives an ACK), according to Section 13.3.1.4 of RFC 448 3261 [1], it seems unnecessary to retransmit 200 when the UAS 449 receives the retransmission of ini-INVITE. (For implementation, it 450 does not matter if the UAS sends the retransmission of 200, since the 451 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 Section 13.3.1.4 of RFC 3261 [1], an INVITE server 464 transaction is terminated at this point. However, this has been 465 reported as a SIP bug, and the UAS MUST correctly recognize the 466 ini-INVITE (F4) 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 since 474 it does not have a To tag. However, Bob have to recognize the 475 retransmitted INVITE correctly, without treating it as a new 476 INVITE. */ 478 F5 ACK Alice -> Bob 480 3.1.2. Receiving CANCEL (Early state) in Moratorium state 482 State Alice Bob State 483 | | 484 | INVITE F1 | 485 |----------------------------->| 486 Pre | 180 Ringing F2 | Pre 487 |<-----------------------------| 488 Ear | | Ear 489 |CANCEL F3 200(INVITE) F4| 490 |------------ -------------| 491 | \ / | Mora 492 | X | 493 | / \ | 494 |<----------- ------------>| *race* 495 Mora | | 496 | ACK F6 200(CANCEL) F5| 497 |------------ -------------| 498 Est | \ / | 499 | X | 500 | / \ | 501 |<----------- ------------>| 502 | | Est 503 | One Way RTP Media | 504 | (Two Way RTP Media possible) | 505 |<=============================| 506 | BYE F7 | 507 |----------------------------->| 508 Mort | 200 F8 | Mort 509 |<-----------------------------| 510 | ^ ^ | 511 | | Timer K | | 512 | V | | 513 Morg | Timer J | | 514 | V | 515 | | Morg 516 | | 518 This scenario illustrates the race condition which occurs when UAS 519 receives an Early message, CANCEL, in the Moratorium state. Alice 520 sends a CANCEL and Bob sends a 200 OK response to the initial INVITE 521 message at the same time. As described in the previous section, 522 according to RFC 3261 [1], an INVITE server transaction is supposed 523 to be terminated by a 200 response, but this has been reported as a 524 bug #769. 526 This section describes a case in which an INVITE server transaction 527 is not terminated by a 200 response to the INVITE request. In this 528 case, there is an INVITE transaction which the CANCEL request 529 matches, so a 200 response is sent to the request. This 200 response 530 simply means that the next hop received the CANCEL request 531 (Successful CANCEL (200) does not mean an INVITE failure). When UAS 532 does not deal with #769, UAC MAY receive a 481 response for CANCEL 533 since there is no transaction which the CANCEL request matches. This 534 481 simply means that there is no matching INVITE server transaction 535 and CANCEL is not sent to the next hop. Regardless of the success/ 536 failure of the CANCEL, Alice checks the final response to INVITE, and 537 if she receives 200 to the INVITE request she immediately sends a BYE 538 and terminates the dialog. (Section 15, RFC 3261 [1]) 540 From the time F1 is received by Bob until the time that F8 is sent by 541 Bob, media may be flowing one way from Bob to Alice. From the time 542 that an answer is received by Alice from Bob there is the possibility 543 that media may flow from Alice to Bob as well. However, once Alice 544 has decided to cancel the call, she presumably will not send media, 545 so practically speaking the media stream will remain one way. 547 Message Details 549 F1 INVITE Alice -> Bob 551 F2 180 Ringing Bob -> Alice 553 F3 CANCEL Alice -> Bob 555 /* Alice sends a CANCEL in the Early state. */ 557 F4 200 OK (INVITE) Bob -> Alice 559 /* Alice receives a 200 to INVITE (F1) in the Moratorium state. 560 Alice has the potential to send as well as receive media, but in 561 practice will not send because there is an intent to end the call. 562 */ 564 F5 200 OK (CANCEL) Bob -> Alice 566 /* 200 to CANCEL simply means that the CANCEL was received. The 200 567 response is sent, since this document deals with the bug reported 568 in #769. When an INVITE server transaction is terminated as the 569 procedure stated in RFC 3261 [1], UAC MAY receive 481 response 570 instead of 200. */ 572 F6 ACK Alice -> Bob 574 /* INVITE is successful, and the CANCEL becomes invalid. Bob 575 establishes RTP streams. However, the next BYE request 576 immediately terminates the dialog and session. */ 578 F7 BYE Alice -> Bob 580 F8 200 OK Bob -> Alice 582 3.1.3. Receiving BYE (Early state) in Moratorium state 584 State Alice Bob State 585 | | 586 | ini-INVITE F1 | 587 |------------------------------->| 588 Pre | 180 F2 | Pre 589 |<-------------------------------| 590 Ear | | Ear 591 | BYE F4 200(INVITE) F3| 592 |------------- --------------| 593 Mort | \ / | Mora 594 | X | 595 | / \ | 596 |<------------ ------------->| *race* 597 | | Mort 598 | ACK F5 200(BYE) F6 | 599 |------------- --------------| 600 | \ / ^ | 601 | X | | 602 | / \ | | 603 |<------------ ------------->| 604 | ^ | | 605 | | Timer K | | 606 | V | | 607 Morg | Timer J | | 608 | V | 609 | | Morg 610 | | 612 This scenario illustrates the race condition which occurs when UAS 613 receives an Early message, BYE, in the Moratorium state. Alice sends 614 a BYE in the Early state and Bob sends a 200 OK response to the 615 initial INVITE request at the same time. Bob receives the BYE in the 616 Confirmed dialog state though Alice sent the request in the Early 617 state (As explained in Section 2 and Appendix A, this behavior is NOT 618 RECOMMENDED). When a proxy is performing forking, the BYE is only 619 able to terminate the early dialog with a particular UA. If caller 620 wants to terminate all early dialogs instead of that with a 621 particular UA, it needs to send CANCEL, not BYE. However, it is not 622 illegal to send BYE in the Early state to terminate a specific early 623 dialog according to the caller's intent. 625 The BYE functions normally even if it is received after the INVITE 626 transaction termination because BYE differs from CANCEL, and is sent 627 not to the request but to the dialog. Alice gets into the Mortal 628 state on sending the BYE request, and remains Mortal until Timer K 629 timeout occurs. In the Mortal state, UAC does not establish a 630 session, even though it receives a 200 response to INVITE. Even so, 631 the UAC sends an ACK to 200 for the completion of INVITE transaction. 632 The ACK is always sent to complete the three-way handshake of INVITE 633 transaction (Further explained in Appendix D below). 635 Message Details 637 F1 INVITE Alice -> Bob 639 F2 180 Ringing Bob -> Alice 641 F3 200 OK (ini-INVITE) Bob -> Alice 643 F4 BYE Alice -> Bob 645 /* Alice transits to the Mortal state upon sending BYE. Therefore, 646 after this, she does not begin a session even though she receives 647 a 200 response with an answer. */ 649 F5 ACK Alice -> Bob 651 F6 200 OK (BYE) Bob -> Alice 653 3.1.4. Receiving re-INVITE (Established state) in Moratorium state 654 (case 1) 656 State Alice Bob State 657 | | 658 | ini-INVITE w/offer1 F1 | 659 |------------------------------->| 660 Pre | 180 F2 | Pre 661 |<-------------------------------| 662 Ear | | Ear 663 | 200(ini-INV) w/answer1 F3 | 664 |<-------------------------------| 665 Mora | ACK F4(packet loss) | Mora 666 |-------------------->x | 667 Est | | 668 | re-INVITE F6 200 F5(=F3) | 669 | w/offer2 w/answer1 | 670 |------------- --------------| 671 | \ / | 672 | X | 673 | / \ | 674 |<------------ ------------->| *race* 675 | 200(re-INV) F8| 676 | ACK F7(=F4) w/answer2 | 677 |------------- --------------| 678 | \ / | 679 | X | 680 | / \ | 681 |<------------ ------------->| 682 | ACK (re-INV) F9 | Est 683 |------------------------------->| 684 | | 685 | | 687 This scenario illustrates the race condition which occurs when UAS 688 receives re-INVITE request sent from the Established state, in the 689 Moratorium state. 691 UAS receives a re-INVITE (w/offer2) before receiving an ACK for ini- 692 INVITE (w/offer1). UAS sends a 200 OK (w/answer2) to the re-INVITE 693 (F8) because it has sent a 200 OK (w/answer1) to the ini-INVITE (F3, 694 F5) and the dialog has already been established. (Because F5 is a 695 retransmission of F3, SDP negotiation is not performed here.) 697 If a 200 OK to the ini-INVITE has an offer and the answer is in the 698 ACK, it is recommended that UA return a 491 to the re-INVITE (refer 699 to Section 3.1.5). (Note: 500 with Retry-After header may be 700 returned, if the 491 response is understood to indicate request 701 collision. However, 491 is recommended here because 500 applies to 702 so many cases that it is difficult to determine what the real problem 703 was.) As it can be seen in Section 3.3.2 below, the 491 response 704 seems to be closely related to session establishment, even in cases 705 other than INVITE cross-over. This example recommends 200 be sent 706 instead of 491 because it does not have influence on session. 707 However, a 491 response can also lead to the same outcome, so the 708 either response can be used. 710 Moreover, if UAS doesn't receive an ACK for a long time, it should 711 send a BYE and terminate the dialog. Note that ACK F7 has the same 712 CSeq number as ini-INVITE F1 (See Section 13.2.2.4 of RFC 3261 [1]). 713 The UA should not reject or drop the ACK on grounds of CSeq number. 715 Note: There is a hint for implementation to avoid the race conditions 716 of this type. That is for the caller to delay sending re-INVITE F6 717 for some period of time (2 seconds, perhaps), from which the caller 718 is reasonably able to assume that its ACK has been received. 719 Implementors can decouple the actions of the user (e.g. pressing the 720 hold button) from the actions of the protocol (the sending of re- 721 INVITE F6), so that the UA can behave as such. In this case, it is 722 dependent on the implementor's choice as to how long it waits. In 723 most cases, such implementation may be useful to prevent a type of 724 race condition shown in this section. 726 Message Details 728 F1 INVITE Alice -> Bob 730 INVITE sip:bob@biloxi.example.com SIP/2.0 731 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 732 Max-Forwards: 70 733 From: Alice ;tag=9fxced76sl 734 To: Bob 735 Call-ID: 3848276298220188511@atlanta.example.com 736 CSeq: 1 INVITE 737 Contact: 738 Content-Type: application/sdp 739 Content-Length: 137 741 v=0 742 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 743 s=- 744 c=IN IP4 192.0.2.101 745 t=0 0 746 m=audio 49172 RTP/AVP 0 747 a=rtpmap:0 PCMU/8000 748 /* Detailed messages are shown for the sequence to illustrate offer 749 and answer examples. */ 751 F2 180 Ringing Bob -> Alice 753 SIP/2.0 180 Ringing 754 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 755 ;received=192.0.2.101 756 From: Alice ;tag=9fxced76sl 757 To: Bob ;tag=8321234356 758 Call-ID: 3848276298220188511@atlanta.example.com 759 CSeq: 1 INVITE 760 Contact: 761 Content-Length: 0 763 F3 200 OK Bob -> Alice 765 SIP/2.0 200 OK 766 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 767 ;received=192.0.2.101 768 From: Alice ;tag=9fxced76sl 769 To: Bob ;tag=8321234356 770 Call-ID: 3848276298220188511@atlanta.example.com 771 CSeq: 1 INVITE 772 Contact: 773 Content-Type: application/sdp 774 Content-Length: 133 776 v=0 777 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 778 s=- 779 c=IN IP4 192.0.2.201 780 t=0 0 781 m=audio 3456 RTP/AVP 0 782 a=rtpmap:0 PCMU/8000 784 F4 ACK Alice -> Bob 786 ACK sip:bob@client.biloxi.example.com SIP/2.0 787 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 788 Max-Forwards: 70 789 From: Alice ;tag=9fxced76sl 790 To: Bob ;tag=8321234356 791 Call-ID: 3848276298220188511@atlanta.example.com 792 CSeq: 1 ACK 793 Content-Length: 0 795 /* ACK request is lost. */ 797 F5(=F3) 200 OK Bob -> Alice (retransmission) 799 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 800 received an ACK. */ 802 F6 re-INVITE Alice -> Bob 804 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 805 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 806 Max-Forwards: 70 807 From: Alice ;tag=9fxced76sl 808 To: Bob ;tag=8321234356 809 Call-ID: 3848276298220188511@atlanta.example.com 810 CSeq: 2 INVITE 811 Content-Length: 147 813 v=0 814 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 815 s=- 816 c=IN IP4 192.0.2.101 817 t=0 0 818 m=audio 49172 RTP/AVP 0 819 a=rtpmap:0 PCMU/8000 820 a=sendonly 822 F7(=F4) ACK Alice -> Bob (retransmission) 824 F8 200 OK (re-INVITE) Bob -> Alice 826 SIP/2.0 200 OK 827 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 828 Max-Forwards: 70 829 From: Alice ;tag=9fxced76sl 830 To: Bob ;tag=8321234356 831 Call-ID: 3848276298220188511@atlanta.example.com 832 CSeq: 2 INVITE 833 Content-Length: 143 835 v=0 836 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com 837 s=- 838 c=IN IP4 192.0.2.201 839 t=0 0 840 m=audio 3456 RTP/AVP 0 841 a=rtpmap:0 PCMU/8000 842 a=recvonly 844 F9 ACK (re-INVITE) Alice -> Bob 846 ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 847 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21 848 Max-Forwards: 70 849 From: Alice ;tag=9fxced76sl 850 To: Bob ;tag=8321234356 851 Call-ID: 3848276298220188511@atlanta.example.com 852 CSeq: 2 ACK 853 Content-Length: 0 855 3.1.5. Receiving re-INVITE (Established state) in Moratorium state 856 (case 2) 858 State Alice Bob State 859 | | 860 | ini-INVITE (no offer) F1 | 861 |------------------------------->| 862 Pre | 180 F2 | Pre 863 |<-------------------------------| 864 Ear | | Ear 865 | 200(ini-INV) w/offer1 F3 | 866 |<-------------------------------| 867 Mora | ACK w/answer1 F4(packet loss) | Mora 868 |-------------------->x | 869 Est | | 870 | re-INVITE F6 200 F5(=F3) | 871 | w/offer2 w/offer1 | 872 |------------- --------------| 873 | \ / | 874 | X | 875 | / \ | 876 |<------------ ------------->| 877 | ACK F7(=F4) 491(re-INV) F8| 878 |------------- --------------| 879 | \ / | 880 | X | 881 | / \ | 882 |<------------ ------------->| 883 | ACK (re-INV) F9 | Est 884 |------------------------------->| 885 | | 886 | | 888 This scenario is basically the same as that of Section 3.1.4, but 889 differs in sending an offer in 200 and an answer in ACK. Different 890 to the previous case, the offer in the 200 (F3) and the offer in the 891 re-INVITE (F6) collide with each other. 893 Bob sends 491 to re-INVITE (F6) since he is not able to properly 894 handle a new request until he receives an answer. (Note: 500 with 895 Retry-After header may be returned, if the 491 response is understood 896 to indicate request collision. However, 491 is recommended here 897 because 500 applies to so many cases that it is difficult to 898 determine what the real problem was.) Even if F6 is UPDATE with 899 offer, it will reach the same result. 901 Note: As noted in Section 3.1.4, it may be useful for the caller to 902 delay sending re-INVITE F6 for some period of time (2 seconds, 903 perhaps), from which the caller is reasonably able to assume that its 904 ACK has been received, to prevent a type of race condition shown in 905 this section. 907 Message Details 909 F1 INVITE Alice -> Bob 911 INVITE sip:bob@biloxi.example.com SIP/2.0 912 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 913 Max-Forwards: 70 914 From: Alice ;tag=9fxced76sl 915 To: Bob 916 Call-ID: 3848276298220188511@atlanta.example.com 917 CSeq: 1 INVITE 918 Contact: 919 Content-Length: 0 921 /* The request does not contain an offer. Detailed messages are 922 shown for the sequence to illustrate offer and answer examples. 923 */ 925 F2 180 Ringing Bob -> Alice 927 F3 200 OK Bob -> Alice 929 SIP/2.0 200 OK 930 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 931 ;received=192.0.2.101 932 From: Alice ;tag=9fxced76sl 933 To: Bob ;tag=8321234356 934 Call-ID: 3848276298220188511@atlanta.example.com 935 CSeq: 1 INVITE 936 Contact: 937 Content-Type: application/sdp 938 Content-Length: 133 940 v=0 941 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 942 s=- 943 c=IN IP4 192.0.2.201 944 t=0 0 945 m=audio 3456 RTP/AVP 0 946 a=rtpmap:0 PCMU/8000 947 /* An offer is made in 200. */ 949 F4 ACK Alice -> Bob 951 ACK sip:bob@client.biloxi.example.com SIP/2.0 952 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 953 Max-Forwards: 70 954 From: Alice ;tag=9fxced76sl 955 To: Bob ;tag=8321234356 956 Call-ID: 3848276298220188511@atlanta.example.com 957 CSeq: 1 ACK 958 Content-Type: application/sdp 959 Content-Length: 137 961 v=0 962 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 963 s=- 964 c=IN IP4 192.0.2.101 965 t=0 0 966 m=audio 49172 RTP/AVP 0 967 a=rtpmap:0 PCMU/8000 969 /* The request contains an answer, but the request is lost. */ 971 F5(=F3) 200 OK Bob -> Alice (retransmission) 973 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 974 received an ACK. */ 976 F6 re-INVITE Alice -> Bob 978 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 979 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 980 Max-Forwards: 70 981 From: Alice ;tag=9fxced76sl 982 To: Bob ;tag=8321234356 983 Call-ID: 3848276298220188511@atlanta.example.com 984 CSeq: 2 INVITE 985 Content-Length: 147 987 v=0 988 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 989 s=- 990 c=IN IP4 192.0.2.101 991 t=0 0 992 m=audio 49172 RTP/AVP 0 993 a=rtpmap:0 PCMU/8000 994 a=sendonly 996 /* The request contains an offer. */ 998 F7(=F4) ACK Alice -> Bob (retransmission) 1000 /* A retransmission triggered by the reception of a retransmitted 1001 200. */ 1003 F8 491 (re-INVITE) Bob -> Alice 1005 /* Bob sends 491 (Request Pending), since Bob has a pending offer. 1006 */ 1008 F9 ACK (re-INVITE) Alice -> Bob 1010 3.1.6. Receiving BYE (Established state) in Moratorium state 1012 State Alice Bob State 1013 | | 1014 | INVITE F1 | 1015 |-------------------------->| 1016 Pre | 180 Ringing F2 | Pre 1017 |<--------------------------| 1018 Ear | | Ear 1019 | 200 OK F3 | 1020 |<--------------------------| 1021 Mora | ACK F4(packet loss) | Mora 1022 |--------------->x | 1023 Est | Both Way RTP Media | 1024 |<=========================>| 1025 | BYE F6 200 F5(=F3)| 1026 |----------- -----------| 1027 Mort | \ / | 1028 | X | 1029 | / \ | 1030 |<---------- ---------->| *race* 1031 |ACK F7(=F4) 200(BYE) F8| Mort 1032 |----------- -----------| 1033 | \ / | 1034 | X | 1035 | / \ | 1036 |<---------- ---------->| 1037 | ^ ^ | 1038 | | Timer K | | 1039 | V | | 1040 Morg | Timer J | | 1041 | V | 1042 | | Morg 1043 | | 1045 This scenario illustrates the race condition which occurs when UAS 1046 receives an Established message, BYE, in the Moratorium state. An 1047 ACK request for a 200 OK response is lost (or delayed). Immediately 1048 after Bob retransmits the 200 OK to ini-INVITE, and Alice sends a BYE 1049 request at the same time. Depending on the implementation of a SIP 1050 UA, Alice may start a session again by the reception of the 1051 retransmitted 200 OK with SDP since she has already terminated a 1052 session by sending a BYE. In that case, when UAC receives a 1053 retransmitted 200 OK after sending a BYE, a session should not be 1054 started again since the session which is not associated with dialog 1055 still remains. Moreover, in the case where UAS sends an offer in a 1056 200 OK, UAS should not start a session again for the same reason if 1057 UAS receives a retransmitted ACK after receiving a BYE. 1059 Note: As noted in Section 3.1.4, there is a hint for implementation 1060 to avoid the race conditions of this type. That is for the caller to 1061 delay sending BYE F6 for some period of time (2 seconds, perhaps), 1062 from which the caller is reasonably able to assume that its ACK has 1063 been received. Implementors can decouple the actions of the user 1064 (e.g. hanging up) from the actions of the protocol (the sending of 1065 BYE F6), so that the UA can behave as such. In this case, it is 1066 dependent on the implementor's choice as to how long it waits. In 1067 most cases, such implementation may be useful to prevent a type of 1068 race condition shown in this section. 1070 Message Details 1072 F1 INVITE Alice -> Bob 1074 F2 180 Ringing Bob -> Alice 1076 F3 200 OK Bob -> Alice 1078 F4 ACK Alice -> Bob 1080 /* ACK request is lost. */ 1082 F5(=F3) 200 OK Bob -> Alice 1084 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 1085 received an ACK. */ 1087 F6 BYE Alice -> Bob 1089 /* Bob retransmits a 200 OK and Alice sends a BYE at the same time. 1090 Alice transits to the Mortal state, so she does not begin a 1091 session after this even though she receives a 200 response to the 1092 re-INVITE. */ 1094 F7(=F4) ACK Alice -> Bob 1096 F8 200 OK (BYE) Bob -> Alice 1097 /* Bob sends a 200 OK to the BYE. */ 1099 3.2. Receiving message in the Mortal State 1101 This section shows some examples of call flow in race condition when 1102 receiving the message from other states in the Mortal state. 1104 3.2.1. Receiving BYE (Establish state) in Mortal state 1106 State Alice Bob State 1107 | | 1108 | INVITE F1 | 1109 |----------------------->| 1110 Pre | 180 Ringing F2 | Pre 1111 |<-----------------------| 1112 Ear | | Ear 1113 | 200 OK F3 | 1114 |<-----------------------| 1115 Mora | ACK F4 | Mora 1116 |----------------------->| 1117 Est | Both Way RTP Media | Est 1118 |<======================>| 1119 | | 1120 | BYE F5 BYE F6 | 1121 |--------- ----------| 1122 Mort | \ / | Mort 1123 | X | 1124 | / \ | 1125 |<-------- --------->| *race* 1126 | | 1127 | 200 F8 200 F7 | 1128 |--------- ----------| 1129 | \ / | 1130 | X | 1131 | / \ | 1132 |<-------- --------->| 1133 | ^ ^ | 1134 | | Timer K | | 1135 | V | | 1136 Morg | Timer J | | 1137 | V | 1138 | | Morg 1139 | | 1141 This scenario illustrates the race condition which occurs when UAS 1142 receives an Established message, BYE, in the Mortal state. Alice and 1143 Bob send a BYE at the same time. A dialog and session are ended 1144 shortly after a BYE request is passed to a client transaction. As 1145 shown in Section 2, UA remains in the Mortal state. 1147 UAs in the Mortal state return error responses to the requests that 1148 operate dialog or session, such as re-INVITE, UPDATE, or REFER. 1149 However, UA shall return 200 OK to the BYE taking the use case into 1150 consideration where BYE request is sent by both a caller and a callee 1151 to exchange reports about the session when it is being terminated. 1152 (Since the dialogue and the session both terminate when a BYE is 1153 sent, the choice of sending 200 or an error response upon receiving 1154 BYE in the Mortal state does not affect the resulting termination. 1155 Therefore, even though this example uses a 200 response, other 1156 responses can also be used.) 1158 Message Details 1160 F1 INVITE Alice -> Bob 1162 F2 180 Ringing Bob -> Alice 1164 F3 200 OK Bob -> Alice 1166 F4 ACK Alice -> Bob 1168 F5 BYE Alice -> Bob 1170 /* The session is terminated at the moment Alice sends a BYE. The 1171 dialog still exists then, but it is certain to be terminated in a 1172 short period of time. The dialog is completely terminated when 1173 the timeout of the BYE request occurs. */ 1175 F6 BYE Bob -> Alice 1177 /* Bob has also transmitted a BYE simultaneously with Alice. Bob 1178 terminates the session and the dialog. */ 1180 F7 200 OK Bob -> Alice 1181 /* Since the dialog is in the Moratorium state, Bob responds with a 1182 200 to the BYE request. */ 1184 F8 200 OK Alice -> Bob 1186 /* Since Alice has transited from the Established state to the Mortal 1187 state by sending BYE, Alice responds with a 200 to the BYE 1188 request. */ 1190 3.2.2. Receiving re-INVITE (Establish state) in Mortal state 1192 State Alice Bob State 1193 | | 1194 | INVITE F1 | 1195 |----------------------->| 1196 Pre | 180 Ringing F2 | Pre 1197 |<-----------------------| 1198 Ear | | Ear 1199 | 200 OK F3 | 1200 |<-----------------------| 1201 Mora | ACK F4 | Mora 1202 |----------------------->| 1203 Est | Both Way RTP Media | Est 1204 |<======================>| 1205 | | 1206 | BYE F5 re-INVITE F6| 1207 |--------- ----------| 1208 Mort | \ / | 1209 | X | 1210 | / \ | 1211 *race* |<-------- --------->| 1212 | | Mort 1213 | 481 F8 200 F7 | 1214 | (re-INV) (BYE) | 1215 |--------- ----------| 1216 | \ / |^ 1217 | X || 1218 | / \ ||Timer J 1219 |<-------- --------->|| 1220 ^| ACK (re-INV) F9 || 1221 ||<-----------------------|| 1222 Timer K|| || 1223 V| || 1224 Morg | |V 1225 | | Morg 1226 | | 1228 This scenario illustrates the race condition which occurs when UAS 1229 receives an Established message, re-INVITE, in the Mortal state. Bob 1230 sends a re-INVITE, and Alice sends a BYE at the same time. The re- 1231 INVITE is responded by a 481, since the TU of Alice has transited 1232 from the Established state to the Mortal state by sending BYE. Bob 1233 sends ACK for the 481 response, because the ACK for error responses 1234 is handled by the transaction layer and at the point of receiving the 1235 481 the INVITE client transaction still remains (even though the 1236 dialog has been terminated). 1238 Message Details 1240 F1 INVITE Alice -> Bob 1242 F2 180 Ringing Bob -> Alice 1244 F3 200 OK Bob -> Alice 1246 F4 ACK Alice -> Bob 1248 F5 BYE Alice -> Bob 1250 /* Alice sends a BYE and terminates the session, and transits from 1251 the Established state to the Mortal state. */ 1253 F6 re-INVITE Bob -> Alice 1255 /* Alice sends a BYE, and Bob sends a re-INVITE at the same time. 1256 The dialog state transits to the Mortal state at the moment Alice 1257 sends the BYE, but Bob does not know it until he receives the BYE. 1258 Therefore, the dialog is in the Terminated state from Alice's 1259 point of view, but it is the Confirmed state from Bob's point of 1260 view. A race condition occurs. */ 1262 F7 200 OK (BYE) Bob -> Alice 1264 F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob 1266 /* Since Alice is in the Mortal state, she responds with a 481 to the 1267 re-INVITE. */ 1269 F9 ACK (re-INVITE) Bob -> Alice 1271 /* ACK for an error response is handled by Bob's INVITE client 1272 transaction. */ 1274 3.2.3. Receiving 200 OK for re-INVITE (Established state) in Mortal 1275 state 1277 State Alice Bob State 1278 | | 1279 | INVITE F1 | 1280 |----------------------->| 1281 Pre | 180 Ringing F2 | Pre 1282 |<-----------------------| 1283 Ear | | Ear 1284 | 200 OK F3 | 1285 |<-----------------------| 1286 Mora | ACK F4 | Mora 1287 |----------------------->| 1288 Est | Both Way RTP Media | Est 1289 |<======================>| 1290 | | 1291 | re-INVITE F5 | 1292 |<-----------------------| 1293 | 200 F7 BYE F6 | 1294 |--------- ----------| 1295 | \ / | Mort 1296 | X | 1297 | / \ | 1298 |<-------- --------->| *race* 1299 Mort | 200 F8 ACK F9 | 1300 | (BYE) (re-INV) | 1301 |--------- ----------| 1302 | ^ \ / | 1303 | | X | 1304 | | / \ | 1305 |<-------- --------->| 1306 | | ^ | 1307 | | Timer K | | 1308 | | V | 1309 | | Timer J | Morg 1310 | V | 1311 Morg | | 1312 | | 1314 This scenario illustrates the race condition which occurs when UAS 1315 receives an Established message, 200 to re-INVITE, in the Mortal 1316 state. Bob sends a BYE immediately after sending a re-INVITE. (A 1317 user is not conscious that refresher sends re-INVITE automatically. 1318 For example, in the case of a telephone application, it is possible 1319 that a user places a receiver immediately after refresher.) Bob 1320 sends ACK for a 200 response to INVITE in the Mortal state, so that 1321 he completes the INVITE transaction. 1323 Note: As noted in Section 3.1.4, there is a hint for implementation 1324 to avoid the race conditions of this type. That is for the UAC to 1325 delay sending BYE F6 until re-INVITE F5 transaction completes. 1326 Implementors can decouple the actions of the user (e.g. hanging up) 1327 from the actions of the protocol (the sending of BYE F6), so that the 1328 UA can behave as such. In this case, it is dependent on the 1329 implementor's choice as to how long it waits. In most cases, such 1330 implementation may be useful to prevent a type of race condition 1331 shown in this section. 1333 Message Details 1335 F1 INVITE Alice -> Bob 1337 F2 180 Ringing Bob -> Alice 1339 F3 200 OK Bob -> Alice 1341 F4 ACK Alice -> Bob 1343 F5 re-INVITE Bob -> Alice 1345 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1346 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1347 Session-Expires: 300;refresher=uac 1348 Supported: timer 1349 Max-Forwards: 70 1350 From: Bob ;tag=8321234356 1351 To: Alice ;tag=9fxced76sl 1352 Call-ID: 3848276298220188511@atlanta.example.com 1353 CSeq: 1 INVITE 1354 Content-Length: 0 1356 /* Some detailed messages are shown for the sequence to illustrate 1357 that the re-INVITE is handled in the usual manner in the Mortal 1358 state. */ 1360 F6 BYE Bob -> Alice 1361 /* Bob sends BYE immediately after sending the re-INVITE. Bob 1362 terminates the session and transits from the Established state to 1363 the Mortal state. */ 1365 F7 200 OK (re-INVITE) Alice -> Bob 1367 SIP/2.0 200 OK 1368 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7 1369 ;received=192.0.2.201 1370 Require: timer 1371 Session-Expires: 300;refresher=uac 1372 From: Bob ;tag=8321234356 1373 To: Alice ;tag=9fxced76sl 1374 Call-ID: 3848276298220188511@atlanta.example.com 1375 CSeq: 1 INVITE 1376 Content-Length: 0 1378 /* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE. 1379 A race condition occurs. */ 1381 F8 200 OK (BYE) Alice -> Bob 1383 F9 ACK (re-INVITE) Bob -> Alice 1385 ACK sip:alice@client.atlanta.example.com SIP/2.0 1386 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44 1387 Max-Forwards: 70 1388 From: Bob ;tag=8321234356 1389 To: Alice ;tag=9fxced76sl 1390 Call-ID: 3848276298220188511@atlanta.example.com 1391 CSeq: 2 ACK 1392 Content-Length: 0 1394 /* Bob sends ACK in the Mortal state to complete the three-way 1395 handshake of the INVITE transaction. */ 1397 3.2.4. Receiving ACK (Moratorium state) in Mortal state 1399 State Alice Bob State 1400 | | 1401 | ini-INVITE F1 | 1402 |------------------------------->| 1403 Pre | 180 F2 | Pre 1404 |<-------------------------------| 1405 Ear | 200 F3 | Ear 1406 |<-------------------------------| 1407 Mora | | Mora 1408 | ACK F4 BYE F5 | 1409 |------------- --------------| 1410 Est | \ / | Mort 1411 | X | 1412 | / \ | 1413 |<------------ ------------->| *race* 1414 Mort | 200 F6 | 1415 |------------------------------->| 1416 | ^ ^ | 1417 | | Timer K | | 1418 | | V | 1419 | | Timer J | Morg 1420 | V | 1421 Morg | | 1422 | | 1424 This scenario illustrates the race condition which occurs when UAS 1425 receives an Established message, ACK to 200, in the Mortal state. 1426 Alice sends an ACK and Bob sends a BYE at the same time. When the 1427 offer is in a 2xx, and the answer is in an ACK, this example is in a 1428 race condition. The session is not started by receiving the ACK 1429 because Bob has already terminated the session by sending the BYE. 1430 The answer in the ACK request is just ignored. 1432 Note: As noted in Section 3.1.4, there is a hint for implementation 1433 to avoid the race conditions of this type. Implementors can decouple 1434 the actions of the user (e.g. hanging up) from the actions of the 1435 protocol (the sending of BYE F5), so that the UA can behave as such. 1436 In this case, it is dependent on the implementor's choice as to how 1437 long it waits. In most cases, such implementation may be useful to 1438 prevent a type of race condition shown in this section. 1440 Message Details 1442 F1 INVITE Alice -> Bob 1443 F2 180 Ringing Bob -> Alice 1445 F3 200 OK Bob -> Alice 1447 F4 ACK Alice -> Bob 1449 /* RTP streams are established between Alice and Bob */ 1451 F5 BYE Alice -> Bob 1453 F6 200 OK Bob -> Alice 1455 /* Alice sends a BYE and terminates the session and dialog. */ 1457 3.3. Other race conditions 1459 This section shows the examples in race condition that are not 1460 directly related to the dialog state transition. In SIP, processing 1461 functions are deployed in three layers, dialog, session, and 1462 transaction. There are related each other, but have to be treated 1463 separately. Section 17 of RFC 3261 [1] details the processing on 1464 transactions. This draft has tried so far to clarify the processing 1465 on dialogs. This section explains race conditions which are related 1466 to sessions established by SIP. 1468 3.3.1. Re-INVITE crossover 1470 Alice Bob 1471 | | 1472 | INVITE F1 | 1473 |--------------------------->| 1474 | 180 Ringing F2 | 1475 |<---------------------------| 1476 | 200 OK F3 | 1477 |<---------------------------| 1478 | ACK F4 | 1479 |--------------------------->| 1480 | Both Way RTP Media | 1481 |<==========================>| 1482 | | 1483 |re-INVITE F5 re-INVITE F6 | 1484 |------------ -------------| 1485 | \ / | 1486 | X | 1487 | / \ | 1488 |<----------- ------------>| 1489 | 491 F8 491 F7 | 1490 |------------ -------------| 1491 | \ / | 1492 | X | 1493 | / \ | 1494 |<----------- ------------>| 1495 | ^ ACK F9 ^ ACK F10| 1496 |--|--------- ----|--------| 1497 | | \ / | | 1498 | | X | | 1499 | | / \ | | 1500 |<-|---------- ---|------->| 1501 | | | | 1502 | |0-2.0 sec | | 1503 | | | | 1504 | v re-INVITE F11(=F6) | 1505 |<------------------|--------| 1506 | 200 OK F12 | | 1507 |-------------------|------->| 1508 | ACK F13 | | 1509 |<------------------|--------| 1510 | | | 1511 | |2.1-4.0 sec 1512 | | | 1513 |re-INVITE F14(=F5) v | 1514 |--------------------------->| 1515 | 200 OK F15 | 1516 |<---------------------------| 1517 | ACK F16 | 1518 |--------------------------->| 1519 | | 1520 | | 1522 In this scenario, Alice and Bob send re-INVITE at the same time. 1523 When two re-INVITEs cross in the same dialog, they resend re-INVITEs 1524 after different interval for each, according to Section 14.1, of RFC 1525 3261 [1]. When Alice sends the re-INVITE and it crosses, the re- 1526 INVITE will be sent again after 2.1-4.0 seconds because she owns the 1527 Call-ID (she generated it). Bob will send an INVITE again after 1528 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID. 1529 Therefore, each user agent must remember whether it has generated the 1530 Call-ID of the dialog or not, in case an INVITE may cross with 1531 another INVITE. 1533 In this example, Alice's re-INVITE is for session modification and 1534 Bob's re-INVITE is for session refresh. In this case, after the 491 1535 responses, Bob retransmits the re-INVITE for session refresh earlier 1536 than Alice. If Alice was to retransmit her re-INVITE (that is, if 1537 she was not the owner of Call-ID), the request would refresh and 1538 modify the session at the same time. Then Bob would know that he 1539 would not need to retransmit his re-INVITE to refresh the session. 1541 In another instance where two re-INVITEs for session modification, 1542 cross over, retransmitting the same re-INVITE again after 491 by the 1543 Call-ID owner (the UA which retransmits its re-INVITE after the other 1544 UA) may result in a behavior different from what the user originally 1545 intended to, so the UA needs to decide if the retransmission of the 1546 re-INVITE is necessary. (For example, when a call hold and an 1547 addition of video media cross over, mere retransmission of the re- 1548 INVITE at the firing of the timer may result in the situation where 1549 the video is transmitted immediately after the holding of the audio. 1550 This behavior is probably not intended by the users.) 1552 Message Details 1554 F1 INVITE Alice -> Bob 1556 F2 180 Ringing Bob -> Alice 1558 F3 200 OK Bob -> Alice 1560 F4 ACK Alice -> Bob 1562 F5 re-INVITE Alice -> Bob 1564 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1565 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1566 Max-Forwards: 70 1567 From: Alice ;tag=9fxced76sl 1568 To: Bob ;tag=8321234356 1569 Call-ID: 3848276298220188511@atlanta.example.com 1570 CSeq: 2 INVITE 1571 Content-Length: 147 1573 v=0 1574 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1575 s=- 1576 c=IN IP4 192.0.2.101 1577 t=0 0 1578 m=audio 49172 RTP/AVP 0 1579 a=rtpmap:0 PCMU/8000 1580 a=sendonly 1582 /* Some detailed messages are shown for the sequence to illustrate 1583 what sort of INVITE requests crossed over each other. */ 1585 F6 re-INVITE Bob -> Alice 1587 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1588 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1589 Session-Expires: 300;refresher=uac 1590 Supported: timer 1591 Max-Forwards: 70 1592 From: Bob ;tag=8321234356 1593 To: Alice ;tag=9fxced76sl 1594 Call-ID: 3848276298220188511@atlanta.example.com 1595 CSeq: 1 INVITE 1596 Content-Length: 0 1598 /* A re-INVITE request for a session refresh and that for a call hold 1599 are sent at the same time. */ 1601 F7 491 Request Pending Bob -> Alice 1603 /* Since a re-INVITE is in progress, a 491 response is returned. */ 1605 F8 491 Request Pending Alice -> Bob 1607 F9 ACK (INVITE) Alice -> Bob 1609 F10 ACK (INVITE) Bob -> Alice 1611 F11 re-INVITE Bob -> Alice 1613 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1614 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 1615 Session-Expires: 300;refresher=uac 1616 Supported: timer 1617 Max-Forwards: 70 1618 From: Bob ;tag=8321234356 1619 To: Alice ;tag=9fxced76sl 1620 Call-ID: 3848276298220188511@atlanta.example.com 1621 CSeq: 2 INVITE 1622 Content-Type: application/sdp 1623 Content-Length: 133 1625 v=0 1626 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1627 s=- 1628 c=IN IP4 192.0.2.201 1629 t=0 0 1630 m=audio 3456 RTP/AVP 0 1631 a=rtpmap:0 PCMU/8000 1633 /* Since Bob is not the owner of the Call-ID, he sends a re-INVITE 1634 again after 0.0-2.0 seconds. */ 1636 F12 200 OK Alice -> Bob 1638 F13 ACK Bob -> Alice 1640 F14 re-INVITE Alice -> Bob 1642 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1643 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1644 Max-Forwards: 70 1645 From: Alice ;tag=9fxced76sl 1646 To: Bob ;tag=8321234356 1647 Call-ID: 3848276298220188511@atlanta.example.com 1648 CSeq: 3 INVITE 1649 Content-Length: 147 1651 v=0 1652 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1653 s=- 1654 c=IN IP4 192.0.2.101 1655 t=0 0 1656 m=audio 49172 RTP/AVP 0 1657 a=rtpmap:0 PCMU/8000 1658 a=sendonly 1660 /* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE 1661 again after 2.1-4.0 seconds. */ 1663 F15 200 OK Bob -> Alice 1665 F16 ACK Alice -> Bob 1667 3.3.2. UPDATE and re-INVITE crossover 1669 Alice Bob 1670 | | 1671 | INVITE F1 | 1672 |--------------------------->| 1673 | 180 Ringing F2 | 1674 |<---------------------------| 1675 | | 1676 | 200 OK F3 | 1677 |<---------------------------| 1678 | ACK F4 | 1679 |--------------------------->| 1680 | Both Way RTP Media | 1681 |<==========================>| 1682 | | 1683 | UPDATE F5 re-INVITE F6 | 1684 |------------ -------------| 1685 | \ / | 1686 | X | 1687 | / \ | 1688 |<----------- ------------>| 1689 | 491 F8 491 F7 | 1690 | (re-INVITE) (UPDATE) | 1691 |------------ -------------| 1692 | \ / | 1693 | X | 1694 | / \ | 1695 |<----------- ------------>| 1696 | ^ ACK F9 ^ | 1697 |<-|----------------|--------| 1698 | | | | 1699 | |0-2.0 sec | | 1700 | | | | 1701 | v re-INVITE F10 | | 1702 |<------------------|--------| 1703 | 200 OK F11 | | 1704 |-------------------|------->| 1705 | ACK F12 | | 1706 |<------------------|--------| 1707 | | | 1708 | |2.1-4.0 sec 1709 | | | 1710 | UPDATE F13 v | 1711 |--------------------------->| 1712 | 200 OK F14 | 1713 |<---------------------------| 1714 | | 1715 | | 1717 In this scenario, the UPDATE contains an SDP offer, therefore the 1718 UPDATE and re-INVITE are responded with 491 as in the case of "re- 1719 INVITE crossover". When an UPDATE for refresher which doesn't 1720 contain a session description and a re-INVITE crossed each other, 1721 both requests succeed with 200 (491 means that UA have a pending 1722 request). Moreover, the same is equally true for UPDATE crossover. 1723 In the former case where either UPDATE contains a session description 1724 the requests fail with 491, and in the latter cases succeed with 200. 1726 Note: 1727 A 491 response is sent because SDP offer is pending, and 491 is an 1728 error which is related to matters that behave on the session 1729 established by SIP. 1731 Message Details 1733 F1 INVITE Alice -> Bob 1735 F2 180 Ringing Bob -> Alice 1737 F3 200 OK Bob -> Alice 1739 F4 ACK Alice -> Bob 1741 F5 UPDATE Alice -> Bob 1743 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1744 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1745 Max-Forwards: 70 1746 From: Alice ;tag=9fxced76sl 1747 To: Bob ;tag=8321234356 1748 Call-ID: 3848276298220188511@atlanta.example.com 1749 CSeq: 2 UPDATE 1750 Content-Length: 147 1752 v=0 1753 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1754 s=- 1755 c=IN IP4 192.0.2.101 1756 t=0 0 1757 m=audio 49172 RTP/AVP 0 1758 a=rtpmap:0 PCMU/8000 1759 a=sendonly 1761 /* Some detailed messages are shown for the sequence to illustrate 1762 the example messages crossed over each other. */ 1764 F6 re-INVITE Bob -> Alice 1766 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1767 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1768 Session-Expires: 300;refresher=uac 1769 Supported: timer 1770 Max-Forwards: 70 1771 From: Bob ;tag=8321234356 1772 To: Alice ;tag=9fxced76sl 1773 Call-ID: 3848276298220188511@atlanta.example.com 1774 CSeq: 1 INVITE 1775 Content-Length: 0 1777 /* A case where a re-INVITE for a session refresh and a UPDATE for a 1778 call hold are sent at the same time. */ 1780 F7 491 Request Pending (UPDATE) Bob -> Alice 1782 /* Since a re-INVITE is in process, a 491 response are returned. */ 1784 F8 491 Request Pending (re-INVITE) Alice -> Bob 1786 F9 ACK (re-INVITE) Alice -> Bob 1788 F10 re-INVITE Bob -> Alice 1790 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1791 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 1792 Session-Expires: 300;refresher=uac 1793 Supported: timer 1794 Max-Forwards: 70 1795 From: Bob ;tag=8321234356 1796 To: Alice ;tag=9fxced76sl 1797 Call-ID: 3848276298220188511@atlanta.example.com 1798 CSeq: 2 INVITE 1799 Content-Type: application/sdp 1800 Content-Length: 133 1801 v=0 1802 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1803 s=- 1804 c=IN IP4 192.0.2.201 1805 t=0 0 1806 m=audio 3456 RTP/AVP 0 1807 a=rtpmap:0 PCMU/8000 1809 /* Since Bob is not the owner of Call-ID, Bob sends an INVITE again 1810 after 0.0-2.0 seconds. */ 1812 F11 200 OK Alice -> Bob 1814 F12 ACK Bob -> Alice 1816 F13 UPDATE Alice -> Bob 1818 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1819 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1820 Max-Forwards: 70 1821 From: Alice ;tag=9fxced76sl 1822 To: Bob ;tag=8321234356 1823 Call-ID: 3848276298220188511@atlanta.example.com 1824 CSeq: 3 UPDATE 1825 Content-Length: 147 1827 v=0 1828 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1829 s=- 1830 c=IN IP4 192.0.2.101 1831 t=0 0 1832 m=audio 49172 RTP/AVP 0 1833 a=rtpmap:0 PCMU/8000 1834 a=sendonly 1836 /* Since Alice is the owner of the Call-ID, Alice sends the UPDATE 1837 again after 2.1-4.0 seconds. */ 1839 F14 200 OK Bob -> Alice 1841 3.3.3. Receiving REFER (Establish state) in Mortal state 1843 State Alice Bob State 1844 | | 1845 | INVITE F1 | 1846 |----------------------->| 1847 Pre | 180 Ringing F2 | Pre 1848 |<-----------------------| 1849 Ear | | Ear 1850 | 200 OK F3 | 1851 |<-----------------------| 1852 Mora | ACK F4 | Mora 1853 |----------------------->| 1854 Est | Both Way RTP Media | Est 1855 |<======================>| 1856 | | 1857 | BYE F5 REFER F6 | 1858 |--------- ----------| 1859 Mort | \ / | 1860 | X | 1861 | / \ | 1862 *race* |<-------- --------->| 1863 | | Mort 1864 | 481 F8 200 F7 | 1865 | (REFER) (BYE) | 1866 |--------- ----------| 1867 | \ / ^ | 1868 | X | | 1869 | / \ | | 1870 |<-------- --------->| 1871 | ^ | | 1872 | | Timer K | | 1873 | V Timer J | | 1874 Morg | V | 1875 | | Morg 1876 | | 1878 This scenario illustrates the race condition which occurs when UAS 1879 receives an Established message, REFER, in the Mortal state. Bob 1880 sends a REFER, and Alice sends a BYE at the same time. Bob sends the 1881 REFER in the same dialog. Alice's dialog state moves to the Mortal 1882 state at the point of sending BYE. In the Mortal state, UA possesses 1883 dialog information for internal process but dialog shouldn't exist 1884 outwardly. Therefore, UA sends an error response to a REFER which is 1885 transmitted as a mid-dialog request. So, Alice in the Mortal state 1886 sends an error response to the REFER. However, Bob has already 1887 started the SUBSCRIBE usage with REFER, so the dialog continues until 1888 the SUBSCRIBE usage terminates, even though the INVITE dialog usage 1889 terminates by receiving BYE. Bob's behavior in this case needs to 1890 follow the procedure in I-D.ietf-sipping-dialogusage [6]. (For 1891 handling of dialogs with multiple usages see I-D.ietf-sipping- 1892 dialogusage [6].) 1894 Message Details 1896 F1 INVITE Alice -> Bob 1898 F2 180 Ringing Bob -> Alice 1900 F3 200 OK Bob -> Alice 1902 F4 ACK Alice -> Bob 1904 F5 BYE Alice -> Bob 1906 /* Alice sends a BYE request and terminates the session, and transits 1907 from the Confirmed state to Terminated state. */ 1909 F6 REFER Bob -> Alice 1911 /* Alice sends a BYE, and Bob sends a REFER at the same time. Bob 1912 sends the REFER on the INVITE dialog. The dialog state transits 1913 to the Mortal state at the moment Alice sends the BYE, but Bob 1914 doesn't know it until he receives the BYE. A race condition 1915 occurs. */ 1917 F7 200 OK (BYE) Bob -> Alice 1919 F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob 1921 /* Alice in the Mortal state sends a 481 to the REFER. */ 1923 4. IANA Considerations 1925 This document has no actions for IANA. 1927 5. Security Considerations 1929 This document contains clarifications of behavior specified in RFC 1930 3261 [1], RFC 3264 [2] and RFC 3515 [4]. The security considerations 1931 of those documents continue to apply after the application of these 1932 clarifications. 1934 6. Acknowledgements 1936 The authors would like to thank Robert Sparks, Dean Willis, Cullen 1937 Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, Akihiro 1938 Shimizu, Mayumi Munakata, Yasunori Inagaki, Tadaatsu Kidokoro, 1939 Kenichi Hiragi, Dale Worley, Vijay K. Gurbani and Anders Kristensen 1940 for their comments on this document. 1942 7. References 1944 7.1. Normative References 1946 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1947 Peterson, J., Sparks, R., Handley, M., and E. Scooler, "SIP: 1948 Session Initiation Protocol", RFC 3261, June 2002. 1950 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1951 the Session Description Protocol (SDP)", RFC 3264, June 2002. 1953 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1954 Levels", BCP 14, RFC 2119, March 1997. 1956 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1957 Method", RFC 3515, April 2003. 1959 [5] Sparks, R. and H. Schulzrinne, "Reliability of Provisional 1960 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 1961 June 2002. 1963 7.2. Informative References 1965 [6] Sparks, R., "Multiple Dialog Usages in the Session Initiation 1966 Protocol", I-D draft-ietf-sipping-dialogusage-06 (work in 1967 progress), February 2007. 1969 Appendix A. BYE on the Early Dialog 1971 This section, related to Section 3.1.3, explains why BYE is not 1972 recommended in the Early state, illustrating the case in which BYE in 1973 the early dialog triggers confusion. 1975 Alice Proxy Bob Carol 1976 | | | | 1977 | INVITE F1 | | | 1978 |--------------->| INVITE F2 | | 1979 | 100 F3 |----------------->| | 1980 |<---------------| 180(To tag=A) F4 | | 1981 | 180(A) F5 |<-----------------| | 1982 |<---------------| | | 1983 | | INVITE(Fork) F6 | 1984 | |------------------------>| 1985 | | 100 F7 | 1986 | BYE(A) F8 |<------------------------| 1987 |--------------->| BYE(A) F9 | | 1988 | |----------------->| | 1989 | | 200(A,BYE) F10 | | 1990 | 200(A,BYE) F11 |<-----------------| | 1991 |<---------------| 487(A,INV) F12 | | 1992 | |<-----------------| | 1993 | | ACK(A) F13 | | 1994 | |----------------->| | 1995 | | | | 1996 | | | 1997 | | 200(To tag=B) F13 | 1998 | 200(B) F14 |<------------------------| 1999 |<---------------| | 2000 | ACK(B) F15 | | 2001 |--------------->| ACK(B) F16 | 2002 | |------------------------>| 2003 | BYE(B) F17 | | 2004 |--------------->| BYE(B) F18 | 2005 | |------------------------>| 2006 | | 200(B) F19 | 2007 | 200(B) F20 |<------------------------| 2008 |<---------------| | 2009 | | | 2010 | | | 2012 Care is advised in sending BYE in the Early state when forking by a 2013 proxy is expected. In this example, the BYE request progresses 2014 normally, and it succeeds in correctly terminating the dialog with 2015 Bob. After Bob terminates the dialog by receiving the BYE, he sends 2016 487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261 [1], 2017 it is RECOMMENDED for UAS to generate 487 to any pending requests 2018 after receiving BYE. In the example, Bob sends 487 to ini-INVITE 2019 since he receives BYE while the ini-INVITE is in pending state. 2021 However, Alice receives a final response to INVITE (a 200 from Carol) 2022 even though she has successfully terminated the dialog with Bob. This 2023 means that, regardless of the success/failure of the BYE in the Early 2024 state, Alice MUST be prepared for the establishment of a new dialog 2025 until receiving the final response for the INVITE and terminating the 2026 INVITE transaction. 2028 It is not illegal to send BYE in the Early state to terminate a 2029 specific early dialog according to the caller's intent. However, the 2030 choice of BYE or CANCEL in the Early state must be made carefully. 2031 CANCEL is appropriate when the goal is to abandon the call attempt 2032 entirely. BYE is appropriate when the goal is to abandon a 2033 particular early dialog while allowing the call to be completed with 2034 other destinations. When using either BYE or CANCEL the UAC must be 2035 prepared for the possibility that a call may still be established to 2036 one (or more) destinations. 2038 Appendix B. BYE request overlapped on re-INVITE 2040 UAC UAS 2041 | | 2042 The session has been already established 2043 ========================== 2044 | re-INVITE F1 | 2045 |--------------------->| 2046 | BYE F2 | 2047 |--------------------->| 2048 | 200(BYE) F3 | 2049 |<---------------------| 2050 | INVITE F4(=F1) | 2051 |--------------------->| 2052 | | 2053 | | 2055 This case could look similar to the one in Section 3.2.3. However, 2056 it is not a race condition. This case describes the behavior where 2057 there is no response for INVITE for some reasons. The appendix 2058 explains the behavior in such case and its rationale behind, since 2059 this case is likely to cause confusion. 2061 First of all, it is important not to confuse the behavior of the 2062 transaction layer and that of the dialog layer. RFC 3261 [1] details 2063 the transaction layer behavior. The dialog layer behavior is 2064 explained in this document. It has to be noted that these behaviors 2065 are independent of each other, even though the both layers change 2066 their states triggered by sending or receiving of the same SIP 2067 messages (A dialog can be terminated even though a transaction still 2068 remain, and vice versa). 2070 In the sequence above, there is no response for F1, and F2 (BYE) is 2071 sent immediately after F1 (F1 is a mid-dialog request. If F1 was 2072 ini-INVITE, BYE could not be sent before UAC received a provisional 2073 response to the request with To tag). 2075 Below is a figure which illustrates UAC's dialog state and 2076 transaction state. 2078 BYE INV dialog UAC UAS 2079 : | | 2080 : | | 2081 | | re-INVITE F1 | 2082 o | |--------------------->| 2083 | | | BYE F2 | 2084 o | (Mortal) |--------------------->| 2085 | | | | 200(BYE) F3 | 2086 | | | |<---------------------| 2087 | | | | INVITE F4(=F1) | 2088 | | | |--------------------->| 2089 | | | | 481(INV) F5 | 2090 | | | |<---------------------| 2091 | | | | ACK(INV) F6 | 2092 | | | |--------------------->| 2093 | | | | | 2094 o | o | | 2095 | | | 2096 o | | 2097 | | 2099 For UAC, the INVITE client transaction begins at the point F1 is 2100 sent. The UAC sends BYE (F2) immediately after F1. This is a 2101 legitimate behavior. (Usually the usage of each SIP method is 2102 independent, for BYE and others. However, it should be noted that it 2103 is prohibited to send a request with an SDP offer while the previous 2104 offer is in progress.) 2106 After that, F2 triggers the BYE client transaction. At the same 2107 time, the dialog state transits to the Mortal state and then only a 2108 BYE or its response can be handled. 2110 It is permitted to send F4 (a retransmission of INVITE) in the Mortal 2111 state, because the retransmission of F1 is handled by the transaction 2112 layer, and the INVITE transaction has not yet transited to the 2113 Terminated state. As it is mentioned above, the dialog and the 2114 transaction behave independently each other. Therefore the 2115 transaction handling has to be continued even though the dialog moved 2116 to the Terminated state. 2118 Next, UAS's state is shown below. 2120 UAC UAS dialog INV BYE 2121 | | : 2122 | | : 2123 | re-INVITE F1 | | 2124 |-------------->x | | 2125 | BYE F2 | | 2126 |--------------------->| | o 2127 | 200(BYE) F3 | (Mortal) | 2128 |<---------------------| | |<-Start Timer J 2129 | INVITE F4(=F1) | | | 2130 |--------------------->| | o | 2131 | 4xx/5xx(INV) F5 | o | o 2132 |<---------------------| | 2133 | ACK(INV) F6 | | 2134 |--------------------->| |<-Start Timer I 2135 | | | 2136 | | | 2137 | | o 2138 | | 2140 For UAS, it can be regarded that F1 packet is lost or delayed (Here 2141 the behavior is explained for the case UAS receives F2 BYE before F1 2142 INVITE). Therefore, F2 triggers the BYE transaction for UAS, and 2143 simultaneously the dialog moves to the Mortal state. Then, upon the 2144 reception of F4 the INVITE server transaction begins. (It is allowed 2145 to start the INVITE server transaction in the Mortal state. The 2146 INVITE server transaction begins to handle received SIP request 2147 regardless of the dialog state.) UAS's TU sends an appropriate error 2148 response for F4 INVITE, either 481 (because the TU knows that the 2149 dialog which matches to the INVITE is in the Terminated state) or 500 2150 (because the re-sent F4 has an out-of-order CSeq). (It is mentioned 2151 above that F4 (and F1) INVITE is a mid-dialog request. Mid-dialog 2152 requests have a To tag. It should be noted that UAS's TU does not 2153 begin a new dialog upon the reception of INVITE with a To tag.) 2155 Appendix C. UA's behavior for CANCEL 2157 This section explains the CANCEL behaviors which indirectly involve 2158 in the dialog state transition in the Early state. CANCEL does not 2159 have any influence on UAC's dialog state. However, the request has 2160 indirect influence on the dialog state transition because it has a 2161 significant effect on ini-INVITE. For UAS the CANCEL request has 2162 more direct effects on the dialog than the sending of CANCEL by UAC, 2163 because they can be a trigger to send the 487 response. Figure 3 2164 explains UAS's behavior in the Early state. This flow diagram is 2165 only an explanatory figure, and the actual dialog state transition is 2166 as illustrated in Figure 1 and 2. 2168 In the flow, full lines are related to dialog state transition, and 2169 dotted lines are involved with CANCEL. (r) represents the reception 2170 of signaling, and (s) means sending. There is no dialog state for 2171 CANCEL, but here the Cancelled state is virtually handled just for 2172 the ease of understanding of the UA's behavior when it sends and 2173 receives CANCEL. 2175 Below, UAS's flow is explained. 2177 +-------------+ 2178 | Preparative |---+ 2179 +-------------+ | 2180 : | 1xx(s) | 2181 : V | 2182 : +-------+ | 2xx(s) 2183 : | Early |-----+------+ 2184 : +-------+ | 2185 : : V 2186 : : +-----------+ 2187 : : | Confirmed |<... 2188 :.....: +-----------+ : 2189 : | : : 2190 : BYE(r)| : : 2191 : CANCEL(r) | :.......: 2192 V | CANCEL(r) 2193 ............. | 2194 : Cancelled : | 2195 :...........: | 2196 | 487(s) | 2197 | | 2198 +--------------------+ 2199 | 2200 V 2201 +------------+ 2202 | Terminated | 2203 +------------+ 2205 Figure 3. CANCEL flow diagram for UAS 2207 There are two behaviors for UAS depending on the state when it 2208 receives CANCEL. 2210 One is when UAS receives CANCEL in the Early states. In this case 2211 the UAS immediately sends 487 for the INVITE, and the dialog transits 2212 to the Terminated state. 2214 The other is the case in which UAS receives CANCEL in the Confirmed 2215 state. In this case the dialog state transition does not occur 2216 because UAS has already sent a final response to the INVITE to which 2217 the CANCEL is targeted. (Note that, because of UAC's behavior, a UAS 2218 that receives a CANCEL in the Confirmed state can expect to receive a 2219 BYE immediately and move to the Terminated state. However, the UAS's 2220 state does not transit until it actually receives BYE.) 2222 Appendix D. Notes on the request in Mortal state 2224 This section describes UA's behavior in the Mortal state which needs 2225 careful attention. Note that every transaction completes independent 2226 of others, following the principle of RFC 3261 [1]. 2228 In the Mortal state, BYE can be accepted, and the other messages in 2229 the INVITE dialog usage are responded with an error. However, 2230 sending of ACK and the authentication procedure for BYE are conducted 2231 in this state. (The handling of messages concerning multiple dialog 2232 usages is out of the scope of this document. Refer to I-D.ietf- 2233 sipping-dialogusage [6] for further information.) 2235 ACK for error responses is handled by the transaction layer, so the 2236 handling is not related to the dialog state. Unlike the ACK for 2237 error responses, ACK for 2xx responses is a request newly generated 2238 by TU. However, the ACK for 2xx and the ACK for error responses are 2239 both a part of the INVITE transaction, even though their handling 2240 differs (Section 17.1.1.1, RFC 3261 [1]). Therefore, the INVITE 2241 transaction is completed by the three-way handshake, which includes 2242 ACK, even in the Mortal state. 2244 Considering actual implementation, UA needs to keep the INVITE dialog 2245 usage until the Mortal state finishes, so that it is able to send ACK 2246 for a 2xx response in the Mortal state. If a 2xx to INVITE is 2247 received in the Mortal state, the duration of the INVITE dialog usage 2248 will be extended to 64*T1 seconds after the receiving of the 2xx, to 2249 cope with the possible 2xx retransmission. (The duration of the 2xx 2250 retransmission is 64*T1, so the UA need to be prepared to handle the 2251 retransmission for this duration.) However, the UA shall send error 2252 response to other requests, since the INVITE dialog usage in the 2253 Mortal state is kept only for the sending of ACK for 2xx. 2255 BYE authentication procedure shall be processed in the Mortal state. 2256 When authentication is requested by 401 or 407 response, UAC resends 2257 BYE with appropriate credentials. Also UAS handles the 2258 retransmission of the BYE which it requested authentication itself. 2260 Appendix E. Forking and receiving new To tags 2262 This section details the behavior of TU when it receives multiple 2263 responses with a different To tag to ini-INVITE. 2265 When an INVITE is forked inside a SIP network, there is a possibility 2266 that the TU receives multiple responses with a different To tag to 2267 ini-INVITE (See Section 12.1, 13.1, 13.2.2.4, 16.7, 19.3, etc. of RFC 2268 3261 [1]). If the TU receives multiple 1xx responses with a 2269 different To tag, the original DSM forks and a new DSM instance is 2270 created. As a consequence multiple early dialogs are generated. 2272 If one of the multiple early dialogs receives a 2xx response, it 2273 naturally transits to the Confirmed state. No DSM state transition 2274 occurs for the other early dialogs, and their sessions (early media) 2275 terminate. The TU of the UAC terminates the INVITE transaction after 2276 64*T1 seconds starting at the point of receiving the first 2xx 2277 response. Moreover, all mortal early dialogs which do not transit to 2278 the Established state are terminated (See Section 13.2.2.4 of RFC 2279 3261 [1]). By "mortal early dialog" we mean any early dialog that 2280 the UA will terminate when another early dialog is confirmed. 2282 Below is an example sequence in which two 180 responses with a 2283 different To tag are received, and then a 200 response for one of the 2284 early dialogs (dialog A) is received. Dotted lines (..) in sequences 2285 are auxiliary lines to represent the influence on dialog B. 2287 UAC 2288 dialog(A) | INVITE F1 2289 Pre o |-------------------------> 2290 | | 100 F2 2291 | |<------------------------- 2292 | | 180(To tag=A) F3 2293 Ear | |<------------------------- 2294 dialog(B) | | 2295 forked new DSM | | 180(To tag=B) F4 2296 Ear o..........|..........|<------------------------- 2297 | | | 2298 | | | 200(A) F5 2299 terminate->|.....Mora |..........|<------------------------- 2300 early | | ^ | ACK(A) F6 2301 media | Est | | |-------------------------> 2302 | | | | 2303 | | |64*T1 | 2304 | | |(13.2.2.4 of RFC 3261 [1]) 2305 | | | | 2306 | | | | 2307 | | V | 2308 o..........|.(terminate INVITE transaction) 2309 terminated | | 2310 dialog(B) | | 2311 | | 2313 Figure 4. Receiving 1xx responses with different To tags 2315 The figure above shows the DSM inside a SIP TU. Triggered by the 2316 reception of a provisional response with a different To tag (F4 2317 180(To tag=B)), DSM forks and the early dialog B is generated. After 2318 64*T1 seconds after the dialog A receives 200 OK response, the dialog 2319 B, which does not transit to the Established state, terminates. 2321 Next, the behavior of a TU which receives multiple 2xx responses with 2322 a different To tag is explained. When a mortal early dialog, which 2323 did not match the first 2xx response the TU received, receives 2324 another 2xx response which matches its To tag before 64*T1 INVITE 2325 transaction timeout, its DSM state transits to the Confirmed state. 2326 However, the session on the mortal early dialog is terminated when 2327 the TU receives the first 2xx to establish a dialog, so no session is 2328 established for the mortal early dialog. Therefore, when the mortal 2329 early dialog receives a 2xx response, the TU send an ACK and, 2330 immediately after, the TU usually sends a BYE to terminate DSM. (In 2331 special cases, e.g. a UA intends to establish multiple dialogs, the 2332 TU may not send the BYE.) 2334 The handling of the second early dialog after receiving the 200 for 2335 the first dialog is quite appropriate for a typical device, such as a 2336 phone. It is important to note that what is being shown is a 2337 typically useful action and not the only valid one. Some devices 2338 might want to handle things differently. For instance, a conference 2339 focus that has sent out an INVITE that forks may want to accept and 2340 mix all the dialogs it gets. In that case, no early dialog is 2341 treated as mortal. 2343 Below is an example sequence in which two 180 responses with a 2344 different To tag are received and then a 200 response for each of the 2345 early dialogs is received. 2347 UAC 2348 dialog(A) | INVITE F1 2349 Pre o |-----------------------> 2350 | | 100 F2 2351 | |<----------------------- 2352 | | 180(To tag=A) F3 2353 dialog(B) Ear | |<----------------------- 2354 forked new DSM | | 180(To tag=B) F4 2355 Ear o..........|..........|<----------------------- 2356 | | | 2357 | | | 200(A) F5 2358 terminate->|.....Mora |..........|<----------------------- 2359 early | | ^ | ACK(A) F6 2360 media | Est | | |-----------------------> 2361 | | |64*T1 | 2362 | | | | 200(B) F7 2363 Mora |..........|.|........|<----------------------- 2364 | | | | ACK(B) F8 2365 Est |..........|.|........|-----------------------> 2366 | | | | BYE(B) F9 2367 Mort |..........|.|........|-----------------------> 2368 ^ | | | | 200(B) F10 2369 | | | | |<----------------------- 2370 |Timer K | | | 2371 | | | V | 2372 | | | (terminate INVITE transaction) 2373 V | | | 2374 Morg o | | 2375 | | 2377 Figure 5. Receiving 1xx and 2xx responses with different To tags 2379 Below is an example sequence when a TU receives multiple 200 2380 responses with a different To tag before 64*T1 timeout of the INVITE 2381 transaction in the absence of a provisional response. Even though a 2382 TU does not receive provisional response, the TU needs to process the 2383 2xx responses (See Section 13.2.2.4 of RFC 3261 [1]). In that case, 2384 the DSM state is forked at the Confirmed state, and then the TU sends 2385 an ACK for the 2xx response and, immediately after, the TU usually 2386 sends a BYE. (In special cases, e.g. a UA intends to establish 2387 multiple dialogs, the TU may not send the BYE.) 2389 UAC 2390 dialog(A) | INVITE F1 2391 Pre o |-----------------------> 2392 | | 100 F2 2393 | |<----------------------- 2394 | | 180(To tag=A) F3 2395 Ear | |<----------------------- 2396 | | 2397 | | 200(A) F4 2398 Mora |..........|<----------------------- 2399 | ^ | ACK(A) F5 2400 Est | | |-----------------------> 2401 | | | 2402 dialog(B) | |64*T1 | 2403 forked new DSM | | | 200(To tag=B) F6 2404 Mora o..........|.|........|<----------------------- 2405 | | | | ACK(B) F7 2406 Est |..........|.|........|-----------------------> 2407 | | | | BYE(B) F8 2408 Mort |..........|.|........|-----------------------> 2409 ^ | | | | 200(B) F9 2410 | | | | |<----------------------- 2411 | | | V | 2412 |Timer K | (terminate INVITE transaction) 2413 | | | | 2414 V | | | 2415 Morg o | | 2416 | | 2418 Figure 6. Receiving 2xx responses with different To tags 2420 Below is an example sequence in which the option tag 100rel (RFC 3262 2421 [5]) is required by a 180. 2423 If a forking proxy supports 100rel, it transparently transmits to the 2424 UAC a provisional response which contains a Require header with the 2425 value of 100rel. Upon receiving a provisional response with 100rel, 2426 the UAC establishes the early dialog (B) and sends PRACK. (Here, 2427 also, every transaction completes independent of others.) 2429 As Figure. 4, the early dialog (B) terminates at the same time the 2430 INVITE transaction terminates. In the case where a proxy does not 2431 support 100rel, the provisional response will be handled in the usual 2432 way (a provisional response with 100rel is discarded by the proxy, 2433 not to be transmitted to the UAC). 2435 UAC 2436 dialog(A) | INVITE F1 2437 Pre o |-------------------------> 2438 | | 100 F2 2439 | |<------------------------- 2440 | | 180(To tag=A) F3 2441 Ear | |<------------------------- 2442 | | 200(A) F4 2443 Mora |..........|<------------------------- 2444 | ^ | ACK(A) F5 2445 Est | | |-------------------------> 2446 dialog(B) | | | 2447 forked new DSM | | | 180(To tag=B) w/100rel F6 2448 Ear o..........|.|........|<------------------------- 2449 | | | | PRACK(B) F7 2450 | | | |-------------------------> 2451 | | | | 200(B,PRACK) F8 2452 | | | |<------------------------- 2453 | | |64*T1 | 2454 | | |(13.2.2.4 of RFC 3261 [1]) 2455 | | | | 2456 | | | | 2457 | | | | 2458 | | V | 2459 o..........|.(terminate INVITE transaction) 2460 terminated | | 2461 dialog(B) | | 2462 | | 2464 Figure 7. Receiving 1xx responses with different To tags when using 2465 the mechanism for reliable provisional responses (100rel) 2467 Authors' Addresses 2469 Miki Hasebe 2470 NTT-east Corporation 2471 19-2 Nishi-shinjuku 3-chome 2472 Shinjuku-ku, Tokyo 163-8019 2473 JP 2475 Email: hasebe.miki@east.ntt.co.jp 2476 Jun Koshiko 2477 NTT-east Corporation 2478 19-2 Nishi-shinjuku 3-chome 2479 Shinjuku-ku, Tokyo 163-8019 2480 JP 2482 Email: j.koshiko@east.ntt.co.jp 2484 Yasushi Suzuki 2485 NTT-east Corporation 2486 19-2 Nishi-shinjuku 3-chome 2487 Shinjuku-ku, Tokyo 163-8019 2488 JP 2490 Email: suzuki.yasushi@east.ntt.co.jp 2492 Tomoyuki Yoshikawa 2493 NTT-east Corporation 2494 19-2 Nishi-shinjuku 3-chome 2495 Shinjuku-ku, Tokyo 163-8019 2496 JP 2498 Email: tomoyuki.yoshikawa@east.ntt.co.jp 2500 Paul H. Kyzivat 2501 Cisco Systems, Inc. 2502 1414 Massachusetts Avenue 2503 Boxborough, MA 01719 2504 US 2506 Email: pkyzivat@cisco.com 2508 Full Copyright Statement 2510 Copyright (C) The IETF Trust (2007). 2512 This document is subject to the rights, licenses and restrictions 2513 contained in BCP 78, and except as set forth therein, the authors 2514 retain all their rights. 2516 This document and the information contained herein are provided on an 2517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2519 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2520 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2521 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2524 Intellectual Property 2526 The IETF takes no position regarding the validity or scope of any 2527 Intellectual Property Rights or other rights that might be claimed to 2528 pertain to the implementation or use of the technology described in 2529 this document or the extent to which any license under such rights 2530 might or might not be available; nor does it represent that it has 2531 made any independent effort to identify any such rights. Information 2532 on the procedures with respect to rights in RFC documents can be 2533 found in BCP 78 and BCP 79. 2535 Copies of IPR disclosures made to the IETF Secretariat and any 2536 assurances of licenses to be made available, or the result of an 2537 attempt made to obtain a general license or permission for the use of 2538 such proprietary rights by implementers or users of this 2539 specification can be obtained from the IETF on-line IPR repository at 2540 http://www.ietf.org/ipr. 2542 The IETF invites any interested party to bring to its attention any 2543 copyrights, patents or patent applications, or other proprietary 2544 rights that may cover technology that may be required to implement 2545 this standard. Please address the information to the IETF at 2546 ietf-ipr@ietf.org. 2548 Acknowledgment 2550 Funding for the RFC Editor function is provided by the IETF 2551 Administrative Support Activity (IASA).