idnits 2.17.1 draft-ietf-sipping-race-examples-06.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2630. 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 -- 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 (September 23, 2008) is 5691 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) == Outdated reference: A later version (-03) exists of draft-sparks-sip-invfix-02 Summary: 1 error (**), 0 flaws (~~), 3 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: BCP NTT-east Corporation 5 Expires: March 27, 2009 Y. Suzuki 6 NTT Corporation 7 T. Yoshikawa 8 NTT-east Corporation 9 P. Kyzivat 10 Cisco Systems, Inc. 11 September 23, 2008 13 Example calls flows of race conditions in the Session Initiation 14 Protocol (SIP) 15 draft-ietf-sipping-race-examples-06 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on March 27, 2009. 42 Abstract 44 This document gives examples call flows of race conditions in the 45 Session Initiation Protocol (SIP). Race conditions are inherently 46 confusing and difficult to thwart; this document shows the best 47 practices to handle them. The elements in these call flows include 48 SIP User Agents and SIP Proxy Servers. Call flow diagrams and 49 message details are given. 51 Table of Contents 53 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 4 55 1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 4 56 1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 5 57 2. The Dialog State Machine for INVITE dialog usage . . . . . . . 6 58 3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 11 59 3.1. Receiving message in the Moratorium State . . . . . . . . 12 60 3.1.1. Callee receives Initial INVITE retransmission 61 (Preparative state) while in the Moratorium state . . 12 62 3.1.2. Callee receives CANCEL (Early state) when in 63 Moratorium state . . . . . . . . . . . . . . . . . . . 14 64 3.1.3. Callee receives BYE (Early state) while in the 65 Moratorium state . . . . . . . . . . . . . . . . . . . 16 66 3.1.4. Callee receives re-INVITE (Established state) 67 while in the Moratorium state (case 1) . . . . . . . . 18 68 3.1.5. Callee receives re-INVITE (Established state) 69 while in the Moratorium state (case 2) . . . . . . . . 23 70 3.1.6. Callee receives BYE (Established state) while in 71 the Moratorium state . . . . . . . . . . . . . . . . . 27 72 3.2. Receiving message in the Mortal State . . . . . . . . . . 29 73 3.2.1. UA receives BYE (Established state) while in the 74 Mortal state . . . . . . . . . . . . . . . . . . . . . 30 75 3.2.2. UA receives re-INVITE (Established state) while in 76 the Mortal state . . . . . . . . . . . . . . . . . . . 32 77 3.2.3. UA receives 200 OK for re-INVITE (Established 78 state) while in the Mortal state . . . . . . . . . . . 34 79 3.2.4. Callee receives ACK (Moratorium state) while in 80 the Mortal state . . . . . . . . . . . . . . . . . . . 37 81 3.3. Other race conditions . . . . . . . . . . . . . . . . . . 38 82 3.3.1. Re-INVITE crossover . . . . . . . . . . . . . . . . . 38 83 3.3.2. UPDATE and re-INVITE crossover . . . . . . . . . . . . 44 84 3.3.3. Receiving REFER (Established state) while in the 85 Mortal state . . . . . . . . . . . . . . . . . . . . . 48 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 50 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 50 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 51 92 Appendix A. BYE in the Early Dialog . . . . . . . . . . . . . . . 51 93 Appendix B. BYE request overlapping with re-INVITE . . . . . . . 53 94 Appendix C. UA's behavior for CANCEL . . . . . . . . . . . . . . 56 95 Appendix D. Notes on the request in the Mortal state . . . . . . 58 96 Appendix E. Forking and receiving new To tags . . . . . . . . . . 58 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 98 Intellectual Property and Copyright Statements . . . . . . . . . . 65 100 1. Overview 102 The call flows shown in this document were developed in the design of 103 a SIP IP communications network. These examples are of race 104 conditions, which stem from transitions in dialog states; mainly 105 transitions during session establishment after the sending of an 106 INVITE. 108 When implementing SIP, various complex situations may arise. 109 Therefore, it is helpful to provide implementors of the protocol with 110 examples of recommended terminal and server behavior. 112 This document clarifies SIP UA behaviors when messages cross each 113 other as race conditions. By clarifying the operation under race 114 conditions, inconsistent interpretations between implementations are 115 avoided and interoperability is expected to be promoted. 117 It is the hope of the authors that this document will be useful for 118 SIP implementors, designers, and protocol researchers and will help 119 them achieve the goal of a standard implementation of RFC 3261 [1]. 121 These call flows are based on the version 2.0 of SIP defined in RFC 122 3261 [1] with SDP usage as described in RFC 3264 [2]. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in BCP 14, RFC 2119 [3]. 128 1.1. General Assumptions 130 A number of architectural, network, and protocol assumptions underlie 131 the call flows in this document. Note that these assumptions are not 132 requirements. They are outlined in this section so that they may be 133 taken into consideration and help understanding of the call flow 134 examples. 136 These flows do not assume specific underlying transport protocols 137 such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for 138 details of the transport issues for SIP. 140 1.2. Legend for Message Flows 142 Dashed lines (---) and slash lines (/, \) represent signaling 143 messages that are mandatory to the call scenario. (X) represents the 144 crossover of signaling messages. (->x, x<-) indicate that the packet 145 is lost. The arrow indicates the direction of message flow. Double 146 dashed lines (===) represent media paths between network elements. 148 Messages are identified in the figures as F1, F2, etc. These numbers 149 are used for references to the message details that follow the 150 Figure. Comments in the message details are shown in the following 151 form: 153 /* Comments. */ 155 1.3. SIP Protocol Assumptions 157 This document does not prescribe the flows precisely as they are 158 shown, but rather illustrates the principles for best practice. They 159 are best practice usages (orderings, syntax, selection of features 160 for the purpose, or handling of errors) of SIP methods, headers and 161 parameters. Note: The flows in this document must not be copied 162 as-is by implementors because additional annotations have been 163 incorporated into this document for ease of explanation. To sum up, 164 the procedures described in this document represent well-reviewed 165 examples of SIP usage, which exemplify best common practice according 166 to IETF consensus. 168 For reasons of simplicity in reading and editing the document, there 169 are a number of differences between some of the examples and actual 170 SIP messages. For instance, Call-IDs are often replicated, CSeq 171 often begins at 1, header fields are usually shown in the same order, 172 usually only the minimum required header field set is shown, and 173 other headers which would usually be included such as Accept, Allow, 174 etc. are not shown. 176 Actors: 178 Element Display Name URI IP Address 179 ------- ------------ --- ---------- 181 User Agent Alice sip:alice@atlanta.example.com 192.0.2.101 182 User Agent Bob sip:bob@biloxi.example.com 192.0.2.201 183 User Agent Carol sip:carol@chicago.example.com 192.0.2.202 184 Proxy Server ss.atlanta.example.com 192.0.2.111 186 The term "session" is used in this document in the same way it is 187 used in RFC 3261 [1] sections 13-15. (Which differs somewhat from 188 the definition of the term in RFC 3261.) RFC 5057 [6] introduces 189 another term, "invite dialog usage", which is more precisely defined. 190 The term "session" used herein is almost, but not quite, identical to 191 the term "invite dialog usage". The two have differing definitions 192 of when the state ends -- the session ends earlier, when BYE is sent 193 or received. 195 2. The Dialog State Machine for INVITE dialog usage 197 Race conditions are generated when the dialog state of the receiving 198 side differs from that of the sending side. 200 For instance, a race condition occurs when a UAC (User Agent Client) 201 sends a CANCEL in the Early state while the UAS (User Agent Server) 202 is transitioning from the Early state to the Confirmed state by 203 sending a 200 OK to an initial INVITE (indicated as "ini-INVITE" 204 hereafter). The DSM (dialog state machine) for the INVITE dialog 205 usage is presented as follows to help understanding of the UA's 206 behavior in race conditions. 208 The DSM clarifies the UA's behavior by subdividing the dialog state 209 shown in RFC 3261 [1] into various internal states. We call the 210 state before the establishment of a dialog the Preparative state. 211 The Confirmed state is subdivided into two substates, the Moratorium 212 and the Established states, and the Terminated state is subdivided 213 into the Mortal and Morgue states. Messages which are the triggers 214 for the state transitions between these states are indicated with 215 arrows. In this figure, messages which are not related to state 216 transition are omitted. 218 Below are the DSMs, first for the caller and then for the callee. 220 INV +-----------------------------------------------+ 221 --->| Preparative | 222 +-----------------------------------------------+ 223 | | | 224 | 3xx-6xx | 1xx-tag | 2xx 225 | | | 226 | | 1xx-tag | 227 | V w/new tag | 228 | +-----------------+ [new DSM] | 229 | 3xx-6xx | | | (new DSM | 230 +<--------| Early | | instance | 231 | | |<--+ created) | 232 | +-----------------+ | 233 | | | | 2xx w/new tag 234 | | BYE | 2xx | [new DSM] 235 | | +------------>+<-+ | (new DSM 236 | | | | instance 237 +-----C------------C-----+ +-----------C------+ | created) 238 | | Terminated | | | Confirmed | | | 239 | | +<----C---------| | | | 240 | | | | BYE(sr) | | | | 241 | | V | | V | | 242 | 2xx | +-----------+ | | +-----------+ | | 243 | +---C--| |---C-+ | | | | | 244 | | | | Mortal | | | BYE(r)| | Moratorium|<-C--+ 245 | +---C->| |<--C-+ | | | | 246 | ACK | +-----------+ | | +-----------+ | 247 | | | | | | | 248 | | | Timeout | | | ACK | 249 | | | | | | | 250 | V V | | V | 251 | +---------------+ | | +-----------+ | 252 | | | | | | |--C-+ 253 | | Morgue | | | |Established| | | 2xx,ACK 254 | | | | | | |<-C-+ 255 | +---------------+ | | +-----------+ | 256 | | | | 257 +------------------------+ +------------------+ 259 (r): indicates that only reception is allowed. 260 Where (r) is not used as an indicator, "response" means 261 receive, and "request" means send. 262 (sr): indicates that both sending and reception are allowed. 264 Figure 1: DSM for INVITE dialog usage (Caller) 266 Figure 1 represents the caller's DSM for the INVITE dialog usage. 267 The caller MAY send a BYE in the Early state, even though this 268 behavior is not recommended. A BYE sent in the Early state 269 terminates the early dialog using a specific To tag. That is, when a 270 proxy is performing forking, the BYE is only able to terminate the 271 early dialog with a particular UA. If the caller wants to terminate 272 all early dialogs instead of that with a particular UA, it needs to 273 send CANCEL, not BYE. However, it is not illegal to send BYE in the 274 Early state to terminate a specific early dialog if this is to the 275 caller's intent. Moreover, until the caller receives a final 276 response and terminates the INVITE transaction, the caller MUST be 277 prepared to establish a dialog by receiving a new response to the 278 INVITE even if it has already sent a CANCEL or BYE and terminated the 279 dialog (see Appendix A). 281 INV +-----------------------------------------------+ 282 --->| Preparative | 283 +-----------------------------------------------+ 284 | | | 285 | 3xx-6xx | 1xx-tag | 2xx 286 | | | 287 | V | 288 | +------------------+ | 289 | 3xx-6xx | | | 290 +<--------| Early | | 291 | | | | 292 | +------------------+ | 293 | | | | 294 | |BYE/487(INV) | 2xx | 295 | | +------------>+<-+ 296 | | | 297 +-----C------------C-----+ +-----------C------+ 298 | | Terminated | | | Confirmed | | 299 | | +<----C---------| | | 300 | | | | BYE(sr) | | | 301 | | V | | V | 302 | | +------------+ | | +-----------+ | 303 | | | |---C-+ | | |--C-+ 304 | | | Mortal | | | BYE | | Moratorium| | | 2xx 305 | | | |<--C-+ | | |<-C-+ if ACK not 306 | | +------------+ | | +-----------+ | received 307 | | | | | | | 308 | | | Timeout | | | ACK | 309 | | | | | | | 310 | V V | | V | 311 | +---------------+ | | +-----------+ | 312 | | | | | | | | 313 | | Morgue | | | |Established| | 314 | | | | | | | | 315 | +---------------+ | | +-----------+ | 316 | | | | 317 +------------------------+ +------------------+ 319 (sr): indicates that both sending and reception are allowed. 320 Where (sr) is not used as an indicator, "response" means send, 321 and "request" means receive. 323 Figure 2: DSM for INVITE dialog usage (Callee) 325 Figure 2 represents the callee's DSM for the INVITE dialog usage. 326 The figure does not illustrate the state transition related to CANCEL 327 requests. A CANCEL request does not cause a dialog state transition. 328 However, the callee terminates the dialog and triggers the dialog 329 transition by sending 487 immediately after the reception of the 330 CANCEL. This behavior upon the reception of the CANCEL request is 331 further explained in Appendix C. 333 The UA's behavior in each state is as follows. 335 Preparative (Pre): The Preparative state is in effect until the 336 early dialog is established by sending or receiving a provisional 337 response with a To tag after an ini-INVITE is sent or received. 338 The dialog does not yet exist in the Preparative state. If the UA 339 sends or receives a 2xx response, the dialog state transitions 340 from the Preparative to the Moratorium state, which is a substate 341 of the Confirmed state. In addition, if UA sends or receives a 342 3xx-6xx response the dialog state transitions to the Morgue state 343 which is a substate of the Terminated state. Sending an ACK for a 344 3xx-6xx response and retransmissions of 3xx-6xx are not shown on 345 the DSMs because they are sent by the INVITE transaction. 347 Early (Ear): The early dialog is established by sending or receiving 348 a provisional response except 100 Trying. The early dialog exists 349 even though the dialog does not exist in this state yet. The 350 dialog state transitions from the Early to the Moratorium state, a 351 substate of the Confirmed state, by sending or receiving a 2xx 352 response. In addition, the dialog state transitions to the Morgue 353 state, a substate of the Terminated state, by sending or receiving 354 a 3xx-6xx response. Sending an ACK for a 3xx-6xx response and 355 retransmissions of 3xx-6xx are not shown on this DSM because they 356 are automatically processed on the transaction layer and don't 357 influence the dialog state. The UAC may send a CANCEL in the 358 Early state. The UAC may also send a BYE (although it is not 359 recommended). The UAS may send a 1xx-6xx response. The sending 360 or receiving of a CANCEL request does not have a direct influence 361 on the dialog state. The UA's behavior upon the reception of the 362 CANCEL request is explained further in Appendix C. 364 Confirmed (Con): The sending or receiving of a 2xx final response 365 establishes a dialog. The dialog starts in this state. The 366 Confirmed state transitions to the Mortal state, a substate of the 367 Terminated state, by sending or receiving a BYE request. The 368 Confirmed state has two substates, the Moratorium and the 369 Established states, which are different with regard to the 370 messages that UAs are allowed to send. 372 Moratorium (Mora): The Moratorium state is a substate of the 373 Confirmed state and inherits its behavior. The Moratorium state 374 transitions to the Established state by sending or receiving an 375 ACK request. The UAC may send an ACK and the UAS may send a 2xx 376 final response. 378 Established (Est): The Established state is a substate of the 379 Confirmed state and inherits its behavior. Both caller and callee 380 may send various messages which influence a dialog. The caller 381 supports the transmission of ACK to the retransmission of a 2xx 382 response to an ini-INVITE. 384 Terminated (Ter): The Terminated state is subdivided into two 385 substates, the Mortal and Morgue states, to cover the behavior 386 when a dialog is being terminated. In this state, the UA holds 387 information about the dialog which is being terminated. 389 Mortal (Mort): The caller and callee enter the Mortal state by 390 sending or receiving a BYE. The UA MUST NOT send any new requests 391 within the dialog because there is no dialog. (Here the new 392 requests do not include ACK for 2xx and BYE for 401 or 407 as 393 further explained in Appendix D below.) In the Mortal state, BYE 394 can be accepted, and the other messages in the INVITE dialog usage 395 are responded with an error. This addresses the case where a 396 caller and a callee exchange reports about the session when it is 397 being terminated. Therefore the UA possesses dialog information 398 for internal processing but the dialog shouldn't be externally 399 visible. The UA stops managing its dialog state and changes it to 400 the Morgue state, when the BYE transaction is terminated. 402 Morgue (Morg): The dialog no longer exists in this state. The 403 sending or receiving of signaling which influences a dialog is not 404 performed. (A dialog is literally terminated.) The caller and 405 callee enter the Morgue state via the termination of the BYE or 406 INVITE transaction. 408 3. Race Conditions 410 This section details a race condition between two SIP UAs, Alice and 411 Bob. Alice (sip:alice@atlanta.example.com) and Bob 412 (sip:bob@biloxi.example.com) are assumed to be SIP phones or SIP- 413 enabled devices. Only significant signaling is illustrated. Dialog 414 state transitions caused by the sending or receiving of SIP messages 415 are shown and race conditions are indicated by '*race*'. (For 416 abbreviations for the dialog state transitions, refer to Section 2.) 417 '*race*' indicates the moment when a race condition occurs. 419 Examples of race conditions are described below. 421 3.1. Receiving message in the Moratorium State 423 This section shows some examples of call flow race conditions when 424 receiving messages from other states while in the Moratorium state. 426 3.1.1. Callee receives Initial INVITE retransmission (Preparative 427 state) while in the Moratorium state 429 State Alice Bob State 430 | | 431 | ini-INVITE F1 | 432 |------------------------------------>| 433 Pre | 180 F2(Packet loss) | Pre 434 | x<-----------------------| 435 | | Ear 436 | ini-INVITE F4(=F1) 200 F3 | 437 |------------------ --------------| 438 | \ / | Mora 439 | X | 440 | / \ | 441 |<----------------- ------------->| *race* 442 Mora | ACK F5 | 443 |------------------------------------>| 444 Est | | Est 445 | | 447 This scenario illustrates the race condition which occurs when the 448 UAS receives a Preparative message while in the Moratorium state. 449 All provisional responses to the initial INVITE (ini-INVITE F1) are 450 lost, and the UAC retransmits an ini-INVITE (F4). At the same time 451 as this retransmission, the UAS generates a 200 OK (F3) to the ini- 452 INVITE and terminates the INVITE server transaction, according to 453 Section 13.3.1.4 of RFC 3261 [1]. 455 However, it is reported that terminating an INVITE server transaction 456 when sending 200 OK is an essential correction to SIP [7]. 457 Therefore, the INVITE server transaction is not terminated by F3, and 458 the F4 MUST be handled properly as a retransmission. 460 In RFC 3261 [1], it is not specified whether UAS retransmits 200 to 461 the retransmission of ini-INVITE. Considering the retransmission of 462 200 triggered by a timer (the TU keeps retransmitting 200 based on T1 463 and T2 until it receives an ACK), according to Section 13.3.1.4 of 464 RFC 3261 [1], it seems unnecessary to retransmit 200 when the UAS 465 receives the retransmission of ini-INVITE. (For implementation, it 466 does not matter if the UAS sends the retransmission of 200, since the 467 200 does not cause any problem.) 468 Message Details 470 F1 INVITE Alice -> Bob 472 F2 180 Ringing Bob -> Alice 474 /* 180 response is lost and does not reach Alice. */ 476 F3 200 OK Bob -> Alice 478 /* According to Section 13.3.1.4 of RFC 3261 [1], the INVITE server 479 transaction is terminated at this point. However, this has been 480 reported as an essential correction to SIP, and the UAS MUST 481 correctly recognize the ini-INVITE (F4) as a retransmission. */ 483 F4 INVITE (retransmission) Alice -> Bob 485 /* F4 is a retransmission of F1. They are exactly the same INVITE 486 request. For UAs that have not dealt with the correction [7] (an 487 INVITE server transaction is terminated when sending 200 to 488 INVITE), this request does not match the transaction as well as 489 the dialog since it does not have a To tag. However, Bob must 490 recognize the retransmitted INVITE correctly, without treating it 491 as a new INVITE. */ 493 F5 ACK Alice -> Bob 495 3.1.2. Callee receives CANCEL (Early state) when in Moratorium state 497 State Alice Bob State 498 | | 499 | INVITE F1 | 500 |----------------------------->| 501 Pre | 180 Ringing F2 | Pre 502 |<-----------------------------| 503 Ear | | Ear 504 |CANCEL F3 200(INVITE) F4| 505 |------------ -------------| 506 | \ / | Mora 507 | X | 508 | / \ | 509 |<----------- ------------>| *race* 510 Mora | | 511 | ACK F6 200(CANCEL) F5| 512 |------------ -------------| 513 Est | \ / | 514 | X | 515 | / \ | 516 |<----------- ------------>| 517 | | Est 518 | One Way RTP Media | 519 | (Two Way RTP Media possible) | 520 |<=============================| 521 | BYE F7 | 522 |----------------------------->| 523 Mort | 200 F8 | Mort 524 |<-----------------------------| 525 | ^ ^ | 526 | | Timer K | | 527 | V | | 528 Morg | Timer J | | 529 | V | 530 | | Morg 531 | | 533 This scenario illustrates the race condition which occurs when the 534 UAS receives an Early message, CANCEL, while in the Moratorium state. 535 Alice sends a CANCEL and Bob sends a 200 OK response to the initial 536 INVITE message at the same time. As described in the previous 537 section, according to RFC 3261 [1], an INVITE server transaction is 538 supposed to be terminated by a 200 response, but this has been 539 corrected in [7]. 541 This section describes a case in which an INVITE server transaction 542 is not terminated by a 200 response to the INVITE request. In this 543 case, there is an INVITE transaction which the CANCEL request 544 matches, so a 200 response to the request is sent. This 200 response 545 simply means that the next hop receives the CANCEL request 546 (Successful CANCEL (200) does not mean the INVITE was actually 547 canceled). When a UAS has not dealt with the correction [7], the UAC 548 MAY receive a 481 response to the CANCEL since there is no 549 transaction which the CANCEL request matches. This 481 simply means 550 that there is no matching INVITE server transaction and CANCEL is not 551 sent to the next hop. Regardless of the success/failure of the 552 CANCEL, Alice checks the final response to the INVITE, and if she 553 receives 200 to the INVITE request she immediately sends a BYE and 554 terminates the dialog. (Section 15, RFC 3261 [1]) 556 From the time F1 is received by Bob until the time that F8 is sent by 557 Bob, media may be flowing one way from Bob to Alice. From the time 558 that an answer is received by Alice from Bob there is the possibility 559 that media may flow from Alice to Bob as well. However, once Alice 560 has decided to cancel the call, she presumably will not send media, 561 so practically speaking the media stream will remain one way. 563 Message Details 565 F1 INVITE Alice -> Bob 567 F2 180 Ringing Bob -> Alice 569 F3 CANCEL Alice -> Bob 571 /* Alice sends a CANCEL in the Early state. */ 573 F4 200 OK (INVITE) Bob -> Alice 575 /* Alice receives a 200 to INVITE (F1) in the Moratorium state. 576 Alice has the potential to send as well as receive media, but in 577 practice will not send because there is an intent to end the call. 578 */ 580 F5 200 OK (CANCEL) Bob -> Alice 582 /* 200 to CANCEL simply means that the CANCEL was received. The 200 583 response is sent, since this case assumes the correction [7] has 584 been made. If an INVITE server transaction is terminated 585 according to the procedure stated in RFC 3261 [1], UAC MAY receive 586 a 481 response instead of 200. */ 588 F6 ACK Alice -> Bob 590 /* INVITE is successful, and the CANCEL becomes invalid. Bob 591 establishes RTP streams. However, the next BYE request 592 immediately terminates the dialog and session. */ 594 F7 BYE Alice -> Bob 596 F8 200 OK Bob -> Alice 598 3.1.3. Callee receives BYE (Early state) while in the Moratorium state 600 State Alice Bob State 601 | | 602 | ini-INVITE F1 | 603 |------------------------------->| 604 Pre | 180 F2 | Pre 605 |<-------------------------------| 606 Ear | | Ear 607 | BYE F4 200(INVITE) F3| 608 |------------- --------------| 609 Mort | \ / | Mora 610 | X | 611 | / \ | 612 |<------------ ------------->| *race* 613 | | Mort 614 | ACK F5 200(BYE) F6 | 615 |------------- --------------| 616 | \ / ^ | 617 | X | | 618 | / \ | | 619 |<------------ ------------->| 620 | ^ | | 621 | | Timer K | | 622 | V | | 623 Morg | Timer J | | 624 | V | 625 | | Morg 626 | | 628 This scenario illustrates the race condition which occurs when UAS 629 receives an Early message, BYE, while in the Moratorium state. Alice 630 sends a BYE in the Early state and Bob sends a 200 OK to the initial 631 INVITE request at the same time. Bob receives the BYE in the 632 Confirmed dialog state although Alice sent the request in the Early 633 state (As explained in Section 2 and Appendix A, this behavior is not 634 recommended). When a proxy is performing forking, the BYE is only 635 able to terminate the early dialog with a particular UA. If the 636 caller wants to terminate all early dialogs instead of only that with 637 a particular UA, it needs to send CANCEL, not BYE. However, it is 638 not illegal to send BYE in the Early state to terminate a specific 639 early dialog if that is the caller's intent. 641 The BYE functions normally even if it is received after the INVITE 642 transaction termination because BYE differs from CANCEL, and is sent 643 not to the request but to the dialog. Alice enters the Mortal state 644 on sending the BYE request, and remains Mortal until the Timer K 645 timeout occurs. In the Mortal state, the UAC does not establish a 646 session, even though it receives a 200 response to the INVITE. Even 647 so, the UAC sends an ACK to 200 in order to complete the INVITE 648 transaction. The ACK is always sent to complete the three-way 649 handshake of the INVITE transaction (Further explained in Appendix D 650 below). 652 Message Details 654 F1 INVITE Alice -> Bob 656 F2 180 Ringing Bob -> Alice 658 F3 200 OK (ini-INVITE) Bob -> Alice 660 F4 BYE Alice -> Bob 662 /* Alice transitions to the Mortal state upon sending BYE. 663 Therefore, after this, she does not begin a session even though 664 she receives a 200 response with an answer. */ 666 F5 ACK Alice -> Bob 668 F6 200 OK (BYE) Bob -> Alice 670 3.1.4. Callee receives re-INVITE (Established state) while in the 671 Moratorium state (case 1) 673 State Alice Bob State 674 | | 675 | ini-INVITE w/offer1 F1 | 676 |------------------------------->| 677 Pre | 180 F2 | Pre 678 |<-------------------------------| 679 Ear | | Ear 680 | 200(ini-INV) w/answer1 F3 | 681 |<-------------------------------| 682 Mora | ACK F4(packet loss) | Mora 683 |-------------------->x | 684 Est | | 685 | re-INVITE F6 200 F5(=F3) | 686 | w/offer2 w/answer1 | 687 |------------- --------------| 688 | \ / | 689 | X | 690 | / \ | 691 |<------------ ------------->| *race* 692 | 200(re-INV) F8| 693 | ACK F7(=F4) w/answer2 | 694 |------------- --------------| 695 | \ / | 696 | X | 697 | / \ | 698 |<------------ ------------->| 699 | ACK (re-INV) F9 | Est 700 |------------------------------->| 701 | | 702 | | 704 This scenario illustrates the race condition which occurs when a UAS 705 in the Moratorium state receives a re-INVITE sent by a UAC in the 706 Established state. 708 The UAS receives a re-INVITE (with offer2) before receiving an ACK 709 for ini-INVITE (with offer1). The UAS sends a 200 OK (with answer2) 710 to the re-INVITE (F8) because it has sent a 200 OK (with answer1) to 711 the ini-INVITE (F3, F5) and the dialog has already been established. 712 (Because F5 is a retransmission of F3, SDP negotiation is not 713 performed here.) 715 As can be seen in Section 3.3.2 below, the 491 response seems to be 716 closely related to session establishment, even in cases other than 717 INVITE cross-over. This example recommends that 200 be sent instead 718 of 491 because it does not have an influence on the session. 719 However, a 491 response can also lead to the same outcome, so either 720 response can be used. 722 Moreover, if UAS doesn't receive an ACK for a long time, it should 723 send a BYE and terminate the dialog. Note that ACK F7 has the same 724 CSeq number as ini-INVITE F1 (See Section 13.2.2.4 of RFC 3261 [1]). 725 The UA should not reject or drop the ACK on grounds of the CSeq 726 number. 728 Note: Implementation issues are outside the scope of this document, 729 but this note provides a tip for avoiding race conditions of this 730 type. That is for the caller to delay sending re-INVITE F6 for some 731 period of time (2 seconds, perhaps), after which the caller can 732 reasonably assume that its ACK has been received. Implementors can 733 decouple the actions of the user (e.g. pressing the hold button) from 734 the actions of the protocol (the sending of re-INVITE F6), so that 735 the UA can behave like this. In this case, it is the implementor's 736 choice as to how long to wait. In most cases, such an implementation 737 may be useful to prevent the type of race condition shown in this 738 section. This document expresses no preference about whether or not 739 they should wait for an ACK to be delivered. After considering the 740 impact on users experience, implementors should decide whether to 741 wait for a while or not, because the user experience depends on the 742 implementation and has no direct bearing on protocol behaviour. 744 Message Details 746 F1 INVITE Alice -> Bob 748 INVITE sip:bob@biloxi.example.com SIP/2.0 749 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 750 Max-Forwards: 70 751 From: Alice ;tag=9fxced76sl 752 To: Bob 753 Call-ID: 3848276298220188511@atlanta.example.com 754 CSeq: 1 INVITE 755 Contact: 756 Content-Type: application/sdp 757 Content-Length: 137 759 v=0 760 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 761 s=- 762 c=IN IP4 192.0.2.101 763 t=0 0 764 m=audio 49172 RTP/AVP 0 765 a=rtpmap:0 PCMU/8000 767 /* Detailed messages are shown for the sequence to illustrate the 768 offer and answer examples. */ 770 F2 180 Ringing Bob -> Alice 772 SIP/2.0 180 Ringing 773 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 774 ;received=192.0.2.101 775 From: Alice ;tag=9fxced76sl 776 To: Bob ;tag=8321234356 777 Call-ID: 3848276298220188511@atlanta.example.com 778 CSeq: 1 INVITE 779 Contact: 780 Content-Length: 0 782 F3 200 OK Bob -> Alice 784 SIP/2.0 200 OK 785 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 786 ;received=192.0.2.101 787 From: Alice ;tag=9fxced76sl 788 To: Bob ;tag=8321234356 789 Call-ID: 3848276298220188511@atlanta.example.com 790 CSeq: 1 INVITE 791 Contact: 792 Content-Type: application/sdp 793 Content-Length: 133 795 v=0 796 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 797 s=- 798 c=IN IP4 192.0.2.201 799 t=0 0 800 m=audio 3456 RTP/AVP 0 801 a=rtpmap:0 PCMU/8000 803 F4 ACK Alice -> Bob 805 ACK sip:bob@client.biloxi.example.com SIP/2.0 806 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 807 Max-Forwards: 70 808 From: Alice ;tag=9fxced76sl 809 To: Bob ;tag=8321234356 810 Call-ID: 3848276298220188511@atlanta.example.com 811 CSeq: 1 ACK 812 Content-Length: 0 814 /* ACK request is lost. */ 816 F5(=F3) 200 OK Bob -> Alice (retransmission) 818 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 819 received an ACK. */ 821 F6 re-INVITE Alice -> Bob 823 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 824 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 825 Max-Forwards: 70 826 From: Alice ;tag=9fxced76sl 827 To: Bob ;tag=8321234356 828 Call-ID: 3848276298220188511@atlanta.example.com 829 CSeq: 2 INVITE 830 Content-Length: 147 832 v=0 833 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 834 s=- 835 c=IN IP4 192.0.2.101 836 t=0 0 837 m=audio 49172 RTP/AVP 0 838 a=rtpmap:0 PCMU/8000 839 a=sendonly 841 F7(=F4) ACK Alice -> Bob (retransmission) 843 /* "(=F4)" of ACK F7 shows that it is equivalent to F4 in that it is 844 an ACK for F3. This doesn't mean that F4 and F7 must be equal in 845 Via-branch value. Although it is ambiguous whether Via-branch of 846 ACK F7 differs from F4 in RFC3261, it doesn't affect UAS's 847 behavior. */ 849 F8 200 OK (re-INVITE) Bob -> Alice 851 SIP/2.0 200 OK 852 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 853 Max-Forwards: 70 854 From: Alice ;tag=9fxced76sl 855 To: Bob ;tag=8321234356 856 Call-ID: 3848276298220188511@atlanta.example.com 857 CSeq: 2 INVITE 858 Content-Length: 143 860 v=0 861 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com 862 s=- 863 c=IN IP4 192.0.2.201 864 t=0 0 865 m=audio 3456 RTP/AVP 0 866 a=rtpmap:0 PCMU/8000 867 a=recvonly 869 F9 ACK (re-INVITE) Alice -> Bob 871 ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 872 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21 873 Max-Forwards: 70 874 From: Alice ;tag=9fxced76sl 875 To: Bob ;tag=8321234356 876 Call-ID: 3848276298220188511@atlanta.example.com 877 CSeq: 2 ACK 878 Content-Length: 0 880 3.1.5. Callee receives re-INVITE (Established state) while in the 881 Moratorium state (case 2) 883 State Alice Bob State 884 | | 885 | ini-INVITE (no offer) F1 | 886 |------------------------------->| 887 Pre | 180 F2 | Pre 888 |<-------------------------------| 889 Ear | | Ear 890 | 200(ini-INV) w/offer1 F3 | 891 |<-------------------------------| 892 Mora | ACK w/answer1 F4(packet loss) | Mora 893 |-------------------->x | 894 Est | | 895 | re-INVITE F6 200 F5(=F3) | 896 | w/offer2 w/offer1 | 897 |------------- --------------| 898 | \ / | 899 | X | 900 | / \ | 901 |<------------ ------------->| 902 | ACK F7(=F4) 491(re-INV) F8| 903 |------------- --------------| 904 | \ / | 905 | X | 906 | / \ | 907 |<------------ ------------->| 908 | ACK (re-INV) F9 | Est 909 |------------------------------->| 910 | | 911 | | 913 This scenario is basically the same as that of Section 3.1.4, but 914 differs in sending an offer in the 200 and an answer in the ACK. In 915 contrast to the previous case, the offer in the 200 (F3) and the 916 offer in the re-INVITE (F6) collide with each other. 918 Bob sends a 491 to the re-INVITE (F6) since he is not able to 919 properly handle a new request until he receives an answer. (Note: 920 500 with Retry-After header may be returned, if the 491 response is 921 understood to indicate request collision. However, 491 is 922 recommended here because 500 applies to so many cases that it is 923 difficult to determine what the real problem was.) The same result 924 will be reached if F6 is an UPDATE with offer. 926 Note: As noted in Section 3.1.4, caller may delay sending a re-INVITE 927 F6 for some period of time (2 seconds, perhaps), after which the 928 caller may reasonably assume that its ACK has been received, to 929 prevent this type of race condition. This document expresses no 930 preference about whether or not they should wait for an ACK to be 931 delivered. After considering the impact on users experience, 932 implementors should decide whether to wait for a while or not, 933 because the user experience depends on the implementation and has no 934 direct bearing on protocol behaviour. 936 Message Details 938 F1 INVITE Alice -> Bob 940 INVITE sip:bob@biloxi.example.com SIP/2.0 941 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 942 Max-Forwards: 70 943 From: Alice ;tag=9fxced76sl 944 To: Bob 945 Call-ID: 3848276298220188511@atlanta.example.com 946 CSeq: 1 INVITE 947 Contact: 948 Content-Length: 0 950 /* The request does not contain an offer. Detailed messages are 951 shown for the sequence to illustrate offer and answer examples. 952 */ 954 F2 180 Ringing Bob -> Alice 956 F3 200 OK Bob -> Alice 958 SIP/2.0 200 OK 959 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 960 ;received=192.0.2.101 961 From: Alice ;tag=9fxced76sl 962 To: Bob ;tag=8321234356 963 Call-ID: 3848276298220188511@atlanta.example.com 964 CSeq: 1 INVITE 965 Contact: 966 Content-Type: application/sdp 967 Content-Length: 133 969 v=0 970 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 971 s=- 972 c=IN IP4 192.0.2.201 973 t=0 0 974 m=audio 3456 RTP/AVP 0 975 a=rtpmap:0 PCMU/8000 977 /* An offer is made in 200. */ 979 F4 ACK Alice -> Bob 981 ACK sip:bob@client.biloxi.example.com SIP/2.0 982 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 983 Max-Forwards: 70 984 From: Alice ;tag=9fxced76sl 985 To: Bob ;tag=8321234356 986 Call-ID: 3848276298220188511@atlanta.example.com 987 CSeq: 1 ACK 988 Content-Type: application/sdp 989 Content-Length: 137 991 v=0 992 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 993 s=- 994 c=IN IP4 192.0.2.101 995 t=0 0 996 m=audio 49172 RTP/AVP 0 997 a=rtpmap:0 PCMU/8000 999 /* The request contains an answer, but the request is lost. */ 1001 F5(=F3) 200 OK Bob -> Alice (retransmission) 1003 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 1004 received an ACK. */ 1006 F6 re-INVITE Alice -> Bob 1008 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1009 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1010 Max-Forwards: 70 1011 From: Alice ;tag=9fxced76sl 1012 To: Bob ;tag=8321234356 1013 Call-ID: 3848276298220188511@atlanta.example.com 1014 CSeq: 2 INVITE 1015 Content-Length: 147 1017 v=0 1018 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1019 s=- 1020 c=IN IP4 192.0.2.101 1021 t=0 0 1022 m=audio 49172 RTP/AVP 0 1023 a=rtpmap:0 PCMU/8000 1024 a=sendonly 1026 /* The request contains an offer. */ 1028 F7(=F4) ACK Alice -> Bob (retransmission) 1030 /* A retransmission triggered by the reception of a retransmitted 1031 200. "(=F4)" of ACK F7 shows that it is equivalent to the F4 in 1032 that it is an ACK for F3. This doesn't mean that F4 and F7 are 1033 necessarily equal in Via-branch value. Although it is ambiguous 1034 whether Via-branch of ACK F7 differs from F4 in RFC3261, it 1035 doesn't affect UAS's behavior. */ 1037 F8 491 (re-INVITE) Bob -> Alice 1039 /* Bob sends 491 (Request Pending), since Bob has a pending offer. 1040 */ 1042 F9 ACK (re-INVITE) Alice -> Bob 1044 3.1.6. Callee receives BYE (Established state) while in the Moratorium 1045 state 1047 State Alice Bob State 1048 | | 1049 | INVITE F1 | 1050 |-------------------------->| 1051 Pre | 180 Ringing F2 | Pre 1052 |<--------------------------| 1053 Ear | | Ear 1054 | 200 OK F3 | 1055 |<--------------------------| 1056 Mora | ACK F4(packet loss) | Mora 1057 |--------------->x | 1058 Est | Both Way RTP Media | 1059 |<=========================>| 1060 | BYE F6 200 F5(=F3)| 1061 |----------- -----------| 1062 Mort | \ / | 1063 | X | 1064 | / \ | 1065 |<---------- ---------->| *race* 1066 |ACK F7(=F4) 200(BYE) F8| Mort 1067 |----------- -----------| 1068 | \ / | 1069 | X | 1070 | / \ | 1071 |<---------- ---------->| 1072 | ^ ^ | 1073 | | Timer K | | 1074 | V | | 1075 Morg | Timer J | | 1076 | V | 1077 | | Morg 1078 | | 1080 This scenario illustrates the race condition which occurs when the 1081 UAS receives an Established message, BYE, while in the Moratorium 1082 state. An ACK request for a 200 OK response is lost (or delayed). 1083 Bob retransmits the 200 OK to the ini-INVITE, and at the same time 1084 Alice sends a BYE request and terminates the session. Upon receipt 1085 of retransmitted 200 OK Alice's UA might be inclined to reestablish 1086 the session. But that is wrong - the session should not be 1087 reestablished when the dialog is in the Mortal state. Moreover, in 1088 the case where the UAS sends an offer in a 200 OK, the UAS should not 1089 start a session again, for the same reason, if the UAS receives a 1090 retransmitted ACK after receiving a BYE. 1092 Note: As noted in Section 3.1.4, implementation issues are outside 1093 the scope of this document, but this note provides a tip for avoiding 1094 race conditions of this type. That is for the caller to delay 1095 sending BYE F6 for some period of time (2 seconds, perhaps), after 1096 which the caller can reasonably assume that its ACK has been 1097 received. Implementors can decouple the actions of the user (e.g. 1098 hanging up) from the actions of the protocol (the sending of BYE F6), 1099 so that the UA can behave like this. In this case, it is the 1100 implementor's choice as to how long to wait. In most cases, such an 1101 implementation may be useful to prevent the type of race condition 1102 shown in this section. This document expresses no preference about 1103 whether or not they should wait for an ACK to be delivered. After 1104 considering the impact on users experience, implementors should 1105 decide whether to wait for a while or not, because the user 1106 experience depends on the implementation and has no direct bearing on 1107 protocol behaviour. 1109 Message Details 1111 F1 INVITE Alice -> Bob 1113 F2 180 Ringing Bob -> Alice 1115 F3 200 OK Bob -> Alice 1117 F4 ACK Alice -> Bob 1119 /* ACK request is lost. */ 1121 F5(=F3) 200 OK Bob -> Alice 1123 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 1124 received an ACK. */ 1126 F6 BYE Alice -> Bob 1128 /* Bob retransmits a 200 OK and Alice sends a BYE at the same time. 1129 Alice transitions to the Mortal state, so she does not begin a 1130 session after this even though she receives a 200 response to the 1131 re-INVITE. */ 1133 F7(=F4) ACK Alice -> Bob 1135 /* "(=F4)" of ACK F7 shows that it is equivalent to the F4 in that it 1136 is an ACK for F3. This doesn't mean that F4 and F7 must be equal 1137 in Via-branch value. Although it is ambiguous whether Via-branch 1138 of ACK F7 differs from F4 in RFC3261, it doesn't affect UAS's 1139 behavior. */ 1141 F8 200 OK (BYE) Bob -> Alice 1143 /* Bob sends a 200 OK to the BYE. */ 1145 3.2. Receiving message in the Mortal State 1147 This section shows some examples of call flow race conditions when 1148 receiving messages from other states while in the Mortal state. 1150 3.2.1. UA receives BYE (Established state) while in the Mortal state 1152 State Alice Bob State 1153 | | 1154 | INVITE F1 | 1155 |----------------------->| 1156 Pre | 180 Ringing F2 | Pre 1157 |<-----------------------| 1158 Ear | | Ear 1159 | 200 OK F3 | 1160 |<-----------------------| 1161 Mora | ACK F4 | Mora 1162 |----------------------->| 1163 Est | Both Way RTP Media | Est 1164 |<======================>| 1165 | | 1166 | BYE F5 BYE F6 | 1167 |--------- ----------| 1168 Mort | \ / | Mort 1169 | X | 1170 | / \ | 1171 |<-------- --------->| *race* 1172 | | 1173 | 200 F8 200 F7 | 1174 |--------- ----------| 1175 | \ / | 1176 | X | 1177 | / \ | 1178 |<-------- --------->| 1179 | ^ ^ | 1180 | | Timer K | | 1181 | V | | 1182 Morg | Timer J | | 1183 | V | 1184 | | Morg 1185 | | 1187 This scenario illustrates the race condition which occurs when the 1188 UAS receives an Established message, BYE, while in the Mortal state. 1189 Alice and Bob send a BYE at the same time. A dialog and session are 1190 ended shortly after a BYE request is passed to a client transaction. 1191 As shown in Section 2, the UA remains in the Mortal state. 1193 UAs in the Mortal state return error responses to the requests that 1194 operate within a dialog or session, such as re-INVITE, UPDATE, or 1195 REFER. However, the UA shall return 200 OK to the BYE taking the use 1196 case into consideration where a caller and a callee exchange reports 1197 about the session when it is being terminated. (Since the dialogue 1198 and the session both terminate when a BYE is sent, the choice of 1199 sending a 200 or an error response upon receiving a BYE while in the 1200 Mortal state does not affect the resulting termination. Therefore, 1201 even though this example uses a 200 response, other responses can 1202 also be used.) 1204 Message Details 1206 F1 INVITE Alice -> Bob 1208 F2 180 Ringing Bob -> Alice 1210 F3 200 OK Bob -> Alice 1212 F4 ACK Alice -> Bob 1214 F5 BYE Alice -> Bob 1216 /* The session is terminated at the moment Alice sends a BYE. The 1217 dialog still exists then, but it is certain to be terminated in a 1218 short period of time. The dialog is completely terminated when 1219 the timeout of the BYE request occurs. */ 1221 F6 BYE Bob -> Alice 1223 /* Bob has also transmitted a BYE simultaneously with Alice. Bob 1224 terminates the session and the dialog. */ 1226 F7 200 OK Bob -> Alice 1228 /* Since the dialog is in the Moratorium state, Bob responds with a 1229 200 to the BYE request. */ 1231 F8 200 OK Alice -> Bob 1233 /* Since Alice has transitioned from the Established state to the 1234 Mortal state by sending a BYE, Alice responds with a 200 to the 1235 BYE request. */ 1237 3.2.2. UA receives re-INVITE (Established state) while in the Mortal 1238 state 1240 State Alice Bob State 1241 | | 1242 | INVITE F1 | 1243 |----------------------->| 1244 Pre | 180 Ringing F2 | Pre 1245 |<-----------------------| 1246 Ear | | Ear 1247 | 200 OK F3 | 1248 |<-----------------------| 1249 Mora | ACK F4 | Mora 1250 |----------------------->| 1251 Est | Both Way RTP Media | Est 1252 |<======================>| 1253 | | 1254 | BYE F5 re-INVITE F6| 1255 |--------- ----------| 1256 Mort | \ / | 1257 | X | 1258 | / \ | 1259 *race* |<-------- --------->| 1260 | | Mort 1261 | 481 F8 200 F7 | 1262 | (re-INV) (BYE) | 1263 |--------- ----------| 1264 | \ / |^ 1265 | X || 1266 | / \ ||Timer J 1267 |<-------- --------->|| 1268 ^| ACK (re-INV) F9 || 1269 ||<-----------------------|| 1270 Timer K|| || 1271 V| || 1272 Morg | |V 1273 | | Morg 1274 | | 1276 This scenario illustrates the race condition which occurs when the 1277 UAS receives an Established message, re-INVITE, while in the Mortal 1278 state. Bob sends a re-INVITE, and Alice sends a BYE at the same 1279 time. The re-INVITE receives a 481 response, since the TU of Alice 1280 has transitioned from the Established state to the Mortal state by 1281 sending BYE. Bob sends an ACK for the 481 response, because the ACK 1282 for error responses is handled by the transaction layer and at the 1283 point of receiving the 481 the INVITE client transaction still 1284 remains (even though the dialog has been terminated). 1286 Message Details 1288 F1 INVITE Alice -> Bob 1290 F2 180 Ringing Bob -> Alice 1292 F3 200 OK Bob -> Alice 1294 F4 ACK Alice -> Bob 1296 F5 BYE Alice -> Bob 1298 /* Alice sends a BYE and terminates the session, and transitions from 1299 the Established state to the Mortal state. */ 1301 F6 re-INVITE Bob -> Alice 1303 /* Alice sends a BYE, and Bob sends a re-INVITE at the same time. 1304 The dialog state transitions to the Mortal state at the moment 1305 Alice sends the BYE, but Bob does not know this until he receives 1306 the BYE. Therefore, the dialog is in the Terminated state from 1307 Alice's point of view, but in the Confirmed state from Bob's point 1308 of view. A race condition occurs. */ 1310 F7 200 OK (BYE) Bob -> Alice 1312 F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob 1314 /* Since Alice is in the Mortal state, she responds with a 481 to the 1315 re-INVITE. */ 1317 F9 ACK (re-INVITE) Bob -> Alice 1319 /* ACK for an error response is handled by Bob's INVITE client 1320 transaction. */ 1322 3.2.3. UA receives 200 OK for re-INVITE (Established state) while in 1323 the Mortal state 1325 State Alice Bob State 1326 | | 1327 | INVITE F1 | 1328 |----------------------->| 1329 Pre | 180 Ringing F2 | Pre 1330 |<-----------------------| 1331 Ear | | Ear 1332 | 200 OK F3 | 1333 |<-----------------------| 1334 Mora | ACK F4 | Mora 1335 |----------------------->| 1336 Est | Both Way RTP Media | Est 1337 |<======================>| 1338 | | 1339 | re-INVITE F5 | 1340 |<-----------------------| 1341 | 200 F7 BYE F6 | 1342 |--------- ----------| 1343 | \ / | Mort 1344 | X | 1345 | / \ | 1346 |<-------- --------->| *race* 1347 Mort | 200 F8 ACK F9 | 1348 | (BYE) (re-INV) | 1349 |--------- ----------| 1350 | ^ \ / | 1351 | | X | 1352 | | / \ | 1353 |<-------- --------->| 1354 | | ^ | 1355 | | Timer K | | 1356 | | V | 1357 | | Timer J | Morg 1358 | V | 1359 Morg | | 1360 | | 1362 This scenario illustrates the race condition which occurs when the 1363 UAS receives an Established message, 200 to a re-INVITE, while in the 1364 Mortal state. Bob sends a BYE immediately after sending a re-INVITE. 1365 (For example, in the case of a telephone application, it is possible 1366 that a user hangs up the phone immediately after refreshing the 1367 session.) Bob sends an ACK for a 200 response to INVITE while in the 1368 Mortal state, completing the INVITE transaction. 1370 Note: As noted in Section 3.1.4, implementation issues are outside 1371 the scope of this document, but this note provides a tip for avoiding 1372 race conditions of this type. That is for the UAC to delay sending a 1373 BYE F6 until the re-INVITE transaction F5 completes. Implementors 1374 can decouple the actions of the user (e.g. hanging up) from the 1375 actions of the protocol (the sending of BYE F6), so that the UA can 1376 behave like this. In this case, it is the implementor's choice as to 1377 how long to wait. In most cases, such an implementation may be 1378 useful in preventing the type of race condition described in this 1379 section. This document expresses no preference about whether or not 1380 they should wait for an ACK to be delivered. After considering the 1381 impact on users experience, implementors should decide whether to 1382 wait for a while or not, because the user experience depends on the 1383 implementation and has no direct bearing on protocol behaviour. 1385 Message Details 1387 F1 INVITE Alice -> Bob 1389 F2 180 Ringing Bob -> Alice 1391 F3 200 OK Bob -> Alice 1393 F4 ACK Alice -> Bob 1395 F5 re-INVITE Bob -> Alice 1397 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1398 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1399 Session-Expires: 300;refresher=uac 1400 Supported: timer 1401 Max-Forwards: 70 1402 From: Bob ;tag=8321234356 1403 To: Alice ;tag=9fxced76sl 1404 Call-ID: 3848276298220188511@atlanta.example.com 1405 CSeq: 1 INVITE 1406 Content-Length: 0 1408 /* Some detailed messages are shown for the sequence to illustrate 1409 that the re-INVITE is handled in the usual manner in the Mortal 1410 state. */ 1412 F6 BYE Bob -> Alice 1414 /* Bob sends BYE immediately after sending the re-INVITE. Bob 1415 terminates the session and transitions from the Established state 1416 to the Mortal state. */ 1418 F7 200 OK (re-INVITE) Alice -> Bob 1420 SIP/2.0 200 OK 1421 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7 1422 ;received=192.0.2.201 1423 Require: timer 1424 Session-Expires: 300;refresher=uac 1425 From: Bob ;tag=8321234356 1426 To: Alice ;tag=9fxced76sl 1427 Call-ID: 3848276298220188511@atlanta.example.com 1428 CSeq: 1 INVITE 1429 Content-Length: 0 1431 /* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE. 1432 A race condition occurs. */ 1434 F8 200 OK (BYE) Alice -> Bob 1436 F9 ACK (re-INVITE) Bob -> Alice 1438 ACK sip:alice@client.atlanta.example.com SIP/2.0 1439 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44 1440 Max-Forwards: 70 1441 From: Bob ;tag=8321234356 1442 To: Alice ;tag=9fxced76sl 1443 Call-ID: 3848276298220188511@atlanta.example.com 1444 CSeq: 2 ACK 1445 Content-Length: 0 1447 /* Bob sends ACK in the Mortal state to complete the three-way 1448 handshake of the INVITE transaction. */ 1450 3.2.4. Callee receives ACK (Moratorium state) while in the Mortal state 1452 State Alice Bob State 1453 | | 1454 | ini-INVITE F1 | 1455 |------------------------------->| 1456 Pre | 180 F2 | Pre 1457 |<-------------------------------| 1458 Ear | 200 F3 | Ear 1459 |<-------------------------------| 1460 Mora | | Mora 1461 | ACK F4 BYE F5 | 1462 |------------- --------------| 1463 Est | \ / | Mort 1464 | X | 1465 | / \ | 1466 |<------------ ------------->| *race* 1467 Mort | 200 F6 | 1468 |------------------------------->| 1469 | ^ ^ | 1470 | | Timer K | | 1471 | | V | 1472 | | Timer J | Morg 1473 | V | 1474 Morg | | 1475 | | 1477 This scenario illustrates the race condition which occurs when the 1478 UAS receives an Established message, ACK to 200, while in the Mortal 1479 state. Alice sends an ACK and Bob sends a BYE at the same time. 1480 When the offer is in a 2xx, and the answer is in an ACK, there is a 1481 race condition. A session is not started when the ACK is received 1482 because Bob has already terminated the session by sending a BYE. The 1483 answer in the ACK request is just ignored. 1485 Note: As noted in Section 3.1.4, implementation issues are outside 1486 the scope of this document, but this note provides a tip for avoiding 1487 race conditions of this type. Implementors can decouple the actions 1488 of the user (e.g. hanging up) from the actions of the protocol (the 1489 sending of BYE F5), so that the UA can behave like this. In this 1490 case, it is the implementor's choice as to how long to wait. In most 1491 cases, such an implementation may be useful in preventing the type of 1492 race condition described in this section. This document expresses no 1493 preference about whether or not they should wait for an ACK to be 1494 delivered. After considering the impact on users experience, 1495 implementors should decide whether to wait for a while or not, 1496 because the user experience depends on the implementation and has no 1497 direct bearing on protocol behaviour. 1499 Message Details 1501 F1 INVITE Alice -> Bob 1503 F2 180 Ringing Bob -> Alice 1505 F3 200 OK Bob -> Alice 1507 F4 ACK Alice -> Bob 1509 /* RTP streams are established between Alice and Bob */ 1511 F5 BYE Alice -> Bob 1513 F6 200 OK Bob -> Alice 1515 /* Alice sends a BYE and terminates the session and dialog. */ 1517 3.3. Other race conditions 1519 This section shows examples of race conditions that are not directly 1520 related to dialog state transition. In SIP, processing functions are 1521 deployed in three layers, dialog, session, and transaction. They are 1522 related each other, but have to be treated separately. Section 17 of 1523 RFC 3261 [1] details the processing of transactions. This draft has 1524 tried so far to clarify the processing on dialogs. This section 1525 explains race conditions which are related to sessions established 1526 with SIP. 1528 3.3.1. Re-INVITE crossover 1530 Alice Bob 1531 | | 1532 | INVITE F1 | 1533 |--------------------------->| 1534 | 180 Ringing F2 | 1535 |<---------------------------| 1536 | 200 OK F3 | 1537 |<---------------------------| 1538 | ACK F4 | 1539 |--------------------------->| 1540 | Both Way RTP Media | 1541 |<==========================>| 1542 | | 1543 |re-INVITE F5 re-INVITE F6 | 1544 |------------ -------------| 1545 | \ / | 1546 | X | 1547 | / \ | 1548 |<----------- ------------>| 1549 | 491 F8 491 F7 | 1550 |------------ -------------| 1551 | \ / | 1552 | X | 1553 | / \ | 1554 |<----------- ------------>| 1555 | ^ ACK F9 ^ ACK F10| 1556 |--|--------- ----|--------| 1557 | | \ / | | 1558 | | X | | 1559 | | / \ | | 1560 |<-|---------- ---|------->| 1561 | | | | 1562 | |0-2.0 sec | | 1563 | | | | 1564 | v re-INVITE F11(=F6) | 1565 |<------------------|--------| 1566 | 200 OK F12 | | 1567 |-------------------|------->| 1568 | ACK F13 | | 1569 |<------------------|--------| 1570 | | | 1571 | |2.1-4.0 sec 1572 | | | 1573 |re-INVITE F14(=F5) v | 1574 |--------------------------->| 1575 | 200 OK F15 | 1576 |<---------------------------| 1577 | ACK F16 | 1578 |--------------------------->| 1579 | | 1580 | | 1582 In this scenario, Alice and Bob send re-INVITE at the same time. 1583 When two re-INVITEs cross in the same dialog, they are retried, each 1584 after a different interval, according to Section 14.1, of RFC 3261 1585 [1]. When Alice sends the re-INVITE and it crosses with Bob's, the 1586 re-INVITE will be retried after 2.1-4.0 seconds because she owns the 1587 Call-ID (she generated it). Bob will retry his INVITE again after 1588 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID. 1590 Therefore, each user agent must remember whether it has generated the 1591 Call-ID of the dialog or not, in case an INVITE may cross with 1592 another INVITE. 1594 In this example, Alice's re-INVITE is for session modification and 1595 Bob's re-INVITE is for session refresh. In this case, after the 491 1596 responses, Bob retries the re-INVITE for session refresh earlier than 1597 Alice. If Alice was to retry her re-INVITE (that is, if she was not 1598 the owner of Call-ID), the request would refresh and modify the 1599 session at the same time. Then Bob would know that he would not need 1600 to retry his re-INVITE to refresh the session. 1602 In another instance where two re-INVITEs for session modification, 1603 cross over, retrying the same re-INVITE again after a 491 by the 1604 Call-ID owner (the UA which retries its re-INVITE after the other UA) 1605 may result in unintended behavior, so the UA must decide if the retry 1606 of the re-INVITE is necessary. (For example, when a call hold and an 1607 addition of video media cross over, mere retry of the re-INVITE at 1608 the firing of the timer may result in the situation where the video 1609 is transmitted immediately after the holding of the audio. This 1610 behavior is probably not intended by the users.) 1612 Message Details 1614 F1 INVITE Alice -> Bob 1616 F2 180 Ringing Bob -> Alice 1618 F3 200 OK Bob -> Alice 1620 F4 ACK Alice -> Bob 1622 F5 re-INVITE Alice -> Bob 1624 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1625 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1626 Max-Forwards: 70 1627 From: Alice ;tag=9fxced76sl 1628 To: Bob ;tag=8321234356 1629 Call-ID: 3848276298220188511@atlanta.example.com 1630 CSeq: 2 INVITE 1631 Content-Length: 147 1632 v=0 1633 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1634 s=- 1635 c=IN IP4 192.0.2.101 1636 t=0 0 1637 m=audio 49172 RTP/AVP 0 1638 a=rtpmap:0 PCMU/8000 1639 a=sendonly 1641 /* Some detailed messages are shown for the sequence to illustrate 1642 what sort of INVITE requests crossed over each other. */ 1644 F6 re-INVITE Bob -> Alice 1646 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1647 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1648 Session-Expires: 300;refresher=uac 1649 Supported: timer 1650 Max-Forwards: 70 1651 From: Bob ;tag=8321234356 1652 To: Alice ;tag=9fxced76sl 1653 Call-ID: 3848276298220188511@atlanta.example.com 1654 CSeq: 1 INVITE 1655 Content-Length: 0 1657 /* A re-INVITE request for a session refresh and another for a call 1658 hold are sent at the same time. */ 1660 F7 491 Request Pending Bob -> Alice 1662 /* Since a re-INVITE is in progress, a 491 response is returned. */ 1664 F8 491 Request Pending Alice -> Bob 1666 F9 ACK (INVITE) Alice -> Bob 1668 F10 ACK (INVITE) Bob -> Alice 1670 F11 re-INVITE Bob -> Alice 1672 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1673 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 1674 Session-Expires: 300;refresher=uac 1675 Supported: timer 1676 Max-Forwards: 70 1677 From: Bob ;tag=8321234356 1678 To: Alice ;tag=9fxced76sl 1679 Call-ID: 3848276298220188511@atlanta.example.com 1680 CSeq: 2 INVITE 1681 Content-Type: application/sdp 1682 Content-Length: 133 1684 v=0 1685 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1686 s=- 1687 c=IN IP4 192.0.2.201 1688 t=0 0 1689 m=audio 3456 RTP/AVP 0 1690 a=rtpmap:0 PCMU/8000 1692 /* Since Bob is not the owner of the Call-ID, he sends a re-INVITE 1693 again after 0.0-2.0 seconds. */ 1695 F12 200 OK Alice -> Bob 1697 F13 ACK Bob -> Alice 1699 F14 re-INVITE Alice -> Bob 1701 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1702 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1703 Max-Forwards: 70 1704 From: Alice ;tag=9fxced76sl 1705 To: Bob ;tag=8321234356 1706 Call-ID: 3848276298220188511@atlanta.example.com 1707 CSeq: 3 INVITE 1708 Content-Length: 147 1710 v=0 1711 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1712 s=- 1713 c=IN IP4 192.0.2.101 1714 t=0 0 1715 m=audio 49172 RTP/AVP 0 1716 a=rtpmap:0 PCMU/8000 1717 a=sendonly 1718 /* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE 1719 again after 2.1-4.0 seconds. */ 1721 F15 200 OK Bob -> Alice 1723 F16 ACK Alice -> Bob 1725 3.3.2. UPDATE and re-INVITE crossover 1727 Alice Bob 1728 | | 1729 | INVITE F1 | 1730 |--------------------------->| 1731 | 180 Ringing F2 | 1732 |<---------------------------| 1733 | | 1734 | 200 OK F3 | 1735 |<---------------------------| 1736 | ACK F4 | 1737 |--------------------------->| 1738 | Both Way RTP Media | 1739 |<==========================>| 1740 | | 1741 | UPDATE F5 re-INVITE F6 | 1742 |------------ -------------| 1743 | \ / | 1744 | X | 1745 | / \ | 1746 |<----------- ------------>| 1747 | 491 F8 491 F7 | 1748 | (re-INVITE) (UPDATE) | 1749 |------------ -------------| 1750 | \ / | 1751 | X | 1752 | / \ | 1753 |<----------- ------------>| 1754 | ^ ACK F9 ^ | 1755 |<-|----------------|--------| 1756 | | | | 1757 | |0-2.0 sec | | 1758 | | | | 1759 | v re-INVITE F10 | | 1760 |<------------------|--------| 1761 | 200 OK F11 | | 1762 |-------------------|------->| 1763 | ACK F12 | | 1764 |<------------------|--------| 1765 | | | 1766 | |2.1-4.0 sec 1767 | | | 1768 | UPDATE F13 v | 1769 |--------------------------->| 1770 | 200 OK F14 | 1771 |<---------------------------| 1772 | | 1773 | | 1775 In this scenario, the UPDATE contains an SDP offer, therefore the 1776 UPDATE and re-INVITE are both responded to with 491 as in the case of 1777 "re-INVITE crossover". When an UPDATE for session refresh which 1778 doesn't contain a session description and a re-INVITE cross each 1779 other, both requests succeed with 200 (491 means that a UA has a 1780 pending request). The same is true for UPDATE crossover. In the 1781 former case where either UPDATE contains a session description the 1782 requests fail with 491, and in the latter cases succeed with 200. 1784 Note: 1785 A 491 response is sent because an SDP offer is pending, and 491 is 1786 an error which is related to matters that impact the session 1787 established by SIP. 1789 Message Details 1791 F1 INVITE Alice -> Bob 1793 F2 180 Ringing Bob -> Alice 1795 F3 200 OK Bob -> Alice 1797 F4 ACK Alice -> Bob 1799 F5 UPDATE Alice -> Bob 1801 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1802 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1803 Max-Forwards: 70 1804 From: Alice ;tag=9fxced76sl 1805 To: Bob ;tag=8321234356 1806 Call-ID: 3848276298220188511@atlanta.example.com 1807 CSeq: 2 UPDATE 1808 Content-Length: 147 1810 v=0 1811 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1812 s=- 1813 c=IN IP4 192.0.2.101 1814 t=0 0 1815 m=audio 49172 RTP/AVP 0 1816 a=rtpmap:0 PCMU/8000 1817 a=sendonly 1819 /* Some detailed messages are shown for the sequence to illustrate 1820 messages crossing over each other. */ 1822 F6 re-INVITE Bob -> Alice 1824 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1825 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1826 Session-Expires: 300;refresher=uac 1827 Supported: timer 1828 Max-Forwards: 70 1829 From: Bob ;tag=8321234356 1830 To: Alice ;tag=9fxced76sl 1831 Call-ID: 3848276298220188511@atlanta.example.com 1832 CSeq: 1 INVITE 1833 Content-Type: application/sdp 1834 Content-Length: 133 1836 v=0 1837 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1838 s=- 1839 c=IN IP4 192.0.2.201 1840 t=0 0 1841 m=audio 3456 RTP/AVP 0 1842 a=rtpmap:0 PCMU/8000 1844 /* A case where a re-INVITE for a session refresh and a UPDATE for a 1845 call hold are sent at the same time. */ 1847 F7 491 Request Pending (UPDATE) Bob -> Alice 1849 /* Since a re-INVITE is in process, a 491 response is returned. */ 1851 F8 491 Request Pending (re-INVITE) Alice -> Bob 1853 F9 ACK (re-INVITE) Alice -> Bob 1855 F10 re-INVITE Bob -> Alice 1857 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1858 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 1859 Session-Expires: 300;refresher=uac 1860 Supported: timer 1861 Max-Forwards: 70 1862 From: Bob ;tag=8321234356 1863 To: Alice ;tag=9fxced76sl 1864 Call-ID: 3848276298220188511@atlanta.example.com 1865 CSeq: 2 INVITE 1866 Content-Type: application/sdp 1867 Content-Length: 133 1869 v=0 1870 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1871 s=- 1872 c=IN IP4 192.0.2.201 1873 t=0 0 1874 m=audio 3456 RTP/AVP 0 1875 a=rtpmap:0 PCMU/8000 1877 /* Since Bob is not the owner of the Call-ID, Bob sends an INVITE 1878 again after 0.0-2.0 seconds. */ 1880 F11 200 OK Alice -> Bob 1882 F12 ACK Bob -> Alice 1884 F13 UPDATE Alice -> Bob 1886 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1887 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1888 Max-Forwards: 70 1889 From: Alice ;tag=9fxced76sl 1890 To: Bob ;tag=8321234356 1891 Call-ID: 3848276298220188511@atlanta.example.com 1892 CSeq: 3 UPDATE 1893 Content-Length: 147 1895 v=0 1896 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1897 s=- 1898 c=IN IP4 192.0.2.101 1899 t=0 0 1900 m=audio 49172 RTP/AVP 0 1901 a=rtpmap:0 PCMU/8000 1902 a=sendonly 1903 /* Since Alice is the owner of the Call-ID, Alice sends the UPDATE 1904 again after 2.1-4.0 seconds. */ 1906 F14 200 OK Bob -> Alice 1908 3.3.3. Receiving REFER (Established state) while in the Mortal state 1910 State Alice Bob State 1911 | | 1912 | INVITE F1 | 1913 |----------------------->| 1914 Pre | 180 Ringing F2 | Pre 1915 |<-----------------------| 1916 Ear | | Ear 1917 | 200 OK F3 | 1918 |<-----------------------| 1919 Mora | ACK F4 | Mora 1920 |----------------------->| 1921 Est | Both Way RTP Media | Est 1922 |<======================>| 1923 | | 1924 | BYE F5 REFER F6 | 1925 |--------- ----------| 1926 Mort | \ / | 1927 | X | 1928 | / \ | 1929 *race* |<-------- --------->| 1930 | | Mort 1931 | 481 F8 200 F7 | 1932 | (REFER) (BYE) | 1933 |--------- ----------| 1934 | \ / ^ | 1935 | X | | 1936 | / \ | | 1937 |<-------- --------->| 1938 | ^ | | 1939 | | Timer K | | 1940 | V Timer J | | 1941 Morg | V | 1942 | | Morg 1943 | | 1945 This scenario illustrates the race condition which occurs when the 1946 UAS receives an Established message, REFER, while in the Mortal 1947 state. Bob sends a REFER, and Alice sends a BYE at the same time. 1948 Bob sends the REFER in the same dialog. Alice's dialog state moves 1949 to the Mortal state at the point of sending BYE. In the Mortal 1950 state, the UA possesses dialog information for an internal process 1951 but the dialog shouldn't exist outwardly. Therefore, the UA sends an 1952 error response to the REFER, which is transmitted as a mid-dialog 1953 request. So Alice, in the Mortal state, sends an error response to 1954 the REFER. However, Bob has already started the SUBSCRIBE usage with 1955 REFER, so the dialog continues until the SUBSCRIBE usage terminates, 1956 even though the INVITE dialog usage terminates by receiving BYE. 1957 Bob's behavior in this case needs to follow the procedures in RFC 1958 5057 [6]. 1960 Message Details 1962 F1 INVITE Alice -> Bob 1964 F2 180 Ringing Bob -> Alice 1966 F3 200 OK Bob -> Alice 1968 F4 ACK Alice -> Bob 1970 F5 BYE Alice -> Bob 1972 /* Alice sends a BYE request and terminates the session, and 1973 transitions from the Confirmed state to the Terminated state. */ 1975 F6 REFER Bob -> Alice 1977 /* Alice sends a BYE, and Bob sends a REFER at the same time. Bob 1978 sends the REFER on the INVITE dialog. The dialog state 1979 transitions to the Mortal state at the moment Alice sends the BYE, 1980 but Bob doesn't know this until he receives the BYE. A race 1981 condition occurs. */ 1983 F7 200 OK (BYE) Bob -> Alice 1985 F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob 1986 /* Alice in the Mortal state sends a 481 to the REFER. */ 1988 4. IANA Considerations 1990 This document has no actions for IANA. 1992 5. Security Considerations 1994 This document contains clarifications of behavior specified in RFC 1995 3261 [1], RFC 3264 [2] and RFC 3515 [4]. The security considerations 1996 of those documents continue to apply after the application of these 1997 clarifications. 1999 6. Acknowledgements 2001 The authors would like to thank Robert Sparks, Dean Willis, Cullen 2002 Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, Akihiro 2003 Shimizu, Mayumi Munakata, Yasunori Inagaki, Tadaatsu Kidokoro, 2004 Kenichi Hiragi, Dale Worley, Vijay K. Gurbani and Anders Kristensen 2005 for their comments on this document. 2007 7. References 2009 7.1. Normative References 2011 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2012 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2013 Session Initiation Protocol", RFC 3261, June 2002. 2015 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2016 Session Description Protocol (SDP)", RFC 3264, June 2002. 2018 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2019 Levels", BCP 14, RFC 2119, March 1997. 2021 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2022 Method", RFC 3515, April 2003. 2024 [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 2025 Responses in Session Initiation Protocol (SIP)", RFC 3262, 2026 June 2002. 2028 7.2. Informative References 2030 [6] Sparks, R., "Multiple Dialog Usages in the Session Initiation 2031 Protocol", RFC 5057, November 2007. 2033 [7] Sparks, R., "Correct transaction handling for 200 responses to 2034 Session Initiation Protocol INVITE requests", 2035 draft-sparks-sip-invfix-02 (work in progress), July 2008. 2037 Appendix A. BYE in the Early Dialog 2039 This section, related to Section 3.1.3, explains why BYE is not 2040 recommended in the Early state, illustrating a case in which a BYE in 2041 the early dialog triggers confusion. 2043 Alice Proxy Bob Carol 2044 | | | | 2045 | INVITE F1 | | | 2046 |--------------->| INVITE F2 | | 2047 | 100 F3 |----------------->| | 2048 |<---------------| 180(To tag=A) F4 | | 2049 | 180(A) F5 |<-----------------| | 2050 |<---------------| | | 2051 | | INVITE(Fork) F6 | 2052 | |------------------------>| 2053 | | 100 F7 | 2054 | BYE(A) F8 |<------------------------| 2055 |--------------->| BYE(A) F9 | | 2056 | |----------------->| | 2057 | | 200(A,BYE) F10 | | 2058 | 200(A,BYE) F11 |<-----------------| | 2059 |<---------------| 487(A,INV) F12 | | 2060 | |<-----------------| | 2061 | | ACK(A) F13 | | 2062 | |----------------->| | 2063 | | | | 2064 | | | 2065 | | 200(To tag=B) F13 | 2066 | 200(B) F14 |<------------------------| 2067 |<---------------| | 2068 | ACK(B) F15 | | 2069 |--------------->| ACK(B) F16 | 2070 | |------------------------>| 2071 | BYE(B) F17 | | 2072 |--------------->| BYE(B) F18 | 2073 | |------------------------>| 2074 | | 200(B) F19 | 2075 | 200(B) F20 |<------------------------| 2076 |<---------------| | 2077 | | | 2078 | | | 2080 Care is advised in sending BYE in the Early state when forking by a 2081 proxy is expected. In this example, the BYE request progresses 2082 normally, and it succeeds in correctly terminating the dialog with 2083 Bob. After Bob terminates the dialog by receiving the BYE, he sends a 2084 487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261 [1], 2085 it is RECOMMENDED for the UAS to generate a 487 to any pending 2086 requests after receiving a BYE. In the example, Bob sends a 487 to 2087 the ini-INVITE since he receives the BYE while the ini-INVITE is in 2088 pending state. 2090 However, Alice receives a final response to the INVITE (a 200 from 2091 Carol) even though she has successfully terminated the dialog with 2092 Bob. This means that, regardless of the success/failure of the BYE in 2093 the Early state, Alice MUST be prepared for the establishment of a 2094 new dialog until receiving the final response for the INVITE and 2095 terminating the INVITE transaction. 2097 It is not illegal to send a BYE in the Early state to terminate a 2098 specific early dialog - it may satisfy the intent of some callers. 2099 However, the choice of BYE or CANCEL in the Early state must be made 2100 carefully. CANCEL is appropriate when the goal is to abandon the 2101 call attempt entirely. BYE is appropriate when the goal is to 2102 abandon a particular early dialog while allowing the call to be 2103 completed with other destinations. When using either BYE or CANCEL 2104 the UAC must be prepared for the possibility that a call may still be 2105 established to one (or more) destinations. 2107 Appendix B. BYE request overlapping with re-INVITE 2109 UAC UAS 2110 | | 2111 The session has been already established 2112 ========================== 2113 | re-INVITE F1 | 2114 |--------------------->| 2115 | BYE F2 | 2116 |--------------------->| 2117 | 200(BYE) F3 | 2118 |<---------------------| 2119 | INVITE F4(=F1) | 2120 |--------------------->| 2121 | | 2122 | | 2124 This case could look similar to the one in Section 3.2.3. However, 2125 it is not a race condition. This case describes the behavior when 2126 there is no response to the INVITE for some reason. The appendix 2127 explains the behavior in this case and its rationale, since this case 2128 is likely to cause confusion. 2130 First of all, it is important not to confuse the behavior of the 2131 transaction layer and that of the dialog layer. RFC 3261 [1] details 2132 the transaction layer behavior. The dialog layer behavior is 2133 explained in this document. It has to be noted that these two 2134 behaviors are independent of each other, even though both layers may 2135 be triggered to change their states by sending or receiving the same 2136 SIP messages. (A dialog can be terminated even though a transaction 2137 still remains, and vice versa.) 2138 In the sequence above, there is no response to F1, and F2 (BYE) is 2139 sent immediately after F1 (F1 is a mid-dialog request. If F1 was an 2140 ini-INVITE, BYE could not be sent before the UAC received a 2141 provisional response to the request with a To tag). 2143 Below is a figure which illustrates the UAC's dialog state and the 2144 transaction state. 2146 BYE INV dialog UAC UAS 2147 : | | 2148 : | | 2149 | | re-INVITE F1 | 2150 o | |--------------------->| 2151 | | | BYE F2 | 2152 o | (Mortal) |--------------------->| 2153 | | | | 200(BYE) F3 | 2154 | | | |<---------------------| 2155 | | | | INVITE F4(=F1) | 2156 | | | |--------------------->| 2157 | | | | 481(INV) F5 | 2158 | | | |<---------------------| 2159 | | | | ACK(INV) F6 | 2160 | | | |--------------------->| 2161 | | | | | 2162 o | o | | 2163 | | | 2164 o | | 2165 | | 2167 For the UAC, the INVITE client transaction begins at the point F1 is 2168 sent. The UAC sends BYE (F2) immediately after F1. This is a 2169 legitimate behavior. (Usually the usage of each SIP method is 2170 independent, for BYE and others. However, it should be noted that it 2171 is prohibited to send a request with an SDP offer while the previous 2172 offer is in progress.) 2174 After that, F2 triggers the BYE client transaction. At the same 2175 time, the dialog state transitions to the Mortal state and then only 2176 a BYE or a response to a BYE can be handled. 2178 It is permitted to send F4 (a retransmission of INVITE) in the Mortal 2179 state, because the retransmission of F1 is handled by the transaction 2180 layer, and the INVITE transaction has not yet transitioned to the 2181 Terminated state. As is mentioned above, the dialog and the 2182 transaction behave independently each other. Therefore the 2183 transaction handling has to be continued even though the dialog has 2184 moved to the Terminated state. 2186 Note: As noted in Section 3.1.4, implementation issues are outside 2187 the scope of this document, but this note provides a tip for avoiding 2188 race conditions of this type. That is for the UAC to delay sending 2189 BYE F2 until the re-INVITE transaction F1 completes. Implementors 2190 can decouple the actions of the user (e.g. hanging up) from the 2191 actions of the protocol (the sending of BYE F2), so that the UA can 2192 behave like this. In this case, it is the implementor's choice as to 2193 how long to wait. In most cases, such an implementation may be 2194 useful to prevent this case. This document expresses no preference 2195 about whether or not they should wait for an ACK to be delivered. 2196 After considering the impact on users experience, implementors should 2197 decide whether to wait for a while or not, because the user 2198 experience depends on the implementation and has no direct bearing on 2199 protocol behaviour. 2201 Next, the UAS's state is shown below. 2203 UAC UAS dialog INV BYE 2204 | | : 2205 | | : 2206 | re-INVITE F1 | | 2207 |-------------->x | | 2208 | BYE F2 | | 2209 |--------------------->| | o 2210 | 200(BYE) F3 | (Mortal) | 2211 |<---------------------| | |<-Start Timer J 2212 | INVITE F4(=F1) | | | 2213 |--------------------->| | o | 2214 | 4xx/5xx(INV) F5 | o | o 2215 |<---------------------| | 2216 | ACK(INV) F6 | | 2217 |--------------------->| |<-Start Timer I 2218 | | | 2219 | | | 2220 | | o 2221 | | 2223 For the UAS, it can be considered that packet the F1 is lost or 2224 delayed (here the behavior is explained for the case that the UAS 2225 receives F2 BYE before F1 INVITE). Therefore, F2 triggers the BYE 2226 transaction for UAS, and simultaneously the dialog moves to the 2227 Mortal state. Then, upon the reception of F4 the INVITE server 2228 transaction begins. (It is permitted to start the INVITE server 2229 transaction in the Mortal state. The INVITE server transaction 2230 begins to handle the received SIP request regardless of the dialog 2231 state.) The UAS's TU sends an appropriate error response for the F4 2232 INVITE, either 481 (because the TU knows that the dialog which 2233 matches the INVITE is in the Terminated state) or 500 (because the 2234 re-sent F4 has an out-of-order CSeq). (It is mentioned above that 2235 INVITE message F4 (and F1) is a mid-dialog request. Mid-dialog 2236 requests have a To tag. It should be noted that the UAS's TU does 2237 not begin a new dialog upon the reception of INVITE with a To tag.) 2239 Appendix C. UA's behavior for CANCEL 2241 This section explains the CANCEL behaviors which indirectly impact 2242 the dialog state transition in the Early state. CANCEL does not have 2243 any influence on the UAC's dialog state. However, the request has a 2244 indirect influence on the dialog state transition because it has a 2245 significant effect on ini-INVITE. For the UAS the CANCEL request has 2246 more direct effects on the dialog than the sending of a CANCEL by the 2247 UAC, because it can be a trigger to send the 487 response. Figure 3 2248 explains UAS's behavior in the Early state. This flow diagram is 2249 only an explanatory figure, and the actual dialog state transition is 2250 as illustrated in Figures 1 and 2. 2252 In the flow, full lines are related to dialog state transition, and 2253 dotted lines are involved with CANCEL. (r) represents the reception 2254 of signaling, and (s) means sending. There is no dialog state for 2255 CANCEL, but here the Cancelled state is handled virtually just for 2256 the ease of understanding of the UA's behavior when it sends and 2257 receives CANCEL. 2259 +-------------+ 2260 | Preparative |---+ 2261 +-------------+ | 2262 : | 1xx(s) | 2263 : V | 2264 : +-------+ | 2xx(s) 2265 : | Early |-----+------+ 2266 : +-------+ | 2267 : : V 2268 : : +-----------+ 2269 : : | Confirmed |<... 2270 :.....: +-----------+ : 2271 : | : : 2272 : BYE(r)| : : 2273 : CANCEL(r) | :.......: 2274 V | CANCEL(r) 2275 ............. | 2276 : Cancelled : | 2277 :...........: | 2278 | 487(s) | 2279 | | 2280 +--------------------+ 2281 | 2282 V 2283 +------------+ 2284 | Terminated | 2285 +------------+ 2287 Figure 3: CANCEL flow diagram for UAS 2289 There are two behaviors for the UAS depending on the state when it 2290 receives a CANCEL. 2292 The first behavior is when the UAS receives a CANCEL in the Early 2293 state. In this case the UAS immediately sends a 487 for the INVITE, 2294 and the dialog transitions to the Terminated state. 2296 The other is the case in which the UAS receives a CANCEL while in the 2297 Confirmed state. In this case the dialog state transition does not 2298 occur because UAS has already sent a final response to the INVITE to 2299 which the CANCEL is targeted. (Note that, because of the UAC's 2300 behavior, a UAS that receives a CANCEL in the Confirmed state can 2301 expect to receive a BYE immediately and move to the Terminated state. 2302 However, the UAS's state does not transition until it actually 2303 receives a BYE.) 2305 Appendix D. Notes on the request in the Mortal state 2307 This section describes the UA's behavior in the Mortal state, which 2308 needs careful attention. Note that every transaction completes 2309 independently of others, following the principle of RFC 3261 [1]. 2311 In the Mortal state, only a BYE can be accepted, and the other 2312 messages in the INVITE dialog usage are responded to with an error. 2313 However, sending of ACK and the authentication procedure for BYE are 2314 conducted in this state. (The handling of messages concerning 2315 multiple dialog usages is out of the scope of this document. Refer 2316 to RFC 5057 [6] for further information.) 2318 ACK for error responses is handled by the transaction layer, so the 2319 handling is not related to the dialog state. Unlike the ACK for 2320 error responses, ACK for 2xx responses is a request newly generated 2321 by a TU. However, the ACK for 2xx and the ACK for error responses 2322 are both a part of the INVITE transaction, even though their handling 2323 differs (Section 17.1.1.1, RFC 3261 [1]). Therefore, the INVITE 2324 transaction is completed by the three-way handshake, which includes 2325 ACK, even in the Mortal state. 2327 Considering actual implementation, the UA needs to keep the INVITE 2328 dialog usage until the Mortal state finishes, so that it is able to 2329 send ACK for a 2xx response in the Mortal state. If a 2xx to INVITE 2330 is received in the Mortal state, the duration of the INVITE dialog 2331 usage will be extended to 64*T1 seconds after the receiving of the 2332 2xx, to cope with the possible 2xx retransmission. (The duration of 2333 the 2xx retransmission is 64*T1, so the UA needs to be prepared to 2334 handle the retransmission for this duration.) However, the UA shall 2335 send an error response to other requests, since the INVITE dialog 2336 usage in the Mortal state is kept only for the sending of ACK for 2337 2xx. 2339 The BYE authentication procedure shall be processed in the Mortal 2340 state. When authentication is requested by a 401 or 407 response, 2341 UAC resends BYE with appropriate credentials. Also the UAS handles 2342 the retransmission of the BYE for which it requested authentication. 2344 Appendix E. Forking and receiving new To tags 2346 This section details the behavior of the TU when it receives multiple 2347 responses with a different To tag to ini-INVITE. 2349 When an INVITE is forked inside a SIP network, there is a possibility 2350 that the TU receives multiple responses to the ini-INVITE with 2351 differing To tags (See Section 12.1, 13.1, 13.2.2.4, 16.7, 19.3, etc. 2353 of RFC 3261 [1]). If the TU receives multiple 1xx responses with 2354 different To tags, the original DSM forks and a new DSM instance is 2355 created. As a consequence multiple early dialogs are generated. 2357 If one of the multiple early dialogs receives a 2xx response, it 2358 naturally transitions to the Confirmed state. No DSM state 2359 transition occurs for the other early dialogs, and their sessions 2360 (early media) terminate. The TU of the UAC terminates the INVITE 2361 transaction after 64*T1 seconds starting at the point of receiving 2362 the first 2xx response. Moreover, all mortal early dialogs which do 2363 not transition to the Established state are terminated (See Section 2364 13.2.2.4 of RFC 3261 [1]). By "mortal early dialog" we mean any 2365 early dialog that the UA will terminate when another early dialog is 2366 confirmed. 2368 Below is an example sequence in which two 180 responses with 2369 different To tags are received, and then a 200 response for one of 2370 the early dialogs (dialog A) is received. Dotted lines (..) in the 2371 sequences are auxiliary lines to represent the influence on dialog B. 2373 UAC 2374 dialog(A) | INVITE F1 2375 Pre o |-------------------------> 2376 | | 100 F2 2377 | |<------------------------- 2378 | | 180(To tag=A) F3 2379 Ear | |<------------------------- 2380 dialog(B) | | 2381 forked new DSM | | 180(To tag=B) F4 2382 Ear o..........|..........|<------------------------- 2383 | | | 2384 | | | 200(A) F5 2385 terminate->|.....Mora |..........|<------------------------- 2386 early | | ^ | ACK(A) F6 2387 media | Est | | |-------------------------> 2388 | | | | 2389 | | |64*T1 | 2390 | | |(13.2.2.4 of RFC 3261 [1]) 2391 | | | | 2392 | | | | 2393 | | V | 2394 o..........|.(terminate INVITE transaction) 2395 terminated | | 2396 dialog(B) | | 2397 | | 2399 Figure 4: Receiving 1xx responses with different To tags 2401 The figure above shows the DSM inside a SIP TU. Triggered by the 2402 reception of a provisional response with a different To tag (F4 2403 180(To tag=B)), the DSM forks and the early dialog B is generated. 2404 64*T1 seconds later dialog A receives a 200 OK response. Dialog B, 2405 which does not transition to the Established state, terminates. 2407 Next, the behavior of a TU which receives multiple 2xx responses with 2408 different To tags is explained. When a mortal early dialog, which 2409 did not match the first 2xx response that the TU received, receives 2410 another 2xx response which matches its To tag before the 64*T1 INVITE 2411 transaction timeout, its DSM transitions to the Confirmed state. 2412 However, the session on the mortal early dialog is terminated when 2413 the TU receives the first 2xx to establish a dialog, so no session is 2414 established for the mortal early dialog. Therefore, when the mortal 2415 early dialog receives a 2xx response, the TU sends an ACK and, 2416 immediately after, the TU usually sends a BYE to terminate the DSM. 2417 (In special cases, e.g. if a UA intends to establish multiple 2418 dialogs, the TU may not send the BYE.) 2420 The handling of the second early dialog after receiving the 200 for 2421 the first dialog is quite appropriate for a typical device, such as a 2422 phone. It is important to note that what is being shown is a typical 2423 useful action and not the only valid one. Some devices might want to 2424 handle things differently. For instance, a conference focus that has 2425 sent out an INVITE that forks may want to accept and mix all the 2426 dialogs it gets. In that case, no early dialog is treated as mortal. 2428 Below is an example sequence in which two 180 responses with a 2429 different To tag are received and then a 200 response for each of the 2430 early dialogs is received. 2432 UAC 2433 dialog(A) | INVITE F1 2434 Pre o |-----------------------> 2435 | | 100 F2 2436 | |<----------------------- 2437 | | 180(To tag=A) F3 2438 dialog(B) Ear | |<----------------------- 2439 forked new DSM | | 180(To tag=B) F4 2440 Ear o..........|..........|<----------------------- 2441 | | | 2442 | | | 200(A) F5 2443 terminate->|.....Mora |..........|<----------------------- 2444 early | | ^ | ACK(A) F6 2445 media | Est | | |-----------------------> 2446 | | |64*T1 | 2447 | | | | 200(B) F7 2448 Mora |..........|.|........|<----------------------- 2449 | | | | ACK(B) F8 2450 Est |..........|.|........|-----------------------> 2451 | | | | BYE(B) F9 2452 Mort |..........|.|........|-----------------------> 2453 ^ | | | | 200(B) F10 2454 | | | | |<----------------------- 2455 |Timer K | | | 2456 | | | V | 2457 | | | (terminate INVITE transaction) 2458 V | | | 2459 Morg o | | 2460 | | 2462 Figure 5: Receiving 1xx and 2xx responses with different To tags 2464 Below is an example sequence when a TU receives multiple 200 2465 responses with different To tags before the 64*T1 timeout of the 2466 INVITE transaction in the absence of a provisional response. Even 2467 though a TU does not receive a provisional response, the TU needs to 2468 process the 2xx responses (See Section 13.2.2.4 of RFC 3261 [1]). In 2469 that case, the DSM state is forked at the Confirmed state, and then 2470 the TU sends an ACK for the 2xx response and, immediately after, the 2471 TU usually sends a BYE. (In special cases, e.g. if a UA intends to 2472 establish multiple dialogs, the TU may not send the BYE.) 2473 UAC 2474 dialog(A) | INVITE F1 2475 Pre o |-----------------------> 2476 | | 100 F2 2477 | |<----------------------- 2478 | | 180(To tag=A) F3 2479 Ear | |<----------------------- 2480 | | 2481 | | 200(A) F4 2482 Mora |..........|<----------------------- 2483 | ^ | ACK(A) F5 2484 Est | | |-----------------------> 2485 | | | 2486 dialog(B) | |64*T1 | 2487 forked new DSM | | | 200(To tag=B) F6 2488 Mora o..........|.|........|<----------------------- 2489 | | | | ACK(B) F7 2490 Est |..........|.|........|-----------------------> 2491 | | | | BYE(B) F8 2492 Mort |..........|.|........|-----------------------> 2493 ^ | | | | 200(B) F9 2494 | | | | |<----------------------- 2495 | | | V | 2496 |Timer K | (terminate INVITE transaction) 2497 | | | | 2498 V | | | 2499 Morg o | | 2500 | | 2502 Figure 6: Receiving 2xx responses with different To tags 2504 Below is an example sequence in which the option tag 100rel (RFC 3262 2505 [5]) is required by a 180. 2507 If a forking proxy supports 100rel, it transparently transmits to the 2508 UAC a provisional response which contains a Require header with the 2509 value of 100rel. Upon receiving a provisional response with 100rel, 2510 the UAC establishes the early dialog (B) and sends PRACK. (Here, 2511 also, every transaction completes independently of others.) 2513 As in Figure 4, the early dialog (B) terminates at the same time the 2514 INVITE transaction terminates. In the case where a proxy does not 2515 support 100rel, the provisional response will be handled in the usual 2516 way (a provisional response with 100rel is discarded by the proxy, 2517 not to be transmitted to the UAC). 2519 UAC 2520 dialog(A) | INVITE F1 2521 Pre o |-------------------------> 2522 | | 100 F2 2523 | |<------------------------- 2524 | | 180(To tag=A) F3 2525 Ear | |<------------------------- 2526 | | 200(A) F4 2527 Mora |..........|<------------------------- 2528 | ^ | ACK(A) F5 2529 Est | | |-------------------------> 2530 dialog(B) | | | 2531 forked new DSM | | | 180(To tag=B) w/100rel F6 2532 Ear o..........|.|........|<------------------------- 2533 | | | | PRACK(B) F7 2534 | | | |-------------------------> 2535 | | | | 200(B,PRACK) F8 2536 | | | |<------------------------- 2537 | | |64*T1 | 2538 | | |(13.2.2.4 of RFC 3261 [1]) 2539 | | | | 2540 | | | | 2541 | | | | 2542 | | V | 2543 o..........|.(terminate INVITE transaction) 2544 terminated | | 2545 dialog(B) | | 2546 | | 2548 Figure 7: Receiving 1xx responses with different To tags 2549 when using the mechanism for reliable provisional responses (100rel) 2551 Authors' Addresses 2553 Miki Hasebe 2554 NTT-east Corporation 2555 19-2 Nishi-shinjuku 3-chome 2556 Shinjuku-ku, Tokyo 163-8019 2557 JP 2559 Email: hasebe.miki@east.ntt.co.jp 2560 Jun Koshiko 2561 NTT-east Corporation 2562 19-2 Nishi-shinjuku 3-chome 2563 Shinjuku-ku, Tokyo 163-8019 2564 JP 2566 Email: j.koshiko@east.ntt.co.jp 2568 Yasushi Suzuki 2569 NTT Corporation 2570 9-11, Midori-cho 3-Chome 2571 Musashino-shi, Tokyo 180-8585 2572 JP 2574 Email: suzuki.yasushi@lab.ntt.co.jp 2576 Tomoyuki Yoshikawa 2577 NTT-east Corporation 2578 19-2 Nishi-shinjuku 3-chome 2579 Shinjuku-ku, Tokyo 163-8019 2580 JP 2582 Email: tomoyuki.yoshikawa@east.ntt.co.jp 2584 Paul H. Kyzivat 2585 Cisco Systems, Inc. 2586 1414 Massachusetts Avenue 2587 Boxborough, MA 01719 2588 US 2590 Email: pkyzivat@cisco.com 2592 Full Copyright Statement 2594 Copyright (C) The IETF Trust (2008). 2596 This document is subject to the rights, licenses and restrictions 2597 contained in BCP 78, and except as set forth therein, the authors 2598 retain all their rights. 2600 This document and the information contained herein are provided on an 2601 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2602 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2603 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2604 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2605 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2606 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2608 Intellectual Property 2610 The IETF takes no position regarding the validity or scope of any 2611 Intellectual Property Rights or other rights that might be claimed to 2612 pertain to the implementation or use of the technology described in 2613 this document or the extent to which any license under such rights 2614 might or might not be available; nor does it represent that it has 2615 made any independent effort to identify any such rights. Information 2616 on the procedures with respect to rights in RFC documents can be 2617 found in BCP 78 and BCP 79. 2619 Copies of IPR disclosures made to the IETF Secretariat and any 2620 assurances of licenses to be made available, or the result of an 2621 attempt made to obtain a general license or permission for the use of 2622 such proprietary rights by implementers or users of this 2623 specification can be obtained from the IETF on-line IPR repository at 2624 http://www.ietf.org/ipr. 2626 The IETF invites any interested party to bring to its attention any 2627 copyrights, patents or patent applications, or other proprietary 2628 rights that may cover technology that may be required to implement 2629 this standard. Please address the information to the IETF at 2630 ietf-ipr@ietf.org.