idnits 2.17.1 draft-ietf-sipping-race-examples-00.txt: -(388): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 2405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2395. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: 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 2312, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2321, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2324, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialogusage-05 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-dialogusage (ref. '8') Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. HASEBE 3 Internet-Draft J. KOSHIKO 4 Expires: Jun 11th, 2007 Y. SUZUKI 5 T. YOSHIKAWA 6 NTT-East 7 P. Kyzivat 8 Cisco Systems, Inc. 9 Dec 11th, 2006 11 Examples call flow in race condition on Session Initiation Protocol 12 draft-ietf-sipping-race-examples-00.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 June 11, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 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 condition . . . . . . . . . . . . . . . . . . . . . . . . .9 59 3.1 Receiving message in the Moratorium State. . . . . . . . . .9 60 3.1.1 Receiving Initial INVITE retransmission(Trying state). .9 61 3.1.2 Receiving CANCEL(Proceeding or Early state). . . . . . .11 62 3.1.3 Receiving BYE (Early state). . . . . . . . . . . . . . .12 63 3.1.4 Receiving re-INVITE (Established state)(case 1). . . . .14 64 3.1.5 Receiving re-INVITE (Established state)(case 2). . . . .18 65 3.1.6 Receiving BYE (Established state). . . . . . . . . . . .21 66 3.2 Receiving message in the Mortal State. . . . . . . . . . . .23 67 3.2.1 Receiving BYE(Established state) . . . . . . . . . . . .23 68 3.2.2 Receiving re-INVITE(Established state) . . . . . . . . .26 69 3.2.3 Receiving 200OK for re-INVITE(Established state) . . . .29 70 3.2.4 Receiving ACK (Moratorium state) . . . . . . . . . . . .31 71 3.3 other race condition . . . . . . . . . . . . . . . . . . . .33 72 3.3.1 re-INVITE crossover. . . . . . . . . . . . . . . . . . .33 73 3.3.2 UPDATE and re-INVITE crossover . . . . . . . . . . . . .37 74 3.3.3 Receiving REFER(Established state) . . . . . . . . . . .41 75 Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . .43 76 Appendix B. BYE request overlapped on re-INVITE . . . . . . . . . .44 77 Appendix C. UA's behaviour for CANCEL . . . . . . . . . . . . . . .46 78 Appendix D. Notes on the request in Mortal state. . . . . . . . . .48 79 References . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 80 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . . .49 81 Intellectual Property Statement . . . . . . . . . . . . . . . . . .50 82 Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . . . .51 83 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . .51 84 Acknowledgment. . . . . . . . . . . . . . . . . . . . . . . . . . .51 86 1. Overview 88 The call flows shown in this document were developed in the design of 89 a SIP IP communications network. These examples are of race 90 condition, which stems from the dialog state transition mainly 91 established by INVITE. 93 When implementing SIP, various complex situations may arise. 94 Therefore, it will be helpful to provide implementors of the 95 protocol with examples of recommended terminal and server behavior. 97 This document clarifies SIP UA behaviors when messages cross each 98 other as race conditions. By clarifying operation under race 99 conditions, inconsistent interpretations between implementations are 100 avoided and interoperability is expected to be promoted. 102 It is the hope of the authors that this document will be useful for 103 SIP implementors, designers, and protocol researchers and will help 104 them achieve the goal of a standard implementation of RFC 3261 [1]. 106 These call flows are based on the version 2.0 of SIP defined in RFC 107 3261 [1] with SDP usage described in RFC 3264 [2]. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in BCP 14, RFC 2119 [4]. 113 1.1 General Assumptions 115 A number of architecture, network, and protocol assumptions underlie 116 the call flows in this document. Note that these assumptions are not 117 requirements. They are outlined in this section so that they may be 118 taken into consideration and help understanding the call 119 flow examples. 121 These flows do not assume specific underlying transport protocols 122 such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for 123 details on the transport issues for SIP. 125 1.2 Legend for Message Flows 127 Dashed lines (---) and slash lines (/,\) represent signaling messages 128 that are mandatory to the call scenario. (X) represents crossover of 129 signaling messages. (->x,x<-) indicate that the packet is lost. 130 The arrow indicate the direction of message flow. Double dashed 131 lines (===) represent media paths between network elements. 133 Messages are identified in the Figures as F1, F2, etc. These numbers 134 are used for references to the message details that follow the 135 Figure. 136 Comments in the message details are shown in the following form: 138 /* Comments. */ 140 1.3 SIP Protocol Assumptions 142 This document does not prescribe the flows precisely as they are 143 shown, but rather illustrates the principles for best practice. 144 They are best practice usages (orderings, syntax, selection of 145 features for the purpose, or handling of error) of SIP methods, 146 headers and parameters. NOTE: The flows in this document must not 147 be copied as they are by implementors because additional 148 characteristics were incorporated into the document for ease of 149 explanation. To sum up, the procedures described in this document 150 represent well-reviewed examples of SIP usage, which are best common 151 practice according to IETF consensus. 153 For simplicity in reading and editing the document, there are a 154 number of differences between some of the examples and actual SIP 155 messages. For instance, Call-IDs are often repeated, CSeq often 156 begins at 1, header fields are usually shown in the same order, 157 usually only the minimum required header field set is shown, and 158 other headers which would usually be included such as Accept, Allow, 159 etc are not shown. 161 Actors: 163 Element Display Name URI IP Address 164 ------- ------------ --- ---------- 166 User Agent Alice sip:alice@atlanta.example.com 192.0.2.101 167 User Agent Bob sip:bob@biloxi.example.com 192.0.2.201 168 User Agent Carol sip:carol@chicago.example.com 192.0.2.202 169 Proxy Server ss.atlanta.example.com 192.0.2.111 171 2. The Dialog State Machine for INVITE dialog usage 173 Race conditions are generated when the dialog state of the receiving 174 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. 181 The DSM (dialog state machine) for the INVITE dialog usage is 182 presented as follows to help understanding UA's behavior in race 183 conditions. 185 The DSM clarifies UA's behavior by subdividing some internal states 186 showed in the FSM (Finite State Machine) for dialog state of the 187 dialog-package [7], without changing the states of the dialog, 188 "early", "confirmed", and "terminated" shown in RFC3261 [1]. 189 The Preparative state is put before the Early state, which includes 190 the Trying and Proceeding states. The Confirmed state is subdivided 191 into two substates, the Moratorium and Established states and the 192 Terminated state is subdivided into the Mortal and Morgue states. 194 Below are the DSMs for UAC and UAS respectively. 196 +-----------------------------------------------+ 197 | Preparative | 198 | +----------+ +--------------+ | 199 | | | 100 | |-----C-+ 200 | | Trying |---------->| Proceeding | | | 100 201 | | | | |<----C-+ 202 | +----------+ +--------------+ | 203 | | 204 +-----------------------------------------------+ 205 | | | 206 | 3xx-6xx | 1xx-tag | 2xx 207 | | | 208 | V | 209 | +------------------+ | 210 | 3xx-6xx | |--+ 1xx-tag | 211 +<--------| Early | | w/new tag | 212 | | |<-+ (new DSM | 213 | +------------------+ instance | 214 | | | created) | 215 | | BYE | 2xx | 216 | | +------------>+<-+ 217 | | | 218 +-----C------------C-----+ +-----------C------+ 219 | | Terminated | | | Confirmed | | 220 | | +<----C---------| | | 221 | | | | BYE | | | 222 | | V | | V | 223 | | +------------+ | | +-----------+ | 224 | | | |---C-+ | | |--C-+ 2xx 225 | | | Mortal | | | BYE(r)| | Moratorium| | | w/new tag 226 | | | |<--C-+ | | |<-C-+ (new DSM 227 | | +------------+ | | +-----------+ | instance 228 | | | | | | | created) 229 | | | Timeout | | | ACK | 230 | | | (Timer K) | | | | 231 | V V | | V | 232 | +---------------+ | | +-----------+ | 233 | | | | | | | | 234 | | Morgue | | | |Established| | 235 | | | | | | | | 236 | +---------------+ | | +-----------+ | 237 | | | | 238 +------------------------+ +------------------+ 240 (r): indicates only reception is allowed. 241 Where (r) is not indicated, response means receive, request 242 means send. 244 Figure 1. DSM for INVITE dialog usage (UAC) 246 Figure 1 represents the UAC's DSM for the INVITE dialog usage. 247 UAC MAY send a BYE in the Early state, even though this behavior is 248 NOT RECOMMENDED. The BYE sent in the Early state terminates the 249 Early dialog with a specific To-tag. That is, when a proxy is 250 performing forking, the BYE is only able to terminate the Early 251 dialog between a particular UA. If UAC wants to terminate all Early 252 dialogs instead of that with a particular UA, it needs to send 253 CANCEL, not BYE. Moreover, until UAC receives a final response and 254 terminates the INVITE transaction, the UAC MUST be prepared to 255 establish a dialog by receiving a new response to the INVITE even 256 though it had sent a BYE and terminated the dialog (see Appendix A). 258 +-----------------------------------------------+ 259 | Preparative | 260 | +----------+ +--------------+ | 261 | | | 100 | |-----C-+ 262 | | Trying |---------->| Proceeding | | | 100 263 | | | | |<----C-+ 264 | +----------+ +--------------+ | 265 | | 266 +-----------------------------------------------+ 267 | | | 268 | 3xx-6xx | 1xx-tag | 2xx 269 | | | 270 | V | 271 | +------------------+ | 272 | 3xx-6xx | |--+ | 273 +<--------| Early | | 1xx-tag | 274 | | |<-+ | 275 | +------------------+ | 276 | | | | 277 | | BYE | 2xx | 278 | | +------------>+<-+ 279 | | | 280 +-----C------------C-----+ +-----------C------+ 281 | | Terminated | | | Confirmed | | 282 | | +<----C---------| | | 283 | | | | BYE(sr) | | | 284 | | V | | V | 285 | | +------------+ | | +-----------+ | 286 | | | |---C-+ | | |--C-+ 287 | | | Mortal | | | BYE | | Moratorium| | | 2xx 288 | | | |<--C-+ | | |<-C-+ 289 | | +------------+ | | +-----------+ | 290 | | | | | | | 291 | | | Timeout | | | ACK | 292 | | | (Timer J) | | | | 293 | V V | | V | 294 | +---------------+ | | +-----------+ | 295 | | | | | | | | 296 | | Morgue | | | |Established| | 297 | | | | | | | | 298 | +---------------+ | | +-----------+ | 299 | | | | 300 +------------------------+ +------------------+ 302 (sr): indicates that both sending and reception are allowed. 303 Where (sr) is not indicated, response means send, 304 request means receive. 306 Figure 2. DSM for INVITE dialog usage (UAS) 308 Figure 2 represents UAS's DSM for the INVITE dialog usage. 309 The figure does not illustrate the state transition related to 310 CANCEL request. CANCEL request does not cause a dialog state 311 transition. However, the UAS terminates the dialog and triggers the 312 dialog transition by sending 487 immediately after the reception of 313 the CANCEL. Considering this, the behavior upon the reception of the 314 CANCEL request is further explained in the Appendix C. 316 Following are UA's behaviors in each state. 318 Preparative (Pre): The Preparative state is a state until the 319 Early dialog is established by sending and receiving a 320 provisional response with To-tag after an ini-INVITE is sent 321 and received. The dialog has not existed yet in the 322 Preparative state. The dialog state transits from the 323 Preparative to the Early by sending or receiving a provisional 324 response with To-tag. Moreover, if UA sends or receives a 2xx 325 response, the dialog state transit to the Moratorium state 326 which is a substate of the Confirmed state. 327 In addition, if UA sends or receives a 3xx-6xx response the 328 dialog state transit to the Morgue state which is a substate of 329 the Terminated state. Sending an ACK for a 3xx-6xx response 330 and retransmissions of 3xx-6xx are not expressed on this DSM 331 because they are sent by the INVITE transaction. 333 Trying (Try): The Trying state is a substate of the Preparative 334 state and inherits the behavior of the superstate. The Trying 335 state is started by sending and receiving of an ini-INVITE. 336 It transits to the Proceeding state by sending or receiving a 337 1xx (usually 100 trying) without To-tag. UAC may retransmit an 338 INVITE on transaction layer and must not send a CANCEL request. 339 UAS may send a 1xx-6xx response. 341 Proceeding (Pro): The Proceeding state is a substate of the 342 Preparative state and inherits the behavior of the superstate. 343 Dialog becomes the Proceeding state if a dialog in the Trying 344 state sends or receives a 1xx without To-tag (usually 100 345 trying). UAC may send CANCEL, and UAS may send a 1xx-6xx 346 response in the Proceeding state. 348 Early (Ear): The early dialog is established by sending or 349 receiving a provisional response with To-tag. The early dialog 350 exists though the dialog does not existed in this state yet. 351 The dialog state transits from the Early to Moratorium state, a 352 substate of the Confirmed state, by sending or receiving a 2xx 353 response. In addition, the dialog state transits to the Morgue 354 state, a substate of the Terminated state, by sending and 355 receiving a 3xx-6xx response. Sending an ACK for a 3xx-6xx 356 response and retransmissions of 3xx-6xx are not expressed on 357 this DSM because they are automatically processed on 358 transaction layer and don't influence the dialog state. UAC 359 may send CANCEL in the Early state. UAC may send BYE 360 (although it is not recommended). UAS may send a 1xx-6xx 361 response. Sending or receiving of a CANCEL request does not 362 have direct influences on dialog state. The UA's behavior upon 363 the reception of the CANCEL request is further explained in the 364 Appendix C. 366 Confirmed (Con): Sending or receiving of a 2xx final response 367 establishes a dialog. Dialog exists in this state. The BYE 368 request the changes state from the Confirmed to Mortal state, 369 a substate of the Terminated state. The Confirmed has two 370 substates, the Moratorium and Established state, which are 371 different in messages UAs are allowed to send. 373 Moratorium (Mora): The Moratorium state is a substate of the 374 Confirmed state and inherits the behavior of the superstate. 375 The Moratorium state transits to the Established state by 376 sending or receiving an ACK request. UAC may send ACK and UAS 377 may send a 2xx final response. 379 Established (Est): The Established state is a substate of the 380 Confirmed state and inherits the behavior of superstate. Both 381 caller and callee may send various messages which influences a 382 dialog. Caller supports the transmission of ACK for a 383 retransmission of a 2xx response to an ini-INVITE. 385 Terminated (Ter): The Terminated state is divided into two 386 substates, the Mortal and Morgue states, to cover the behavior 387 when a dialog is being terminated. In this state, UAs hold 388 information about��the dialog which is being terminated. The 389 Confirmed state transits to the Mortal state, a substate of the 390 Terminated state, by sending or receiving a BYE request. 392 Mortal (Mort): Caller and callee becomes Mortal state by sending 393 or receiving a BYE. UA MUST NOT send any new requests since 394 there is no dialog. (Here the new requests do not include ACK 395 for 2xx and BYE for 401 or 407 as further explained in the 396 Appendix D below.) 397 In this state, only BYE or its response can be handled, and no 398 other messages can be received. This is because the use case 399 is taken into consideration that BYE is sent by both a caller 400 and a callee to exchange reports about the session when it is 401 being terminated. Therefore, UA possesses dialog information 402 for internal process but dialog shouldn't exist outwardly. The 403 UA stops managing its dialog state and changes it to the Morgue 404 state, when the BYE transaction is finished by timer 405 (Timer F or Timer K for UAC. Timer J for UAS). 407 Morgue (Morg): Dialog does not exist any more in this state. 408 Sending or receiving of a signal which influences a dialog is 409 not performed. (A dialog is literally terminated.) 411 3. Race condition 413 This section details race condition between two SIP UAs, Alice and 414 Bob. Alice (sip:alice@atlanta.example.com) and Bob 415 (sip:bob@biloxi.example.com) are assumed to be SIP phones or 416 SIP-enabled devices. 417 Only significant signals are illustrated. Dialog state transitions 418 caused by sending and receiving of SIP messages as well as '*race*', 419 which indicates race condition are shown. (For abbreviations for 420 the dialog state transitions, refer to Chapter 2.) 421 '*race*' indicates the moment when a race condition occurs. 423 Examples of race conditions are shown below. 425 3.1 Receiving message in the Moratorium State 427 This section shows some examples of call flow in race condition 428 when receiving the message from other states in the Moratorium state. 430 3.1.1 Receiving Initial INVITE retransmission (Trying state) 431 in Moratorium state 433 State Alice Bob State 434 | | 435 | ini-INVITE F1 | 436 Pre |------------------------------------>| Pre 437 | 180 F2(Packet loss) | 438 | x<-----------------------| Ear 439 | | 440 | ini-INVITE(=F1) F4 200 F3 | 441 |------------------ --------------| Mora 442 | \ / | 443 | X | 444 | / \ | 445 Mora |<----------------- ------------->| *race* 446 | ACK F5 | 447 Est |------------------------------------>| Est 448 | | 449 | | 451 This scenario illustrates the race condition which occurs when UAS 452 receives a Preparative message in the Moratorium state. All 453 provisional responses to the initial INVITE (ini-INVITE F1) are lost, 454 and UAC retransmits an ini-INVITE (F4). At the same time as 455 retransmission, UAS generates a 200 OK (F3) to the ini-INVITE and it 456 terminate an INVITE server transaction, according to Section 13.3.1.4 457 of RFC3261 [1]. 458 However, it is reported that terminating an INVITE server transaction 459 by 200 OK is a SIP bug. (http://bugs.sipit.net/, #769) 460 Therefore, the INVITE server transaction is not terminated at F3, and 461 the F4 MUST be properly handled as a retransmission. 462 (UAs that do not deal with this bug still need to recognize the 463 dialog relying on its From-tag and Call-ID, and the retransmitted 464 request relying on the CSeq header field value even though it does 465 not match the transaction.) 466 In RFC3261 [1], it is not specified whether UAS retransmits 200 to 467 the retransmission of ini-INVITE. Considering the retransmission of 468 200 triggered by timer (TU keeps retransmitting 200 based on T1 469 and T2 until it receives an ACK), according to Section 13.3.1.4 of 470 RFC3261 [1], it seems unnecessary to retransmit 200 when the UAS 471 receives the retransmission of ini-INVITE. (For implementation, it 472 does not matter if the UAS sends the retransmission of 200, since the 473 200 does not cause any problem.) 475 Message Details 477 F1 INVITE Alice -> Bob 479 F2 180 Ringing Bob -> Alice 480 /* 180 response is lost and does not reach Alice. */ 482 F3 200 OK Bob -> Alice 483 /* According to 13.3.1.4 of RFC3261, an INVITE server transaction 484 is terminated at this point. However, this has been reported as a 485 SIP bug, and the UAS MUST correctly recognize the ini-INVITE (F4) as 486 a retransmission. */ 487 F4 INVITE (retransmission) Alice -> Bob 488 /* F4 is a retransmission of F1. They are exactly the same INVITE 489 request. For UAs do not deal with the bug reported in #769 (an 490 INVITE server transaction is terminated by 200 to INVITE), this 491 request does not match the transaction as well as the dialog 492 since it does not have a To-tag. 493 However, Bob have to recognize the retransmitted INVITE correctly, 494 without treating it as a new INVITE. */ 496 F5 ACK Alice -> Bob 498 3.1.2 Receiving CANCEL (Proceeding or Early state) 499 in Moratorium state 501 State Alice Bob State 502 | | 503 | INVITE F1 | 504 Pre |----------------------------->| Pre 505 | 180 Ringing F2 | 506 Ear |<-----------------------------| Ear 507 | | 508 |CANCEL F3 200(INVITE) F4| 509 |------------ -------------| Mora 510 | \ / | 511 | X | 512 | / \ | 513 Mora |<----------- ------------>| *race* 514 | | 515 | ACK F6 200(CANCEL) F5| 516 Est |------------ -------------| 517 | \ / | 518 | X | 519 | / \ | 520 |<----------- ------------>| Est 521 | | 522 | One Way RTP Media | 523 | (Two Way RTP Media possible) | 524 |<=============================| 525 | BYE F7 | 526 Mort |----------------------------->| Mort 527 | 200 F8 | 528 |<-----------------------------| 529 | ^ ^ | 530 | | Timer K | | 531 | V | | 532 Morg | Timer J | | 533 | V | 534 | | Morg 535 | | 537 This scenario illustrates the race condition which occurs when UAS 538 receives an Early message, CANCEL, in the Moratorium state. Alice 539 sends a CANCEL and Bob sends a 200 OK response to the initial INVITE 540 message at the same time. As described in the previous section, 541 according to RFC3261, an INVITE server transaction is supposed to be 542 terminated by a 200 response, but this has been reported as a bug 543 #769. 544 This section describes a case in which an INVITE server transaction 545 is not terminated by a response to the CANCEL request. In this case, 546 there is an INVITE transaction which the CANCEL request matches, so a 547 200 response is sent to the request. This 200 response simply means 548 that the next hop received the CANCEL request (Successful CANCEL 549 (200) does not mean an INVITE failure). When UAS does not deal with 550 #769, UAC MAY receive a 481 response for CANCEL since there is no 551 transaction which the CANCEL request matches. This 481 simply means 552 that there is no matching INVITE server transaction and CANCEL is not 553 sent to the next hop. 554 Regardless of the success/failure of the CANCEL, Alice checks the 555 final response to INVITE, and if she receives 200 to the INVITE 556 request she immediately sends a BYE and terminates a dialog. 557 (Section 15, RFC3261 [1]) 558 From the time F1 is received by Bob until the time that F8 is sent by 559 Bob, media may be flowing one way from Bob to Alice. From the time 560 than an answer is received by Alice from Bob there is the possibility 561 that media may flow from Alice to Bob as well. However, once Alice 562 has decided to cancel the call, she presumably will not send media, 563 so practically speaking the media stream will remain one way. 565 Message Details 567 F1 INVITE Alice -> Bob 569 F2 180 Ringing Bob -> Alice 571 F3 CANCEL Alice -> Bob 572 /* Alice sends a CANCEL in the Early state. */ 574 F4 200 OK (INVITE) Bob -> Alice 575 /* Alice receives a 200 to INVITE (F1) in the Moratorium state. 576 Alice has the potential to send as well as receive media, 577 but in practice will not send because there is an intent 578 to end the call. */ 580 F5 200 OK (CANCEL) Bob -> Alice 581 /* 200 to CANCEL simply means that the CANCEL was received. 582 The 200 response is sent, since this document deals with the 583 bug reported in #769. When an INVITE server transaction is 584 terminated as the procedure stated in RFC3261, UAC MAY receive 585 481 response instead of 200. */ 587 F6 ACK Alice -> Bob 588 /* INVITE is successful, and the CANCEL becomes invalid. Bob 589 establishes RTP streams. 590 However, the next BYE request immediately terminates 591 the dialog and session. */ 593 F7 BYE Alice -> Bob 595 F8 200 OK Bob -> Alice 597 3.1.3 Receiving BYE (Early state) 598 in Moratorium state 600 State Alice Bob State 601 | | 602 | ini-INVITE F1 | 603 Pre |------------------------------->| Pre 604 | 180 F2 | 605 Ear |<-------------------------------| Ear 606 | | 607 | BYE F4 200(INVITE) F3| 608 Mort |------------- --------------| Mora 609 | \ / | 610 | X | 611 | / \ | 612 |<------------ ------------->| Mort & *race* 613 | | 614 | ACK F5 200(BYE) F6 | 615 |------------- --------------| 616 | \ / ^ | 617 | X | | 618 | / \ | | 619 |<------------ ------------->| 620 | ^ | | 621 | | Timer K | | 622 | V | | 623 Morg | Timer J | | 624 | V | 625 | | Morg 626 | | 628 This scenario illustrates the race condition which occurs when UAS 629 receives an Early message, BYE, in the Moratorium state. Alice sends 630 a BYE in the Early state and Bob sends a 200 OK response to the 631 initial INVITE request at the same time. Bob receives the BYE in the 632 Confirmed dialog state though Alice sent the request in the Early 633 state (As explained in Section 2, this behavior is NOT RECOMMENDED). 634 The BYE functions normally even if it is received after the INVITE 635 transaction termination because BYE differs from CANCEL, and is sent 636 not to the request but to the dialog. Alice gets into the Mortal 637 state on receiving the BYE response, and remains Mortal until the 638 Timer K timeout occurs. In the Mortal state, UAC does not establish 639 a session, even though it receives a 200 response to INVITE. Even 640 so, the UAC sends an ACK to 200 for the completion of INVITE 641 transaction. The ACK is always sent to complete the three-way 642 handshake of INVITE transaction (Further explained in the Appendix D 643 below). 645 Message Details 647 F1 INVITE Alice -> Bob 649 F2 180 Ringing Bob -> Alice 651 F3 200 OK (ini-INVITE) Bob -> Alice 653 F4 BYE Alice -> Bob 655 /* Alice transits to the Mortal state upon sending BYE. 656 Therefore, after this, she does not begin a session even 657 though she receives a 200 response with an answer. */ 659 F5 ACK Alice -> Bob 661 F6 200 OK (BYE) Bob -> Alice 663 3.1.4 Receiving re-INVITE (Established state) 664 in Moratorium state (case 1) 666 State Alice Bob State 667 | | 668 | ini-INVITE F1 | 669 Pre |------------------------------->| Pre 670 | 180 F2 | 671 Ear |<-------------------------------| Ear 672 | | 673 | 200(ini-INV) F3 | 674 Mora |<-------------------------------| Mora 675 | ACK F4(packet loss) | 676 Est |-------------------->x | 677 | | 678 | re-INVITE F6 200(=F3) F5 | 679 |------------- --------------| 680 | \ / | 681 | X | 682 | / \ | 683 |<------------ ------------->| *race* 684 | ACK(=F4) F7 200(re-INV) F8| 685 |------------- --------------| 686 | \ / | 687 | X | 688 | / \ | 689 |<------------ ------------->| Est 690 | ACK F9 | 691 |------------------------------->| 692 | | 693 | | 695 This scenario illustrates the race condition which occurs when UAS 696 receives re-INVITE request sent from the Established state, in the 697 Moratorium state. 698 UAS receives a re-INVITE before receiving an ACK for ini-INVITE. UAS 699 sends a 200 OK to the re-INVITE (F8) because it has sent a 200 OK to 700 the ini-INVITE (F3, F5) and the dialog has already been established. 701 (Because F5 is a retransmission of F3, SDP negotiation is not 702 performed here.) If a 200 OK to the ini-INVITE has an offer and the 703 answer is in the ACK, UA should return by a 491 to the 704 re-INVITE (refer to 3.1.5). As it can be seen in Section 3.3.2 705 below, the 491 response seems to be closely related to session 706 establishment, even in cases other than INVITE cross-over. This 707 example recommends 200 be sent instead of 491 because it does not 708 have influence on session. However, a 491 response can also lead to 709 the same outcome, so the either response can be used. 710 Moreover, if UAS doesn't receive an ACK for a long time, 711 it should send a BYE and terminate the dialog. 713 Message Details 715 F1 INVITE Alice -> Bob 717 INVITE sip:bob@biloxi.example.com SIP/2.0 718 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 719 Max-Forwards: 70 720 From: Alice ;tag=9fxced76sl 721 To: Bob 722 Call-ID: 3848276298220188511@atlanta.example.com 723 CSeq: 1 INVITE 724 Contact: 725 Content-Type: application/sdp 726 Content-Length: 137 728 v=0 729 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 730 s=- 731 c=IN IP4 192.0.2.101 732 t=0 0 733 m=audio 49172 RTP/AVP 0 734 a=rtpmap:0 PCMU/8000 736 /* ini-INVITE contains an offer. */ 738 F2 180 Ringing Bob -> Alice 740 SIP/2.0 180 Ringing 741 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 742 ;received=192.0.2.101 743 From: Alice ;tag=9fxced76sl 744 To: Bob ;tag=8321234356 746 Call-ID: 3848276298220188511@atlanta.example.com 747 CSeq: 1 INVITE 748 Contact: 749 Content-Length: 0 751 F3 200 OK Bob -> Alice 753 SIP/2.0 200 OK 754 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 755 ;received=192.0.2.101 756 From: Alice ;tag=9fxced76sl 757 To: Bob ;tag=8321234356 758 Call-ID: 3848276298220188511@atlanta.example.com 759 CSeq: 1 INVITE 760 Contact: 761 Content-Type: application/sdp 762 Content-Length: 133 764 v=0 765 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 766 s=- 767 c=IN IP4 192.0.2.201 768 t=0 0 769 m=audio 3456 RTP/AVP 0 770 a=rtpmap:0 PCMU/8000 772 F4 ACK Alice -> Bob 773 ACK sip:bob@client.biloxi.example.com SIP/2.0 774 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 775 Max-Forwards: 70 776 From: Alice ;tag=9fxced76sl 777 To: Bob ;tag=8321234356 778 Call-ID: 3848276298220188511@atlanta.example.com 779 CSeq: 1 ACK 780 Content-Length: 0 782 /* ACK request is lost. */ 784 F5 200 OK (=F3) Bob -> Alice (retransmission) 785 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 786 received an ACK. */ 788 F6 re-INVITE Alice -> Bob 790 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 791 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 792 Max-Forwards: 70 793 From: Alice ;tag=9fxced76sl 794 To: Bob ;tag=8321234356 795 Call-ID: 3848276298220188511@atlanta.example.com 796 CSeq: 2 INVITE 797 Content-Length: 147 799 v=0 800 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 801 s=- 802 c=IN IP4 192.0.2.101 803 t=0 0 804 m=audio 49172 RTP/AVP 0 805 a=rtpmap:0 PCMU/8000 806 a=sendonly 808 F7 ACK (=F4) Alice -> Bob (retransmission) 810 F8 200 OK (re-INVITE) Bob -> Alice 812 SIP/2.0 200 OK 813 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 814 Max-Forwards: 70 815 From: Alice ;tag=9fxced76sl 816 To: Bob ;tag=8321234356 817 Call-ID: 3848276298220188511@atlanta.example.com 818 CSeq: 2 INVITE 819 Content-Length: 143 821 v=0 822 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com 823 s=- 824 c=IN IP4 192.0.2.201 825 t=0 0 826 m=audio 3456 RTP/AVP 0 827 a=rtpmap:0 PCMU/8000 828 a=recvonly 830 F9 ACK Alice -> Bob 832 ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 833 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f2.1 834 Max-Forwards: 70 835 From: Alice ;tag=9fxced76sl 836 To: Bob ;tag=8321234356 837 Call-ID: 3848276298220188511@atlanta.example.com 838 CSeq: 2 ACK 839 Content-Length: 0 841 3.1.5 Receiving re-INVITE (Established state) 842 in Moratorium state (case 2) 844 State Alice Bob State 845 | | 846 | ini-INVITE F1 | 847 Pre |------------------------------->| Pre 848 | 180 F2 | 849 Ear |<-------------------------------| Ear 850 | | 851 | 200(ini-INV) F3 | 852 Mora |<-------------------------------| Mora 853 | ACK F4(packet loss) | 854 Est |-------------------->x | 855 | | 856 | re-INVITE F6 200(=F3) F5 | 857 |------------- --------------| 858 | \ / | 859 | X | 860 | / \ | 861 |<------------ ------------->| 862 | ACK(=F4) F7 491(re-INV) F8| 863 |------------- --------------| 864 | \ / | 865 | X | 866 | / \ | 867 |<------------ ------------->| Est 868 | ACK F9 | 869 |------------------------------->| 870 | | 871 | | 873 This scenario is basically the same as that of Section 3.1.4, but 874 differs in sending an offer in 200 and an answer in ACK. Different 875 to the previous case, the offer in the 200 (F3) and the offer in the 876 re-INVITE (F6) collide with each other. 877 Bob sends 491 to re-INVITE since he is not able to properly handle a 878 new request until he receives an answer. 880 Message Details 882 F1 INVITE Alice -> Bob 884 INVITE sip:bob@biloxi.example.com SIP/2.0 885 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 886 Max-Forwards: 70 887 From: Alice ;tag=9fxced76sl 888 To: Bob 889 Call-ID: 3848276298220188511@atlanta.example.com 890 CSeq: 1 INVITE 891 Contact: 892 Content-Length: 0 894 /* The request does not contain an offer. */ 896 F2 180 Ringing Bob -> Alice 898 F3 200 OK Bob -> Alice 900 SIP/2.0 200 OK 901 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 902 ;received=192.0.2.101 903 From: Alice ;tag=9fxced76sl 904 To: Bob ;tag=8321234356 905 Call-ID: 3848276298220188511@atlanta.example.com 906 CSeq: 1 INVITE 907 Contact: 908 Content-Type: application/sdp 909 Content-Length: 133 911 v=0 912 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 913 s=- 914 c=IN IP4 192.0.2.201 915 t=0 0 916 m=audio 3456 RTP/AVP 0 917 a=rtpmap:0 PCMU/8000 919 /* An offer is made in 200 */ 921 F4 ACK Alice -> Bob 923 ACK sip:bob@client.biloxi.example.com SIP/2.0 924 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 925 Max-Forwards: 70 926 From: Alice ;tag=9fxced76sl 927 To: Bob ;tag=8321234356 928 Call-ID: 3848276298220188511@atlanta.example.com 929 CSeq: 1 ACK 930 Content-Type: application/sdp 931 Content-Length: 137 933 v=0 934 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 935 s=- 936 c=IN IP4 192.0.2.101 937 t=0 0 938 m=audio 49172 RTP/AVP 0 939 a=rtpmap:0 PCMU/8000 941 /* The request contains an answer, but the request is lost. */ 943 F5 200 OK (=F3) Bob -> Alice (retransmission) 944 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 945 received an ACK. */ 947 F6 re-INVITE Alice -> Bob 949 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 951 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 952 Max-Forwards: 70 953 From: Alice ;tag=9fxced76sl 954 To: Bob ;tag=8321234356 955 Call-ID: 3848276298220188511@atlanta.example.com 956 CSeq: 2 INVITE 957 Content-Length: 147 959 v=0 960 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 961 s=- 962 c=IN IP4 192.0.2.101 963 t=0 0 964 m=audio 49172 RTP/AVP 0 965 a=rtpmap:0 PCMU/8000 966 a=sendonly 968 /* The request contains an offer. */ 970 F7 ACK (=F4) Alice -> Bob (retransmission) 971 /* A retransmission triggered by the reception of a retransmitted 972 200. */ 974 F8 491 (re-INVITE) Bob -> Alice 975 /* Bob sends 491 (Request Pending), since Bob has a pending 976 offer. */ 978 F9 ACK Alice -> Bob 980 3.1.6 Receiving BYE (Established state) 981 in Moratorium state 983 State Alice Bob State 984 | | 985 | INVITE F1 | 986 Pre |-------------------------->| Pre 987 | 180 Ringing F2 | 988 Ear |<--------------------------| Ear 989 | | 990 | 200 OK F3 | 991 Mora |<--------------------------| Mora 992 | ACK F4(packet loss) | 993 Est |--------------->x | 994 | Both Way RTP Media | 995 |<=========================>| 996 | BYE F6 200(=F3) F5| 997 Mort |----------- -----------| 998 | \ / | 999 | X | 1000 | / \ | 1001 |<---------- ---------->| Mort & *race* 1002 |ACK(=F4) F7 200(BYE) F8| 1003 |----------- -----------| 1004 | \ / | 1005 | X | 1006 | / \ | 1007 |<---------- ---------->| 1008 | ^ ^ | 1009 | | Timer K | | 1010 | V | | 1011 Morg | Timer J | | 1012 | V | 1013 | | Morg 1014 | | 1016 This scenario illustrates the race condition which occurs when UAS 1017 receives an Established message, BYE, in the Moratorium state. 1018 An ACK request for a 200 OK response is lost (or delayed). 1019 Immediately after Bob retransmits the 200 OK to ini-INVITE, and Alice 1020 sends a BYE request at the same time. 1021 Depending on the implementation of a SIP UA, Alice may want to start 1022 a session again by the reception of the retransmitted 200 OK with SDP 1023 since she has already terminated a session by sending a BYE. In that 1024 case, when UAC receives a retransmitted 200 OK after sending a BYE, 1025 a session should not be started again since the session which is not 1026 associated with dialog still remains. Moreover, in the case where 1027 UAS sends an offer in a 200 OK , UAS should not start a session again 1028 for the same reason if UAS receives a retransmitted ACK after 1029 receiving a BYE. 1031 Message Details 1033 F1 INVITE Alice -> Bob 1035 F2 180 Ringing Bob -> Alice 1037 F3 200 OK Bob -> Alice 1039 F4 ACK Alice -> Bob 1041 ACK sip:bob@client.biloxi.example.com SIP/2.0 1042 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1043 Max-Forwards: 70 1044 From: Alice ;tag=9fxced76sl 1045 To: Bob ;tag=8321234356 1046 Call-ID: 3848276298220188511@atlanta.example.com 1047 CSeq: 1 ACK 1048 Content-Length: 0 1050 /* ACK request is lost. */ 1052 F5 200 OK (retransmission) Bob -> Alice 1054 SIP/2.0 200 OK 1055 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1056 ;received=192.0.2.101 1057 From: Alice ;tag=9fxced76sl 1058 To: Bob ;tag=8321234356 1059 Call-ID: 3848276298220188511@atlanta.example.com 1060 CSeq: 1 INVITE 1061 Contact: 1062 Content-Type: application/sdp 1063 Content-Length: 133 1065 v=0 1066 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1067 s=- 1068 c=IN IP4 192.0.2.201 1069 t=0 0 1070 m=audio 3456 RTP/AVP 0 1071 a=rtpmap:0 PCMU/8000 1073 /* UAS retransmits a 200 OK to the ini-INVITE since it has not 1074 received an ACK. */ 1076 F6 BYE Alice -> Bob 1078 BYE sip:bob@client.biloxi.example.com SIP/2.0 1079 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 1080 Max-Forwards: 70 1081 From: Alice ;tag=9fxced76sl 1082 To: Bob ;tag=8321234356 1083 Call-ID: 3848276298220188511@atlanta.example.com 1084 CSeq: 2 BYE 1085 Content-Length: 0 1087 /* Bob retransmits a 200 OK and Alice sends a BYE at the same time. 1088 Alice transits to the Mortal state, so she does not begin a 1089 session after this even though she receives a 200 response to 1090 the re-INVITE. */ 1092 F7 ACK(=F4) Alice -> Bob 1094 F8 200 OK (BYE) Bob -> Alice 1096 SIP/2.0 200 OK 1097 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 1098 ;received=192.0.2.101 1099 From: Alice ;tag=9fxced76sl 1100 To: Bob ;tag=8321234356 1101 Call-ID: 3848276298220188511@atlanta.example.com 1102 CSeq: 2 BYE 1103 Content-Length: 0 1104 /* Bob sends a 200 OK to the BYE. */ 1106 3.2 Receiving message in the Mortal State 1108 This section shows some examples of call flow in race condition 1109 when receiving the message from other states in the Mortal state. 1111 3.2.1 Receiving BYE (Establish state) 1112 in Mortal state 1114 State Alice Bob 1115 | | 1116 | INVITE F1 | 1117 Pre |----------------------->| Pre 1118 | 180 Ringing F2 | 1119 Ear |<-----------------------| Ear 1120 | | 1121 | 200 OK F3 | 1122 Mora |<-----------------------| Mora 1123 | ACK F4 | 1124 Est |----------------------->| Est 1125 | Both Way RTP Media | 1126 |<======================>| 1127 | | 1128 | BYE F5 BYE F6 | 1129 Mort |--------- ----------| Mort 1130 | \ / | 1131 | X | 1132 | / \ | 1133 |<-------- --------->| *race* 1134 | | 1135 | 200 F8 200 F7 | 1136 |--------- ----------| 1137 | \ / | 1138 | X | 1139 | / \ | 1140 |<-------- --------->| 1141 | ^ ^ | 1142 | | Timer K | | 1143 | V | | 1144 Morg | Timer J | | 1145 | V | 1146 | | Morg 1147 | | 1149 This scenario illustrates the race condition which occurs when UAS 1150 receives an Established message, BYE, in the Mortal state. 1151 Alice and Bob send a BYE at the same time. A dialog and session is 1152 ended shortly after a BYE request is passed to a client transaction. 1153 As shown in Section 2, UA remains in the Mortal state. 1154 UAs in the Mortal state return error responses to the requests that 1155 operate dialog or session, such as re-INVITE, UPDATE, or REFER. 1156 However, UA shall return 200 OK to the BYE taking the use case into 1157 consideration where BYE request is sent by both a caller and a callee 1158 to exchange reports about the session when it is being terminated. 1159 (Since the dialogue and the session both terminate when a BYE is 1160 sent, the choice of sending 200 or an error response upon receiving 1161 BYE in the Mortal state does not affect the resulting termination. 1162 Therefore, even though this example uses a 200 response, other 1163 responses can also be used.) 1165 Message Details 1167 F1 INVITE Alice -> Bob 1169 F2 180 Ringing Bob -> Alice 1171 F3 200 OK Bob -> Alice 1173 F4 ACK Alice -> Bob 1175 F5 BYE Alice -> Bob 1177 BYE sip:bob@client.biloxi.example.com SIP/2.0 1178 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1179 Max-Forwards: 70 1180 From: Alice ;tag=9fxced76sl 1181 To: Bob ;tag=8321234356 1182 Call-ID: 3848276298220188511@atlanta.example.com 1183 CSeq: 2 BYE 1184 Content-Length: 0 1186 /* The session is terminated at the moment Alice sends a BYE. 1187 The dialog still exists then, but it is certain to be terminated 1188 in a short period of time. The dialog is completely 1189 terminated when the timeout of the BYE request occurs. */ 1191 F6 BYE Bob -> Alice 1193 BYE sip:alice@client.atlanta.example.com SIP/2.0 1194 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1195 Max-Forwards: 70 1196 From: Bob ;tag=8321234356 1197 To: Alice ;tag=9fxced76sl 1198 Call-ID: 3848276298220188511@atlanta.example.com 1199 CSeq: 1 BYE 1200 Content-Length: 0 1202 /* Bob has also transmitted a BYE simultaneously with Alice. 1203 Bob terminates the session and the dialog. */ 1205 F7 200 OK Bob -> Alice 1207 SIP/2.0 200 OK 1208 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1209 ;received=192.0.2.201 1210 From: Alice ;tag=9fxced76sl 1211 To: Bob ;tag=8321234356 1212 Call-ID: 3848276298220188511@atlanta.example.com 1213 CSeq: 2 BYE 1214 Content-Length: 0 1216 /* Since the dialog is in the Moratorium state, Bob responds with 1217 a 200 to the BYE request. */ 1219 F8 200 OK Alice -> Bob 1221 SIP/2.0 200 OK 1222 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1223 ;received=192.0.2.201 1224 From: Bob ;tag=8321234356 1225 To: Alice ;tag=9fxced76sl 1226 Call-ID: 3848276298220188511@atlanta.example.com 1227 CSeq: 1 BYE 1228 Content-Length: 0 1230 /* Since Alice has transited from the Established state to the Mortal 1231 state by sending BYE, Alice responds with a 200 to the BYE 1232 request. */ 1234 3.2.2 Receiving re-INVITE (Establish state) 1235 in Mortal state 1237 State Alice Bob 1238 | | 1239 | INVITE F1 | 1240 Pre |----------------------->| Pre 1241 | 180 Ringing F2 | 1242 Ear |<-----------------------| Ear 1243 | | 1244 | 200 OK F3 | 1246 Mora |<-----------------------| Mora 1247 | ACK F4 | 1248 Est |----------------------->| Est 1249 | Both Way RTP Media | 1250 |<======================>| 1251 | | 1252 | BYE F5 re-INVITE F6| 1253 Mort |--------- ----------| 1254 | \ / | 1255 | X | 1256 | / \ | 1257 *race* |<-------- --------->| Mort 1258 | | 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 1293 F5 BYE Alice -> Bob 1295 BYE sip:bob@client.biloxi.example.com SIP/2.0 1296 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1297 Max-Forwards: 70 1298 From: Alice ;tag=9fxced76sl 1299 To: Bob ;tag=8321234356 1300 Call-ID: 3848276298220188511@atlanta.example.com 1301 CSeq: 2 BYE 1302 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 1340 SIP/2.0 481 Call/Transaction Does Not Exist 1341 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1342 ;received=192.0.2.201 1343 From: Bob ;tag=8321234356 1344 To: Alice ;tag=9fxced76sl 1345 Call-ID: 3848276298220188511@atlanta.example.com 1346 CSeq: 1 INVITE 1347 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 Pre |----------------------->| Pre 1364 | 180 Ringing F2 | 1365 Ear |<-----------------------| Ear 1366 | | 1367 | 200 OK F3 | 1368 Mora |<-----------------------| Mora 1369 | ACK F4 | 1370 Est |----------------------->| Est 1371 | Both Way RTP Media | 1372 |<======================>| 1373 | | 1374 | re-INVITE F5 | 1375 |<-----------------------| 1376 | 200 F7 BYE F6 | 1377 |--------- ----------| Mort 1378 | \ / | 1379 | X | 1380 | / \ | 1381 Mort |<-------- --------->| *race* 1382 | 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 | 1481 Pre |------------------------------->| Pre 1482 | 180 F2 | 1483 Ear |<-------------------------------| Ear 1484 | 200 F3 | 1485 Mora |<-------------------------------| Mora 1486 | | 1487 | ACK F4 BYE F5 | 1488 Est |------------- --------------| Mort 1489 | \ / | 1490 | X | 1491 | / \ | 1492 Mort |<------------ ------------->| *race* 1493 | 200 F6 | 1494 |------------------------------->| 1495 | ^ ^ | 1496 | | Timer K | | 1497 | | V | 1498 | | Timer J | Morg 1499 | V | 1500 Morg | | 1501 | | 1503 This scenario illustrates the race condition which occurs when UAS 1504 receives an Established message, ACK to 200, in the Mortal state. 1505 Alice sends an ACK and Bob sends a BYE at the same time. When the 1506 offer is in a 2xx, and the answer is in an ACK, this example is in 1507 a race condition. The session is not started by receiving the ACK 1508 because Bob has already terminated the session by sending the BYE. 1509 The answer in the ACK request is just ignored. 1511 F1 INVITE Alice -> Bob 1513 F2 180 Ringing Bob -> Alice 1515 F3 200 OK Bob -> Alice 1517 F4 ACK Alice -> Bob 1519 ACK sip:bob@client.biloxi.example.com SIP/2.0 1520 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 1521 Max-Forwards: 70 1522 From: Alice ;tag=9fxced76sl 1523 To: Bob ;tag=8321234356 1524 Call-ID: 3848276298220188511@atlanta.example.com 1525 CSeq: 1 ACK 1526 Content-Length: 0 1528 /* 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 condition 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 1730 F14 re-INVITE Alice -> Bob 1732 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1733 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 1734 Max-Forwards: 70 1735 From: Alice ;tag=9fxced76sl 1736 To: Bob ;tag=8321234356 1737 Call-ID: 3848276298220188511@atlanta.example.com 1738 CSeq: 3 INVITE 1739 Content-Length: 147 1741 v=0 1742 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1743 s=- 1744 c=IN IP4 192.0.2.101 1745 t=0 0 1746 m=audio 49172 RTP/AVP 0 1747 a=rtpmap:0 PCMU/8000 1748 a=sendonly 1750 /* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE 1751 again after 2.1-4.0 seconds. */ 1753 F15 200 OK Bob -> Alice 1755 F16 ACK Alice -> Bob 1757 3.3.2 UPDATE and re-INVITE crossover 1759 Alice Bob 1760 | | 1761 | INVITE F1 | 1762 |--------------------------->| 1763 | 180 Ringing F2 | 1764 |<---------------------------| 1765 | | 1766 | 200 OK F3 | 1767 |<---------------------------| 1768 | ACK F4 | 1769 |--------------------------->| 1770 | Both Way RTP Media | 1771 |<==========================>| 1772 | | 1773 | UPDATE F5 re-INVITE F6 | 1774 |------------ -------------| 1775 | \ / | 1776 | X | 1777 | / \ | 1778 |<----------- ------------>| 1779 | 491 F8 491 F7 | 1780 |------------ -------------| 1781 | \ / | 1782 | X | 1783 | / \ | 1784 |<----------- ------------>| 1785 | ^ ACK F9 ^ | 1786 |<-|----------------|--------| 1787 | | | | 1788 | |0-2.0 sec | | 1789 | | | | 1790 | v re-INVITE F10 | | 1791 |<------------------|--------| 1792 | 200 OK F11 | | 1793 |-------------------|------->| 1794 | ACK F12 | | 1795 |<------------------|--------| 1796 | | | 1797 | |2.1-4.0 sec 1798 | | | 1799 | UPDATE F13 v | 1800 |--------------------------->| 1801 | 200 OK F14 | 1802 |<---------------------------| 1803 | | 1804 | | 1806 In this scenario, the UPDATE contains a SDP offer, therefore the 1807 UPDATE and re-INVITE are responded with 491 as in the case of 1808 "re-INVITE crossover". When an UPDATE for refresher which doesn't 1809 contain a session description and a re-INVITE crossed each other, 1810 both requests succeed with 200 (491 means that UA have a pending 1811 request). Moreover, the same is equally true for UPDATE crossover. 1812 In the former case where either UPDATE contains a session description 1813 the requests fail with 491, and in the latter cases succeed with 200. 1815 Editor's Note: 1817 A 491 response is considered as a result that UA judged the 1818 effectiveness of request to "What is established by SIP". 1819 Therefore, it is considered that 491 will be used in all the 1820 requests that demand operation to "What is established by SIP". 1822 Message Details 1824 F1 INVITE Alice -> Bob 1826 F2 180 Ringing Bob -> Alice 1828 F3 200 OK Bob -> Alice 1830 F4 ACK Alice -> Bob 1832 F5 UPDATE Alice -> Bob 1834 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1835 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1836 Max-Forwards: 70 1837 From: Alice ;tag=9fxced76sl 1838 To: Bob ;tag=8321234356 1839 Call-ID: 3848276298220188511@atlanta.example.com 1840 CSeq: 2 UPDATE 1841 Content-Length: 147 1843 v=0 1844 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1845 s=- 1846 c=IN IP4 192.0.2.101 1847 t=0 0 1848 m=audio 49172 RTP/AVP 0 1849 a=rtpmap:0 PCMU/8000 1850 a=sendonly 1852 F6 re-INVITE Bob -> Alice 1854 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1855 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1856 Session-Expires: 300;refresher=uac 1857 Supported: timer 1858 Max-Forwards: 70 1859 From: Bob ;tag=8321234356 1860 To: Alice ;tag=9fxced76sl 1861 Call-ID: 3848276298220188511@atlanta.example.com 1862 CSeq: 1 INVITE 1863 Content-Length: 0 1864 /* A case where a re-INVITE for a session refresh and a re-INVITE for 1865 a call hold are sent at the same time. */ 1867 F7 491 Request Pending Bob -> Alice 1868 /* Since a re-INVITE is in process, a 491 response are returned. */ 1870 F8 491 Request Pending Alice -> Bob 1872 F9 ACK (re-INVITE) Alice -> Bob 1874 F10 re-INVITE Bob -> Alice 1876 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1877 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1 1878 Session-Expires: 300;refresher=uac 1879 Supported: timer 1880 Max-Forwards: 70 1881 From: Bob ;tag=8321234356 1882 To: Alice ;tag=9fxced76sl 1883 Call-ID: 3848276298220188511@atlanta.example.com 1884 CSeq: 2 INVITE 1885 Content-Type: application/sdp 1886 Content-Length: 133 1888 v=0 1889 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1890 s=- 1891 c=IN IP4 192.0.2.201 1892 t=0 0 1893 m=audio 3456 RTP/AVP 0 1894 a=rtpmap:0 PCMU/8000 1896 /* Since Bob is not the owner of Call-ID, Bob sends an INVITE again 1897 after 0.0-2.0 seconds. */ 1899 F11 200 OK Alice -> Bob 1901 F12 ACK Bob -> Alice 1903 F13 UPDATE Alice -> Bob 1905 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1906 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 1907 Max-Forwards: 70 1908 From: Alice ;tag=9fxced76sl 1909 To: Bob ;tag=8321234356 1910 Call-ID: 3848276298220188511@atlanta.example.com 1911 CSeq: 3 UPDATE 1912 Content-Length: 147 1914 v=0 1915 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1916 s=- 1917 c=IN IP4 192.0.2.101 1918 t=0 0 1919 m=audio 49172 RTP/AVP 0 1920 a=rtpmap:0 PCMU/8000 1921 a=sendonly 1923 /* Since Alice is the owner of the Call-ID, Alice sends the UPDATE 1924 again after 2.1-4.0 seconds. */ 1926 F14 200 OK Bob -> Alice 1928 3.3.3 Receiving REFER (Establish state) 1929 in Mortal state 1931 State Alice Bob State 1932 | | 1933 | INVITE F1 | 1934 Pre |----------------------->| Pre 1935 | 180 Ringing F2 | 1936 Ear |<-----------------------| Ear 1937 | | 1938 | 200 OK F3 | 1939 Mora |<-----------------------| Mora 1940 | ACK F4 | 1941 Est |----------------------->| Est 1942 | Both Way RTP Media | 1943 |<======================>| 1944 | | 1945 | BYE F5 REFER F6 | 1946 Mort |--------- ----------| 1947 | \ / | 1948 | X | 1949 | / \ | 1950 *race* |<-------- --------->| Mort 1951 | | 1952 | 481 F8 200 F7 | 1953 |--------- ----------| 1954 | \ / ^ | 1955 | X | | 1956 | / \ | | 1957 |<-------- --------->| 1958 | ^ | | 1959 | | Timer K | | 1960 | V | | 1961 Morg | Timer J | | 1962 | V | 1963 | | Morg 1964 | | 1966 This scenario illustrates the race condition which occurs when UAS 1967 receives an Established message, REFER, in the Mortal state. 1968 Bob sends a REFER, and Alice sends a BYE at the same time. Bob 1969 send the REFER in the same dialog. Alice sends an error response 1970 to the requests which operates the session, such as REFER, because 1971 by sending the BYE, Alice had terminated the session which would 1972 have corresponded to the REFER. For handling of dialogs with 1973 multiple usages, as can be seen in the use of REFER method, 1974 see the draft on dialog usage [8]. 1976 Message Details 1978 F1 INVITE Alice -> Bob 1980 F2 180 Ringing Bob -> Alice 1982 F3 200 OK Bob -> Alice 1984 F4 ACK Alice -> Bob 1986 F5 BYE Alice -> Bob 1987 /* Alice sends a BYE request and terminates the session, and transits 1988 from the Confirmed state to Terminated state. */ 1990 F6 REFER Bob -> Alice 1992 REFER sip:alice@client.atlanta.example.com SIP/2.0 1993 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1994 Max-Forwards: 70 1995 From: Bob ;tag=8321234356 1996 To: Alice ;tag=9fxced76sl 1997 Call-ID: 3848276298220188511@atlanta.example.com 1998 Refer-To: sip:carol@cleveland.example.org 1999 Contact: 2000 CSeq: 1 REFER 2001 Content-Length: 0 2003 /* Alice sends a BYE, and Bob sends a REFER at the same time. 2004 Bob sends the REFER on the INVITE dialog. 2005 The dialog state transits to the Mortal state at the moment 2006 Alice sends the BYE, but Bob doesn't know it until he receives 2007 the BYE. A race condition occurs. */ 2009 F7 200 OK Bob -> Alice 2011 F8 481 Call/Transaction Does Not Exist Alice -> Bob 2012 /* Since Alice has terminated the session, she responds with a 481 2013 to the REFER. */ 2015 Appendix A - BYE on the Early Dialog 2017 This section, related to Section 3.1.3, explains why BYE is not 2018 recommended in the Early state, illustrating the case in which BYE 2019 in the Early dialog triggers confusion. 2021 Alice Proxy Bob Carol 2022 | | | | 2023 | INVITE F1 | | | 2024 |--------------->| INVITE F2 | | 2025 | 100 F3 |----------------->| | 2026 |<---------------| 180(To-tag=1) F4 | | 2027 | 180(1) F5 |<-----------------| | 2028 |<---------------| | | 2029 | | INVITE(Fork) F6 | 2030 | |------------------------>| 2031 | | 100 F7 | 2032 | BYE(1) F8 |<------------------------| 2033 |--------------->| BYE(1) F9 | | 2034 | |----------------->| | 2035 | | 200(1) F10 | | 2036 | 200(1) F11 |<-----------------| | 2037 |<---------------| 487(1) F12 | | 2038 | |<-----------------| | 2039 | | ACK(1) F13 | | 2040 | |----------------->| | 2041 | | | | 2042 | | | 2043 | | 200(To-tag=2) F13 | 2044 | 200(2) F14 |<------------------------| 2045 |<---------------| | 2046 | ACK(2) F15 | | 2047 |--------------->| ACK(2) F16 | 2048 | |------------------------>| 2049 | BYE(2) F17 | | 2050 |--------------->| BYE(2) F18 | 2051 | |------------------------>| 2052 | | 200(2) F19 | 2053 | 200(2) F20 |<------------------------| 2054 |<---------------| | 2055 | | | 2056 | | | 2058 Care is advised in sending BYE in the Early state when forking by a 2059 proxy is expected. In this example, the BYE request progresses 2060 normally, and it succeeds in correctly terminating the dialog with 2061 Bob. After Bob terminates the dialog by receiving the BYE, he sends 2062 487 to the ini-INVITE. According to Section 15.1.2 of RFC3261 [1], 2063 it is RECOMMENDED for UAS to generate 487 to any pending requests 2064 after receiving BYE. In the example, Bob sends 487 to ini-INVITE 2065 since he receives BYE while the ini-INVITE is in pending state. 2067 However, Alice receives a final response to INVITE (a 200 from Carol) 2068 even though she has successfully terminated the dialog with Bob. This 2069 means that, regardless of the success/failure of the BYE in the Early 2070 state, Alice MUST be prepared for the establishment of a new dialog 2071 until receiving the final response for the INVITE and terminating the 2072 INVITE transaction. 2074 The choice of BYE or CANCEL in the early state must be made 2075 carefully. CANCEL is appropriate when the goal is to abandon 2076 the call attempt entirely. BYE is appropriate when the goal is 2077 to abandon a particular early dialog while allowing the call 2078 to be completed with other destinations. When using either BYE 2079 or CANCEL the UAC must be prepared for the possibility that 2080 a call may still be established to one (or more) destinations. 2082 Appendix B - BYE request overlapped on re-INVITE 2084 UAC UAS 2085 | | 2086 The session has been already established 2087 ========================== 2088 | F1 re-INVITE | 2089 |--------------------->| 2090 | F2 BYE | 2091 |--------------------->| 2092 | F3 200(BYE) | 2093 |<---------------------| 2094 | F4 INVITE(=F1) | 2095 |--------------------->| 2096 | | 2097 | | 2099 This case could look similar to the one in Section 3.2.3. However, 2100 it is not a race condition. This case describes the behavior where 2101 there is no response for INVITE for some reasons. The appendix 2102 explains the behavior in such case and its rationale behind, since 2103 this case is likely to cause confusion. 2104 First of all, it is important not to confuse the behavior of the 2105 transaction layer and that of the dialog layer. RFC3261 [1] details 2106 the Transaction layer behavior. The dialog layer behavior is 2107 explained in this document. 2108 It has to be noted that these behaviors are independent of each 2109 other, even though the both layers change their states triggered by 2110 sending or receiving of the same SIP messages (A dialog can be 2111 terminated even though a transaction still remain, and vice versa). 2112 In the sequence above, there is no response for F1, and F2 (BYE) is 2113 sent immediately after F1 (F1 is a mid-dialog request. If F1 was 2114 ini-INVITE, BYE could not be sent before UAC received a provisional 2115 response to the request with To-tag). 2117 Below is a figure which illustrates UAC's dialog state and 2118 transaction state. 2120 BYE INV dialog UAC UAS 2121 : | | 2122 : | | 2123 | | F1 re-INVITE | 2124 o | |--------------------->| 2125 | | | F2 BYE | 2126 o | (Mortal) |--------------------->| 2127 | | | | F3 200(BYE) | 2128 | | | |<---------------------| 2129 | | | | F4 INVITE(=F1) | 2130 | | | |--------------------->| 2131 | | | | F5 481(INV) | 2132 | | | |<---------------------| 2133 | | | | F6 ACK(INV) | 2134 | | | |--------------------->| 2135 | | | | | 2136 o | o | | 2137 | | | 2138 o | | 2139 | | 2141 For UAC, the INVITE client transaction begins at the point F1 is 2142 sent. The UAC sends BYE (F2) immediately after F1. This is a 2143 legitimate behavior. (Usually the usage of each SIP method is 2144 independent, for BYE and others. However, it should be noted that 2145 it is prohibited to send a request with a SDP offer while the 2146 previous offer is in progress.) 2147 After that, F2 triggers the BYE client transaction. At the same time, 2148 the dialog state transits to the Mortal state and then only a BYE or 2149 its response can be handled. 2150 It is permitted to send F4 (a retransmission of INVITE) in the Mortal 2151 state, because the retransmission of F1 is handled by the transaction 2152 layer, and the INVITE transaction has not yet transited to the 2153 Terminated state. As it is mentioned above, the dialog and the 2154 transaction behave independently each other. 2155 Therefore the transaction handling has to be continued even though 2156 the dialog moved to the Terminated state. 2158 Next, UAS's state is shown below. 2160 UAC UAS dialog INV BYE 2161 | | : 2162 | | : 2163 | F1 re-INVITE | | 2164 |-------------->x | | 2165 | F2 BYE | | 2166 |--------------------->| (Mortal) o 2167 | F3 200(BYE) | | | 2168 |<---------------------| | |<-Start TimerJ 2169 | F4 INVITE(=F1) | | | 2170 |--------------------->| | o | 2171 | F5 4xx(INV) | o | o 2172 |<---------------------| | 2173 | F6 ACK(INV) | | 2174 |--------------------->| |<-Start TimerI 2175 | | | 2176 | | | 2177 | | o 2178 | | 2180 For UAS, it can be regarded that F1 packet is lost or delayed (Here 2181 the behavior is explained for the case UAS receives F2 BYE before F1 2182 INVITE). Therefore, F2 triggers the BYE transaction for UAS, and 2183 simultaneously the dialog moves to the Mortal state. 2184 Then, upon the reception of F4 the INVITE server transaction begins. 2185 (It is allowed to start the INVITE server transaction in the Mortal 2186 state. The INVITE server transaction begins to handle received SIP 2187 request regardless of the dialog state.) 2188 UAS's TU sends an appropriate error response (probably 481) for F4 2189 INVITE, because the TU knows that the dialog which matches to the 2190 INVITE is in the Terminated state. 2191 (It is mentioned above that F4 (and F1) INVITE is a mid-dialog 2192 request. Mid-dialog requests have a To-tag. It should be noted that 2193 UAS's TU does not begin a new dialog upon the reception of INVITE 2194 with a To-tag.) 2196 Appendix C - UA's behaviour for CANCEL 2197 This section explains the CANCEL and the Expires header behaviors 2198 which indirectly involve in the dialog state transition in the Early 2199 state. CANCEL does not have any influence on UAC's dialog state. 2200 However, the request has indirect influence on the dialog state 2201 transition because it has a significant effect on ini-INVITE. 2202 Similarly, the Expires header does not have direct influence on the 2203 dialog state transition, but it indirectly affect the state 2204 transition because its expiration triggers the sending of CANCEL. 2205 For UAS the CANCEL request and the Expires header timeout have more 2206 direct effects on the dialog than the sending of CANCEL by UAC, 2207 because they can be a trigger to send the 487 response. Figure 3 2208 explains UAS's behavior in the Early state. This flow diagram is 2209 only an explanatory figure, and the actual dialog state transition is 2210 as illustrated in Figure 1 and 2. 2212 In the flow, full lines are related to dialog state transition, and 2213 dotted lines are involved with CANCEL. (r) represents the reception 2214 of signals, and (s) means sending. There is no dialog state for 2215 CANCEL, but here the Cancelled state is virtually handled just for 2216 the ease of understanding of the UA's behavior when it sends and 2217 receives CANCEL. 2219 Below, UAS's flow is explained. 2221 +------------+ 2222 | Proceeding |----+ 2223 +------------+ | 2224 : | 1xx(s) | 2225 : V | 2226 : +-------+ | 2xx(s) 2227 : | Early |-----+------+ 2228 : +-------+ | 2229 : : V 2230 : : +-----------+ 2231 : : | Confirmed |<... 2232 :.....: +-----------+ : 2233 : | : : 2234 : BYE(r)| : : 2235 : CANCEL(r) | :.......: 2236 V | CANCEL(r) 2237 ............. | 2238 : Cancelled : | 2239 :...........: | 2240 | 487(s) | 2241 | | 2242 +--------------------+ 2243 | 2244 V 2246 +------------+ 2247 | Terminated | 2248 +------------+ 2250 Figure 3. CANCEL flow diagram for UAS 2252 There are two behaviors for UAS depending on the state when it 2253 receives CANCEL. 2254 One is when UAS receives CANCEL in the Proceeding and Early states. 2255 In this case the UAS immediately sends 487 for the INVITE, and the 2256 dialog transits to the Terminated state. 2257 The other is the case in which UAS receives CANCEL in the Confirmed 2258 state. In this case the dialog state transition does not occur 2259 because UAS has already sent a final response to the INVITE to which 2260 the CANCEL is targeted. 2261 (Note that, from the point of UAC's behavior, it can be expected 2262 that UAS receives BYE immediately after the reception of CANCEL and 2263 moves to the Terminated state. However, the UAS's state does not 2264 transit until it actually receives BYE.) 2266 Appendix D - Notes on the request in Mortal state 2268 This section describes UA's behavior in the Mortal state which need 2269 careful attention. 2271 In the Mortal state, BYE can be accepted, and the other messages in 2272 the INVITE dialog usage are responded with an error. However, 2273 sending of ACK and the authentication procedure for BYE are 2274 conducted in this state. 2275 (The handling of messages concerning multiple dialog usages is out of 2276 the scope of this document. Refer to [8] for further information.) 2278 ACK for error responses is handled by the transaction layer, so the 2279 handling is not related to the dialog state. Unlike the ACK for 2280 error responses, ACK for 2xx responses is a request newly generated 2281 by TU. However, the ACK for 2xx and the one for error responses are 2282 both a part of the INVITE transaction, even though their hadlings 2283 differ (Section 17.1.1.1, RFC3261 [1]). 2284 Therefore, the INVITE transaction is completed by the three-way 2285 handshake, which includes ACK, even in the Mortal state. 2286 Considering actual implementation, UA needs to keep the INVITE dialog 2287 usage until the Mortal state finishes, so that it is able to ACK for 2288 a 2xx response in the Mortal state. 2289 If a 2xx to INVITE is received in the Mortal state, the duration of 2290 the INVITE dialog usage will be extended to 64*T1 seconds after the 2291 receiving of the 2xx, to cope with the possible 2xx retransmission. 2292 (The duration of the 2xx retransmission is 64*T1, so the UA need to 2293 be prepared to handle the retransmission for this duration.) 2294 However, the UA shall send error response to other requests, since 2295 the INVITE dialog usage in the Mortal state is kept only for the 2296 sending of ACK for 2xx. 2298 BYE authentication procedure shall be processed in the Mortal state. 2299 When authentication is requested by 401 or 407 response, UAC resends 2300 BYE with an appropriate credentials. Also UAS handles the 2301 retransmission of the BYE which it requested authentication itself. 2303 References 2305 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2306 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2307 Session Initiation Protocol", RFC 3261, June 2002. 2309 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2310 SDP", RFC 3264, April 2002. 2312 [3] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 2313 Summers, "Session Initiation Protocol (SIP) Basic Call Flow 2314 Examples", BCP 75, RFC 3665, December 2003. 2316 [4] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 2317 Summers, "Session Initiation Protocol (SIP) Public Switched 2318 Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December 2319 2003. 2321 [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2322 Method", RFC 3515, April 2003. 2324 [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 2325 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 2326 June 2002. 2328 [7] Rosenberg, J., Schulzrinne, H., Mahy, R., "An INVITE-Initiated 2329 Dialog Event Package for the Session Initiation Protocol (SIP)", 2330 RFC 4235, November 2005. 2332 [8] Sparks, R., "Multiple Dialog Usages in the Session Initiation 2333 Protocol", draft-ietf-sipping-dialogusage-05 (work in progress), 2334 November 9, 2006. 2336 Author's Addresses 2338 All listed authors actively contributed large amounts of text to this 2339 document. 2341 Miki Hasebe 2342 NTT-east Corporation 2343 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2345 EMail: hasebe.miki@east.ntt.co.jp 2347 Jun Koshiko 2348 NTT-east Corporation 2349 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2351 EMail: j.koshiko@east.ntt.co.jp 2353 Yasushi Suzuki 2354 NTT-east Corporation 2355 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2357 EMail: suzuki.yasushi@east.ntt.co.jp 2359 Tomoyuki Yoshikawa 2360 NTT-east Corporation 2361 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2363 EMail: tomoyuki.yoshikawa@east.ntt.co.jp 2365 Paul H. Kyzivat 2366 Cisco Systems, Inc. 2367 1414 Massachusetts Avenue 2368 Boxborough, MA 01719 2369 USA 2371 Email: pkyzivat@cisco.com 2373 Intellectual Property Statement 2375 The IETF takes no position regarding the validity or scope of any 2376 Intellectual Property Rights or other rights that might be claimed to 2377 pertain to the implementation or use of the technology described in 2378 this document or the extent to which any license under such rights 2379 might or might not be available; nor does it represent that it has 2380 made any independent effort to identify any such rights. Information 2381 on the procedures with respect to rights in RFC documents can be 2382 found in BCP 78 and BCP 79. 2384 Copies of IPR disclosures made to the IETF Secretariat and any 2385 assurances of licenses to be made available, or the result of an 2386 attempt made to obtain a general license or permission for the use of 2387 such proprietary rights by implementors or users of this 2388 specification can be obtained from the IETF on-line IPR repository at 2389 http://www.ietf.org/ipr. 2391 The IETF invites any interested party to bring to its attention any 2392 copyrights, patents or patent applications, or other proprietary 2393 rights that may cover technology that may be required to implement 2394 this standard. Please address the information to the IETF at 2395 ietf-ipr@ietf.org. 2397 Disclaimer of Validity 2399 This document and the information contained herein are provided on an 2400 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2401 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2402 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2403 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2404 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2405 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2407 Copyright Statement 2409 Copyright (C) The Internet Society (2006). This document is subject 2410 to the rights, licenses and restrictions contained in BCP 78, and 2411 except as set forth therein, the authors retain all their rights. 2413 Acknowledgment 2415 The authors would like to thank Robert Sparks, Dean Willis, 2416 Cullen Jennings, James M. Polk, Gonzalo Camarillo, 2417 Kenichi Ogami, Akihiro Shimizu, Mayumi Munakata, 2418 Yasunori Inagaki, Tadaatsu Kidokoro and Kenichi Hiragi for 2419 the comments on this document.