idnits 2.17.1 draft-ietf-sipping-race-examples-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2546. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2536. ** Found boilerplate matching RFC 3978, Section 5.5, updated by RFC 4748 (on line 2562), which is fine, but *also* found old RFC 3978, Section 5.5 text on line 2546. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 20 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. == 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: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == In addition to RFC 3978, Section 5.5, updated by RFC 4748 boilerplate, a section with a similar start was also found: This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 2387 has weird spacing: '... Ear o.......' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 2454, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2463, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2466, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-dialogusage (ref. '8') Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. HASEBE 3 Internet-Draft J. KOSHIKO 4 Expires: Sep 6, 2007 Y. SUZUKI 5 T. YOSHIKAWA 6 NTT-East 7 P. Kyzivat 8 Cisco Systems, Inc. 9 Mar 5th, 2007 11 Examples call flow in race condition on Session Initiation Protocol 12 draft-ietf-sipping-race-examples-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 1, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document gives examples of the Session Initiation Protocol (SIP) 46 call flows in race condition. Call flows in race condition are 47 confusing, and this document shows the best practice to handle 48 them. The elements in these call flows include SIP User Agents 49 and SIP Proxies. Call flow diagrams and message details are shown. 51 Table of Contents 53 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 54 1.1 General Assumptions. . . . . . . . . . . . . . . . . . . . .3 55 1.2 Legend for Message Flows . . . . . . . . . . . . . . . . . .3 56 1.3 SIP Protocol Assumptions . . . . . . . . . . . . . . . . . .3 57 2. The Dialog State Machine for INVITE dialog usage . . . . . . . .4 58 3. Race Conditions. . . . . . . . . . . . . . . . . . . . . . . . .10 59 3.1 Receiving message in the Moratorium State. . . . . . . . . .10 60 3.1.1 Receiving Initial INVITE retransmission(Trying state). .10 61 3.1.2 Receiving CANCEL(Proceeding or Early state). . . . . . .12 62 3.1.3 Receiving BYE (Early state). . . . . . . . . . . . . . .14 63 3.1.4 Receiving re-INVITE (Established state)(case 1). . . . .15 64 3.1.5 Receiving re-INVITE (Established state)(case 2). . . . .19 65 3.1.6 Receiving BYE (Established state). . . . . . . . . . . .24 66 3.2 Receiving message in the Mortal State. . . . . . . . . . . .24 67 3.2.1 Receiving BYE(Established state) . . . . . . . . . . . .25 68 3.2.2 Receiving re-INVITE(Established state) . . . . . . . . .27 69 3.2.3 Receiving 200OK for re-INVITE(Established state) . . . .30 70 3.2.4 Receiving ACK (Moratorium state) . . . . . . . . . . . .32 71 3.3 Other race conditions. . . . . . . . . . . . . . . . . . . .34 72 3.3.1 Re-INVITE crossover. . . . . . . . . . . . . . . . . . .34 73 3.3.2 UPDATE and re-INVITE crossover . . . . . . . . . . . . .38 74 3.3.3 Receiving REFER(Established state) . . . . . . . . . . .42 75 Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . .44 76 Appendix B. BYE request overlapped on re-INVITE . . . . . . . . . .45 77 Appendix C. UA's behaviour for CANCEL . . . . . . . . . . . . . . .47 78 Appendix D. Notes on the request in Mortal state. . . . . . . . . .49 79 Appendix E. Forking and receiving new To-tags . . . . . . . . . . .50 80 References . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 81 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . . .53 82 Intellectual Property Statement . . . . . . . . . . . . . . . . . .54 83 Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . . . .55 84 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . .55 85 Acknowledgment. . . . . . . . . . . . . . . . . . . . . . . . . . .55 87 1. Overview 89 The call flows shown in this document were developed in the design of 90 a SIP IP communications network. These examples are of race 91 condition, which stems from the dialog state transition mainly 92 established by INVITE. 94 When implementing SIP, various complex situations may arise. 95 Therefore, it will be helpful to provide implementors of the 96 protocol with examples of recommended terminal and server behavior. 98 This document clarifies SIP UA behaviors when messages cross each 99 other as race conditions. By clarifying operation under race 100 conditions, inconsistent interpretations between implementations are 101 avoided and interoperability is expected to be promoted. 103 It is the hope of the authors that this document will be useful for 104 SIP implementors, designers, and protocol researchers and will help 105 them achieve the goal of a standard implementation of RFC 3261 [1]. 107 These call flows are based on the version 2.0 of SIP defined in RFC 108 3261 [1] with SDP usage described in RFC 3264 [2]. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in BCP 14, RFC 2119 [4]. 114 1.1 General Assumptions 116 A number of architecture, network, and protocol assumptions underlie 117 the call flows in this document. Note that these assumptions are not 118 requirements. They are outlined in this section so that they may be 119 taken into consideration and help understanding the call 120 flow examples. 122 These flows do not assume specific underlying transport protocols 123 such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for 124 details on the transport issues for SIP. 126 1.2 Legend for Message Flows 128 Dashed lines (---) and slash lines (/,\) represent signaling messages 129 that are mandatory to the call scenario. (X) represents crossover of 130 signaling messages. (->x,x<-) indicate that the packet is lost. 131 The arrow indicate the direction of message flow. Double dashed 132 lines (===) represent media paths between network elements. 134 Messages are identified in the Figures as F1, F2, etc. These numbers 135 are used for references to the message details that follow the 136 Figure. 137 Comments in the message details are shown in the following form: 139 /* Comments. */ 141 1.3 SIP Protocol Assumptions 143 This document does not prescribe the flows precisely as they are 144 shown, but rather illustrates the principles for best practice. 145 They are best practice usages (orderings, syntax, selection of 146 features for the purpose, or handling of error) of SIP methods, 147 headers and parameters. NOTE: The flows in this document must not 148 be copied as they are by implementors because additional 149 characteristics were incorporated into the document for ease of 150 explanation. To sum up, the procedures described in this document 151 represent well-reviewed examples of SIP usage, which are best common 152 practice according to IETF consensus. 154 For simplicity in reading and editing the document, there are a 155 number of differences between some of the examples and actual SIP 156 messages. For instance, Call-IDs are often repeated, CSeq often 157 begins at 1, header fields are usually shown in the same order, 158 usually only the minimum required header field set is shown, and 159 other headers which would usually be included such as Accept, Allow, 160 etc are not shown. 162 Actors: 164 Element Display Name URI IP Address 165 ------- ------------ --- ---------- 167 User Agent Alice sip:alice@atlanta.example.com 192.0.2.101 168 User Agent Bob sip:bob@biloxi.example.com 192.0.2.201 169 User Agent Carol sip:carol@chicago.example.com 192.0.2.202 170 Proxy Server ss.atlanta.example.com 192.0.2.111 172 2. The Dialog State Machine for INVITE dialog usage 174 Race conditions are generated when the dialog state of the receiving 175 side differs from that of the sending side. 176 For instance, a race condition occurs when UAC (User Agent Client) 177 sends a CANCEL in the Early state while UAS (User Agent Server) is 178 transiting from the Early state to the Confirmed state by sending a 179 200 OK to ini-INVITE. 180 The DSM (dialog state machine) for the INVITE dialog usage is 181 presented as follows to help understanding UA's behavior in race 182 conditions. 183 The DSM clarifies UA's behavior by subdividing some internal states 184 shown in the FSM (Finite State Machine) for dialog state of the 185 dialog-package [7], without changing the states of the dialog, 186 "early", "confirmed", and "terminated" shown in RFC3261 [1]. 187 The Preparative state is put before the Early state, which includes 188 the Trying and Proceeding states. The Confirmed state is subdivided 189 into two substates, the Moratorium and Established states and the 190 Terminated state is subdivided into the Mortal and Morgue states. 191 Messages which are the triggers of the state transitions between 192 these states are indicated with arrows. In this figure, messages 193 which are not related to state transition are omitted. 195 Below are the DSMs for UAC and UAS respectively. 197 +-----------------------------------------------+ 198 | Preparative | 199 | +----------+ +--------------+ | 200 | | | 100 | |-----C-+ 201 | | Trying |---------->| Proceeding | | | 100 202 | | | | |<----C-+ 203 | +----------+ +--------------+ | 204 | | 205 +-----------------------------------------------+ 206 | | | 207 | 3xx-6xx | 1xx-tag | 2xx 208 | | | 209 | V | 210 | +------------------+ | 211 | 3xx-6xx | |--+ 1xx-tag | 212 +<--------| Early | | w/new tag | 213 | | |<-+ (new DSM | 214 | +------------------+ instance | 215 | | | created) | 216 | | BYE | 2xx | 217 | | +------------>+<-+ 218 | | | 219 +-----C------------C-----+ +-----------C------+ 220 | | Terminated | | | Confirmed | | 221 | | +<----C---------| | | 222 | | | | BYE | | | 223 | | V | | V | 224 | | +------------+ | | +-----------+ | 225 | | | |---C-+ | | |--C-+ 2xx 226 | | | Mortal | | | BYE(r)| | Moratorium| | | w/new tag 227 | | | |<--C-+ | | |<-C-+ (new DSM 228 | | +------------+ | | +-----------+ | instance 229 | | | | | | | created) 230 | | | Timeout | | | ACK | 231 | | | (Timer K) | | | | 232 | V V | | V | 233 | +---------------+ | | +-----------+ | 234 | | | | | | | | 235 | | Morgue | | | |Established| | 236 | | | | | | | | 237 | +---------------+ | | +-----------+ | 238 | | | | 239 +------------------------+ +------------------+ 241 (r): indicates only reception is allowed. 242 Where (r) is not indicated, response means receive, request 243 means send. 245 Figure 1. DSM for INVITE dialog usage (UAC) 247 Figure 1 represents the UAC's DSM for the INVITE dialog usage. UAC 248 MAY send a BYE in the Early state, even though this behavior is 249 NOT RECOMMENDED. The BYE sent in the Early state terminates the 250 Early dialog with a specific To-tag. That is, when a proxy is 251 performing forking, the BYE is only able to terminate the Early 252 dialog with a particular UA. If UAC wants to terminate all Early 253 dialogs instead of that with a particular UA, it needs to send 254 CANCEL, not BYE. Moreover, until UAC receives a final response and 255 terminates the INVITE transaction, the UAC MUST be prepared to 256 establish a dialog by receiving a new response to the INVITE even 257 though it had sent a BYE and terminated the dialog (see Appendix A). 259 +-----------------------------------------------+ 260 | Preparative | 261 | +----------+ +--------------+ | 262 | | | 100 | |-----C-+ 263 | | Trying |---------->| Proceeding | | | 100 264 | | | | |<----C-+ 265 | +----------+ +--------------+ | 266 | | 267 +-----------------------------------------------+ 268 | | | 269 | 3xx-6xx | 1xx-tag | 2xx 270 | | | 271 | V | 272 | +------------------+ | 273 | 3xx-6xx | |--+ | 274 +<--------| Early | | 1xx-tag | 275 | | |<-+ | 276 | +------------------+ | 277 | | | | 278 | | BYE | 2xx | 279 | | +------------>+<-+ 280 | | | 281 +-----C------------C-----+ +-----------C------+ 282 | | Terminated | | | Confirmed | | 283 | | +<----C---------| | | 284 | | | | BYE(sr) | | | 285 | | V | | V | 286 | | +------------+ | | +-----------+ | 287 | | | |---C-+ | | |--C-+ 288 | | | Mortal | | | BYE | | Moratorium| | | 2xx 289 | | | |<--C-+ | | |<-C-+ 290 | | +------------+ | | +-----------+ | 291 | | | | | | | 292 | | | Timeout | | | ACK | 293 | | | (Timer J) | | | | 294 | V V | | V | 295 | +---------------+ | | +-----------+ | 296 | | | | | | | | 297 | | Morgue | | | |Established| | 298 | | | | | | | | 299 | +---------------+ | | +-----------+ | 300 | | | | 301 +------------------------+ +------------------+ 303 (sr): indicates that both sending and reception are allowed. 304 Where (sr) is not indicated, response means send, 305 request means receive. 307 Figure 2. DSM for INVITE dialog usage (UAS) 309 Figure 2 represents UAS's DSM for the INVITE dialog usage. 310 The figure does not illustrate the state transition related to 311 CANCEL request. CANCEL request does not cause a dialog state 312 transition. However, the UAS terminates the dialog and triggers the 313 dialog transition by sending 487 immediately after the reception of 314 the CANCEL. Considering this, the behavior upon the reception of the 315 CANCEL request is further explained in the Appendix C. 317 Following are UA's behaviors in each state. 319 Preparative (Pre): The Preparative state is a state until the 320 Early dialog is established by sending and receiving a 321 provisional response with To-tag after an ini-INVITE is sent 322 and received. The dialog has not existed yet in the 323 Preparative state. The dialog state transits from the 324 Preparative to the Early by sending or receiving a provisional 325 response with To-tag. Moreover, if UA sends or receives a 2xx 326 response, the dialog state transit to the Moratorium state 327 which is a substate of the Confirmed state. 328 In addition, if UA sends or receives a 3xx-6xx response the 329 dialog state transit to the Morgue state which is a substate of 330 the Terminated state. Sending an ACK for a 3xx-6xx response 331 and retransmissions of 3xx-6xx are not expressed on this DSM 332 because they are sent by the INVITE transaction. 334 Trying (Try): The Trying state is a substate of the Preparative 335 state and inherits the behavior of the superstate. The Trying 336 state is started by sending and receiving of an ini-INVITE. 337 It transits to the Proceeding state by sending or receiving a 338 1xx (usually 100 trying) without To-tag. UAC may retransmit an 339 INVITE on transaction layer and must not send a CANCEL request. 340 UAS may send a 1xx-6xx response. 342 Proceeding (Pro): The Proceeding state is a substate of the 343 Preparative state and inherits the behavior of the superstate. 344 Dialog becomes the Proceeding state if a dialog in the Trying 345 state sends or receives a 1xx without To-tag (usually 100 346 trying). UAC may send CANCEL, and UAS may send a 1xx-6xx 347 response in the Proceeding state. 349 Early (Ear): The early dialog is established by sending or 350 receiving a provisional response with To-tag. The early dialog 351 exists though the dialog does not existed in this state yet. 352 The dialog state transits from the Early to Moratorium state, a 353 substate of the Confirmed state, by sending or receiving a 2xx 354 response. In addition, the dialog state transits to the Morgue 355 state, a substate of the Terminated state, by sending and 356 receiving a 3xx-6xx response. Sending an ACK for a 3xx-6xx 357 response and retransmissions of 3xx-6xx are not expressed on 358 this DSM because they are automatically processed on 359 transaction layer and don't influence the dialog state. UAC 360 may send CANCEL in the Early state. UAC may send BYE 361 (although it is not recommended). UAS may send a 1xx-6xx 362 response. Sending or receiving of a CANCEL request does not 363 have direct influences on dialog state. The UA's behavior upon 364 the reception of the CANCEL request is further explained in the 365 Appendix C. 367 Confirmed (Con): Sending or receiving of a 2xx final response 368 establishes a dialog. Dialog exists in this state. The BYE 369 request the changes state from the Confirmed to Mortal state, 370 a substate of the Terminated state. The Confirmed has two 371 substates, the Moratorium and Established state, which are 372 different in messages UAs are allowed to send. 374 Moratorium (Mora): The Moratorium state is a substate of the 375 Confirmed state and inherits the behavior of the superstate. 376 The Moratorium state transits to the Established state by 377 sending or receiving an ACK request. UAC may send ACK and UAS 378 may send a 2xx final response. 380 Established (Est): The Established state is a substate of the 381 Confirmed state and inherits the behavior of superstate. Both 382 caller and callee may send various messages which influences a 383 dialog. Caller supports the transmission of ACK for a 384 retransmission of a 2xx response to an ini-INVITE. 386 Terminated (Ter): The Terminated state is divided into two 387 substates, the Mortal and Morgue states, to cover the behavior 388 when a dialog is being terminated. In this state, UAs hold 389 information about the dialog which is being terminated. The 390 Confirmed state transits to the Mortal state, a substate of the 391 Terminated state, by sending or receiving a BYE request. 393 Mortal (Mort): Caller and callee becomes Mortal state by sending 394 or receiving a BYE. UA MUST NOT send any new requests since 395 there is no dialog. (Here the new requests do not include ACK 396 for 2xx and BYE for 401 or 407 as further explained in the 397 Appendix D below.) 398 In this state, only BYE or its response can be handled, and no 399 other messages can be received. This is because the use case 400 is taken into consideration that BYE is sent by both a caller 401 and a callee to exchange reports about the session when it is 402 being terminated. Therefore, UA possesses dialog information 403 for internal process but dialog shouldn't exist outwardly. The 404 UA stops managing its dialog state and changes it to the Morgue 405 state, when the BYE transaction is finished by timer 406 (Timer F or Timer K for UAC. Timer J for UAS). 408 Morgue (Morg): Dialog does not exist any more in this state. 409 Sending or receiving of a signal which influences a dialog is 410 not performed. (A dialog is literally terminated.) 412 3. Race conditions 414 This section details race condition between two SIP UAs, Alice and 415 Bob. Alice (sip:alice@atlanta.example.com) and Bob 416 (sip:bob@biloxi.example.com) are assumed to be SIP phones or 417 SIP-enabled devices. 418 Only significant signals are illustrated. Dialog state transitions 419 caused by sending and receiving of SIP messages as well as '*race*', 420 which indicates race condition are shown. (For abbreviations for 421 the dialog state transitions, refer to Chapter 2.) 422 '*race*' indicates the moment when a race condition occurs. 424 Examples of race conditions are shown below. 426 3.1 Receiving message in the Moratorium State 428 This section shows some examples of call flow in race condition 429 when receiving the message from other states in the Moratorium state. 431 3.1.1 Receiving Initial INVITE retransmission (Trying state) 432 in Moratorium state 434 State Alice Bob State 435 | | 436 | ini-INVITE F1 | 437 |------------------------------------>| 438 Pre | 180 F2(Packet loss) | Pre 439 | x<-----------------------| 440 | | Ear 441 | ini-INVITE(=F1) F4 200 F3 | 442 |------------------ --------------| 443 | \ / | Mora 444 | X | 445 | / \ | 446 |<----------------- ------------->| *race* 447 Mora | ACK F5 | 448 |------------------------------------>| 449 Est | | Est 450 | | 452 This scenario illustrates the race condition which occurs when UAS 453 receives a Preparative message in the Moratorium state. All 454 provisional responses to the initial INVITE (ini-INVITE F1) are lost, 455 and UAC retransmits an ini-INVITE (F4). At the same time as 456 retransmission, UAS generates a 200 OK (F3) to the ini-INVITE and it 457 terminate an INVITE server transaction, according to Section 13.3.1.4 458 of RFC3261 [1]. 459 However, it is reported that terminating an INVITE server transaction 460 by 200 OK is a SIP bug. (http://bugs.sipit.net/, #769) 461 Therefore, the INVITE server transaction is not terminated at F3, and 462 the F4 MUST be properly handled as a retransmission. 463 (UAs that do not deal with this bug still need to recognize the 464 dialog relying on its From-tag and Call-ID, and the retransmitted 465 request relying on the CSeq header field value even though it does 466 not match the transaction.) 467 In RFC3261 [1], it is not specified whether UAS retransmits 200 to 468 the retransmission of ini-INVITE. Considering the retransmission of 469 200 triggered by timer (TU keeps retransmitting 200 based on T1 470 and T2 until it receives an ACK), according to Section 13.3.1.4 of 471 RFC3261 [1], it seems unnecessary to retransmit 200 when the UAS 472 receives the retransmission of ini-INVITE. (For implementation, it 473 does not matter if the UAS sends the retransmission of 200, since the 474 200 does not cause any problem.) 476 Message Details 478 F1 INVITE Alice -> Bob 480 F2 180 Ringing Bob -> Alice 481 /* 180 response is lost and does not reach Alice. */ 483 F3 200 OK Bob -> Alice 484 /* According to 13.3.1.4 of RFC3261, an INVITE server transaction 485 is terminated at this point. However, this has been reported as a 486 SIP bug, and the UAS MUST correctly recognize the ini-INVITE (F4) as 487 a retransmission. */ 489 F4 INVITE (retransmission) Alice -> Bob 490 /* F4 is a retransmission of F1. They are exactly the same INVITE 491 request. For UAs do not deal with the bug reported in #769 (an 492 INVITE server transaction is terminated by 200 to INVITE), this 493 request does not match the transaction as well as the dialog 494 since it does not have a To-tag. 495 However, Bob have to recognize the retransmitted INVITE correctly, 496 without treating it as a new INVITE. */ 498 F5 ACK Alice -> Bob 500 3.1.2 Receiving CANCEL (Proceeding or Early state) 501 in Moratorium state 503 State Alice Bob State 504 | | 505 | INVITE F1 | 506 Pre |----------------------------->| 507 | 180 Ringing F2 | Pre 508 Ear |<-----------------------------| 509 | | Ear 510 |CANCEL F3 200(INVITE) F4| 511 |------------ -------------| 512 | \ / | Mora 513 | X | 514 | / \ | 515 |<----------- ------------>| *race* 516 Mora | | 517 | ACK F6 200(CANCEL) F5| 518 |------------ -------------| 519 Est | \ / | 520 | X | 521 | / \ | 522 |<----------- ------------>| 523 | | Est 524 | One Way RTP Media | 525 | (Two Way RTP Media possible) | 526 |<=============================| 527 | BYE F7 | 528 |----------------------------->| 529 Mort | 200 F8 | Mort 530 |<-----------------------------| 531 | ^ ^ | 532 | | Timer K | | 533 | V | | 534 Morg | Timer J | | 535 | V | 536 | | Morg 537 | | 539 This scenario illustrates the race condition which occurs when UAS 540 receives an Early message, CANCEL, in the Moratorium state. Alice 541 sends a CANCEL and Bob sends a 200 OK response to the initial INVITE 542 message at the same time. As described in the previous section, 543 according to RFC3261, an INVITE server transaction is supposed to be 544 terminated by a 200 response, but this has been reported as a bug 545 #769. 546 This section describes a case in which an INVITE server transaction 547 is not terminated by a response to the CANCEL request. In this case, 548 there is an INVITE transaction which the CANCEL request matches, so a 549 200 response is sent to the request. This 200 response simply means 550 that the next hop received the CANCEL request (Successful CANCEL 551 (200) does not mean an INVITE failure). When UAS does not deal with 552 #769, UAC MAY receive a 481 response for CANCEL since there is no 553 transaction which the CANCEL request matches. This 481 simply means 554 that there is no matching INVITE server transaction and CANCEL is not 555 sent to the next hop. 556 Regardless of the success/failure of the CANCEL, Alice checks the 557 final response to INVITE, and if she receives 200 to the INVITE 558 request she immediately sends a BYE and terminates a dialog. 559 (Section 15, RFC3261 [1]) 560 From the time F1 is received by Bob until the time that F8 is sent by 561 Bob, media may be flowing one way from Bob to Alice. From the time 562 than an answer is received by Alice from Bob there is the possibility 563 that media may flow from Alice to Bob as well. However, once Alice 564 has decided to cancel the call, she presumably will not send media, 565 so practically speaking the media stream will remain one way. 567 Message Details 569 F1 INVITE Alice -> Bob 571 F2 180 Ringing Bob -> Alice 573 F3 CANCEL Alice -> Bob 574 /* Alice sends a CANCEL in the Early state. */ 576 F4 200 OK (INVITE) Bob -> Alice 577 /* Alice receives a 200 to INVITE (F1) in the Moratorium state. 578 Alice has the potential to send as well as receive media, 579 but in practice will not send because there is an intent 580 to end the call. */ 582 F5 200 OK (CANCEL) Bob -> Alice 583 /* 200 to CANCEL simply means that the CANCEL was received. 584 The 200 response is sent, since this document deals with the 585 bug reported in #769. When an INVITE server transaction is 586 terminated as the procedure stated in RFC3261, UAC MAY receive 587 481 response instead of 200. */ 589 F6 ACK Alice -> Bob 590 /* INVITE is successful, and the CANCEL becomes invalid. Bob 591 establishes RTP streams. 592 However, the next BYE request immediately terminates 593 the dialog and session. */ 595 F7 BYE Alice -> Bob 597 F8 200 OK Bob -> Alice 599 3.1.3 Receiving BYE (Early state) 600 in Moratorium state 602 State Alice Bob State 603 | | 604 | ini-INVITE F1 | 605 |------------------------------->| 606 Pre | 180 F2 | Pre 607 |<-------------------------------| 608 Ear | | Ear 609 | BYE F4 200(INVITE) F3| 610 |------------- --------------| 611 Mort | \ / | Mora 612 | X | 613 | / \ | 614 |<------------ ------------->| *race* 615 | | Mort 616 | ACK F5 200(BYE) F6 | 617 |------------- --------------| 618 | \ / ^ | 619 | X | | 620 | / \ | | 621 |<------------ ------------->| 622 | ^ | | 623 | | Timer K | | 624 | V | | 625 Morg | Timer J | | 626 | V | 627 | | Morg 628 | | 630 This scenario illustrates the race condition which occurs when UAS 631 receives an Early message, BYE, in the Moratorium state. Alice sends 632 a BYE in the Early state and Bob sends a 200 OK response to the 633 initial INVITE request at the same time. Bob receives the BYE in the 634 Confirmed dialog state though Alice sent the request in the Early 635 state (As explained in Section 2, this behavior is NOT RECOMMENDED). 636 The BYE functions normally even if it is received after the INVITE 637 transaction termination because BYE differs from CANCEL, and is sent 638 not to the request but to the dialog. Alice gets into the Mortal 639 state on receiving the BYE response, and remains Mortal until the 640 Timer K timeout occurs. In the Mortal state, UAC does not establish 641 a session, even though it receives a 200 response to INVITE. Even 642 so, the UAC sends an ACK to 200 for the completion of INVITE 643 transaction. The ACK is always sent to complete the three-way 644 handshake of INVITE transaction (Further explained in the Appendix D 645 below). 647 Message Details 649 F1 INVITE Alice -> Bob 651 F2 180 Ringing Bob -> Alice 653 F3 200 OK (ini-INVITE) Bob -> Alice 655 F4 BYE Alice -> Bob 657 /* Alice transits to the Mortal state upon sending BYE. 658 Therefore, after this, she does not begin a session even 659 though she receives a 200 response with an answer. */ 661 F5 ACK Alice -> Bob 663 F6 200 OK (BYE) Bob -> Alice 665 3.1.4 Receiving re-INVITE (Established state) 666 in Moratorium state (case 1) 668 State Alice Bob State 669 | | 670 | ini-INVITE w/offer1 F1 | 671 |------------------------------->| 672 Pre | 180 F2 | Pre 673 |<-------------------------------| 674 Ear | | Ear 675 | 200(ini-INV) w/answer1 F3 | 676 |<-------------------------------| 677 Mora | ACK F4(packet loss) | Mora 678 |-------------------->x | 679 Est | | 680 | re-INVITE F6 200(=F3) F5 | 681 | w/offer2 w/answer1 | 682 |------------- --------------| 683 | \ / | 684 | X | 685 | / \ | 686 |<------------ ------------->| *race* 687 | 200(re-INV) F8| 688 | ACK(=F4) F7 w/answer2 | 689 |------------- --------------| 690 | \ / | 691 | X | 692 | / \ | 693 |<------------ ------------->| 694 | ACK F9 | Est 695 |------------------------------->| 696 | | 697 | | 699 This scenario illustrates the race condition which occurs when UAS 700 receives re-INVITE request sent from the Established state, in the 701 Moratorium state. 702 UAS receives a re-INVITE (w/offer2) before receiving an ACK for 703 ini-INVITE (w/offer1). UAS sends a 200 OK (w/answer2) to the 704 re-INVITE (F8) because it has sent a 200 OK (w/answer1) to the 705 ini-INVITE (F3, F5) and the dialog has already been established. 706 (Because F5 is a retransmission of F3, SDP negotiation is not 707 performed here.) If a 200 OK to the ini-INVITE has an offer and the 708 answer is in the ACK, UA should return by a 491 to the 709 re-INVITE (refer to 3.1.5). As it can be seen in Section 3.3.2 710 below, the 491 response seems to be closely related to session 711 establishment, even in cases other than INVITE cross-over. This 712 example recommends 200 be sent instead of 491 because it does not 713 have influence on session. However, a 491 response can also lead to 714 the same outcome, so the either response can be used. 715 Moreover, if UAS doesn't receive an ACK for a long time, 716 it should send a BYE and terminate the dialog. 718 Message Details 720 F1 INVITE Alice -> Bob 722 INVITE sip:bob@biloxi.example.com SIP/2.0 723 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 724 Max-Forwards: 70 725 From: Alice ;tag=9fxced76sl 726 To: Bob 727 Call-ID: 3848276298220188511@atlanta.example.com 728 CSeq: 1 INVITE 729 Contact: 730 Content-Type: application/sdp 731 Content-Length: 137 733 v=0 734 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 735 s=- 736 c=IN IP4 192.0.2.101 737 t=0 0 738 m=audio 49172 RTP/AVP 0 739 a=rtpmap:0 PCMU/8000 741 /* ini-INVITE contains an offer. */ 742 F2 180 Ringing Bob -> Alice 744 SIP/2.0 180 Ringing 745 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 746 ;received=192.0.2.101 747 From: Alice ;tag=9fxced76sl 748 To: Bob ;tag=8321234356 750 Call-ID: 3848276298220188511@atlanta.example.com 751 CSeq: 1 INVITE 752 Contact: 753 Content-Length: 0 755 F3 200 OK Bob -> Alice 757 SIP/2.0 200 OK 758 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 759 ;received=192.0.2.101 760 From: Alice ;tag=9fxced76sl 761 To: Bob ;tag=8321234356 762 Call-ID: 3848276298220188511@atlanta.example.com 763 CSeq: 1 INVITE 764 Contact: 765 Content-Type: application/sdp 766 Content-Length: 133 768 v=0 769 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 770 s=- 771 c=IN IP4 192.0.2.201 772 t=0 0 773 m=audio 3456 RTP/AVP 0 774 a=rtpmap:0 PCMU/8000 776 F4 ACK Alice -> Bob 778 ACK sip:bob@client.biloxi.example.com SIP/2.0 779 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 780 Max-Forwards: 70 781 From: Alice ;tag=9fxced76sl 782 To: Bob ;tag=8321234356 783 Call-ID: 3848276298220188511@atlanta.example.com 784 CSeq: 1 ACK 785 Content-Length: 0 787 /* ACK request is lost. */ 788 F5 200 OK (=F3) Bob -> Alice (retransmission) 789 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 790 received an ACK. */ 792 F6 re-INVITE Alice -> Bob 794 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 795 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 796 Max-Forwards: 70 797 From: Alice ;tag=9fxced76sl 798 To: Bob ;tag=8321234356 799 Call-ID: 3848276298220188511@atlanta.example.com 800 CSeq: 2 INVITE 801 Content-Length: 147 803 v=0 804 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 805 s=- 806 c=IN IP4 192.0.2.101 807 t=0 0 808 m=audio 49172 RTP/AVP 0 809 a=rtpmap:0 PCMU/8000 810 a=sendonly 812 F7 ACK (=F4) Alice -> Bob (retransmission) 814 F8 200 OK (re-INVITE) Bob -> Alice 816 SIP/2.0 200 OK 817 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 818 Max-Forwards: 70 819 From: Alice ;tag=9fxced76sl 820 To: Bob ;tag=8321234356 821 Call-ID: 3848276298220188511@atlanta.example.com 822 CSeq: 2 INVITE 823 Content-Length: 143 825 v=0 826 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com 827 s=- 828 c=IN IP4 192.0.2.201 829 t=0 0 830 m=audio 3456 RTP/AVP 0 831 a=rtpmap:0 PCMU/8000 832 a=recvonly 833 F9 ACK Alice -> Bob 835 ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 836 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f2.1 837 Max-Forwards: 70 838 From: Alice ;tag=9fxced76sl 839 To: Bob ;tag=8321234356 840 Call-ID: 3848276298220188511@atlanta.example.com 841 CSeq: 2 ACK 842 Content-Length: 0 844 3.1.5 Receiving re-INVITE (Established state) 845 in Moratorium state (case 2) 847 State Alice Bob State 848 | | 849 | ini-INVITE (no offer) F1 | 850 |------------------------------->| 851 Pre | 180 F2 | Pre 852 |<-------------------------------| 853 Ear | | Ear 854 | 200(ini-INV) w/offer1 F3 | 855 |<-------------------------------| 856 Mora | ACK w/answer1 F4(packet loss) | Mora 857 |-------------------->x | 858 Est | | 859 | re-INVITE F6 200(=F3) F5 | 860 | w/offer2 w/offer1 | 861 |------------- --------------| 862 | \ / | 863 | X | 864 | / \ | 865 |<------------ ------------->| 866 | ACK(=F4) F7 491(re-INV) F8| 867 |------------- --------------| 868 | \ / | 869 | X | 870 | / \ | 871 |<------------ ------------->| 872 | ACK F9 | Est 873 |------------------------------->| 874 | | 875 | | 877 This scenario is basically the same as that of Section 3.1.4, but 878 differs in sending an offer in 200 and an answer in ACK. Different 879 to the previous case, the offer in the 200 (F3) and the offer in the 880 re-INVITE (F6) collide with each other. 881 Bob sends 491 to re-INVITE (F6) since he is not able to properly 882 handle a new request until he receives an answer. Even if F6 is 883 UPDATE with offer, it will reach the same result. 885 Message Details 887 F1 INVITE Alice -> Bob 889 INVITE sip:bob@biloxi.example.com SIP/2.0 890 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 891 Max-Forwards: 70 892 From: Alice ;tag=9fxced76sl 893 To: Bob 894 Call-ID: 3848276298220188511@atlanta.example.com 895 CSeq: 1 INVITE 896 Contact: 897 Content-Length: 0 899 /* The request does not contain an offer. */ 901 F2 180 Ringing Bob -> Alice 903 F3 200 OK Bob -> Alice 905 SIP/2.0 200 OK 906 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 907 ;received=192.0.2.101 908 From: Alice ;tag=9fxced76sl 909 To: Bob ;tag=8321234356 910 Call-ID: 3848276298220188511@atlanta.example.com 911 CSeq: 1 INVITE 912 Contact: 913 Content-Type: application/sdp 914 Content-Length: 133 916 v=0 917 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 918 s=- 919 c=IN IP4 192.0.2.201 920 t=0 0 921 m=audio 3456 RTP/AVP 0 922 a=rtpmap:0 PCMU/8000 924 /* An offer is made in 200 */ 926 F4 ACK Alice -> Bob 927 ACK sip:bob@client.biloxi.example.com SIP/2.0 928 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 929 Max-Forwards: 70 930 From: Alice ;tag=9fxced76sl 931 To: Bob ;tag=8321234356 932 Call-ID: 3848276298220188511@atlanta.example.com 933 CSeq: 1 ACK 934 Content-Type: application/sdp 935 Content-Length: 137 937 v=0 938 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 939 s=- 940 c=IN IP4 192.0.2.101 941 t=0 0 942 m=audio 49172 RTP/AVP 0 943 a=rtpmap:0 PCMU/8000 945 /* The request contains an answer, but the request is lost. */ 947 F5 200 OK (=F3) Bob -> Alice (retransmission) 948 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 949 received an ACK. */ 951 F6 re-INVITE Alice -> Bob 953 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 955 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 956 Max-Forwards: 70 957 From: Alice ;tag=9fxced76sl 958 To: Bob ;tag=8321234356 959 Call-ID: 3848276298220188511@atlanta.example.com 960 CSeq: 2 INVITE 961 Content-Length: 147 963 v=0 964 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 965 s=- 966 c=IN IP4 192.0.2.101 967 t=0 0 968 m=audio 49172 RTP/AVP 0 969 a=rtpmap:0 PCMU/8000 970 a=sendonly 972 /* The request contains an offer. */ 973 F7 ACK (=F4) Alice -> Bob (retransmission) 974 /* A retransmission triggered by the reception of a retransmitted 975 200. */ 977 F8 491 (re-INVITE) Bob -> Alice 978 /* Bob sends 491 (Request Pending), since Bob has a pending 979 offer. */ 981 F9 ACK Alice -> Bob 983 3.1.6 Receiving BYE (Established state) 984 in Moratorium state 986 State Alice Bob State 987 | | 988 | INVITE F1 | 989 |-------------------------->| 990 Pre | 180 Ringing F2 | Pre 991 |<--------------------------| 992 Ear | | Ear 993 | 200 OK F3 | 994 |<--------------------------| 995 Mora | ACK F4(packet loss) | Mora 996 |--------------->x | 997 Est | Both Way RTP Media | 998 |<=========================>| 999 | BYE F6 200(=F3) F5| 1000 |----------- -----------| 1001 Mort | \ / | 1002 | X | 1003 | / \ | 1004 |<---------- ---------->| *race* 1005 |ACK(=F4) F7 200(BYE) F8| Mort 1006 |----------- -----------| 1007 | \ / | 1008 | X | 1009 | / \ | 1010 |<---------- ---------->| 1011 | ^ ^ | 1012 | | Timer K | | 1013 | V | | 1014 Morg | Timer J | | 1015 | V | 1016 | | Morg 1017 | | 1019 This scenario illustrates the race condition which occurs when UAS 1020 receives an Established message, BYE, in the Moratorium state. 1021 An ACK request for a 200 OK response is lost (or delayed). 1022 Immediately after Bob retransmits the 200 OK to ini-INVITE, and Alice 1023 sends a BYE request at the same time. Depending on the 1024 implementation of a SIP UA, Alice may start a session again by the 1025 reception of the retransmitted 200 OK with SDP since she has already 1026 terminated a session by sending a BYE. In that case, when UAC 1027 receives a retransmitted 200 OK after sending a BYE, a session should 1028 not be started again since the session which is not associated with 1029 dialog still remains. Moreover, in the case where UAS sends an offer 1030 in a 200 OK , UAS should not start a session again for the same 1031 reason if UAS receives a retransmitted ACK after receiving a BYE. 1033 Message Details 1035 F1 INVITE Alice -> Bob 1037 F2 180 Ringing Bob -> Alice 1039 F3 200 OK Bob -> Alice 1041 F4 ACK Alice -> Bob 1043 ACK sip:bob@client.biloxi.example.com SIP/2.0 1044 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1045 Max-Forwards: 70 1046 From: Alice ;tag=9fxced76sl 1047 To: Bob ;tag=8321234356 1048 Call-ID: 3848276298220188511@atlanta.example.com 1049 CSeq: 1 ACK 1050 Content-Length: 0 1052 /* ACK request is lost. */ 1054 F5 200 OK (retransmission) Bob -> Alice 1056 SIP/2.0 200 OK 1057 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1058 ;received=192.0.2.101 1059 From: Alice ;tag=9fxced76sl 1060 To: Bob ;tag=8321234356 1061 Call-ID: 3848276298220188511@atlanta.example.com 1062 CSeq: 1 INVITE 1063 Contact: 1064 Content-Type: application/sdp 1065 Content-Length: 133 1066 v=0 1067 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1068 s=- 1069 c=IN IP4 192.0.2.201 1070 t=0 0 1071 m=audio 3456 RTP/AVP 0 1072 a=rtpmap:0 PCMU/8000 1074 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 1075 received an ACK. */ 1077 F6 BYE Alice -> Bob 1079 BYE sip:bob@client.biloxi.example.com SIP/2.0 1080 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 1081 Max-Forwards: 70 1082 From: Alice ;tag=9fxced76sl 1083 To: Bob ;tag=8321234356 1084 Call-ID: 3848276298220188511@atlanta.example.com 1085 CSeq: 2 BYE 1086 Content-Length: 0 1088 /* Bob retransmits a 200 OK and Alice sends a BYE at the same time. 1089 Alice transits to the Mortal state, so she does not begin a 1090 session after this even though she receives a 200 response to 1091 the re-INVITE. */ 1093 F7 ACK(=F4) Alice -> Bob 1095 F8 200 OK (BYE) Bob -> Alice 1097 SIP/2.0 200 OK 1098 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 1099 ;received=192.0.2.101 1100 From: Alice ;tag=9fxced76sl 1101 To: Bob ;tag=8321234356 1102 Call-ID: 3848276298220188511@atlanta.example.com 1103 CSeq: 2 BYE 1104 Content-Length: 0 1106 /* Bob sends a 200 OK to the BYE. */ 1108 3.2 Receiving message in the Mortal State 1110 This section shows some examples of call flow in race condition 1111 when receiving the message from other states in the Mortal state. 1113 3.2.1 Receiving BYE (Establish state) 1114 in Mortal state 1116 State Alice Bob 1117 | | 1118 | INVITE F1 | 1119 |----------------------->| 1120 Pre | 180 Ringing F2 | Pre 1121 |<-----------------------| 1122 Ear | | Ear 1123 | 200 OK F3 | 1124 |<-----------------------| 1125 Mora | ACK F4 | Mora 1126 |----------------------->| 1127 Est | Both Way RTP Media | Est 1128 |<======================>| 1129 | | 1130 | BYE F5 BYE F6 | 1131 |--------- ----------| 1132 Mort | \ / | Mort 1133 | X | 1134 | / \ | 1135 |<-------- --------->| *race* 1136 | | 1137 | 200 F8 200 F7 | 1138 |--------- ----------| 1139 | \ / | 1140 | X | 1141 | / \ | 1142 |<-------- --------->| 1143 | ^ ^ | 1144 | | Timer K | | 1145 | V | | 1146 Morg | Timer J | | 1147 | V | 1148 | | Morg 1149 | | 1151 This scenario illustrates the race condition which occurs when UAS 1152 receives an Established message, BYE, in the Mortal state. 1153 Alice and Bob send a BYE at the same time. A dialog and session is 1154 ended shortly after a BYE request is passed to a client transaction. 1155 As shown in Section 2, UA remains in the Mortal state. 1156 UAs in the Mortal state return error responses to the requests that 1157 operate dialog or session, such as re-INVITE, UPDATE, or REFER. 1158 However, UA shall return 200 OK to the BYE taking the use case into 1159 consideration where BYE request is sent by both a caller and a callee 1160 to exchange reports about the session when it is being terminated. 1161 (Since the dialogue and the session both terminate when a BYE is 1162 sent, the choice of sending 200 or an error response upon receiving 1163 BYE in the Mortal state does not affect the resulting termination. 1164 Therefore, even though this example uses a 200 response, other 1165 responses can also be used.) 1167 Message Details 1169 F1 INVITE Alice -> Bob 1171 F2 180 Ringing Bob -> Alice 1173 F3 200 OK Bob -> Alice 1175 F4 ACK Alice -> Bob 1177 F5 BYE Alice -> Bob 1179 BYE sip:bob@client.biloxi.example.com SIP/2.0 1180 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1181 Max-Forwards: 70 1182 From: Alice ;tag=9fxced76sl 1183 To: Bob ;tag=8321234356 1184 Call-ID: 3848276298220188511@atlanta.example.com 1185 CSeq: 2 BYE 1186 Content-Length: 0 1188 /* The session is terminated at the moment Alice sends a BYE. 1189 The dialog still exists then, but it is certain to be terminated 1190 in a short period of time. The dialog is completely 1191 terminated when the timeout of the BYE request occurs. */ 1193 F6 BYE Bob -> Alice 1195 BYE sip:alice@client.atlanta.example.com SIP/2.0 1196 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1197 Max-Forwards: 70 1198 From: Bob ;tag=8321234356 1199 To: Alice ;tag=9fxced76sl 1200 Call-ID: 3848276298220188511@atlanta.example.com 1201 CSeq: 1 BYE 1202 Content-Length: 0 1204 /* Bob has also transmitted a BYE simultaneously with Alice. 1205 Bob terminates the session and the dialog. */ 1207 F7 200 OK Bob -> Alice 1208 SIP/2.0 200 OK 1209 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1210 ;received=192.0.2.201 1211 From: Alice ;tag=9fxced76sl 1212 To: Bob ;tag=8321234356 1213 Call-ID: 3848276298220188511@atlanta.example.com 1214 CSeq: 2 BYE 1215 Content-Length: 0 1217 /* Since the dialog is in the Moratorium state, Bob responds with 1218 a 200 to the BYE request. */ 1220 F8 200 OK Alice -> Bob 1222 SIP/2.0 200 OK 1223 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1224 ;received=192.0.2.201 1225 From: Bob ;tag=8321234356 1226 To: Alice ;tag=9fxced76sl 1227 Call-ID: 3848276298220188511@atlanta.example.com 1228 CSeq: 1 BYE 1229 Content-Length: 0 1231 /* Since Alice has transited from the Established state to the Mortal 1232 state by sending BYE, Alice responds with a 200 to the BYE 1233 request. */ 1235 3.2.2 Receiving re-INVITE (Establish state) 1236 in Mortal state 1238 State Alice Bob 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 |--------- ----------| 1261 | \ / |^ 1262 | X || 1263 | / \ ||Timer J 1264 |<-------- --------->|| 1265 ^| ACK F9 || 1266 ||<-----------------------|| 1267 Timer K|| || 1268 || || 1269 V| || 1270 Morg | |V 1271 | | Morg 1272 | | 1274 This scenario illustrates the race condition which occurs when UAS 1275 receives an Established message, re-INVITE, in the Mortal state. 1276 Bob sends a re-INVITE, and Alice sends a BYE at the same time. 1277 The re-INVITE is responded by a 481, since the TU of Alice has 1278 transited from the Established state to the Mortal state by sending 1279 BYE. Bob sends ACK for the 481 response, because the ACK for error 1280 responses is handled by the transaction layer and at the point of 1281 receiving the 481 the INVITE client transaction still remains (even 1282 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 BYE sip:bob@client.biloxi.example.com SIP/2.0 1297 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1298 Max-Forwards: 70 1299 From: Alice ;tag=9fxced76sl 1300 To: Bob ;tag=8321234356 1301 Call-ID: 3848276298220188511@atlanta.example.com 1302 CSeq: 2 BYE 1303 Content-Length: 0 1304 /* Alice sends a BYE and terminates the session, and transits from 1305 the Established state to the Mortal state. */ 1307 F6 re-INVITE Bob -> Alice 1309 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1310 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1311 Session-Expires: 300;refresher=uac 1312 Supported: timer 1313 Max-Forwards: 70 1314 From: Bob ;tag=8321234356 1315 To: Alice ;tag=9fxced76sl 1316 Call-ID: 3848276298220188511@atlanta.example.com 1317 CSeq: 1 INVITE 1318 Content-Length: 0 1320 /* Alice sends a BYE, and Bob sends a re-INVITE at the same time. 1321 The dialog state transits to the Mortal state at the moment 1322 Alice sends the BYE, but Bob does not know it until he receives 1323 the BYE. Therefore, the dialog is in the Terminated state from 1324 Alice's point of view, but it is the Confirmed state 1325 from Bob's point of view. A race condition occurs. */ 1327 F7 200 OK Bob -> Alice 1329 SIP/2.0 200 OK 1330 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1331 ;received=192.0.2.201 1332 From: Alice ;tag=9fxced76sl 1333 To: Bob ;tag=8321234356 1334 Call-ID: 3848276298220188511@atlanta.example.com 1336 CSeq: 2 BYE 1337 Content-Length: 0 1339 F8 481 Call/Transaction Does Not Exist Alice -> Bob 1341 SIP/2.0 481 Call/Transaction Does Not Exist 1342 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1343 ;received=192.0.2.201 1344 From: Bob ;tag=8321234356 1345 To: Alice ;tag=9fxced76sl 1346 Call-ID: 3848276298220188511@atlanta.example.com 1347 CSeq: 1 INVITE 1348 Content-Length: 0 1349 /* Since Alice is in the Mortal state, she responds with a 481 to the 1350 re-INVITE. */ 1352 F9 ACK Bob -> Alice 1354 /* ACK for an error response is handled by Bob's INVITE client 1355 transaction. */ 1357 3.2.3 Receiving 200OK for re-INVITE (Established state) 1358 in Mortal state 1360 State Alice Bob 1361 | | 1362 | INVITE F1 | 1363 |----------------------->| 1364 Pre | 180 Ringing F2 | Pre 1365 |<-----------------------| 1366 Ear | | Ear 1367 | 200 OK F3 | 1368 |<-----------------------| 1369 Mora | ACK F4 | Mora 1370 |----------------------->| 1371 Est | Both Way RTP Media | Est 1372 |<======================>| 1373 | | 1374 | re-INVITE F5 | 1375 |<-----------------------| 1376 | 200 F7 BYE F6 | 1377 |--------- ----------| 1378 | \ / | Mort 1379 | X | 1380 | / \ | 1381 |<-------- --------->| *race* 1382 Mort | 200 F8 ACK F9 | 1383 |--------- ----------| 1384 | ^ \ / | 1385 | | X | 1386 | | / \ | 1387 |<-------- --------->| 1388 | | ^ | 1389 | | Timer K | | 1390 | | V | 1391 | | Timer J | Morg 1392 | V | 1393 Morg | | 1394 | | 1396 This scenario illustrates the race condition which occurs when UAS 1397 receives an Established message, 200 to re-INVITE, in the Mortal 1398 state. Bob sends a BYE immediately after sending a re-INVITE. 1399 (A user is not conscious that refresher sends re-INVITE 1400 automatically. For example, in the case of a telephone application, 1401 it is possible that a user places a receiver immediately after 1402 refresher.) 1403 Bob sends ACK for a 200 response to INVITE in the Mortal state, so 1404 that he completes the INVITE transaction. 1406 Message Details 1408 F1 INVITE Alice -> Bob 1410 F2 180 Ringing Bob -> Alice 1412 F3 200 OK Bob -> Alice 1414 F4 ACK Alice -> Bob 1416 F5 re-INVITE Bob -> Alice 1418 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1419 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1420 Session-Expires: 300;refresher=uac 1421 Supported: timer 1422 Max-Forwards: 70 1423 From: Bob ;tag=8321234356 1424 To: Alice ;tag=9fxced76sl 1425 Call-ID: 3848276298220188511@atlanta.example.com 1426 CSeq: 1 INVITE 1427 Content-Length: 0 1429 F6 BYE Bob -> Alice 1431 BYE sip:alice@client.atlanta.example.com SIP/2.0 1432 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8 1433 Max-Forwards: 70 1434 From: Bob ;tag=8321234356 1435 To: Alice ;tag=9fxced76sl 1436 Call-ID: 3848276298220188511@atlanta.example.com 1437 CSeq: 2 BYE 1438 Content-Length: 0 1440 /* Bob sends BYE immediately after sending the re-INVITE. 1441 Bob terminates the session and transits from the Established 1442 state to the Mortal state. */ 1444 F7 200 OK (re-INVITE) Alice -> Bob 1446 SIP/2.0 200 OK 1447 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds7 1448 ;received=192.0.2.201 1449 From: Bob ;tag=8321234356 1450 To: Alice ;tag=9fxced76sl 1451 Call-ID: 3848276298220188511@atlanta.example.com 1452 CSeq: 1 INVITE 1453 Content-Length: 0 1455 /* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE. 1456 A race condition occurs. */ 1458 F8 200 OK (BYE) Alice -> Bob 1460 SIP/2.0 200 OK 1461 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8 1462 ;received=192.0.2.201 1463 From: Bob ;tag=8321234356 1464 To: Alice ;tag=9fxced76sl 1465 Call-ID: 3848276298220188511@atlanta.example.com 1466 CSeq: 2 BYE 1467 Content-Length: 0 1469 F9 ACK Bob -> Alice 1471 /* Bob sends ACK in the Mortal state to complete the three-way 1472 handshake of the INVITE transaction. */ 1474 3.2.4 Receiving ACK (Moratorium state) 1475 in Mortal state 1477 State Alice Bob State 1478 | | 1479 | ini-INVITE F1 | 1480 |------------------------------->| 1481 Pre | 180 F2 | Pre 1482 |<-------------------------------| 1483 Ear | 200 F3 | Ear 1484 |<-------------------------------| 1485 Mora | | Mora 1486 | ACK F4 BYE F5 | 1487 |------------- --------------| 1488 Est | \ / | Mort 1489 | X | 1490 | / \ | 1491 |<------------ ------------->| *race* 1492 Mort | 200 F6 | 1493 |------------------------------->| 1494 | ^ ^ | 1495 | | Timer K | | 1496 | | V | 1497 | | Timer J | Morg 1498 | V | 1499 Morg | | 1500 | | 1502 This scenario illustrates the race condition which occurs when UAS 1503 receives an Established message, ACK to 200, in the Mortal state. 1504 Alice sends an ACK and Bob sends a BYE at the same time. When the 1505 offer is in a 2xx, and the answer is in an ACK, this example is in 1506 a race condition. The session is not started by receiving the ACK 1507 because Bob has already terminated the session by sending the BYE. 1508 The answer in the ACK request is just ignored. 1510 F1 INVITE Alice -> Bob 1512 F2 180 Ringing Bob -> Alice 1514 F3 200 OK Bob -> Alice 1516 F4 ACK Alice -> Bob 1518 ACK sip:bob@client.biloxi.example.com SIP/2.0 1519 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 1520 Max-Forwards: 70 1521 From: Alice ;tag=9fxced76sl 1522 To: Bob ;tag=8321234356 1523 Call-ID: 3848276298220188511@atlanta.example.com 1524 CSeq: 1 ACK 1525 Content-Length: 0 1527 /* RTP streams are established between Alice and Bob */ 1529 F5 BYE Alice -> Bob 1531 BYE sip:bob@client.biloxi.example.com SIP/2.0 1532 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1533 Max-Forwards: 70 1534 From: Alice ;tag=9fxced76sl 1535 To: Bob ;tag=8321234356 1536 Call-ID: 3848276298220188511@atlanta.example.com 1537 CSeq: 2 BYE 1538 Content-Length: 0 1540 /* Alice sends a BYE and terminates the session and dialog. */ 1542 F6 200 OK Bob -> Alice 1544 SIP/2.0 200 OK 1545 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1546 ;received=192.0.2.201 1547 From: Alice ;tag=9fxced76sl 1548 To: Bob ;tag=8321234356 1549 Call-ID: 3848276298220188511@atlanta.example.com 1550 CSeq: 2 BYE 1551 Content-Length: 0 1553 3.3 Other race conditions 1555 This section shows the examples in race condition that are not 1556 directly related to the dialog state transition. Here explains 1557 the way to handle the race condition generated when UAs treat 1558 "What is established by SIP", which has some relation to dialog. 1560 3.3.1 Re-INVITE crossover 1562 Alice Bob 1563 | | 1564 | INVITE F1 | 1565 |--------------------------->| 1566 | 180 Ringing F2 | 1567 |<---------------------------| 1568 | | 1569 | 200 OK F3 | 1570 |<---------------------------| 1571 | ACK F4 | 1572 |--------------------------->| 1573 | Both Way RTP Media | 1574 |<==========================>| 1575 | | 1576 |re-INVITE F5 re-INVITE F6 | 1577 |------------ -------------| 1578 | \ / | 1579 | X | 1580 | / \ | 1581 |<----------- ------------>| 1582 | 491 F8 491 F7 | 1583 |------------ -------------| 1584 | \ / | 1585 | X | 1586 | / \ | 1587 |<----------- ------------>| 1588 | ^ ACK F9 ^ ACK F10| 1589 |--|--------- ----|--------| 1590 | | \ / | | 1591 | | X | | 1592 | | / \ | | 1593 |<-|---------- ---|------->| 1594 | | | | 1595 | |0-2.0 sec | | 1596 | | | | 1597 | v re-INVITE(=F6) F11 | 1598 |<------------------|--------| 1599 | 200 OK F12 | | 1600 |-------------------|------->| 1601 | ACK F13 | | 1602 |<------------------|--------| 1603 | | | 1604 | |2.1-4.0 sec 1605 | | | 1606 |re-INVITE(=F5) F14 v | 1607 |--------------------------->| 1608 | 200 OK F15 | 1609 |<---------------------------| 1610 | ACK F16 | 1611 |--------------------------->| 1612 | | 1613 | | 1615 In this scenario, Alice and Bob send re-INVITE at the same time. 1616 When two re-INVITEs cross in the same dialog, they resend re-INVITEs 1617 after different interval for each, according to Section 14.1, of 1618 RFC3261 [1]. When Alice sends the re-INVITE and it crosses, the 1619 re-INVITE will be sent again after 2.1-4.0 seconds because she owns 1620 the Call-ID (she generated it). Bob will send an INVITE again after 1621 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID. 1622 Therefore, each user agent must remember whether it has generated the 1623 Call-ID of the dialog or not, in case an INVITE may cross with 1624 another INVITE. 1625 In this example, Alice's re-INVITE is for session modification 1626 and Bob's re-INVITE is for session refresh. In this case, after 1627 the 491 responses, Bob retransmits the re-INVITE for session refresh 1628 earlier than Alice. If Alice was to retransmit her re-INVITE (that 1629 is, if she was not the owner of Call-ID), the request would refresh 1630 and modify the session at the same time. Then Bob would know that 1631 he would not need to retransmit his re-INVITE to refresh the session. 1632 In another instance where two re-INVITEs for session modification, 1633 cross over, retransmitting the same re-INVITE again after 491 by the 1634 Call-ID owner (the UA which retransmits its re-INVITE after the 1635 other UA) may result in a behavior different from what the user 1636 originally intended to, so the UA needs to decide if the 1637 retransmission of the re-INVITE is necessary. 1638 (For example, when a call hold and an addition of video media cross 1639 over, mere retransmission of the re-INVITE at the firing of the timer 1640 may result in the situation where the video is transmitted 1641 immediately after the holding of the audio. This behavior is 1642 probably not intended by the users.) 1644 Message Details 1646 F1 INVITE Alice -> Bob 1648 F2 180 Ringing Bob -> Alice 1650 F3 200 OK Bob -> Alice 1652 F4 ACK Alice -> Bob 1654 F5 re-INVITE Alice -> Bob 1656 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1657 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1658 Max-Forwards: 70 1659 From: Alice ;tag=9fxced76sl 1660 To: Bob ;tag=8321234356 1661 Call-ID: 3848276298220188511@atlanta.example.com 1662 CSeq: 2 INVITE 1663 Content-Length: 147 1665 v=0 1666 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1667 s=- 1668 c=IN IP4 192.0.2.101 1669 t=0 0 1670 m=audio 49172 RTP/AVP 0 1671 a=rtpmap:0 PCMU/8000 1672 a=sendonly 1674 /* re-INVITE for session modification (a=sendrecv -> sendonly). */ 1676 F6 re-INVITE Bob -> Alice 1678 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1679 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1680 Session-Expires: 300;refresher=uac 1681 Supported: timer 1682 Max-Forwards: 70 1683 From: Bob ;tag=8321234356 1684 To: Alice ;tag=9fxced76sl 1685 Call-ID: 3848276298220188511@atlanta.example.com 1686 CSeq: 1 INVITE 1687 Content-Length: 0 1689 /* A re-INVITE request for a session refresh and that for 1690 a call hold are sent at the same time. */ 1692 F7 491 Request Pending Bob -> Alice 1693 /* Since a re-INVITE is in progress, a 491 response is returned. */ 1695 F8 491 Request Pending Alice -> Bob 1697 F9 ACK (INVITE) Alice -> Bob 1699 F10 ACK (INVITE) Bob -> Alice 1701 F11 re-INVITE Bob -> Alice 1703 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1704 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1 1705 Session-Expires: 300;refresher=uac 1706 Supported: timer 1707 Max-Forwards: 70 1708 From: Bob ;tag=8321234356 1709 To: Alice ;tag=9fxced76sl 1710 Call-ID: 3848276298220188511@atlanta.example.com 1711 CSeq: 2 INVITE 1712 Content-Type: application/sdp 1713 Content-Length: 133 1715 v=0 1716 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1717 s=- 1718 c=IN IP4 192.0.2.201 1719 t=0 0 1720 m=audio 3456 RTP/AVP 0 1721 a=rtpmap:0 PCMU/8000 1723 /* Since Bob is not the owner of the Call-ID, he sends a re-INVITE 1724 again after 0.0-2.0 seconds. */ 1726 F12 200 OK Alice -> Bob 1728 F13 ACK Bob -> Alice 1729 F14 re-INVITE Alice -> Bob 1731 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1732 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 1733 Max-Forwards: 70 1734 From: Alice ;tag=9fxced76sl 1735 To: Bob ;tag=8321234356 1736 Call-ID: 3848276298220188511@atlanta.example.com 1737 CSeq: 3 INVITE 1738 Content-Length: 147 1740 v=0 1741 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1742 s=- 1743 c=IN IP4 192.0.2.101 1744 t=0 0 1745 m=audio 49172 RTP/AVP 0 1746 a=rtpmap:0 PCMU/8000 1747 a=sendonly 1749 /* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE 1750 again after 2.1-4.0 seconds. */ 1752 F15 200 OK Bob -> Alice 1754 F16 ACK Alice -> Bob 1756 3.3.2 UPDATE and re-INVITE crossover 1758 Alice Bob 1759 | | 1760 | INVITE F1 | 1761 |--------------------------->| 1762 | 180 Ringing F2 | 1763 |<---------------------------| 1764 | | 1765 | 200 OK F3 | 1766 |<---------------------------| 1767 | ACK F4 | 1768 |--------------------------->| 1769 | Both Way RTP Media | 1770 |<==========================>| 1771 | | 1772 | UPDATE F5 re-INVITE F6 | 1773 |------------ -------------| 1774 | \ / | 1775 | X | 1776 | / \ | 1777 |<----------- ------------>| 1778 | 491 F8 491 F7 | 1779 |------------ -------------| 1780 | \ / | 1781 | X | 1782 | / \ | 1783 |<----------- ------------>| 1784 | ^ ACK F9 ^ | 1785 |<-|----------------|--------| 1786 | | | | 1787 | |0-2.0 sec | | 1788 | | | | 1789 | v re-INVITE F10 | | 1790 |<------------------|--------| 1791 | 200 OK F11 | | 1792 |-------------------|------->| 1793 | ACK F12 | | 1794 |<------------------|--------| 1795 | | | 1796 | |2.1-4.0 sec 1797 | | | 1798 | UPDATE F13 v | 1799 |--------------------------->| 1800 | 200 OK F14 | 1801 |<---------------------------| 1802 | | 1803 | | 1805 In this scenario, the UPDATE contains a SDP offer, therefore the 1806 UPDATE and re-INVITE are responded with 491 as in the case of 1807 "re-INVITE crossover". When an UPDATE for refresher which doesn't 1808 contain a session description and a re-INVITE crossed each other, 1809 both requests succeed with 200 (491 means that UA have a pending 1810 request). Moreover, the same is equally true for UPDATE crossover. 1811 In the former case where either UPDATE contains a session description 1812 the requests fail with 491, and in the latter cases succeed with 200. 1814 Editor's Note: 1815 A 491 response is considered as a result that UA judged the 1816 effectiveness of request to "What is established by SIP". 1817 Therefore, it is considered that 491 will be used in all the 1818 requests that demand operation to "What is established by SIP". 1820 Message Details 1822 F1 INVITE Alice -> Bob 1823 F2 180 Ringing Bob -> Alice 1825 F3 200 OK Bob -> Alice 1827 F4 ACK Alice -> Bob 1829 F5 UPDATE Alice -> Bob 1831 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1832 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1833 Max-Forwards: 70 1834 From: Alice ;tag=9fxced76sl 1835 To: Bob ;tag=8321234356 1836 Call-ID: 3848276298220188511@atlanta.example.com 1837 CSeq: 2 UPDATE 1838 Content-Length: 147 1840 v=0 1841 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1842 s=- 1843 c=IN IP4 192.0.2.101 1844 t=0 0 1845 m=audio 49172 RTP/AVP 0 1846 a=rtpmap:0 PCMU/8000 1847 a=sendonly 1849 F6 re-INVITE Bob -> Alice 1851 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1852 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1853 Session-Expires: 300;refresher=uac 1854 Supported: timer 1855 Max-Forwards: 70 1856 From: Bob ;tag=8321234356 1857 To: Alice ;tag=9fxced76sl 1858 Call-ID: 3848276298220188511@atlanta.example.com 1859 CSeq: 1 INVITE 1860 Content-Length: 0 1862 /* A case where a re-INVITE for a session refresh and a re-INVITE for 1863 a call hold are sent at the same time. */ 1865 F7 491 Request Pending Bob -> Alice 1866 /* Since a re-INVITE is in process, a 491 response are returned. */ 1868 F8 491 Request Pending Alice -> Bob 1870 F9 ACK (re-INVITE) Alice -> Bob 1871 F10 re-INVITE Bob -> Alice 1873 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1874 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1 1875 Session-Expires: 300;refresher=uac 1876 Supported: timer 1877 Max-Forwards: 70 1878 From: Bob ;tag=8321234356 1879 To: Alice ;tag=9fxced76sl 1880 Call-ID: 3848276298220188511@atlanta.example.com 1881 CSeq: 2 INVITE 1882 Content-Type: application/sdp 1883 Content-Length: 133 1885 v=0 1886 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1887 s=- 1888 c=IN IP4 192.0.2.201 1889 t=0 0 1890 m=audio 3456 RTP/AVP 0 1891 a=rtpmap:0 PCMU/8000 1893 /* Since Bob is not the owner of Call-ID, Bob sends an INVITE again 1894 after 0.0-2.0 seconds. */ 1896 F11 200 OK Alice -> Bob 1898 F12 ACK Bob -> Alice 1900 F13 UPDATE Alice -> Bob 1902 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1903 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 1904 Max-Forwards: 70 1905 From: Alice ;tag=9fxced76sl 1906 To: Bob ;tag=8321234356 1907 Call-ID: 3848276298220188511@atlanta.example.com 1908 CSeq: 3 UPDATE 1909 Content-Length: 147 1911 v=0 1912 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1913 s=- 1914 c=IN IP4 192.0.2.101 1915 t=0 0 1916 m=audio 49172 RTP/AVP 0 1917 a=rtpmap:0 PCMU/8000 1918 a=sendonly 1919 /* Since Alice is the owner of the Call-ID, Alice sends the UPDATE 1920 again after 2.1-4.0 seconds. */ 1922 F14 200 OK Bob -> Alice 1924 3.3.3 Receiving REFER (Establish state) 1925 in Mortal state 1927 State Alice Bob State 1928 | | 1929 | INVITE F1 | 1930 |----------------------->| 1931 Pre | 180 Ringing F2 | Pre 1932 |<-----------------------| 1933 Ear | | Ear 1934 | 200 OK F3 | 1935 |<-----------------------| 1936 Mora | ACK F4 | Mora 1937 |----------------------->| 1938 Est | Both Way RTP Media | Est 1939 |<======================>| 1940 | | 1941 | BYE F5 REFER F6 | 1942 |--------- ----------| 1943 Mort | \ / | 1944 | X | 1945 | / \ | 1946 *race* |<-------- --------->| 1947 | | Mort 1948 | 481 F8 200 F7 | 1949 |--------- ----------| 1950 | \ / ^ | 1951 | X | | 1952 | / \ | | 1953 |<-------- --------->| 1954 | ^ | | 1955 | | Timer K | | 1956 | V | | 1957 Morg | Timer J | | 1958 | V | 1959 | | Morg 1960 | | 1962 This scenario illustrates the race condition which occurs when UAS 1963 receives an Established message, REFER, in the Mortal state. 1964 Bob sends a REFER, and Alice sends a BYE at the same time. Bob 1965 send the REFER in the same dialog. Alice sends an error response 1966 to the requests which operates the session, such as REFER, because 1967 by sending the BYE, Alice had terminated the session which would 1968 have corresponded to the REFER. For handling of dialogs with 1969 multiple usages, as can be seen in the use of REFER method, 1970 see the draft on dialog usage [8]. 1972 Message Details 1974 F1 INVITE Alice -> Bob 1976 F2 180 Ringing Bob -> Alice 1978 F3 200 OK Bob -> Alice 1980 F4 ACK Alice -> Bob 1982 F5 BYE Alice -> Bob 1983 /* Alice sends a BYE request and terminates the session, and transits 1984 from the Confirmed state to Terminated state. */ 1986 F6 REFER Bob -> Alice 1988 REFER sip:alice@client.atlanta.example.com SIP/2.0 1989 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1990 Max-Forwards: 70 1991 From: Bob ;tag=8321234356 1992 To: Alice ;tag=9fxced76sl 1993 Call-ID: 3848276298220188511@atlanta.example.com 1994 Refer-To: sip:carol@cleveland.example.org 1995 Contact: 1996 CSeq: 1 REFER 1997 Content-Length: 0 1999 /* Alice sends a BYE, and Bob sends a REFER at the same time. 2000 Bob sends the REFER on the INVITE dialog. 2001 The dialog state transits to the Mortal state at the moment 2002 Alice sends the BYE, but Bob doesn't know it until he receives 2003 the BYE. A race condition occurs. */ 2005 F7 200 OK Bob -> Alice 2007 F8 481 Call/Transaction Does Not Exist Alice -> Bob 2008 /* Since Alice has terminated the session, she responds with a 481 2009 to the REFER. */ 2011 Appendix A - BYE on the Early Dialog 2013 This section, related to Section 3.1.3, explains why BYE is not 2014 recommended in the Early state, illustrating the case in which BYE 2015 in the Early dialog triggers confusion. 2017 Alice Proxy Bob Carol 2018 | | | | 2019 | INVITE F1 | | | 2020 |--------------->| INVITE F2 | | 2021 | 100 F3 |----------------->| | 2022 |<---------------| 180(To-tag=1) F4 | | 2023 | 180(1) F5 |<-----------------| | 2024 |<---------------| | | 2025 | | INVITE(Fork) F6 | 2026 | |------------------------>| 2027 | | 100 F7 | 2028 | BYE(1) F8 |<------------------------| 2029 |--------------->| BYE(1) F9 | | 2030 | |----------------->| | 2031 | | 200(1) F10 | | 2032 | 200(1) F11 |<-----------------| | 2033 |<---------------| 487(1) F12 | | 2034 | |<-----------------| | 2035 | | ACK(1) F13 | | 2036 | |----------------->| | 2037 | | | | 2038 | | | 2039 | | 200(To-tag=2) F13 | 2040 | 200(2) F14 |<------------------------| 2041 |<---------------| | 2042 | ACK(2) F15 | | 2043 |--------------->| ACK(2) F16 | 2044 | |------------------------>| 2045 | BYE(2) F17 | | 2046 |--------------->| BYE(2) F18 | 2047 | |------------------------>| 2048 | | 200(2) F19 | 2049 | 200(2) F20 |<------------------------| 2050 |<---------------| | 2051 | | | 2052 | | | 2054 Care is advised in sending BYE in the Early state when forking by a 2055 proxy is expected. In this example, the BYE request progresses 2056 normally, and it succeeds in correctly terminating the dialog with 2057 Bob. After Bob terminates the dialog by receiving the BYE, he sends 2058 487 to the ini-INVITE. According to Section 15.1.2 of RFC3261 [1], 2059 it is RECOMMENDED for UAS to generate 487 to any pending requests 2060 after receiving BYE. In the example, Bob sends 487 to ini-INVITE 2061 since he receives BYE while the ini-INVITE is in pending state. 2063 However, Alice receives a final response to INVITE (a 200 from Carol) 2064 even though she has successfully terminated the dialog with Bob. This 2065 means that, regardless of the success/failure of the BYE in the Early 2066 state, Alice MUST be prepared for the establishment of a new dialog 2067 until receiving the final response for the INVITE and terminating the 2068 INVITE transaction. 2070 The choice of BYE or CANCEL in the early state must be made 2071 carefully. CANCEL is appropriate when the goal is to abandon 2072 the call attempt entirely. BYE is appropriate when the goal is 2073 to abandon a particular early dialog while allowing the call 2074 to be completed with other destinations. When using either BYE 2075 or CANCEL the UAC must be prepared for the possibility that 2076 a call may still be established to one (or more) destinations. 2078 Appendix B - BYE request overlapped on re-INVITE 2080 UAC UAS 2081 | | 2082 The session has been already established 2083 ========================== 2084 | F1 re-INVITE | 2085 |--------------------->| 2086 | F2 BYE | 2087 |--------------------->| 2088 | F3 200(BYE) | 2089 |<---------------------| 2090 | F4 INVITE(=F1) | 2091 |--------------------->| 2092 | | 2093 | | 2095 This case could look similar to the one in Section 3.2.3. However, 2096 it is not a race condition. This case describes the behavior where 2097 there is no response for INVITE for some reasons. The appendix 2098 explains the behavior in such case and its rationale behind, since 2099 this case is likely to cause confusion. 2100 First of all, it is important not to confuse the behavior of the 2101 transaction layer and that of the dialog layer. RFC3261 [1] details 2102 the Transaction layer behavior. The dialog layer behavior is 2103 explained in this document. 2104 It has to be noted that these behaviors are independent of each 2105 other, even though the both layers change their states triggered by 2106 sending or receiving of the same SIP messages (A dialog can be 2107 terminated even though a transaction still remain, and vice versa). 2108 In the sequence above, there is no response for F1, and F2 (BYE) is 2109 sent immediately after F1 (F1 is a mid-dialog request. If F1 was 2110 ini-INVITE, BYE could not be sent before UAC received a provisional 2111 response to the request with To-tag). 2113 Below is a figure which illustrates UAC's dialog state and 2114 transaction state. 2116 BYE INV dialog UAC UAS 2117 : | | 2118 : | | 2119 | | F1 re-INVITE | 2120 o | |--------------------->| 2121 | | | F2 BYE | 2122 o | (Mortal) |--------------------->| 2123 | | | | F3 200(BYE) | 2124 | | | |<---------------------| 2125 | | | | F4 INVITE(=F1) | 2126 | | | |--------------------->| 2127 | | | | F5 481(INV) | 2128 | | | |<---------------------| 2129 | | | | F6 ACK(INV) | 2130 | | | |--------------------->| 2131 | | | | | 2132 o | o | | 2133 | | | 2134 o | | 2135 | | 2137 For UAC, the INVITE client transaction begins at the point F1 is 2138 sent. The UAC sends BYE (F2) immediately after F1. This is a 2139 legitimate behavior. (Usually the usage of each SIP method is 2140 independent, for BYE and others. However, it should be noted that 2141 it is prohibited to send a request with a SDP offer while the 2142 previous offer is in progress.) 2143 After that, F2 triggers the BYE client transaction. At the same time, 2144 the dialog state transits to the Mortal state and then only a BYE or 2145 its response can be handled. 2146 It is permitted to send F4 (a retransmission of INVITE) in the Mortal 2147 state, because the retransmission of F1 is handled by the transaction 2148 layer, and the INVITE transaction has not yet transited to the 2149 Terminated state. As it is mentioned above, the dialog and the 2150 transaction behave independently each other. 2151 Therefore the transaction handling has to be continued even though 2152 the dialog moved to the Terminated state. 2154 Next, UAS's state is shown below. 2156 UAC UAS dialog INV BYE 2157 | | : 2158 | | : 2159 | F1 re-INVITE | | 2160 |-------------->x | | 2161 | F2 BYE | | 2162 |--------------------->| | o 2163 | F3 200(BYE) | (Mortal) | 2164 |<---------------------| | |<-Start TimerJ 2165 | F4 INVITE(=F1) | | | 2166 |--------------------->| | o | 2167 | F5 4xx(INV) | o | o 2168 |<---------------------| | 2169 | F6 ACK(INV) | | 2170 |--------------------->| |<-Start TimerI 2171 | | | 2172 | | | 2173 | | o 2174 | | 2176 For UAS, it can be regarded that F1 packet is lost or delayed (Here 2177 the behavior is explained for the case UAS receives F2 BYE before F1 2178 INVITE). Therefore, F2 triggers the BYE transaction for UAS, and 2179 simultaneously the dialog moves to the Mortal state. 2180 Then, upon the reception of F4 the INVITE server transaction begins. 2181 (It is allowed to start the INVITE server transaction in the Mortal 2182 state. The INVITE server transaction begins to handle received SIP 2183 request regardless of the dialog state.) 2184 UAS's TU sends an appropriate error response for F4 INVITE, either 2185 481 (because the TU knows that the dialog which matches to the 2186 INVITE is in the Terminated state) or 500 (because the re-sent F4 2187 has an out-of-order CSeq). 2188 (It is mentioned above that F4 (and F1) INVITE is a mid-dialog 2189 request. Mid-dialog requests have a To-tag. It should be noted that 2190 UAS's TU does not begin a new dialog upon the reception of INVITE 2191 with a To-tag.) 2193 Appendix C - UA's behaviour for CANCEL 2195 This section explains the CANCEL and the Expires header behaviors 2196 which indirectly involve in the dialog state transition in the Early 2197 state. CANCEL does not have any influence on UAC's dialog state. 2198 However, the request has indirect influence on the dialog state 2199 transition because it has a significant effect on ini-INVITE. 2200 Similarly, the Expires header does not have direct influence on the 2201 dialog state transition, but it indirectly affect the state 2202 transition because its expiration triggers the sending of CANCEL. 2203 For UAS the CANCEL request and the Expires header timeout have more 2204 direct effects on the dialog than the sending of CANCEL by UAC, 2205 because they can be a trigger to send the 487 response. Figure 3 2206 explains UAS's behavior in the Early state. This flow diagram is 2207 only an explanatory figure, and the actual dialog state transition is 2208 as illustrated in Figure 1 and 2. 2210 In the flow, full lines are related to dialog state transition, and 2211 dotted lines are involved with CANCEL. (r) represents the reception 2212 of signals, and (s) means sending. There is no dialog state for 2213 CANCEL, but here the Cancelled state is virtually handled just for 2214 the ease of understanding of the UA's behavior when it sends and 2215 receives CANCEL. 2217 Below, UAS's flow is explained. 2219 +------------+ 2220 | Proceeding |----+ 2221 +------------+ | 2222 : | 1xx(s) | 2223 : V | 2224 : +-------+ | 2xx(s) 2225 : | Early |-----+------+ 2226 : +-------+ | 2227 : : V 2228 : : +-----------+ 2229 : : | Confirmed |<... 2230 :.....: +-----------+ : 2231 : | : : 2232 : BYE(r)| : : 2233 : CANCEL(r) | :.......: 2234 V | CANCEL(r) 2235 ............. | 2236 : Cancelled : | 2237 :...........: | 2238 | 487(s) | 2239 | | 2240 +--------------------+ 2241 | 2242 V 2243 +------------+ 2244 | Terminated | 2245 +------------+ 2247 Figure 3. CANCEL flow diagram for UAS 2249 There are two behaviors for UAS depending on the state when it 2250 receives CANCEL. 2251 One is when UAS receives CANCEL in the Proceeding and Early states. 2252 In this case the UAS immediately sends 487 for the INVITE, and the 2253 dialog transits to the Terminated state. 2254 The other is the case in which UAS receives CANCEL in the Confirmed 2255 state. In this case the dialog state transition does not occur 2256 because UAS has already sent a final response to the INVITE to which 2257 the CANCEL is targeted. 2258 (Note that, because of UAC's behavior, a UAS that receives a CANCEL 2259 in the Confirmed state can expect to receive a BYE immediately and 2260 move to the Terminated state. However, the UAS's state does not 2261 transit until it actually receives BYE.) 2263 Appendix D - Notes on the request in Mortal state 2265 This section describes UA's behavior in the Mortal state which need 2266 careful attention. 2268 In the Mortal state, BYE can be accepted, and the other messages in 2269 the INVITE dialog usage are responded with an error. However, 2270 sending of ACK and the authentication procedure for BYE are 2271 conducted in this state. 2272 (The handling of messages concerning multiple dialog usages is out of 2273 the scope of this document. Refer to [8] for further information.) 2275 ACK for error responses is handled by the transaction layer, so the 2276 handling is not related to the dialog state. Unlike the ACK for 2277 error responses, ACK for 2xx responses is a request newly generated 2278 by TU. However, the ACK for 2xx and the ACK for error responses are 2279 both a part of the INVITE transaction, even though their hadling 2280 differs (Section 17.1.1.1, RFC3261 [1]). 2281 Therefore, the INVITE transaction is completed by the three-way 2282 handshake, which includes ACK, even in the Mortal state. 2283 Considering actual implementation, UA needs to keep the INVITE dialog 2284 usage until the Mortal state finishes, so that it is able to ACK for 2285 a 2xx response in the Mortal state. 2286 If a 2xx to INVITE is received in the Mortal state, the duration of 2287 the INVITE dialog usage will be extended to 64*T1 seconds after the 2288 receiving of the 2xx, to cope with the possible 2xx retransmission. 2289 (The duration of the 2xx retransmission is 64*T1, so the UA need to 2290 be prepared to handle the retransmission for this duration.) 2291 However, the UA shall send error response to other requests, since 2292 the INVITE dialog usage in the Mortal state is kept only for the 2293 sending of ACK for 2xx. 2295 BYE authentication procedure shall be processed in the Mortal state. 2296 When authentication is requested by 401 or 407 response, UAC resends 2297 BYE with an appropriate credentials. Also UAS handles the 2298 retransmission of the BYE which it requested authentication itself. 2300 Appendix E - Forking and receiving new To-tags 2302 This section details the behavior of TU when it receives multiple 2303 responses with a different To tag to ini-INVITE. 2304 When an INVITE is forked inside a SIP network, there is a possibility 2305 that the TU receives multiple responses with a different To tag to 2306 ini-INVITE (See Section 11.2, 13.1, 13.2.2.4, 16.7, 19.3 etc. of 2307 RFC3261). If the TU receives multiple 1xx responses with a different 2308 To tag, the original DSM forks and a new DSM instance is created. As 2309 a consequence multiple early dialogs are generated. 2310 If one of the multiple early dialogs receives a 2xx response, it 2311 naturally transits to the Confirmed state. No DSM state transition 2312 occurs for the other early dialogs, and their sessions (early media) 2313 terminate. The TU of the UAC terminates the INVITE transaction after 2314 64*T1 seconds starting at the point of receiving the first 2xx 2315 response. Moreover, all mortal early dialog which do not transit to 2316 the Established state are terminated (See Section 13.2.2.4 of 2317 RFC3261). 2319 Below is an example sequence in which two 180 responses with a 2320 different To tag are received, and then a 200 response for one of the 2321 early dialogs (dialog A) is received. Dot lines (..) in sequences 2322 is auxiliary line to represent the influence on dialog B. 2324 UAC 2325 dialog(A) | F1 INVITE 2326 Pre o |-------------------------> 2327 | | F2 100 2328 | |<------------------------- 2329 | | F3 180(To-tag=A) 2330 Ear | |<------------------------- 2331 dialog(B) | | 2332 forked new DSM | | F4 180(To-tag=B) 2333 Ear o..........|..........|<------------------------- 2334 | | | 2335 | | | F5 200(To-tag=A) 2336 terminate->|.....Mora |..........|<------------------------- 2337 early | | ^ | F6 ACK(To-tag=A) 2338 media | Est | | |-------------------------> 2339 | | | | 2340 | | |64*T1 | 2341 | | |(13.2.2.4 of RFC3261) 2342 | | | | 2343 | | | | 2344 | | | | 2345 | | V | 2346 o..........|.(terminate INVITE transaction) 2347 terminated | | 2348 dialog(B) | | 2349 | | 2351 The figure above shows the DSM inside a SIP TU. Triggered by the 2352 reception of a provisional response with a different To tag 2353 (F4 180(To-tag=B)), DSM forks and the early dialog B is generated. 2354 After 64*T1 seconds after the dialog A receives 200 OK response, the 2355 dialog B, which does not transit to the Established state, 2356 terminates. 2357 Next, the behavior of a TU which receives multiple 2xx responses with 2358 a different To tag is explained. When a mortal early dialog, which 2359 did not match the first 2xx response the TU received, receives 2360 another 2xx response which matches its To tag before 64*T1 INVITE 2361 transaction timeout, its DSM state transits to the Confirmed state. 2362 However, the seesion on the mortal early dialog is terminated when 2363 the TU receives the first 2xx to establish a dialog, so no session is 2364 established for the mortal early dialog. Therefore, when the mortal 2365 early dialog receives a 2xx response, the TU should send an ACK and, 2366 immediately after, BYE to terminate DSM. 2367 The handling of the second early dialog after receiving the 200 for 2368 the first dialog is quite appropriate for a typical device, such as a 2369 phone. It is important to note that what is being shown is a 2370 typically useful action and not the only valid one. Some devices 2371 might want to handle things differently. For instance, a conference 2372 focus that has sent out an invite that forks may want to accept and 2373 mix all the dialogs it gets. 2375 Below is an example sequence in which two 180 responses with a 2376 different To tag are received and then a 200 response for each of the 2377 early dialogs is received. 2379 UAC 2380 dialog(A) | F1 INVITE 2381 Pre o |-----------------------> 2382 | | F2 100 2383 | |<----------------------- 2384 | | F3 180(To-tag=A) 2385 dialog(B) Ear | |<----------------------- 2386 forked new DSM | | F4 180(To-tag=B) 2387 Ear o..........|..........|<----------------------- 2388 | | | 2389 | | | F5 200(To-tag=A) 2390 terminate->|.....Mora |..........|<----------------------- 2391 early | | ^ | F6 ACK(To-tag=A) 2392 media | Est | | |-----------------------> 2393 | | |64*T1 | 2394 | | | | F7 200(To-tag=B) 2395 Mora |..........|.|........|<----------------------- 2396 | | | | F8 ACK(To-tag=B) 2397 Est |..........|.|........|-----------------------> 2398 | | | | F9 BYE(To-tag=B) 2399 Mort |..........|.|........|-----------------------> 2400 ^ | | | | F10 200(To-tag=B) 2401 | | | | |<----------------------- 2402 |Timer K | | | 2403 | | | V | 2404 | | | (terminate INVITE transaction) 2405 V | | | 2406 Morg o | | 2407 | | 2409 Finally, when a TU receives multiple 200 responses with a different 2410 To tag before 64*T1 timeout of the INVITE transaction, even though 2411 a TU does not receive provisional response, the TU needs to respond 2412 to the 2xx responses (See Section 13.2.2.4 of RFC3261). In that 2413 case, the DSM state is forked at the Confirmed state, and then the 2414 TU sends an ACK for the 2xx response and, immediately after, BYE. 2416 UAC 2417 dialog(A) | F1 INVITE 2418 Pre o |-----------------------> 2419 | | F2 100 2420 | |<----------------------- 2421 | | F3 180(To-tag=A) 2422 Ear | |<----------------------- 2423 | | 2424 | | F4 200(To-tag=A) 2425 Mora |..........|<----------------------- 2426 | ^ | F5 ACK(To-tag=A) 2427 Est | | |-----------------------> 2428 | | | 2429 dialog(B) | |64*T1 | 2430 forked new DSM | | | F6 200(To-tag=B) 2431 Mora o..........|.|........|<----------------------- 2432 | | | | F7 ACK(To-tag=B) 2433 Est |..........|.|........|-----------------------> 2434 | | | | F8 BYE(To-tag=B) 2435 Mort |..........|.|........|-----------------------> 2436 ^ | | | | F9 200(To-tag=B) 2437 | | | | |<----------------------- 2438 | | | V | 2439 |Timer K | (terminate INVITE transaction) 2440 | | | | 2441 V | | | 2442 Morg o | | 2443 | | 2445 References 2447 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2448 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2449 Session Initiation Protocol", RFC 3261, June 2002. 2451 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2452 SDP", RFC 3264, April 2002. 2454 [3] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 2455 Summers, "Session Initiation Protocol (SIP) Basic Call Flow 2456 Examples", BCP 75, RFC 3665, December 2003. 2458 [4] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 2459 Summers, "Session Initiation Protocol (SIP) Public Switched 2460 Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December 2461 2003. 2463 [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2464 Method", RFC 3515, April 2003. 2466 [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 2467 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 2468 June 2002. 2470 [7] Rosenberg, J., Schulzrinne, H., Mahy, R., "An INVITE-Initiated 2471 Dialog Event Package for the Session Initiation Protocol (SIP)", 2472 RFC 4235, November 2005. 2474 [8] Sparks, R., "Multiple Dialog Usages in the Session Initiation 2475 Protocol", draft-ietf-sipping-dialogusage-06 (work in progress), 2476 Febrary 20, 2007. 2478 Author's Addresses 2480 All listed authors actively contributed large amounts of text to this 2481 document. 2483 Miki Hasebe 2484 NTT-east Corporation 2485 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2487 EMail: hasebe.miki@east.ntt.co.jp 2489 Jun Koshiko 2490 NTT-east Corporation 2491 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2492 EMail: j.koshiko@east.ntt.co.jp 2494 Yasushi Suzuki 2495 NTT-east Corporation 2496 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2498 EMail: suzuki.yasushi@east.ntt.co.jp 2500 Tomoyuki Yoshikawa 2501 NTT-east Corporation 2502 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2504 EMail: tomoyuki.yoshikawa@east.ntt.co.jp 2506 Paul H. Kyzivat 2507 Cisco Systems, Inc. 2508 1414 Massachusetts Avenue 2509 Boxborough, MA 01719 2510 USA 2512 Email: pkyzivat@cisco.com 2514 Intellectual Property Statement 2516 The IETF takes no position regarding the validity or scope of any 2517 Intellectual Property Rights or other rights that might be claimed to 2518 pertain to the implementation or use of the technology described in 2519 this document or the extent to which any license under such rights 2520 might or might not be available; nor does it represent that it has 2521 made any independent effort to identify any such rights. Information 2522 on the procedures with respect to rights in RFC documents can be 2523 found in BCP 78 and BCP 79. 2525 Copies of IPR disclosures made to the IETF Secretariat and any 2526 assurances of licenses to be made available, or the result of an 2527 attempt made to obtain a general license or permission for the use of 2528 such proprietary rights by implementors or users of this 2529 specification can be obtained from the IETF on-line IPR repository at 2530 http://www.ietf.org/ipr. 2532 The IETF invites any interested party to bring to its attention any 2533 copyrights, patents or patent applications, or other proprietary 2534 rights that may cover technology that may be required to implement 2535 this standard. Please address the information to the IETF at 2536 ietf-ipr@ietf.org. 2538 Disclaimer of Validity 2540 This document and the information contained herein are provided on an 2541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2543 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2544 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2545 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2546 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2548 Full Copyright Statement 2550 Copyright (C) The IETF Trust (2007). 2552 This document is subject to the rights, licenses and restrictions 2553 contained in BCP 78, and except as set forth therein, the authors 2554 retain all their rights. 2556 This document and the information contained herein are provided on an 2557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2559 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2560 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2561 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2564 Acknowledgment 2566 The authors would like to thank Robert Sparks, Dean Willis, 2567 Cullen Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, 2568 Akihiro Shimizu, Mayumi Munakata, Yasunori Inagaki, 2569 Tadaatsu Kidokoro, Kenichi Hiragi and Dale Worley, for their comments 2570 on this document.