idnits 2.17.1 draft-ietf-sipping-race-examples-05.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 2576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2600. 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5905 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 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: Best Current NTT-east Corporation 5 Practice Y. Suzuki 6 Expires: August 21, 2008 NTT Corporation 7 T. Yoshikawa 8 NTT-east Corporation 9 P. Kyzivat 10 Cisco Systems, Inc. 11 February 18, 2008 13 Example calls flows of race conditions in the Session Initiation 14 Protocol (SIP) 15 draft-ietf-sipping-race-examples-05 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 August 21, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document gives examples call flows of race conditions in the 49 Session Initiation Protocol (SIP). Race conditions are inherently 50 confusing and difficult to thwart; this document shows the best 51 practices to handle them. The elements in these call flows include 52 SIP User Agents and SIP Proxy Servers. Call flow diagrams and 53 message details are given. 55 Table of Contents 57 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 4 59 1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 4 60 1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 5 61 2. The Dialog State Machine for INVITE dialog usage . . . . . . . 6 62 3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.1. Receiving message in the Moratorium State . . . . . . . . 12 64 3.1.1. Receiving Initial INVITE retransmission 65 (Preparative state) while in the Moratorium state . . 12 66 3.1.2. Receiving CANCEL (Early state) when in Moratorium 67 state . . . . . . . . . . . . . . . . . . . . . . . . 14 68 3.1.3. Receiving BYE (Early state) while in the 69 Moratorium state . . . . . . . . . . . . . . . . . . . 16 70 3.1.4. Receiving re-INVITE (Established state) while in 71 the Moratorium state (case 1) . . . . . . . . . . . . 18 72 3.1.5. Receiving re-INVITE (Established state) while in 73 the Moratorium state (case 2) . . . . . . . . . . . . 23 74 3.1.6. Receiving BYE (Established state) while in the 75 Moratorium state . . . . . . . . . . . . . . . . . . . 27 76 3.2. Receiving message in the Mortal State . . . . . . . . . . 29 77 3.2.1. Receiving BYE (Established state) while in the 78 Mortal state . . . . . . . . . . . . . . . . . . . . . 29 79 3.2.2. Receiving re-INVITE (Established state) while in 80 the Mortal state . . . . . . . . . . . . . . . . . . . 32 81 3.2.3. Receiving 200 OK for re-INVITE (Established state) 82 while in the Mortal state . . . . . . . . . . . . . . 34 83 3.2.4. Receiving ACK (Moratorium state) while in the 84 Mortal state . . . . . . . . . . . . . . . . . . . . . 37 85 3.3. Other race conditions . . . . . . . . . . . . . . . . . . 38 86 3.3.1. Re-INVITE crossover . . . . . . . . . . . . . . . . . 38 87 3.3.2. UPDATE and re-INVITE crossover . . . . . . . . . . . . 44 88 3.3.3. Receiving REFER (Established state) while in the 89 Mortal state . . . . . . . . . . . . . . . . . . . . . 48 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 50 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 94 7.1. Normative References . . . . . . . . . . . . . . . . . . . 50 95 7.2. Informative References . . . . . . . . . . . . . . . . . . 50 97 Appendix A. BYE in the Early Dialog . . . . . . . . . . . . . . . 50 98 Appendix B. BYE request overlapping with re-INVITE . . . . . . . 52 99 Appendix C. UA's behavior for CANCEL . . . . . . . . . . . . . . 55 100 Appendix D. Notes on the request in the Mortal state . . . . . . 57 101 Appendix E. Forking and receiving new To tags . . . . . . . . . . 57 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 103 Intellectual Property and Copyright Statements . . . . . . . . . . 64 105 1. Overview 107 The call flows shown in this document were developed in the design of 108 a SIP IP communications network. These examples are of race 109 conditions, which stem from transitions in dialog states; mainly 110 transitions during session establishment after the sending of an 111 INVITE. 113 When implementing SIP, various complex situations may arise. 114 Therefore, it is helpful to provide implementors of the protocol with 115 examples of recommended terminal and server behavior. 117 This document clarifies SIP UA behaviors when messages cross each 118 other as race conditions. By clarifying the operation under race 119 conditions, inconsistent interpretations between implementations are 120 avoided and interoperability is expected to be promoted. 122 It is the hope of the authors that this document will be useful for 123 SIP implementors, designers, and protocol researchers and will help 124 them achieve the goal of a standard implementation of RFC 3261 [1]. 126 These call flows are based on the version 2.0 of SIP defined in RFC 127 3261 [1] with SDP usage as described in RFC 3264 [2]. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in BCP 14, RFC 2119 [3]. 133 1.1. General Assumptions 135 A number of architectural, network, and protocol assumptions underlie 136 the call flows in this document. Note that these assumptions are not 137 requirements. They are outlined in this section so that they may be 138 taken into consideration and help understanding of the call flow 139 examples. 141 These flows do not assume specific underlying transport protocols 142 such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for 143 details of the transport issues for SIP. 145 1.2. Legend for Message Flows 147 Dashed lines (---) and slash lines (/, \) represent signaling 148 messages that are mandatory to the call scenario. (X) represents the 149 crossover of signaling messages. (->x, x<-) indicate that the packet 150 is lost. The arrow indicates the direction of message flow. Double 151 dashed lines (===) represent media paths between network elements. 153 Messages are identified in the figures as F1, F2, etc. These numbers 154 are used for references to the message details that follow the 155 Figure. Comments in the message details are shown in the following 156 form: 158 /* Comments. */ 160 1.3. SIP Protocol Assumptions 162 This document does not prescribe the flows precisely as they are 163 shown, but rather illustrates the principles for best practice. They 164 are best practice usages (orderings, syntax, selection of features 165 for the purpose, or handling of errors) of SIP methods, headers and 166 parameters. Note: The flows in this document must not be copied 167 as-is by implementors because additional annotations have been 168 incorporated into this document for ease of explanation. To sum up, 169 the procedures described in this document represent well-reviewed 170 examples of SIP usage, which exemplify best common practice according 171 to IETF consensus. 173 For reasons of simplicity in reading and editing the document, there 174 are a number of differences between some of the examples and actual 175 SIP messages. For instance, Call-IDs are often replicated, CSeq 176 often begins at 1, header fields are usually shown in the same order, 177 usually only the minimum required header field set is shown, and 178 other headers which would usually be included such as Accept, Allow, 179 etc. are not shown. 181 Actors: 183 Element Display Name URI IP Address 184 ------- ------------ --- ---------- 186 User Agent Alice sip:alice@atlanta.example.com 192.0.2.101 187 User Agent Bob sip:bob@biloxi.example.com 192.0.2.201 188 User Agent Carol sip:carol@chicago.example.com 192.0.2.202 189 Proxy Server ss.atlanta.example.com 192.0.2.111 191 The term "session" is used in this document in the same way it is 192 used in RFC 3261 [1] sections 13-15. (Which differs somewhat from 193 the definition of the term in RFC 3261.) RFC 5057 [6] introduces 194 another term, "invite dialog usage", which is more precisely defined. 195 The term "session" used herein is almost, but not quite, identical to 196 the term "invite dialog usage". The two have differing definitions 197 of when the state ends -- the session ends earlier, when BYE is sent 198 or received. 200 2. The Dialog State Machine for INVITE dialog usage 202 Race conditions are generated when the dialog state of the receiving 203 side differs from that of the sending side. 205 For instance, a race condition occurs when a UAC (User Agent Client) 206 sends a CANCEL in the Early state while the UAS (User Agent Server) 207 is transitioning from the Early state to the Confirmed state by 208 sending a 200 OK to an initial INVITE (indicated as "ini-INVITE" 209 hereafter). The DSM (dialog state machine) for the INVITE dialog 210 usage is presented as follows to help understanding of the UA's 211 behavior in race conditions. 213 The DSM clarifies the UA's behavior by subdividing the dialog state 214 shown in RFC 3261 [1] into various internal states. We call the 215 state before the establishment of a dialog the Preparative state. 216 The Confirmed state is subdivided into two substates, the Moratorium 217 and the Established states, and the Terminated state is subdivided 218 into the Mortal and Morgue states. Messages which are the triggers 219 for the state transitions between these states are indicated with 220 arrows. In this figure, messages which are not related to state 221 transition are omitted. 223 Below are the DSMs, first for the caller and then for the callee. 225 INV +-----------------------------------------------+ 226 --->| Preparative | 227 +-----------------------------------------------+ 228 | | | 229 | 3xx-6xx | 1xx-tag | 2xx 230 | | | 231 | | 1xx-tag | 232 | V w/new tag | 233 | +-----------------+ [new DSM] | 234 | 3xx-6xx | | | (new DSM | 235 +<--------| Early | | instance | 236 | | |<--+ created) | 237 | +-----------------+ | 238 | | | | 2xx w/new tag 239 | | BYE | 2xx | [new DSM] 240 | | +------------>+<-+ | (new DSM 241 | | | | instance 242 +-----C------------C-----+ +-----------C------+ | created) 243 | | Terminated | | | Confirmed | | | 244 | | +<----C---------| | | | 245 | | | | BYE(sr) | | | | 246 | | V | | V | | 247 | 2xx | +-----------+ | | +-----------+ | | 248 | +---C--| |---C-+ | | | | | 249 | | | | Mortal | | | BYE(r)| | Moratorium|<-C--+ 250 | +---C->| |<--C-+ | | | | 251 | ACK | +-----------+ | | +-----------+ | 252 | | | | | | | 253 | | | Timeout | | | ACK | 254 | | | | | | | 255 | V V | | V | 256 | +---------------+ | | +-----------+ | 257 | | | | | | |--C-+ 258 | | Morgue | | | |Established| | | 2xx,ACK 259 | | | | | | |<-C-+ 260 | +---------------+ | | +-----------+ | 261 | | | | 262 +------------------------+ +------------------+ 264 (r): indicates that only reception is allowed. 265 Where (r) is not used as an indicator, "response" means 266 receive, and "request" means send. 267 (sr): indicates that both sending and reception are allowed. 269 Figure 1: DSM for INVITE dialog usage (Caller) 271 Figure 1 represents the caller's DSM for the INVITE dialog usage. 272 The caller MAY send a BYE in the Early state, even though this 273 behavior is NOT RECOMMENDED. A BYE sent in the Early state 274 terminates the early dialog using a specific To tag. That is, when a 275 proxy is performing forking, the BYE is only able to terminate the 276 early dialog with a particular UA. If the caller wants to terminate 277 all early dialogs instead of that with a particular UA, it needs to 278 send CANCEL, not BYE. However, it is not illegal to send BYE in the 279 Early state to terminate a specific early dialog if this is to the 280 caller's intent. Moreover, until the caller receives a final 281 response and terminates the INVITE transaction, the caller MUST be 282 prepared to establish a dialog by receiving a new response to the 283 INVITE even if it has already sent a CANCEL or BYE and terminated the 284 dialog (see Appendix A). 286 INV +-----------------------------------------------+ 287 --->| Preparative | 288 +-----------------------------------------------+ 289 | | | 290 | 3xx-6xx | 1xx-tag | 2xx 291 | | | 292 | V | 293 | +------------------+ | 294 | 3xx-6xx | | | 295 +<--------| Early | | 296 | | | | 297 | +------------------+ | 298 | | | | 299 | | BYE | 2xx | 300 | | +------------>+<-+ 301 | | | 302 +-----C------------C-----+ +-----------C------+ 303 | | Terminated | | | Confirmed | | 304 | | +<----C---------| | | 305 | | | | BYE(sr) | | | 306 | | V | | V | 307 | | +------------+ | | +-----------+ | 308 | | | |---C-+ | | |--C-+ 309 | | | Mortal | | | BYE | | Moratorium| | | 2xx 310 | | | |<--C-+ | | |<-C-+ if ACK not 311 | | +------------+ | | +-----------+ | received 312 | | | | | | | 313 | | | Timeout | | | ACK | 314 | | | | | | | 315 | V V | | V | 316 | +---------------+ | | +-----------+ | 317 | | | | | | | | 318 | | Morgue | | | |Established| | 319 | | | | | | | | 320 | +---------------+ | | +-----------+ | 321 | | | | 322 +------------------------+ +------------------+ 324 (sr): indicates that both sending and reception are allowed. 325 Where (sr) is not used as an indicator, "response" means send, 326 and "request" means receive. 328 Figure 2: DSM for INVITE dialog usage (Callee) 330 Figure 2 represents the callee's DSM for the INVITE dialog usage. 331 The figure does not illustrate the state transition related to CANCEL 332 requests. A CANCEL request does not cause a dialog state transition. 333 However, the callee terminates the dialog and triggers the dialog 334 transition by sending 487 immediately after the reception of the 335 CANCEL. This behavior upon the reception of the CANCEL request is 336 further explained in Appendix C. 338 The UA's behavior in each state is as follows. 340 Preparative (Pre): The Preparative state is in effect until the 341 early dialog is established by sending or receiving a provisional 342 response with a To tag after an ini-INVITE is sent or received. 343 The dialog does not yet exist in the Preparative state. If the UA 344 sends or receives a 2xx response, the dialog state transitions 345 from the Preparative to the Moratorium state, which is a substate 346 of the Confirmed state. In addition, if UA sends or receives a 347 3xx-6xx response the dialog state transitions to the Morgue state 348 which is a substate of the Terminated state. Sending an ACK for a 349 3xx-6xx response and retransmissions of 3xx-6xx are not shown on 350 the DSMs because they are sent by the INVITE transaction. 352 Early (Ear): The early dialog is established by sending or receiving 353 a provisional response except 100 Trying. The early dialog exists 354 even though the dialog does not exist in this state yet. The 355 dialog state transitions from the Early to the Moratorium state, a 356 substate of the Confirmed state, by sending or receiving a 2xx 357 response. In addition, the dialog state transitions to the Morgue 358 state, a substate of the Terminated state, by sending or receiving 359 a 3xx-6xx response. Sending an ACK for a 3xx-6xx response and 360 retransmissions of 3xx-6xx are not shown on this DSM because they 361 are automatically processed on the transaction layer and don't 362 influence the dialog state. The UAC may send a CANCEL in the 363 Early state. The UAC may also send a BYE (although it is not 364 recommended). The UAS may send a 1xx-6xx response. The sending 365 or receiving of a CANCEL request does not have a direct influence 366 on the dialog state. The UA's behavior upon the reception of the 367 CANCEL request is explained further in Appendix C. 369 Confirmed (Con): The sending or receiving of a 2xx final response 370 establishes a dialog. The dialog starts in this state. The 371 Confirmed state transitions to the Mortal state, a substate of the 372 Terminated state, by sending or receiving a BYE request. The 373 Confirmed state has two substates, the Moratorium and the 374 Established states, which are different with regard to the 375 messages that UAs are allowed to send. 377 Moratorium (Mora): The Moratorium state is a substate of the 378 Confirmed state and inherits its behavior. The Moratorium state 379 transitions to the Established state by sending or receiving an 380 ACK request. The UAC may send an ACK and the UAS may send a 2xx 381 final response. 383 Established (Est): The Established state is a substate of the 384 Confirmed state and inherits its behavior. Both caller and callee 385 may send various messages which influence a dialog. The caller 386 supports the transmission of ACK to the retransmission of a 2xx 387 response to an ini-INVITE. 389 Terminated (Ter): The Terminated state is subdivided into two 390 substates, the Mortal and Morgue states, to cover the behavior 391 when a dialog is being terminated. In this state, the UA holds 392 information about the dialog which is being terminated. 394 Mortal (Mort): The caller and callee enter the Mortal state by 395 sending or receiving a BYE. The UA MUST NOT send any new requests 396 within the dialog because there is no dialog. (Here the new 397 requests do not include ACK for 2xx and BYE for 401 or 407 as 398 further explained in Appendix D below.) In the Mortal state, BYE 399 can be accepted, and the other messages in the INVITE dialog usage 400 are responded with an error. This addresses the case where BYE is 401 sent by both a caller and a callee to exchange reports about the 402 session when it is being terminated. Therefore the UA possesses 403 dialog information for internal processing but the dialog 404 shouldn't be externally visible. The UA stops managing its dialog 405 state and changes it to the Morgue state, when the BYE transaction 406 is terminated. 408 Morgue (Morg): The dialog no longer exists in this state. The 409 sending or receiving of signaling which influences a dialog is not 410 performed. (A dialog is literally terminated.) The caller and 411 callee enter the Morgue state via the termination of the BYE or 412 INVITE transaction. 414 3. Race Conditions 416 This section details a race condition between two SIP UAs, Alice and 417 Bob. Alice (sip:alice@atlanta.example.com) and Bob 418 (sip:bob@biloxi.example.com) are assumed to be SIP phones or SIP- 419 enabled devices. Only significant signaling is illustrated. Dialog 420 state transitions caused by the sending or receiving of SIP messages 421 are shown and race conditions are indicated by '*race*'. (For 422 abbreviations for the dialog state transitions, refer to Section 2.) 423 '*race*' indicates the moment when a race condition occurs. 425 Examples of race conditions are described below. 427 3.1. Receiving message in the Moratorium State 429 This section shows some examples of call flow race conditions when 430 receiving messages from other states while in the Moratorium state. 432 3.1.1. Receiving Initial INVITE retransmission (Preparative state) 433 while in the Moratorium state 435 State Alice Bob State 436 | | 437 | ini-INVITE F1 | 438 |------------------------------------>| 439 Pre | 180 F2(Packet loss) | Pre 440 | x<-----------------------| 441 | | Ear 442 | ini-INVITE F4(=F1) 200 F3 | 443 |------------------ --------------| 444 | \ / | Mora 445 | X | 446 | / \ | 447 |<----------------- ------------->| *race* 448 Mora | ACK F5 | 449 |------------------------------------>| 450 Est | | Est 451 | | 453 This scenario illustrates the race condition which occurs when the 454 UAS receives a Preparative message while in the Moratorium state. 455 All provisional responses to the initial INVITE (ini-INVITE F1) are 456 lost, and the UAC retransmits an ini-INVITE (F4). At the same time 457 as this retransmission, the UAS generates a 200 OK (F3) to the ini- 458 INVITE and terminates the INVITE server transaction, according to 459 Section 13.3.1.4 of RFC 3261 [1]. 461 However, it is reported that terminating an INVITE server transaction 462 when sending 200 OK is a SIP bug. (http://bugs.sipit.net, #769) 463 Therefore, the INVITE server transaction is not terminated by F3, and 464 the F4 MUST be handled properly as a retransmission. (UAs that do 465 not deal with this bug still need to recognize the dialog by relying 466 on its From tag and Call-ID, and the retransmitted request by relying 467 on the CSeq header field value even though it does not match the 468 transaction.) 470 In RFC 3261 [1], it is not specified whether UAS retransmits 200 to 471 the retransmission of ini-INVITE. Considering the retransmission of 472 200 triggered by a timer (the TU keeps retransmitting 200 based on T1 473 and T2 until it receives an ACK), according to Section 13.3.1.4 of 474 RFC 3261 [1], it seems unnecessary to retransmit 200 when the UAS 475 receives the retransmission of ini-INVITE. (For implementation, it 476 does not matter if the UAS sends the retransmission of 200, since the 477 200 does not cause any problem.) 479 Message Details 481 F1 INVITE Alice -> Bob 483 F2 180 Ringing Bob -> Alice 485 /* 180 response is lost and does not reach Alice. */ 487 F3 200 OK Bob -> Alice 489 /* According to Section 13.3.1.4 of RFC 3261 [1], the INVITE server 490 transaction is terminated at this point. However, this has been 491 reported as a SIP bug, and the UAS MUST correctly recognize the 492 ini-INVITE (F4) as a retransmission. */ 494 F4 INVITE (retransmission) Alice -> Bob 496 /* F4 is a retransmission of F1. They are exactly the same INVITE 497 request. For UAs that have not dealt with bug report #769 (an 498 INVITE server transaction is terminated when sending 200 to 499 INVITE), this request does not match the transaction as well as 500 the dialog since it does not have a To tag. However, Bob must 501 recognize the retransmitted INVITE correctly, without treating it 502 as a new INVITE. */ 504 F5 ACK Alice -> Bob 506 3.1.2. Receiving CANCEL (Early state) when in Moratorium state 508 State Alice Bob State 509 | | 510 | INVITE F1 | 511 |----------------------------->| 512 Pre | 180 Ringing F2 | Pre 513 |<-----------------------------| 514 Ear | | Ear 515 |CANCEL F3 200(INVITE) F4| 516 |------------ -------------| 517 | \ / | Mora 518 | X | 519 | / \ | 520 |<----------- ------------>| *race* 521 Mora | | 522 | ACK F6 200(CANCEL) F5| 523 |------------ -------------| 524 Est | \ / | 525 | X | 526 | / \ | 527 |<----------- ------------>| 528 | | Est 529 | One Way RTP Media | 530 | (Two Way RTP Media possible) | 531 |<=============================| 532 | BYE F7 | 533 |----------------------------->| 534 Mort | 200 F8 | Mort 535 |<-----------------------------| 536 | ^ ^ | 537 | | Timer K | | 538 | V | | 539 Morg | Timer J | | 540 | V | 541 | | Morg 542 | | 544 This scenario illustrates the race condition which occurs when the 545 UAS receives an Early message, CANCEL, while in the Moratorium state. 546 Alice sends a CANCEL and Bob sends a 200 OK response to the initial 547 INVITE message at the same time. As described in the previous 548 section, according to RFC 3261 [1], an INVITE server transaction is 549 supposed to be terminated by a 200 response, but this has been 550 reported as bug #769. 552 This section describes a case in which an INVITE server transaction 553 is not terminated by a 200 response to the INVITE request. In this 554 case, there is an INVITE transaction which the CANCEL request 555 matches, so a 200 response to the request is sent. This 200 response 556 simply means that the next hop receives the CANCEL request 557 (Successful CANCEL (200) does not mean an INVITE failure). When a 558 UAS has not dealt with bug #769, the UAC MAY receive a 481 response 559 to the CANCEL since there is no transaction which the CANCEL request 560 matches. This 481 simply means that there is no matching INVITE 561 server transaction and CANCEL is not sent to the next hop. 562 Regardless of the success/failure of the CANCEL, Alice checks the 563 final response to the INVITE, and if she receives 200 to the INVITE 564 request she immediately sends a BYE and terminates the dialog. 565 (Section 15, RFC 3261 [1]) 567 From the time F1 is received by Bob until the time that F8 is sent by 568 Bob, media may be flowing one way from Bob to Alice. From the time 569 that an answer is received by Alice from Bob there is the possibility 570 that media may flow from Alice to Bob as well. However, once Alice 571 has decided to cancel the call, she presumably will not send media, 572 so practically speaking the media stream will remain one way. 574 Message Details 576 F1 INVITE Alice -> Bob 578 F2 180 Ringing Bob -> Alice 580 F3 CANCEL Alice -> Bob 582 /* Alice sends a CANCEL in the Early state. */ 584 F4 200 OK (INVITE) Bob -> Alice 586 /* Alice receives a 200 to INVITE (F1) in the Moratorium state. 587 Alice has the potential to send as well as receive media, but in 588 practice will not send because there is an intent to end the call. 589 */ 591 F5 200 OK (CANCEL) Bob -> Alice 593 /* 200 to CANCEL simply means that the CANCEL was received. The 200 594 response is sent, since this case assumes the fix to bug #769 has 595 been made. If an INVITE server transaction is terminated 596 according to the procedure stated in RFC 3261 [1], UAC MAY receive 597 a 481 response instead of 200. */ 599 F6 ACK Alice -> Bob 601 /* INVITE is successful, and the CANCEL becomes invalid. Bob 602 establishes RTP streams. However, the next BYE request 603 immediately terminates the dialog and session. */ 605 F7 BYE Alice -> Bob 607 F8 200 OK Bob -> Alice 609 3.1.3. Receiving BYE (Early state) while in the Moratorium state 611 State Alice Bob State 612 | | 613 | ini-INVITE F1 | 614 |------------------------------->| 615 Pre | 180 F2 | Pre 616 |<-------------------------------| 617 Ear | | Ear 618 | BYE F4 200(INVITE) F3| 619 |------------- --------------| 620 Mort | \ / | Mora 621 | X | 622 | / \ | 623 |<------------ ------------->| *race* 624 | | Mort 625 | ACK F5 200(BYE) F6 | 626 |------------- --------------| 627 | \ / ^ | 628 | X | | 629 | / \ | | 630 |<------------ ------------->| 631 | ^ | | 632 | | Timer K | | 633 | V | | 634 Morg | Timer J | | 635 | V | 636 | | Morg 637 | | 639 This scenario illustrates the race condition which occurs when UAS 640 receives an Early message, BYE, while in the Moratorium state. Alice 641 sends a BYE in the Early state and Bob sends a 200 OK to the initial 642 INVITE request at the same time. Bob receives the BYE in the 643 Confirmed dialog state although Alice sent the request in the Early 644 state (As explained in Section 2 and Appendix A, this behavior is NOT 645 RECOMMENDED). When a proxy is performing forking, the BYE is only 646 able to terminate the early dialog with a particular UA. If the 647 caller wants to terminate all early dialogs instead of only that with 648 a particular UA, it needs to send CANCEL, not BYE. However, it is 649 not illegal to send BYE in the Early state to terminate a specific 650 early dialog if that is the caller's intent. 652 The BYE functions normally even if it is received after the INVITE 653 transaction termination because BYE differs from CANCEL, and is sent 654 not to the request but to the dialog. Alice enters the Mortal state 655 on sending the BYE request, and remains Mortal until the Timer K 656 timeout occurs. In the Mortal state, the UAC does not establish a 657 session, even though it receives a 200 response to the INVITE. Even 658 so, the UAC sends an ACK to 200 in order to complete of the INVITE 659 transaction. The ACK is always sent to complete the three-way 660 handshake of the INVITE transaction (Further explained in Appendix D 661 below). 663 Message Details 665 F1 INVITE Alice -> Bob 667 F2 180 Ringing Bob -> Alice 669 F3 200 OK (ini-INVITE) Bob -> Alice 671 F4 BYE Alice -> Bob 673 /* Alice transitions to the Mortal state upon sending BYE. 674 Therefore, after this, she does not begin a session even though 675 she receives a 200 response with an answer. */ 677 F5 ACK Alice -> Bob 679 F6 200 OK (BYE) Bob -> Alice 681 3.1.4. Receiving re-INVITE (Established state) while in the Moratorium 682 state (case 1) 684 State Alice Bob State 685 | | 686 | ini-INVITE w/offer1 F1 | 687 |------------------------------->| 688 Pre | 180 F2 | Pre 689 |<-------------------------------| 690 Ear | | Ear 691 | 200(ini-INV) w/answer1 F3 | 692 |<-------------------------------| 693 Mora | ACK F4(packet loss) | Mora 694 |-------------------->x | 695 Est | | 696 | re-INVITE F6 200 F5(=F3) | 697 | w/offer2 w/answer1 | 698 |------------- --------------| 699 | \ / | 700 | X | 701 | / \ | 702 |<------------ ------------->| *race* 703 | 200(re-INV) F8| 704 | ACK F7(=F4) w/answer2 | 705 |------------- --------------| 706 | \ / | 707 | X | 708 | / \ | 709 |<------------ ------------->| 710 | ACK (re-INV) F9 | Est 711 |------------------------------->| 712 | | 713 | | 715 This scenario illustrates the race condition which occurs when the 716 UAS receives a re-INVITE request sent from the Established state, 717 while in the Moratorium state. 719 The UAS receives a re-INVITE (w/offer2) before receiving an ACK for 720 ini-INVITE (w/offer1). The UAS sends a 200 OK (w/answer2) to the re- 721 INVITE (F8) because it has sent a 200 OK (w/answer1) to the ini- 722 INVITE (F3, F5) and the dialog has already been established. 723 (Because F5 is a retransmission of F3, SDP negotiation is not 724 performed here.) 726 If a 200 OK to the ini-INVITE contains an offer and the answer is in 727 the ACK, it is recommended that the UA return a 491 to the re-INVITE 728 (refer to Section 3.1.5). (Note: 500 with a Retry-After header may 729 be returned, if the 491 response is understood to indicate request 730 collision. However, 491 is recommended here because 500 applies to 731 so many cases that it is difficult to determine what the real problem 732 was.) As can be seen in Section 3.3.2 below, the 491 response seems 733 to be closely related to session establishment, even in cases other 734 than INVITE cross-over. This example recommends that 200 be sent 735 instead of 491 because it does not have an influence on the session. 736 However, a 491 response can also lead to the same outcome, so either 737 response can be used. 739 Moreover, if UAS doesn't receive an ACK for a long time, it should 740 send a BYE and terminate the dialog. Note that ACK F7 has the same 741 CSeq number as ini-INVITE F1 (See Section 13.2.2.4 of RFC 3261 [1]). 742 The UA should not reject or drop the ACK on grounds of the CSeq 743 number. 745 Note: Here is a hint for implementors to avoid race conditions of 746 this type. That is for the caller to delay sending re-INVITE F6 for 747 some period of time (2 seconds, perhaps), after which the caller can 748 reasonably assume that its ACK has been received. Implementors can 749 decouple the actions of the user (e.g. pressing the hold button) from 750 the actions of the protocol (the sending of re-INVITE F6), so that 751 the UA can behave like this. In this case, it is the implementor's 752 choice as to how long to wait. In most cases, such an implementation 753 may be useful to prevent the type of race condition shown in this 754 section. 756 Message Details 758 F1 INVITE Alice -> Bob 760 INVITE sip:bob@biloxi.example.com SIP/2.0 761 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 762 Max-Forwards: 70 763 From: Alice ;tag=9fxced76sl 764 To: Bob 765 Call-ID: 3848276298220188511@atlanta.example.com 766 CSeq: 1 INVITE 767 Contact: 768 Content-Type: application/sdp 769 Content-Length: 137 771 v=0 772 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 773 s=- 774 c=IN IP4 192.0.2.101 775 t=0 0 776 m=audio 49172 RTP/AVP 0 777 a=rtpmap:0 PCMU/8000 779 /* Detailed messages are shown for the sequence to illustrate the 780 offer and answer examples. */ 782 F2 180 Ringing Bob -> Alice 784 SIP/2.0 180 Ringing 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-Length: 0 794 F3 200 OK Bob -> Alice 796 SIP/2.0 200 OK 797 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 798 ;received=192.0.2.101 799 From: Alice ;tag=9fxced76sl 800 To: Bob ;tag=8321234356 801 Call-ID: 3848276298220188511@atlanta.example.com 802 CSeq: 1 INVITE 803 Contact: 804 Content-Type: application/sdp 805 Content-Length: 133 807 v=0 808 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 809 s=- 810 c=IN IP4 192.0.2.201 811 t=0 0 812 m=audio 3456 RTP/AVP 0 813 a=rtpmap:0 PCMU/8000 815 F4 ACK Alice -> Bob 817 ACK sip:bob@client.biloxi.example.com SIP/2.0 818 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 819 Max-Forwards: 70 820 From: Alice ;tag=9fxced76sl 821 To: Bob ;tag=8321234356 822 Call-ID: 3848276298220188511@atlanta.example.com 823 CSeq: 1 ACK 824 Content-Length: 0 826 /* ACK request is lost. */ 828 F5(=F3) 200 OK Bob -> Alice (retransmission) 830 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 831 received an ACK. */ 833 F6 re-INVITE Alice -> Bob 835 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 836 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 837 Max-Forwards: 70 838 From: Alice ;tag=9fxced76sl 839 To: Bob ;tag=8321234356 840 Call-ID: 3848276298220188511@atlanta.example.com 841 CSeq: 2 INVITE 842 Content-Length: 147 844 v=0 845 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 846 s=- 847 c=IN IP4 192.0.2.101 848 t=0 0 849 m=audio 49172 RTP/AVP 0 850 a=rtpmap:0 PCMU/8000 851 a=sendonly 853 F7(=F4) ACK Alice -> Bob (retransmission) 855 /* "(=F4)" of ACK F7 shows that it is equivalent to F4 in that it is 856 an ACK for F3. This doesn't mean that F4 and F7 must be equal in 857 Via-branch value. Although it is ambiguous whether Via-branch of 858 ACK F7 differs from F4 in RFC3261, it doesn't affect UAS's 859 behavior. */ 861 F8 200 OK (re-INVITE) Bob -> Alice 863 SIP/2.0 200 OK 864 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 865 Max-Forwards: 70 866 From: Alice ;tag=9fxced76sl 867 To: Bob ;tag=8321234356 868 Call-ID: 3848276298220188511@atlanta.example.com 869 CSeq: 2 INVITE 870 Content-Length: 143 872 v=0 873 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com 874 s=- 875 c=IN IP4 192.0.2.201 876 t=0 0 877 m=audio 3456 RTP/AVP 0 878 a=rtpmap:0 PCMU/8000 879 a=recvonly 881 F9 ACK (re-INVITE) Alice -> Bob 883 ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 884 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21 885 Max-Forwards: 70 886 From: Alice ;tag=9fxced76sl 887 To: Bob ;tag=8321234356 888 Call-ID: 3848276298220188511@atlanta.example.com 889 CSeq: 2 ACK 890 Content-Length: 0 892 3.1.5. Receiving re-INVITE (Established state) while in the Moratorium 893 state (case 2) 895 State Alice Bob State 896 | | 897 | ini-INVITE (no offer) F1 | 898 |------------------------------->| 899 Pre | 180 F2 | Pre 900 |<-------------------------------| 901 Ear | | Ear 902 | 200(ini-INV) w/offer1 F3 | 903 |<-------------------------------| 904 Mora | ACK w/answer1 F4(packet loss) | Mora 905 |-------------------->x | 906 Est | | 907 | re-INVITE F6 200 F5(=F3) | 908 | w/offer2 w/offer1 | 909 |------------- --------------| 910 | \ / | 911 | X | 912 | / \ | 913 |<------------ ------------->| 914 | ACK F7(=F4) 491(re-INV) F8| 915 |------------- --------------| 916 | \ / | 917 | X | 918 | / \ | 919 |<------------ ------------->| 920 | ACK (re-INV) F9 | Est 921 |------------------------------->| 922 | | 923 | | 925 This scenario is basically the same as that of Section 3.1.4, but 926 differs in sending an offer in the 200 and an answer in the ACK. In 927 contrast to the previous case, the offer in the 200 (F3) and the 928 offer in the re-INVITE (F6) collide with each other. 930 Bob sends a 491 to the re-INVITE (F6) since he is not able to 931 properly handle a new request until he receives an answer. (Note: 932 500 with Retry-After header may be returned, if the 491 response is 933 understood to indicate request collision. However, 491 is 934 recommended here because 500 applies to so many cases that it is 935 difficult to determine what the real problem was.) The same result 936 will be reached if F6 is an UPDATE with offer. 938 Note: As noted in Section 3.1.4, it may be useful for the caller to 939 delay sending a re-INVITE F6 for some period of time (2 seconds, 940 perhaps), after which the caller may reasonably assume that its ACK 941 has been received, to prevent this type of race condition. 943 Message Details 945 F1 INVITE Alice -> Bob 947 INVITE sip:bob@biloxi.example.com SIP/2.0 948 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 949 Max-Forwards: 70 950 From: Alice ;tag=9fxced76sl 951 To: Bob 952 Call-ID: 3848276298220188511@atlanta.example.com 953 CSeq: 1 INVITE 954 Contact: 955 Content-Length: 0 957 /* The request does not contain an offer. Detailed messages are 958 shown for the sequence to illustrate offer and answer examples. 959 */ 961 F2 180 Ringing Bob -> Alice 963 F3 200 OK Bob -> Alice 965 SIP/2.0 200 OK 966 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 967 ;received=192.0.2.101 968 From: Alice ;tag=9fxced76sl 969 To: Bob ;tag=8321234356 970 Call-ID: 3848276298220188511@atlanta.example.com 971 CSeq: 1 INVITE 972 Contact: 973 Content-Type: application/sdp 974 Content-Length: 133 976 v=0 977 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 978 s=- 979 c=IN IP4 192.0.2.201 980 t=0 0 981 m=audio 3456 RTP/AVP 0 982 a=rtpmap:0 PCMU/8000 983 /* An offer is made in 200. */ 985 F4 ACK Alice -> Bob 987 ACK sip:bob@client.biloxi.example.com SIP/2.0 988 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 989 Max-Forwards: 70 990 From: Alice ;tag=9fxced76sl 991 To: Bob ;tag=8321234356 992 Call-ID: 3848276298220188511@atlanta.example.com 993 CSeq: 1 ACK 994 Content-Type: application/sdp 995 Content-Length: 137 997 v=0 998 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 999 s=- 1000 c=IN IP4 192.0.2.101 1001 t=0 0 1002 m=audio 49172 RTP/AVP 0 1003 a=rtpmap:0 PCMU/8000 1005 /* The request contains an answer, but the request is lost. */ 1007 F5(=F3) 200 OK Bob -> Alice (retransmission) 1009 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 1010 received an ACK. */ 1012 F6 re-INVITE Alice -> Bob 1014 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1015 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1016 Max-Forwards: 70 1017 From: Alice ;tag=9fxced76sl 1018 To: Bob ;tag=8321234356 1019 Call-ID: 3848276298220188511@atlanta.example.com 1020 CSeq: 2 INVITE 1021 Content-Length: 147 1023 v=0 1024 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1025 s=- 1026 c=IN IP4 192.0.2.101 1027 t=0 0 1028 m=audio 49172 RTP/AVP 0 1029 a=rtpmap:0 PCMU/8000 1030 a=sendonly 1032 /* The request contains an offer. */ 1034 F7(=F4) ACK Alice -> Bob (retransmission) 1036 /* A retransmission triggered by the reception of a retransmitted 1037 200. "(=F4)" of ACK F7 shows that it is equivalent to the F4 in 1038 that it is an ACK for F3. This doesn't mean that F4 and F7 are 1039 necessarily equal in Via-branch value. Although it is ambiguous 1040 whether Via-branch of ACK F7 differs from F4 in RFC3261, it 1041 doesn't affect UAS's behavior. */ 1043 F8 491 (re-INVITE) Bob -> Alice 1045 /* Bob sends 491 (Request Pending), since Bob has a pending offer. 1046 */ 1048 F9 ACK (re-INVITE) Alice -> Bob 1050 3.1.6. Receiving BYE (Established state) while in the Moratorium state 1052 State Alice Bob State 1053 | | 1054 | INVITE F1 | 1055 |-------------------------->| 1056 Pre | 180 Ringing F2 | Pre 1057 |<--------------------------| 1058 Ear | | Ear 1059 | 200 OK F3 | 1060 |<--------------------------| 1061 Mora | ACK F4(packet loss) | Mora 1062 |--------------->x | 1063 Est | Both Way RTP Media | 1064 |<=========================>| 1065 | BYE F6 200 F5(=F3)| 1066 |----------- -----------| 1067 Mort | \ / | 1068 | X | 1069 | / \ | 1070 |<---------- ---------->| *race* 1071 |ACK F7(=F4) 200(BYE) F8| Mort 1072 |----------- -----------| 1073 | \ / | 1074 | X | 1075 | / \ | 1076 |<---------- ---------->| 1077 | ^ ^ | 1078 | | Timer K | | 1079 | V | | 1080 Morg | Timer J | | 1081 | V | 1082 | | Morg 1083 | | 1085 This scenario illustrates the race condition which occurs when the 1086 UAS receives an Established message, BYE, while in the Moratorium 1087 state. An ACK request for a 200 OK response is lost (or delayed). 1088 Bob retransmits the 200 OK to the ini-INVITE, and at the same time 1089 Alice sends a BYE request and terminates the session. Upon receipt 1090 of retransmitted 200 OK Alice's UA might be inclined to reestablish 1091 the session. But that is wrong - the session should not be 1092 reestablished when the dialog is in the Mortal state. Moreover, in 1093 the case where the UAS sends an offer in a 200 OK, the UAS should not 1094 start a session again, for the same reason, if the UAS receives a 1095 retransmitted ACK after receiving a BYE. 1097 Note: As noted in Section 3.1.4, there is a hint for implementors to 1098 avoid race conditions of this type. That is for the caller to delay 1099 sending BYE F6 for some period of time (2 seconds, perhaps), after 1100 which the caller can reasonably assume that its ACK has been 1101 received. Implementors can decouple the actions of the user (e.g. 1102 hanging up) from the actions of the protocol (the sending of BYE F6), 1103 so that the UA can behave like this. In this case, it is the 1104 implementor's choice as to how long to wait. In most cases, such an 1105 implementation may be useful to prevent the type of race condition 1106 shown in this section. 1108 Message Details 1110 F1 INVITE Alice -> Bob 1112 F2 180 Ringing Bob -> Alice 1114 F3 200 OK Bob -> Alice 1116 F4 ACK Alice -> Bob 1118 /* ACK request is lost. */ 1120 F5(=F3) 200 OK Bob -> Alice 1122 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 1123 received an ACK. */ 1125 F6 BYE Alice -> Bob 1127 /* Bob retransmits a 200 OK and Alice sends a BYE at the same time. 1128 Alice transitions to the Mortal state, so she does not begin a 1129 session after this even though she receives a 200 response to the 1130 re-INVITE. */ 1132 F7(=F4) ACK Alice -> Bob 1134 /* "(=F4)" of ACK F7 shows that it is equivalent to the F4 in that it 1135 is an ACK for F3. This doesn't mean that F4 and F7 must be equal 1136 in Via-branch value. Although it is ambiguous whether Via-branch 1137 of ACK F7 differs from F4 in RFC3261, it doesn't affect UAS's 1138 behavior. */ 1140 F8 200 OK (BYE) Bob -> Alice 1142 /* Bob sends a 200 OK to the BYE. */ 1144 3.2. Receiving message in the Mortal State 1146 This section shows some examples of call flow race conditions when 1147 receiving messages from other states while in the Mortal state. 1149 3.2.1. Receiving BYE (Established state) while in the Mortal state 1151 State Alice Bob State 1152 | | 1153 | INVITE F1 | 1154 |----------------------->| 1155 Pre | 180 Ringing F2 | Pre 1156 |<-----------------------| 1157 Ear | | Ear 1158 | 200 OK F3 | 1159 |<-----------------------| 1160 Mora | ACK F4 | Mora 1161 |----------------------->| 1162 Est | Both Way RTP Media | Est 1163 |<======================>| 1164 | | 1165 | BYE F5 BYE F6 | 1166 |--------- ----------| 1167 Mort | \ / | Mort 1168 | X | 1169 | / \ | 1170 |<-------- --------->| *race* 1171 | | 1172 | 200 F8 200 F7 | 1173 |--------- ----------| 1174 | \ / | 1175 | X | 1176 | / \ | 1177 |<-------- --------->| 1178 | ^ ^ | 1179 | | Timer K | | 1180 | V | | 1181 Morg | Timer J | | 1182 | V | 1183 | | Morg 1184 | | 1186 This scenario illustrates the race condition which occurs when the 1187 UAS receives an Established message, BYE, while in the Mortal state. 1188 Alice and Bob send a BYE at the same time. A dialog and session are 1189 ended shortly after a BYE request is passed to a client transaction. 1190 As shown in Section 2, the UA remains in the Mortal state. 1192 UAs in the Mortal state return error responses to the requests that 1193 operate within a dialog or session, such as re-INVITE, UPDATE, or 1194 REFER. However, the UA shall return 200 OK to the BYE taking the use 1195 case into consideration where a BYE request is sent by both a caller 1196 and a callee to exchange reports about the session when it is being 1197 terminated. (Since the dialogue and the session both terminate when 1198 a BYE is sent, the choice of sending a 200 or an error response upon 1199 receiving a BYE while in the Mortal state does not affect the 1200 resulting termination. Therefore, even though this example uses a 1201 200 response, other responses can also be used.) 1203 Message Details 1205 F1 INVITE Alice -> Bob 1207 F2 180 Ringing Bob -> Alice 1209 F3 200 OK Bob -> Alice 1211 F4 ACK Alice -> Bob 1213 F5 BYE Alice -> Bob 1215 /* The session is terminated at the moment Alice sends a BYE. The 1216 dialog still exists then, but it is certain to be terminated in a 1217 short period of time. The dialog is completely terminated when 1218 the timeout of the BYE request occurs. */ 1220 F6 BYE Bob -> Alice 1222 /* Bob has also transmitted a BYE simultaneously with Alice. Bob 1223 terminates the session and the dialog. */ 1225 F7 200 OK Bob -> Alice 1226 /* Since the dialog is in the Moratorium state, Bob responds with a 1227 200 to the BYE request. */ 1229 F8 200 OK Alice -> Bob 1231 /* Since Alice has transitioned from the Established state to the 1232 Mortal state by sending a BYE, Alice responds with a 200 to the 1233 BYE request. */ 1235 3.2.2. Receiving re-INVITE (Established state) while in the Mortal 1236 state 1238 State Alice Bob State 1239 | | 1240 | INVITE F1 | 1241 |----------------------->| 1242 Pre | 180 Ringing F2 | Pre 1243 |<-----------------------| 1244 Ear | | Ear 1245 | 200 OK F3 | 1246 |<-----------------------| 1247 Mora | ACK F4 | Mora 1248 |----------------------->| 1249 Est | Both Way RTP Media | Est 1250 |<======================>| 1251 | | 1252 | BYE F5 re-INVITE F6| 1253 |--------- ----------| 1254 Mort | \ / | 1255 | X | 1256 | / \ | 1257 *race* |<-------- --------->| 1258 | | Mort 1259 | 481 F8 200 F7 | 1260 | (re-INV) (BYE) | 1261 |--------- ----------| 1262 | \ / |^ 1263 | X || 1264 | / \ ||Timer J 1265 |<-------- --------->|| 1266 ^| ACK (re-INV) F9 || 1267 ||<-----------------------|| 1268 Timer K|| || 1269 V| || 1270 Morg | |V 1271 | | Morg 1272 | | 1274 This scenario illustrates the race condition which occurs when the 1275 UAS receives an Established message, re-INVITE, while in the Mortal 1276 state. Bob sends a re-INVITE, and Alice sends a BYE at the same 1277 time. The re-INVITE receives a 481 response, since the TU of Alice 1278 has transitioned from the Established state to the Mortal state by 1279 sending BYE. Bob sends an ACK for the 481 response, because the ACK 1280 for error responses is handled by the transaction layer and at the 1281 point of receiving the 481 the INVITE client transaction still 1282 remains (even though the dialog has been terminated). 1284 Message Details 1286 F1 INVITE Alice -> Bob 1288 F2 180 Ringing Bob -> Alice 1290 F3 200 OK Bob -> Alice 1292 F4 ACK Alice -> Bob 1294 F5 BYE Alice -> Bob 1296 /* Alice sends a BYE and terminates the session, and transitions from 1297 the Established state to the Mortal state. */ 1299 F6 re-INVITE Bob -> Alice 1301 /* Alice sends a BYE, and Bob sends a re-INVITE at the same time. 1302 The dialog state transitions to the Mortal state at the moment 1303 Alice sends the BYE, but Bob does not know this until he receives 1304 the BYE. Therefore, the dialog is in the Terminated state from 1305 Alice's point of view, but in the Confirmed state from Bob's point 1306 of view. A race condition occurs. */ 1308 F7 200 OK (BYE) Bob -> Alice 1310 F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob 1312 /* Since Alice is in the Mortal state, she responds with a 481 to the 1313 re-INVITE. */ 1315 F9 ACK (re-INVITE) Bob -> Alice 1317 /* ACK for an error response is handled by Bob's INVITE client 1318 transaction. */ 1320 3.2.3. Receiving 200 OK for re-INVITE (Established state) while in the 1321 Mortal state 1323 State Alice Bob State 1324 | | 1325 | INVITE F1 | 1326 |----------------------->| 1327 Pre | 180 Ringing F2 | Pre 1328 |<-----------------------| 1329 Ear | | Ear 1330 | 200 OK F3 | 1331 |<-----------------------| 1332 Mora | ACK F4 | Mora 1333 |----------------------->| 1334 Est | Both Way RTP Media | Est 1335 |<======================>| 1336 | | 1337 | re-INVITE F5 | 1338 |<-----------------------| 1339 | 200 F7 BYE F6 | 1340 |--------- ----------| 1341 | \ / | Mort 1342 | X | 1343 | / \ | 1344 |<-------- --------->| *race* 1345 Mort | 200 F8 ACK F9 | 1346 | (BYE) (re-INV) | 1347 |--------- ----------| 1348 | ^ \ / | 1349 | | X | 1350 | | / \ | 1351 |<-------- --------->| 1352 | | ^ | 1353 | | Timer K | | 1354 | | V | 1355 | | Timer J | Morg 1356 | V | 1357 Morg | | 1358 | | 1360 This scenario illustrates the race condition which occurs when the 1361 UAS receives an Established message, 200 to a re-INVITE, while in the 1362 Mortal state. Bob sends a BYE immediately after sending a re-INVITE. 1363 (For example, in the case of a telephone application, it is possible 1364 that a user hangs up the phone immediately after refreshing the 1365 session.) Bob sends an ACK for a 200 response to INVITE while in the 1366 Mortal state, completing the INVITE transaction. 1368 Note: As noted in Section 3.1.4, there is a hint for implementators 1369 to avoid race conditions of this type. That is for the UAC to delay 1370 sending a BYE F6 until the re-INVITE transaction F5 completes. 1371 Implementors can decouple the actions of the user (e.g. hanging up) 1372 from the actions of the protocol (the sending of BYE F6), so that the 1373 UA can behave like this. In this case, it is the implementor's 1374 choice as to how long to wait. In most cases, such an implementation 1375 may be useful in preventing the type of race condition described in 1376 this section. 1378 Message Details 1380 F1 INVITE Alice -> Bob 1382 F2 180 Ringing Bob -> Alice 1384 F3 200 OK Bob -> Alice 1386 F4 ACK Alice -> Bob 1388 F5 re-INVITE Bob -> Alice 1390 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1391 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1392 Session-Expires: 300;refresher=uac 1393 Supported: timer 1394 Max-Forwards: 70 1395 From: Bob ;tag=8321234356 1396 To: Alice ;tag=9fxced76sl 1397 Call-ID: 3848276298220188511@atlanta.example.com 1398 CSeq: 1 INVITE 1399 Content-Length: 0 1401 /* Some detailed messages are shown for the sequence to illustrate 1402 that the re-INVITE is handled in the usual manner in the Mortal 1403 state. */ 1405 F6 BYE Bob -> Alice 1406 /* Bob sends BYE immediately after sending the re-INVITE. Bob 1407 terminates the session and transitions from the Established state 1408 to the Mortal state. */ 1410 F7 200 OK (re-INVITE) Alice -> Bob 1412 SIP/2.0 200 OK 1413 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7 1414 ;received=192.0.2.201 1415 Require: timer 1416 Session-Expires: 300;refresher=uac 1417 From: Bob ;tag=8321234356 1418 To: Alice ;tag=9fxced76sl 1419 Call-ID: 3848276298220188511@atlanta.example.com 1420 CSeq: 1 INVITE 1421 Content-Length: 0 1423 /* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE. 1424 A race condition occurs. */ 1426 F8 200 OK (BYE) Alice -> Bob 1428 F9 ACK (re-INVITE) Bob -> Alice 1430 ACK sip:alice@client.atlanta.example.com SIP/2.0 1431 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44 1432 Max-Forwards: 70 1433 From: Bob ;tag=8321234356 1434 To: Alice ;tag=9fxced76sl 1435 Call-ID: 3848276298220188511@atlanta.example.com 1436 CSeq: 2 ACK 1437 Content-Length: 0 1439 /* Bob sends ACK in the Mortal state to complete the three-way 1440 handshake of the INVITE transaction. */ 1442 3.2.4. Receiving ACK (Moratorium state) while in the Mortal state 1444 State Alice Bob State 1445 | | 1446 | ini-INVITE F1 | 1447 |------------------------------->| 1448 Pre | 180 F2 | Pre 1449 |<-------------------------------| 1450 Ear | 200 F3 | Ear 1451 |<-------------------------------| 1452 Mora | | Mora 1453 | ACK F4 BYE F5 | 1454 |------------- --------------| 1455 Est | \ / | Mort 1456 | X | 1457 | / \ | 1458 |<------------ ------------->| *race* 1459 Mort | 200 F6 | 1460 |------------------------------->| 1461 | ^ ^ | 1462 | | Timer K | | 1463 | | V | 1464 | | Timer J | Morg 1465 | V | 1466 Morg | | 1467 | | 1469 This scenario illustrates the race condition which occurs when the 1470 UAS receives an Established message, ACK to 200, while in the Mortal 1471 state. Alice sends an ACK and Bob sends a BYE at the same time. 1472 When the offer is in a 2xx, and the answer is in an ACK, there is a 1473 race condition. A session is not started when the ACK is received 1474 because Bob has already terminated the session by sending a BYE. The 1475 answer in the ACK request is just ignored. 1477 Note: As noted in Section 3.1.4, there is a hint for implementors to 1478 avoid race conditions of this type. Implementors can decouple the 1479 actions of the user (e.g. hanging up) from the actions of the 1480 protocol (the sending of BYE F5), so that the UA can behave like 1481 this. In this case, it is the implementor's choice as to how long to 1482 wait. In most cases, such an implementation may be useful in 1483 preventing the type of race condition described in this section. 1485 Message Details 1487 F1 INVITE Alice -> Bob 1488 F2 180 Ringing Bob -> Alice 1490 F3 200 OK Bob -> Alice 1492 F4 ACK Alice -> Bob 1494 /* RTP streams are established between Alice and Bob */ 1496 F5 BYE Alice -> Bob 1498 F6 200 OK Bob -> Alice 1500 /* Alice sends a BYE and terminates the session and dialog. */ 1502 3.3. Other race conditions 1504 This section shows examples of race conditions that are not directly 1505 related to dialog state transition. In SIP, processing functions are 1506 deployed in three layers, dialog, session, and transaction. They are 1507 related each other, but have to be treated separately. Section 17 of 1508 RFC 3261 [1] details the processing of transactions. This draft has 1509 tried so far to clarify the processing on dialogs. This section 1510 explains race conditions which are related to sessions established 1511 with SIP. 1513 3.3.1. Re-INVITE crossover 1515 Alice Bob 1516 | | 1517 | INVITE F1 | 1518 |--------------------------->| 1519 | 180 Ringing F2 | 1520 |<---------------------------| 1521 | 200 OK F3 | 1522 |<---------------------------| 1523 | ACK F4 | 1524 |--------------------------->| 1525 | Both Way RTP Media | 1526 |<==========================>| 1527 | | 1528 |re-INVITE F5 re-INVITE F6 | 1529 |------------ -------------| 1530 | \ / | 1531 | X | 1532 | / \ | 1533 |<----------- ------------>| 1534 | 491 F8 491 F7 | 1535 |------------ -------------| 1536 | \ / | 1537 | X | 1538 | / \ | 1539 |<----------- ------------>| 1540 | ^ ACK F9 ^ ACK F10| 1541 |--|--------- ----|--------| 1542 | | \ / | | 1543 | | X | | 1544 | | / \ | | 1545 |<-|---------- ---|------->| 1546 | | | | 1547 | |0-2.0 sec | | 1548 | | | | 1549 | v re-INVITE F11(=F6) | 1550 |<------------------|--------| 1551 | 200 OK F12 | | 1552 |-------------------|------->| 1553 | ACK F13 | | 1554 |<------------------|--------| 1555 | | | 1556 | |2.1-4.0 sec 1557 | | | 1558 |re-INVITE F14(=F5) v | 1559 |--------------------------->| 1560 | 200 OK F15 | 1561 |<---------------------------| 1562 | ACK F16 | 1563 |--------------------------->| 1564 | | 1565 | | 1567 In this scenario, Alice and Bob send re-INVITE at the same time. 1568 When two re-INVITEs cross in the same dialog, they are retried, each 1569 after a different interval, according to Section 14.1, of RFC 3261 1570 [1]. When Alice sends the re-INVITE and it crosses with Bob's, the 1571 re-INVITE will be retried after 2.1-4.0 seconds because she owns the 1572 Call-ID (she generated it). Bob will retry his INVITE again after 1573 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID. 1574 Therefore, each user agent must remember whether it has generated the 1575 Call-ID of the dialog or not, in case an INVITE may cross with 1576 another INVITE. 1578 In this example, Alice's re-INVITE is for session modification and 1579 Bob's re-INVITE is for session refresh. In this case, after the 491 1580 responses, Bob retransmits the re-INVITE for session refresh earlier 1581 than Alice. If Alice was to retransmit her re-INVITE (that is, if 1582 she was not the owner of Call-ID), the request would refresh and 1583 modify the session at the same time. Then Bob would know that he 1584 would not need to retransmit his re-INVITE to refresh the session. 1586 In another instance where two re-INVITEs for session modification, 1587 cross over, retransmitting the same re-INVITE again after a 491 by 1588 the Call-ID owner (the UA which retransmits its re-INVITE after the 1589 other UA) may result in unintended behavior, so the UA must decide if 1590 the retransmission of the re-INVITE is necessary. (For example, when 1591 a call hold and an addition of video media cross over, mere 1592 retransmission of the re-INVITE at the firing of the timer may result 1593 in the situation where the video is transmitted immediately after the 1594 holding of the audio. This behavior is probably not intended by the 1595 users.) 1597 Message Details 1599 F1 INVITE Alice -> Bob 1601 F2 180 Ringing Bob -> Alice 1603 F3 200 OK Bob -> Alice 1605 F4 ACK Alice -> Bob 1607 F5 re-INVITE Alice -> Bob 1609 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1610 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1611 Max-Forwards: 70 1612 From: Alice ;tag=9fxced76sl 1613 To: Bob ;tag=8321234356 1614 Call-ID: 3848276298220188511@atlanta.example.com 1615 CSeq: 2 INVITE 1616 Content-Length: 147 1618 v=0 1619 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1620 s=- 1621 c=IN IP4 192.0.2.101 1622 t=0 0 1623 m=audio 49172 RTP/AVP 0 1624 a=rtpmap:0 PCMU/8000 1625 a=sendonly 1627 /* Some detailed messages are shown for the sequence to illustrate 1628 what sort of INVITE requests crossed over each other. */ 1630 F6 re-INVITE Bob -> Alice 1632 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1633 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1634 Session-Expires: 300;refresher=uac 1635 Supported: timer 1636 Max-Forwards: 70 1637 From: Bob ;tag=8321234356 1638 To: Alice ;tag=9fxced76sl 1639 Call-ID: 3848276298220188511@atlanta.example.com 1640 CSeq: 1 INVITE 1641 Content-Length: 0 1643 /* A re-INVITE request for a session refresh and another for a call 1644 hold are sent at the same time. */ 1646 F7 491 Request Pending Bob -> Alice 1648 /* Since a re-INVITE is in progress, a 491 response is returned. */ 1650 F8 491 Request Pending Alice -> Bob 1652 F9 ACK (INVITE) Alice -> Bob 1654 F10 ACK (INVITE) Bob -> Alice 1656 F11 re-INVITE Bob -> Alice 1658 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1659 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 1660 Session-Expires: 300;refresher=uac 1661 Supported: timer 1662 Max-Forwards: 70 1663 From: Bob ;tag=8321234356 1664 To: Alice ;tag=9fxced76sl 1665 Call-ID: 3848276298220188511@atlanta.example.com 1666 CSeq: 2 INVITE 1667 Content-Type: application/sdp 1668 Content-Length: 133 1670 v=0 1671 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1672 s=- 1673 c=IN IP4 192.0.2.201 1674 t=0 0 1675 m=audio 3456 RTP/AVP 0 1676 a=rtpmap:0 PCMU/8000 1678 /* Since Bob is not the owner of the Call-ID, he sends a re-INVITE 1679 again after 0.0-2.0 seconds. */ 1681 F12 200 OK Alice -> Bob 1683 F13 ACK Bob -> Alice 1685 F14 re-INVITE Alice -> Bob 1687 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1688 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1689 Max-Forwards: 70 1690 From: Alice ;tag=9fxced76sl 1691 To: Bob ;tag=8321234356 1692 Call-ID: 3848276298220188511@atlanta.example.com 1693 CSeq: 3 INVITE 1694 Content-Length: 147 1696 v=0 1697 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1698 s=- 1699 c=IN IP4 192.0.2.101 1700 t=0 0 1701 m=audio 49172 RTP/AVP 0 1702 a=rtpmap:0 PCMU/8000 1703 a=sendonly 1705 /* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE 1706 again after 2.1-4.0 seconds. */ 1708 F15 200 OK Bob -> Alice 1710 F16 ACK Alice -> Bob 1712 3.3.2. UPDATE and re-INVITE crossover 1714 Alice Bob 1715 | | 1716 | INVITE F1 | 1717 |--------------------------->| 1718 | 180 Ringing F2 | 1719 |<---------------------------| 1720 | | 1721 | 200 OK F3 | 1722 |<---------------------------| 1723 | ACK F4 | 1724 |--------------------------->| 1725 | Both Way RTP Media | 1726 |<==========================>| 1727 | | 1728 | UPDATE F5 re-INVITE F6 | 1729 |------------ -------------| 1730 | \ / | 1731 | X | 1732 | / \ | 1733 |<----------- ------------>| 1734 | 491 F8 491 F7 | 1735 | (re-INVITE) (UPDATE) | 1736 |------------ -------------| 1737 | \ / | 1738 | X | 1739 | / \ | 1740 |<----------- ------------>| 1741 | ^ ACK F9 ^ | 1742 |<-|----------------|--------| 1743 | | | | 1744 | |0-2.0 sec | | 1745 | | | | 1746 | v re-INVITE F10 | | 1747 |<------------------|--------| 1748 | 200 OK F11 | | 1749 |-------------------|------->| 1750 | ACK F12 | | 1751 |<------------------|--------| 1752 | | | 1753 | |2.1-4.0 sec 1754 | | | 1755 | UPDATE F13 v | 1756 |--------------------------->| 1757 | 200 OK F14 | 1758 |<---------------------------| 1759 | | 1760 | | 1762 In this scenario, the UPDATE contains an SDP offer, therefore the 1763 UPDATE and re-INVITE are both responded to with 491 as in the case of 1764 "re-INVITE crossover". When an UPDATE for session refresh which 1765 doesn't contain a session description and a re-INVITE cross each 1766 other, both requests succeed with 200 (491 means that a UA has a 1767 pending request). The same is true for UPDATE crossover. In the 1768 former case where either UPDATE contains a session description the 1769 requests fail with 491, and in the latter cases succeed with 200. 1771 Note: 1772 A 491 response is sent because an SDP offer is pending, and 491 is 1773 an error which is related to matters that impact the session 1774 established by SIP. 1776 Message Details 1778 F1 INVITE Alice -> Bob 1780 F2 180 Ringing Bob -> Alice 1782 F3 200 OK Bob -> Alice 1784 F4 ACK Alice -> Bob 1786 F5 UPDATE Alice -> Bob 1788 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1789 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1790 Max-Forwards: 70 1791 From: Alice ;tag=9fxced76sl 1792 To: Bob ;tag=8321234356 1793 Call-ID: 3848276298220188511@atlanta.example.com 1794 CSeq: 2 UPDATE 1795 Content-Length: 147 1797 v=0 1798 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1799 s=- 1800 c=IN IP4 192.0.2.101 1801 t=0 0 1802 m=audio 49172 RTP/AVP 0 1803 a=rtpmap:0 PCMU/8000 1804 a=sendonly 1806 /* Some detailed messages are shown for the sequence to illustrate 1807 messages crossing over each other. */ 1809 F6 re-INVITE Bob -> Alice 1811 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1812 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 1813 Session-Expires: 300;refresher=uac 1814 Supported: timer 1815 Max-Forwards: 70 1816 From: Bob ;tag=8321234356 1817 To: Alice ;tag=9fxced76sl 1818 Call-ID: 3848276298220188511@atlanta.example.com 1819 CSeq: 1 INVITE 1820 Content-Length: 0 1822 /* A case where a re-INVITE for a session refresh and a UPDATE for a 1823 call hold are sent at the same time. */ 1825 F7 491 Request Pending (UPDATE) Bob -> Alice 1827 /* Since a re-INVITE is in process, a 491 response is returned. */ 1829 F8 491 Request Pending (re-INVITE) Alice -> Bob 1831 F9 ACK (re-INVITE) Alice -> Bob 1833 F10 re-INVITE Bob -> Alice 1835 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1836 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 1837 Session-Expires: 300;refresher=uac 1838 Supported: timer 1839 Max-Forwards: 70 1840 From: Bob ;tag=8321234356 1841 To: Alice ;tag=9fxced76sl 1842 Call-ID: 3848276298220188511@atlanta.example.com 1843 CSeq: 2 INVITE 1844 Content-Type: application/sdp 1845 Content-Length: 133 1846 v=0 1847 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1848 s=- 1849 c=IN IP4 192.0.2.201 1850 t=0 0 1851 m=audio 3456 RTP/AVP 0 1852 a=rtpmap:0 PCMU/8000 1854 /* Since Bob is not the owner of the Call-ID, Bob sends an INVITE 1855 again after 0.0-2.0 seconds. */ 1857 F11 200 OK Alice -> Bob 1859 F12 ACK Bob -> Alice 1861 F13 UPDATE Alice -> Bob 1863 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1864 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 1865 Max-Forwards: 70 1866 From: Alice ;tag=9fxced76sl 1867 To: Bob ;tag=8321234356 1868 Call-ID: 3848276298220188511@atlanta.example.com 1869 CSeq: 3 UPDATE 1870 Content-Length: 147 1872 v=0 1873 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1874 s=- 1875 c=IN IP4 192.0.2.101 1876 t=0 0 1877 m=audio 49172 RTP/AVP 0 1878 a=rtpmap:0 PCMU/8000 1879 a=sendonly 1881 /* Since Alice is the owner of the Call-ID, Alice sends the UPDATE 1882 again after 2.1-4.0 seconds. */ 1884 F14 200 OK Bob -> Alice 1886 3.3.3. Receiving REFER (Established state) while in the Mortal state 1888 State Alice Bob State 1889 | | 1890 | INVITE F1 | 1891 |----------------------->| 1892 Pre | 180 Ringing F2 | Pre 1893 |<-----------------------| 1894 Ear | | Ear 1895 | 200 OK F3 | 1896 |<-----------------------| 1897 Mora | ACK F4 | Mora 1898 |----------------------->| 1899 Est | Both Way RTP Media | Est 1900 |<======================>| 1901 | | 1902 | BYE F5 REFER F6 | 1903 |--------- ----------| 1904 Mort | \ / | 1905 | X | 1906 | / \ | 1907 *race* |<-------- --------->| 1908 | | Mort 1909 | 481 F8 200 F7 | 1910 | (REFER) (BYE) | 1911 |--------- ----------| 1912 | \ / ^ | 1913 | X | | 1914 | / \ | | 1915 |<-------- --------->| 1916 | ^ | | 1917 | | Timer K | | 1918 | V Timer J | | 1919 Morg | V | 1920 | | Morg 1921 | | 1923 This scenario illustrates the race condition which occurs when the 1924 UAS receives an Established message, REFER, while in the Mortal 1925 state. Bob sends a REFER, and Alice sends a BYE at the same time. 1926 Bob sends the REFER in the same dialog. Alice's dialog state moves 1927 to the Mortal state at the point of sending BYE. In the Mortal 1928 state, the UA possesses dialog information for an internal process 1929 but the dialog shouldn't exist outwardly. Therefore, the UA sends an 1930 error response to the REFER, which is transmitted as a mid-dialog 1931 request. So Alice, in the Mortal state, sends an error response to 1932 the REFER. However, Bob has already started the SUBSCRIBE usage with 1933 REFER, so the dialog continues until the SUBSCRIBE usage terminates, 1934 even though the INVITE dialog usage terminates by receiving BYE. 1935 Bob's behavior in this case needs to follow the procedures in RFC 1936 5057 [6]. 1938 Message Details 1940 F1 INVITE Alice -> Bob 1942 F2 180 Ringing Bob -> Alice 1944 F3 200 OK Bob -> Alice 1946 F4 ACK Alice -> Bob 1948 F5 BYE Alice -> Bob 1950 /* Alice sends a BYE request and terminates the session, and 1951 transitions from the Confirmed state to the Terminated state. */ 1953 F6 REFER Bob -> Alice 1955 /* Alice sends a BYE, and Bob sends a REFER at the same time. Bob 1956 sends the REFER on the INVITE dialog. The dialog state 1957 transitions to the Mortal state at the moment Alice sends the BYE, 1958 but Bob doesn't know this until he receives the BYE. A race 1959 condition occurs. */ 1961 F7 200 OK (BYE) Bob -> Alice 1963 F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob 1965 /* Alice in the Mortal state sends a 481 to the REFER. */ 1967 4. IANA Considerations 1969 This document has no actions for IANA. 1971 5. Security Considerations 1973 This document contains clarifications of behavior specified in RFC 1974 3261 [1], RFC 3264 [2] and RFC 3515 [4]. The security considerations 1975 of those documents continue to apply after the application of these 1976 clarifications. 1978 6. Acknowledgements 1980 The authors would like to thank Robert Sparks, Dean Willis, Cullen 1981 Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, Akihiro 1982 Shimizu, Mayumi Munakata, Yasunori Inagaki, Tadaatsu Kidokoro, 1983 Kenichi Hiragi, Dale Worley, Vijay K. Gurbani and Anders Kristensen 1984 for their comments on this document. 1986 7. References 1988 7.1. Normative References 1990 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1991 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1992 Session Initiation Protocol", RFC 3261, June 2002. 1994 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1995 Session Description Protocol (SDP)", RFC 3264, June 2002. 1997 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1998 Levels", BCP 14, RFC 2119, March 1997. 2000 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2001 Method", RFC 3515, April 2003. 2003 [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 2004 Responses in Session Initiation Protocol (SIP)", RFC 3262, 2005 June 2002. 2007 7.2. Informative References 2009 [6] Sparks, R., "Multiple Dialog Usages in the Session Initiation 2010 Protocol", RFC 5057, November 2007. 2012 Appendix A. BYE in the Early Dialog 2014 This section, related to Section 3.1.3, explains why BYE is not 2015 recommended in the Early state, illustrating a case in which a BYE in 2016 the early dialog triggers confusion. 2018 Alice Proxy Bob Carol 2019 | | | | 2020 | INVITE F1 | | | 2021 |--------------->| INVITE F2 | | 2022 | 100 F3 |----------------->| | 2023 |<---------------| 180(To tag=A) F4 | | 2024 | 180(A) F5 |<-----------------| | 2025 |<---------------| | | 2026 | | INVITE(Fork) F6 | 2027 | |------------------------>| 2028 | | 100 F7 | 2029 | BYE(A) F8 |<------------------------| 2030 |--------------->| BYE(A) F9 | | 2031 | |----------------->| | 2032 | | 200(A,BYE) F10 | | 2033 | 200(A,BYE) F11 |<-----------------| | 2034 |<---------------| 487(A,INV) F12 | | 2035 | |<-----------------| | 2036 | | ACK(A) F13 | | 2037 | |----------------->| | 2038 | | | | 2039 | | | 2040 | | 200(To tag=B) F13 | 2041 | 200(B) F14 |<------------------------| 2042 |<---------------| | 2043 | ACK(B) F15 | | 2044 |--------------->| ACK(B) F16 | 2045 | |------------------------>| 2046 | BYE(B) F17 | | 2047 |--------------->| BYE(B) F18 | 2048 | |------------------------>| 2049 | | 200(B) F19 | 2050 | 200(B) F20 |<------------------------| 2051 |<---------------| | 2052 | | | 2053 | | | 2055 Care is advised in sending BYE in the Early state when forking by a 2056 proxy is expected. In this example, the BYE request progresses 2057 normally, and it succeeds in correctly terminating the dialog with 2058 Bob. After Bob terminates the dialog by receiving the BYE, he sends a 2059 487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261 [1], 2060 it is RECOMMENDED for the UAS to generate a 487 to any pending 2061 requests after receiving a BYE. In the example, Bob sends a 487 to 2062 the ini-INVITE since he receives the BYE while the ini-INVITE is in 2063 pending state. 2065 However, Alice receives a final response to the INVITE (a 200 from 2066 Carol) even though she has successfully terminated the dialog with 2067 Bob. This means that, regardless of the success/failure of the BYE in 2068 the Early state, Alice MUST be prepared for the establishment of a 2069 new dialog until receiving the final response for the INVITE and 2070 terminating the INVITE transaction. 2072 It is not illegal to send a BYE in the Early state to terminate a 2073 specific early dialog - it may satisfy the intent of some callers. 2074 However, the choice of BYE or CANCEL in the Early state must be made 2075 carefully. CANCEL is appropriate when the goal is to abandon the 2076 call attempt entirely. BYE is appropriate when the goal is to 2077 abandon a particular early dialog while allowing the call to be 2078 completed with other destinations. When using either BYE or CANCEL 2079 the UAC must be prepared for the possibility that a call may still be 2080 established to one (or more) destinations. 2082 Appendix B. BYE request overlapping with re-INVITE 2084 UAC UAS 2085 | | 2086 The session has been already established 2087 ========================== 2088 | re-INVITE F1 | 2089 |--------------------->| 2090 | BYE F2 | 2091 |--------------------->| 2092 | 200(BYE) F3 | 2093 |<---------------------| 2094 | INVITE F4(=F1) | 2095 |--------------------->| 2096 | | 2097 | | 2099 This case could look similar to the one in Section 3.2.3. However, 2100 it is not a race condition. This case describes the behavior when 2101 there is no response to the INVITE for some reason. The appendix 2102 explains the behavior in this case and its rationale, since this case 2103 is likely to cause confusion. 2105 First of all, it is important not to confuse the behavior of the 2106 transaction layer and that of the dialog layer. RFC 3261 [1] details 2107 the transaction layer behavior. The dialog layer behavior is 2108 explained in this document. It has to be noted that these two 2109 behaviors are independent of each other, even though both layers may 2110 be triggered to change their states by sending or receiving the same 2111 SIP messages. (A dialog can be terminated even though a transaction 2112 still remains, and vice versa.) 2114 In the sequence above, there is no response to F1, and F2 (BYE) is 2115 sent immediately after F1 (F1 is a mid-dialog request. If F1 was an 2116 ini-INVITE, BYE could not be sent before the UAC received a 2117 provisional response to the request with a To tag). 2119 Below is a figure which illustrates the UAC's dialog state and the 2120 transaction state. 2122 BYE INV dialog UAC UAS 2123 : | | 2124 : | | 2125 | | re-INVITE F1 | 2126 o | |--------------------->| 2127 | | | BYE F2 | 2128 o | (Mortal) |--------------------->| 2129 | | | | 200(BYE) F3 | 2130 | | | |<---------------------| 2131 | | | | INVITE F4(=F1) | 2132 | | | |--------------------->| 2133 | | | | 481(INV) F5 | 2134 | | | |<---------------------| 2135 | | | | ACK(INV) F6 | 2136 | | | |--------------------->| 2137 | | | | | 2138 o | o | | 2139 | | | 2140 o | | 2141 | | 2143 For the UAC, the INVITE client transaction begins at the point F1 is 2144 sent. The UAC sends BYE (F2) immediately after F1. This is a 2145 legitimate behavior. (Usually the usage of each SIP method is 2146 independent, for BYE and others. However, it should be noted that it 2147 is prohibited to send a request with an SDP offer while the previous 2148 offer is in progress.) 2150 After that, F2 triggers the BYE client transaction. At the same 2151 time, the dialog state transitions to the Mortal state and then only 2152 a BYE or a response to a BYE can be handled. 2154 It is permitted to send F4 (a retransmission of INVITE) in the Mortal 2155 state, because the retransmission of F1 is handled by the transaction 2156 layer, and the INVITE transaction has not yet transitioned to the 2157 Terminated state. As is mentioned above, the dialog and the 2158 transaction behave independently each other. Therefore the 2159 transaction handling has to be continued even though the dialog has 2160 moved to the Terminated state. 2162 Note: As noted in Section 3.1.4, there is a hint for implementation 2163 to avoid this case. That is for the UAC to delay sending BYE F2 2164 until the re-INVITE transaction F1 completes. Implementors can 2165 decouple the actions of the user (e.g. hanging up) from the actions 2166 of the protocol (the sending of BYE F2), so that the UA can behave 2167 like this. In this case, it is the implementor's choice as to how 2168 long to wait. In most cases, such an implementation may be useful to 2169 prevent this case. 2171 Next, the UAS's state is shown below. 2173 UAC UAS dialog INV BYE 2174 | | : 2175 | | : 2176 | re-INVITE F1 | | 2177 |-------------->x | | 2178 | BYE F2 | | 2179 |--------------------->| | o 2180 | 200(BYE) F3 | (Mortal) | 2181 |<---------------------| | |<-Start Timer J 2182 | INVITE F4(=F1) | | | 2183 |--------------------->| | o | 2184 | 4xx/5xx(INV) F5 | o | o 2185 |<---------------------| | 2186 | ACK(INV) F6 | | 2187 |--------------------->| |<-Start Timer I 2188 | | | 2189 | | | 2190 | | o 2191 | | 2193 For the UAS, it can be considered that packet the F1 is lost or 2194 delayed (here the behavior is explained for the case that the UAS 2195 receives F2 BYE before F1 INVITE). Therefore, F2 triggers the BYE 2196 transaction for UAS, and simultaneously the dialog moves to the 2197 Mortal state. Then, upon the reception of F4 the INVITE server 2198 transaction begins. (It is permitted to start the INVITE server 2199 transaction in the Mortal state. The INVITE server transaction 2200 begins to handle the received SIP request regardless of the dialog 2201 state.) The UAS's TU sends an appropriate error response for the F4 2202 INVITE, either 481 (because the TU knows that the dialog which 2203 matches the INVITE is in the Terminated state) or 500 (because the 2204 re-sent F4 has an out-of-order CSeq). (It is mentioned above that 2205 INVITE message F4 (and F1) is a mid-dialog request. Mid-dialog 2206 requests have a To tag. It should be noted that the UAS's TU does 2207 not begin a new dialog upon the reception of INVITE with a To tag.) 2209 Appendix C. UA's behavior for CANCEL 2211 This section explains the CANCEL behaviors which indirectly impact 2212 the dialog state transition in the Early state. CANCEL does not have 2213 any influence on the UAC's dialog state. However, the request has a 2214 indirect influence on the dialog state transition because it has a 2215 significant effect on ini-INVITE. For the UAS the CANCEL request has 2216 more direct effects on the dialog than the sending of a CANCEL by the 2217 UAC, because it can be a trigger to send the 487 response. Figure 3 2218 explains UAS's behavior in the Early state. This flow diagram is 2219 only an explanatory figure, and the actual dialog state transition is 2220 as illustrated in Figures 1 and 2. 2222 In the flow, full lines are related to dialog state transition, and 2223 dotted lines are involved with CANCEL. (r) represents the reception 2224 of signaling, and (s) means sending. There is no dialog state for 2225 CANCEL, but here the Cancelled state is handled virtually just for 2226 the ease of understanding of the UA's behavior when it sends and 2227 receives CANCEL. 2229 +-------------+ 2230 | Preparative |---+ 2231 +-------------+ | 2232 : | 1xx(s) | 2233 : V | 2234 : +-------+ | 2xx(s) 2235 : | Early |-----+------+ 2236 : +-------+ | 2237 : : V 2238 : : +-----------+ 2239 : : | Confirmed |<... 2240 :.....: +-----------+ : 2241 : | : : 2242 : BYE(r)| : : 2243 : CANCEL(r) | :.......: 2244 V | CANCEL(r) 2245 ............. | 2246 : Cancelled : | 2247 :...........: | 2248 | 487(s) | 2249 | | 2250 +--------------------+ 2251 | 2252 V 2253 +------------+ 2254 | Terminated | 2255 +------------+ 2257 Figure 3: CANCEL flow diagram for UAS 2259 There are two behaviors for the UAS depending on the state when it 2260 receives a CANCEL. 2262 The first behavior is when the UAS receives a CANCEL in the Early 2263 state. In this case the UAS immediately sends a 487 for the INVITE, 2264 and the dialog transitions to the Terminated state. 2266 The other is the case in which the UAS receives a CANCEL while in the 2267 Confirmed state. In this case the dialog state transition does not 2268 occur because UAS has already sent a final response to the INVITE to 2269 which the CANCEL is targeted. (Note that, because of the UAC's 2270 behavior, a UAS that receives a CANCEL in the Confirmed state can 2271 expect to receive a BYE immediately and move to the Terminated state. 2272 However, the UAS's state does not transition until it actually 2273 receives a BYE.) 2275 Appendix D. Notes on the request in the Mortal state 2277 This section describes the UA's behavior in the Mortal state, which 2278 needs careful attention. Note that every transaction completes 2279 independently of others, following the principle of RFC 3261 [1]. 2281 In the Mortal state, only a BYE can be accepted, and the other 2282 messages in the INVITE dialog usage are responded to with an error. 2283 However, sending of ACK and the authentication procedure for BYE are 2284 conducted in this state. (The handling of messages concerning 2285 multiple dialog usages is out of the scope of this document. Refer 2286 to RFC 5057 [6] for further information.) 2288 ACK for error responses is handled by the transaction layer, so the 2289 handling is not related to the dialog state. Unlike the ACK for 2290 error responses, ACK for 2xx responses is a request newly generated 2291 by a TU. However, the ACK for 2xx and the ACK for error responses 2292 are both a part of the INVITE transaction, even though their handling 2293 differs (Section 17.1.1.1, RFC 3261 [1]). Therefore, the INVITE 2294 transaction is completed by the three-way handshake, which includes 2295 ACK, even in the Mortal state. 2297 Considering actual implementation, the UA needs to keep the INVITE 2298 dialog usage until the Mortal state finishes, so that it is able to 2299 send ACK for a 2xx response in the Mortal state. If a 2xx to INVITE 2300 is received in the Mortal state, the duration of the INVITE dialog 2301 usage will be extended to 64*T1 seconds after the receiving of the 2302 2xx, to cope with the possible 2xx retransmission. (The duration of 2303 the 2xx retransmission is 64*T1, so the UA needs to be prepared to 2304 handle the retransmission for this duration.) However, the UA shall 2305 send an error response to other requests, since the INVITE dialog 2306 usage in the Mortal state is kept only for the sending of ACK for 2307 2xx. 2309 The BYE authentication procedure shall be processed in the Mortal 2310 state. When authentication is requested by a 401 or 407 response, 2311 UAC resends BYE with appropriate credentials. Also the UAS handles 2312 the retransmission of the BYE for which it requested authentication. 2314 Appendix E. Forking and receiving new To tags 2316 This section details the behavior of the TU when it receives multiple 2317 responses with a different To tag to ini-INVITE. 2319 When an INVITE is forked inside a SIP network, there is a possibility 2320 that the TU receives multiple responses to the ini-INVITE with 2321 differing To tags (See Section 12.1, 13.1, 13.2.2.4, 16.7, 19.3, etc. 2323 of RFC 3261 [1]). If the TU receives multiple 1xx responses with 2324 different To tags, the original DSM forks and a new DSM instance is 2325 created. As a consequence multiple early dialogs are generated. 2327 If one of the multiple early dialogs receives a 2xx response, it 2328 naturally transitions to the Confirmed state. No DSM state 2329 transition occurs for the other early dialogs, and their sessions 2330 (early media) terminate. The TU of the UAC terminates the INVITE 2331 transaction after 64*T1 seconds starting at the point of receiving 2332 the first 2xx response. Moreover, all mortal early dialogs which do 2333 not transition to the Established state are terminated (See Section 2334 13.2.2.4 of RFC 3261 [1]). By "mortal early dialog" we mean any 2335 early dialog that the UA will terminate when another early dialog is 2336 confirmed. 2338 Below is an example sequence in which two 180 responses with 2339 different To tags are received, and then a 200 response for one of 2340 the early dialogs (dialog A) is received. Dotted lines (..) in the 2341 sequences are auxiliary lines to represent the influence on dialog B. 2343 UAC 2344 dialog(A) | INVITE F1 2345 Pre o |-------------------------> 2346 | | 100 F2 2347 | |<------------------------- 2348 | | 180(To tag=A) F3 2349 Ear | |<------------------------- 2350 dialog(B) | | 2351 forked new DSM | | 180(To tag=B) F4 2352 Ear o..........|..........|<------------------------- 2353 | | | 2354 | | | 200(A) F5 2355 terminate->|.....Mora |..........|<------------------------- 2356 early | | ^ | ACK(A) F6 2357 media | Est | | |-------------------------> 2358 | | | | 2359 | | |64*T1 | 2360 | | |(13.2.2.4 of RFC 3261 [1]) 2361 | | | | 2362 | | | | 2363 | | V | 2364 o..........|.(terminate INVITE transaction) 2365 terminated | | 2366 dialog(B) | | 2367 | | 2369 Figure 4: Receiving 1xx responses with different To tags 2371 The figure above shows the DSM inside a SIP TU. Triggered by the 2372 reception of a provisional response with a different To tag (F4 2373 180(To tag=B)), the DSM forks and the early dialog B is generated. 2374 64*T1 seconds later dialog A receives a 200 OK response. Dialog B, 2375 which does not transition to the Established state, terminates. 2377 Next, the behavior of a TU which receives multiple 2xx responses with 2378 different To tags is explained. When a mortal early dialog, which 2379 did not match the first 2xx response that the TU received, receives 2380 another 2xx response which matches its To tag before the 64*T1 INVITE 2381 transaction timeout, its DSM transitions to the Confirmed state. 2382 However, the session on the mortal early dialog is terminated when 2383 the TU receives the first 2xx to establish a dialog, so no session is 2384 established for the mortal early dialog. Therefore, when the mortal 2385 early dialog receives a 2xx response, the TU sends an ACK and, 2386 immediately after, the TU usually sends a BYE to terminate the DSM. 2387 (In special cases, e.g. if a UA intends to establish multiple 2388 dialogs, the TU may not send the BYE.) 2390 The handling of the second early dialog after receiving the 200 for 2391 the first dialog is quite appropriate for a typical device, such as a 2392 phone. It is important to note that what is being shown is a typical 2393 useful action and not the only valid one. Some devices might want to 2394 handle things differently. For instance, a conference focus that has 2395 sent out an INVITE that forks may want to accept and mix all the 2396 dialogs it gets. In that case, no early dialog is treated as mortal. 2398 Below is an example sequence in which two 180 responses with a 2399 different To tag are received and then a 200 response for each of the 2400 early dialogs is received. 2402 UAC 2403 dialog(A) | INVITE F1 2404 Pre o |-----------------------> 2405 | | 100 F2 2406 | |<----------------------- 2407 | | 180(To tag=A) F3 2408 dialog(B) Ear | |<----------------------- 2409 forked new DSM | | 180(To tag=B) F4 2410 Ear o..........|..........|<----------------------- 2411 | | | 2412 | | | 200(A) F5 2413 terminate->|.....Mora |..........|<----------------------- 2414 early | | ^ | ACK(A) F6 2415 media | Est | | |-----------------------> 2416 | | |64*T1 | 2417 | | | | 200(B) F7 2418 Mora |..........|.|........|<----------------------- 2419 | | | | ACK(B) F8 2420 Est |..........|.|........|-----------------------> 2421 | | | | BYE(B) F9 2422 Mort |..........|.|........|-----------------------> 2423 ^ | | | | 200(B) F10 2424 | | | | |<----------------------- 2425 |Timer K | | | 2426 | | | V | 2427 | | | (terminate INVITE transaction) 2428 V | | | 2429 Morg o | | 2430 | | 2432 Figure 5: Receiving 1xx and 2xx responses with different To tags 2434 Below is an example sequence when a TU receives multiple 200 2435 responses with different To tags before the 64*T1 timeout of the 2436 INVITE transaction in the absence of a provisional response. Even 2437 though a TU does not receive a provisional response, the TU needs to 2438 process the 2xx responses (See Section 13.2.2.4 of RFC 3261 [1]). In 2439 that case, the DSM state is forked at the Confirmed state, and then 2440 the TU sends an ACK for the 2xx response and, immediately after, the 2441 TU usually sends a BYE. (In special cases, e.g. if a UA intends to 2442 establish multiple dialogs, the TU may not send the BYE.) 2443 UAC 2444 dialog(A) | INVITE F1 2445 Pre o |-----------------------> 2446 | | 100 F2 2447 | |<----------------------- 2448 | | 180(To tag=A) F3 2449 Ear | |<----------------------- 2450 | | 2451 | | 200(A) F4 2452 Mora |..........|<----------------------- 2453 | ^ | ACK(A) F5 2454 Est | | |-----------------------> 2455 | | | 2456 dialog(B) | |64*T1 | 2457 forked new DSM | | | 200(To tag=B) F6 2458 Mora o..........|.|........|<----------------------- 2459 | | | | ACK(B) F7 2460 Est |..........|.|........|-----------------------> 2461 | | | | BYE(B) F8 2462 Mort |..........|.|........|-----------------------> 2463 ^ | | | | 200(B) F9 2464 | | | | |<----------------------- 2465 | | | V | 2466 |Timer K | (terminate INVITE transaction) 2467 | | | | 2468 V | | | 2469 Morg o | | 2470 | | 2472 Figure 6: Receiving 2xx responses with different To tags 2474 Below is an example sequence in which the option tag 100rel (RFC 3262 2475 [5]) is required by a 180. 2477 If a forking proxy supports 100rel, it transparently transmits to the 2478 UAC a provisional response which contains a Require header with the 2479 value of 100rel. Upon receiving a provisional response with 100rel, 2480 the UAC establishes the early dialog (B) and sends PRACK. (Here, 2481 also, every transaction completes independently of others.) 2483 As in Figure 4, the early dialog (B) terminates at the same time the 2484 INVITE transaction terminates. In the case where a proxy does not 2485 support 100rel, the provisional response will be handled in the usual 2486 way (a provisional response with 100rel is discarded by the proxy, 2487 not to be transmitted to the UAC). 2489 UAC 2490 dialog(A) | INVITE F1 2491 Pre o |-------------------------> 2492 | | 100 F2 2493 | |<------------------------- 2494 | | 180(To tag=A) F3 2495 Ear | |<------------------------- 2496 | | 200(A) F4 2497 Mora |..........|<------------------------- 2498 | ^ | ACK(A) F5 2499 Est | | |-------------------------> 2500 dialog(B) | | | 2501 forked new DSM | | | 180(To tag=B) w/100rel F6 2502 Ear o..........|.|........|<------------------------- 2503 | | | | PRACK(B) F7 2504 | | | |-------------------------> 2505 | | | | 200(B,PRACK) F8 2506 | | | |<------------------------- 2507 | | |64*T1 | 2508 | | |(13.2.2.4 of RFC 3261 [1]) 2509 | | | | 2510 | | | | 2511 | | | | 2512 | | V | 2513 o..........|.(terminate INVITE transaction) 2514 terminated | | 2515 dialog(B) | | 2516 | | 2518 Figure 7: Receiving 1xx responses with different To tags 2519 when using the mechanism for reliable provisional responses (100rel) 2521 Authors' Addresses 2523 Miki Hasebe 2524 NTT-east Corporation 2525 19-2 Nishi-shinjuku 3-chome 2526 Shinjuku-ku, Tokyo 163-8019 2527 JP 2529 Email: hasebe.miki@east.ntt.co.jp 2530 Jun Koshiko 2531 NTT-east Corporation 2532 19-2 Nishi-shinjuku 3-chome 2533 Shinjuku-ku, Tokyo 163-8019 2534 JP 2536 Email: j.koshiko@east.ntt.co.jp 2538 Yasushi Suzuki 2539 NTT Corporation 2540 9-11, Midori-cho 3-Chome 2541 Musashino-shi, Tokyo 180-8585 2542 JP 2544 Email: suzuki.yasushi@lab.ntt.co.jp 2546 Tomoyuki Yoshikawa 2547 NTT-east Corporation 2548 19-2 Nishi-shinjuku 3-chome 2549 Shinjuku-ku, Tokyo 163-8019 2550 JP 2552 Email: tomoyuki.yoshikawa@east.ntt.co.jp 2554 Paul H. Kyzivat 2555 Cisco Systems, Inc. 2556 1414 Massachusetts Avenue 2557 Boxborough, MA 01719 2558 US 2560 Email: pkyzivat@cisco.com 2562 Full Copyright Statement 2564 Copyright (C) The IETF Trust (2008). 2566 This document is subject to the rights, licenses and restrictions 2567 contained in BCP 78, and except as set forth therein, the authors 2568 retain all their rights. 2570 This document and the information contained herein are provided on an 2571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2572 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2573 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2574 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2575 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2578 Intellectual Property 2580 The IETF takes no position regarding the validity or scope of any 2581 Intellectual Property Rights or other rights that might be claimed to 2582 pertain to the implementation or use of the technology described in 2583 this document or the extent to which any license under such rights 2584 might or might not be available; nor does it represent that it has 2585 made any independent effort to identify any such rights. Information 2586 on the procedures with respect to rights in RFC documents can be 2587 found in BCP 78 and BCP 79. 2589 Copies of IPR disclosures made to the IETF Secretariat and any 2590 assurances of licenses to be made available, or the result of an 2591 attempt made to obtain a general license or permission for the use of 2592 such proprietary rights by implementers or users of this 2593 specification can be obtained from the IETF on-line IPR repository at 2594 http://www.ietf.org/ipr. 2596 The IETF invites any interested party to bring to its attention any 2597 copyrights, patents or patent applications, or other proprietary 2598 rights that may cover technology that may be required to implement 2599 this standard. Please address the information to the IETF at 2600 ietf-ipr@ietf.org. 2602 Acknowledgment 2604 Funding for the RFC Editor function is provided by the IETF 2605 Administrative Support Activity (IASA).