idnits 2.17.1 draft-hasebe-sipping-race-examples-02.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 2374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2364. ** 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: ---------------------------------------------------------------------------- == 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 49 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the 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 2282, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2291, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2294, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialogusage-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-dialogusage (ref. '8') Summary: 9 errors (**), 0 flaws (~~), 8 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 Expiration: Apl 23th, 2007 Y. SUZUKI 5 T. YOSHIKAWA 6 NTT-East 7 P. Kyzivat 8 Cisco Systems, Inc. 9 Oct 23th, 2006 11 Examples call flow in race condition on Session Initiation Protocol 12 draft-hasebe-sipping-race-examples-02.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 April 23, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document gives examples of Session Initiation Protocol (SIP) 46 call flows in race condition. Call flows in race conditions are 47 confusing and this document shows the best practices 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 . . . . . . . . . . . . . . . . 42 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 80 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . . . 49 81 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 50 82 Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . . . . 50 83 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 50 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 condition, 90 which stems from the state transition of the dialog mainly established 91 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, different 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 current version 2.0 of SIP 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 in understanding of 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. Arrow indicate the direction of message flow. 130 Double dashed lines (===) represent media paths between network 131 elements. 133 Messages with parentheses around their name represent optional 134 messages. 136 Messages are identified in the Figures as F1, F2, etc. These numbers 137 are used for references to the message details that follow the Figure. 138 Comments in the message details are shown in the following form: 140 /* Comments. */ 142 1.3 SIP Protocol Assumptions 144 This document does not prescribe the flows precisely as they are 145 shown, but rather illustrates the principles for best practice. 146 They are best practice usages (orderings, syntax, selection of 147 features for the purpose, or handling of error) of SIP methods, 148 headers and parameters. NOTE: The flows in this document must not 149 be copied as they are by implementors because additional 150 characteristics were incorporated into the document for ease of 151 explanation. To sum up, the procedures described in this document 152 represent well-reviewed examples of SIP usage, which are best common 153 practice according to IETF consensus. 155 For simplicity in reading and editing the document, there are a 156 number of differences between some of the examples and actual SIP 157 messages. Examples are: Call-IDs are often repeated; CSeq often 158 begins, at 1; header fields are usually shown in the same order; 159 usually only the minimum required header field set is shown; and 160 and Accept, Allow, 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 the dialog state of the sending side. 177 For instance, a race condition occurs when UAC (User Agent Client) 178 sends a CANCEL on Early state while UAS (User Agent Server) is 179 transitting from Early state to Confirmed state by sending a 200 OK 180 to ini-INVITE. 182 The dialog state machine (DSM) for INVITE dialog usage is 183 represented as follows to help the understanding of UA's behavior 184 in such race conditions. 186 The DSM clarifies UA's behavior by subdividing some internal 187 states showed on FSM (Finite State Machine) for dialog state of the 188 dialog-package [7], without changing the states of the dialog, 189 "early", "confirmed", and "terminated" shown in RFC3261 [1]. 190 Preparative state is put before the Ealy state, which includes 191 Trying and Proceeding. Confirmed state is devided into two 192 sub-states, Moratorium and Established and Terminated state is 193 subdivided into two states, Mortal and Morgue. 195 Below represent the DSM 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, a response means receive, a request 243 means send. 245 figure 1. DSM for INVITE dialog usage (UAC) 247 Figure 1 shows a DSM for UAC. 248 UAC MAY send a BYE in Early state. However, this behavior is 249 NOT RECOMMENDED. The dialog which is to be terminated by BYE in 250 Early state. Early state is the one that exists between the UAC 251 and the UAS that constitutes the early dialog with each other. 252 In Early state, it is possible that UAC receives responses from 253 other UASs in forking. Therefore, until the UAC receives the final 254 response and terminates the INVITE transaction, UAC MUST be prepared 255 to establish a dialog by receiving a new response even though it had 256 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, a response means send, 304 a request means receive. 306 figure 2. DSM for INVITE dialog usage (UAS) 308 Figure 2 shows a DSM for UAS. 309 The figure 2 includes state transition caused by BYE. 310 Originally, the correct description is that a CANCEL request does 311 not cause a dialog state transition, but the UAS terminates the 312 dialog and triggers the dialog transition by sending 487 immediately 313 after the reception of the CANCEL. The behavior upon the reception 314 of the CANCEL request is further explained in the section 2.1. 316 The following is UA's behaviors in each state. 318 Preparative (Pre): Preparative is a state until the Early dialog 319 is established by sending and receiving a provisional 320 response with To-tag after an ini-INVITE is sent and received. 321 The dialog has not existed yet in Preparative state. The 322 dialog state transit from the Preparative to the Early by 323 sending or receiving a provisional response with To-tag. 324 Moreover, the dialog state transit to Moratorium which is a 325 substate of Confirmed state, if UA sends or receives a 2xx 326 response. In addition, the dialog state transit to Morgue 327 state which is a substate of Terminated state, if UA sends 328 or receives a 3xx-6xx response. Sending an ACK to a 3xx-6xx 329 response and retransmissions of 3xx-6xx are not expressed on 330 this DSM because they are sent by INVITE transactions. 332 Trying (Try): Trying is substate of Preparative and inherits the 333 behavior of Preparative. Trying is started by sending and 334 receiving an ini-INVITE. It transits to Proceeding by sending 335 or receiving a 1xx (usually 100 trying) without To-tag. 336 UAC may retransmit an INVITE on transaction layer and UAC 337 must not send a CANCEL request. UAS may send a 1xx-6xx 338 response. 340 Proceeding (Pro): Proceeding is substate of Preparative and 341 inherits the behavior of Preparative. Dialog becomes 342 Proceeding state if dialogs in Trying state send or receive a 343 1xx without To-tag (usually 100 trying). UAC may send a 344 CANCEL, and UAS may send a 1xx-6xx response in Proceeding 345 state. 347 Early (Ear): The early dialog is established by sending or 348 receiving a provisional response with To-tag. The early dialog 349 exists though the dialog has not existed in this state yet. 350 The dialog state transits from Early to Moratorium, substate of 351 Confirmed by sending or receiving a 2xx response. In addition, 352 the dialog state transits to the Morgue subdivided internally 353 in the Terminated by sending and receiving a 3xx-6xx response. 354 Sending an ACK to a 3xx-6xx response and retransmissions of 355 3xx-6xx are not expressed on this DSM because they are 356 automatically processed on transaction layer and don't 357 influence the dialog state. UAC may send CANCEL in Early 358 state. UAC may send BYE (although it is not recommended). UAS 359 may send a 1xx-6xx response. Sending or reception of a CANCEL 360 request does not have direct influences on dialog state. The 361 UA's behavior upon the reception of the CANCEL request is 362 further explaind in the section 2.1 below. 364 Confirmed (Con): Sending or receiving 2xx final response 365 establishes a dialog. Dialog exists in this state. BYE 366 message changes state from Confirmed to Mortal, substate of 367 Terminated. Confirmed has two substates, Moratorium and 368 Established, they are different in messages UA are allowed to 369 send. 371 Moratorium (Mora): Moratorium is a substate of Confirmed and 372 inherits the behavior of Confirmed. Moratorium transits to 373 Established by sending or receiving an ACK request. UAC may 374 send an ACK and UAS may send a 2xx final response. 376 Established (Est): Established is a substate of Confirmed and 377 inherits the behavior of Confirmed. Both caller and callee may 378 send various messages which influences a dialog. Caller 379 supports the transmission of ACK to a retransmission of a 2xx 380 response to an ini-INVITE. 382 Terminated (Ter): Terminated state is devided into two substates, 383 Mortal and Morgue, to consider a behavior when a dialog is 384 being terminated. In this state, UAs hold information about 385 the dialog which is being terminated. Confirmed transits to 386 Mortal, a substate of Terminated, by sending or receiving a 387 BYE request. 389 Mortal (Mort): Caller and callee becomes Mortal state by sending 390 or receiving a BYE. UA MUST NOT send any new requests since 391 there is no dialog. (Here the new requests do not include ACK 392 for 2xx and BYE for 401 or 407. The further explaind is in 393 the section 2.2 below.) 394 In this state, only a BYE or its response can be handled, and 395 no other messages can be received. This is because the use 396 case is taken into consideration that a BYE message are sent 397 by both a caller and a callee to exchange reports about the 398 session when it is being terminated. Therefore, UA possesses 399 dialog information for internal process but dialog shouldn't 400 exist outwardly. UA stops managing dialog state and changes 401 it to Morgue state, when the BYE transaction is done by timer 402 (Timer F or Timer K for UAC. Timer J for UAS). 404 Morgue (Morg): Dialog doesn't exist any more in this state. 405 Sending or receiving a signal which influences a dialog is 406 not performed. (It is literally terminated.) 408 3. Race condition 410 This section details race condition between two SIP User 411 Agents (UAs): Alice and Bob. Alice (sip:alice@atlanta.example.com) 412 and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or 413 SIP-enabled devices. 414 Only significant signals are illustrated. Dialog state transitions 415 caused by sending and reception of SIP messages as well as '*race*', 416 which indicates race condition, are shown. (For abbreviations for 417 the dialog state transitions, refer to Chapter 2) 418 '*race*' indicates the moment when a race condition occurs. 420 Examples of such race conditions are shown below. 422 3.1 Receiving message in the Moratorium State 424 This section shows some examples of call flow in race condition 425 when receiving the message from other states in the Moratorium state. 427 3.1.1 Receiving Initial INVITE retransmission (Trying state) 428 in Moratorium state 430 State Alice Bob State 431 | | 432 | ini-INVITE F1 | 433 Pre |------------------------------------>| Pre 434 | 180 F2(Packet loss) | 435 | X<-----------------------| Ear 436 | | 437 | ini-INVITE(=F1) F4 200 F3 | 438 |------------------ --------------| Mora 439 | \ / | 440 | X | 441 | / \ | 442 Mora |<----------------- ------------->| *race* 443 | ACK F5 | 444 Est |------------------------------------>| Est 445 | | 446 | | 448 This scenario illustrates the race condition which occurs when UAS 449 receives a Preparative message in Moratorium state. All provisional 450 responses to the initial INVITE (ini-INVITE F1) are lost, and UAC 451 retransmits an ini-INVITE (F4). At the same time as retransmission, 452 UAS generates a 200 OK (F3) to the ini-INVITE and it terminate an 453 INVITE server transaction. (RFC3261, 13.3.1.4 [1]) 454 However, it is reported that terminating an INVITE server transaction 455 by 200 OK is a SIP bug. (http://bugs.sipit.net/, #769) 456 Therefore, the INVITE server transaction is not terminated at F3, and 457 the F4 MUST be properly handled as a retransmission. 458 (UAs that do not deal with this bug still need to recognize the 459 retransmission relying on its From-tag and Call-ID, even though it 460 does not match the transaction.) 461 In RFC3261 [1], it is not specified whether a UAS retransmits 200 to 462 the retransmission of ini-INVITE. Considering the retransmission of 463 200 is triggered by timer (TU keeps retransmitting 200 based on T1 464 and T2 until it receives an ACK) according to Section 13.3.1.4 of 465 RFC3261 [1], it seems unnecessary to retransmit 200 when the UAS 466 receives the retransmission of ini-INVITE. (For implementation, it 467 does not matter if UAS sends the retransmission of 200, since the 468 200 does not cause any problem.) 470 Message Details 472 F1 INVITE Alice -> Bob 474 F2 180 Ringing Bob -> Alice 475 /* A 180 response is lost and does not reach Alice. */ 477 F3 200 OK Bob -> Alice 478 /* According to 13.3.1.4 of RFC3261, an INVITE server transaction 479 is terminated at this point. However, this has been reported as 480 a SIP bug, and UAS MUST correctly recognize the ini-INVITE (F4) as 481 a retransmission. */ 483 F4 INVITE (retransmission) Alice -> Bob 484 /* F4 is a retransmission of F1. They are exactly the same INVITE 485 request. When UAs do not deal with the bug reported in #769 (an 486 INVITE server transaction is terminated by 200 to INVITE), this 487 request does not match the transaction as well as the dialog 488 since it does not have a To-tag. 489 However, Bob have to recognize the retransmitted INVITE correctly, 490 without treating it as the new INVITE. */ 492 F5 ACK Alice -> Bob 494 3.1.2 Receiving CANCEL (Proceeding or Early state) 495 in Moratorium state 497 State Alice Bob State 498 | | 499 | INVITE F1 | 500 Pre |----------------------------->| Pre 501 | 180 Ringing F2 | 502 Ear |<-----------------------------| Ear 503 | | 504 |CANCEL F3 200(INVITE) F4| 505 |------------ -------------| Mora 506 | \ / | 507 | X | 508 | / \ | 509 Mora |<----------- ------------>| *race* 510 | | 511 | ACK F6 200(CANCEL) F5| 512 Est |------------ -------------| 513 | \ / | 514 | X | 515 | / \ | 516 |<----------- ------------>| Est 517 | | 518 | Both Way RTP Media | 519 |<============================>| 520 | BYE F7 | 521 Mort |----------------------------->| Mort 522 | 200 F8 | 523 |<-----------------------------| 524 | ^ ^ | 525 | | Timer K | | 526 | V | | 527 Morg | Timer J | | 528 | V | 529 | | Morg 530 | | 532 This scenario illustrates the race condition which occurs when UAS 533 receives an Early message (CANCEL) in Moratorium state. Alice sends 534 a CANCEL and Bob sends a 200 OK response to the initial INVITE 535 message at the same time. As described in the previous section, 536 according to RFC3261 an INVITE server transaction is terminated by 537 a 200 response, but this has been reported as a bug in #769. 538 This section describes a case in which an INVITE server transaction 539 is not terminated by a BYE response to the request. In this case, 540 there is an INVITE transaction which matches a CANCEL request, so a 541 200 response is sent for the request. This 200 response simply means 542 that the next hop received the CANCEL request. 543 (Successful CANCEL (200) does not mean an INVITE failure) 544 When UAS does not deal with #769, UAC MAY receive a 481 response for 545 CANCEL since there is no transaction which matches the CANCEL request. 546 This 481 simply means that there is no matching INVITE server 547 transaction and CANCEL is not sent to the next hop. 548 Regardless of the success/failure of the CANCEL, Alice checks the 549 final response to INVITE, and if she receives 200 to the INVITE 550 request she immediately sends a BYE and terminates a dialog. 551 (RFC3261, 15) 553 Message Details 555 F1 INVITE Alice -> Bob 557 F2 180 Ringing Bob -> Alice 559 F3 CANCEL Alice -> Bob 560 /* Alice sends a CANCEL on the Early state. */ 562 F4 200 OK (INVITE) Bob -> Alice 563 /* Alice receives a 200 to INVITE (F1) on the Moratorium state. */ 565 F5 200 OK (CANCEL) Bob -> Alice 566 /* A 200 to CANCEL simply means that the CANCEL was received. 567 The 200 response is sent, since this document deals with the 568 bug reported in #769. When an INVITE server transaction is 569 terminated as the procedure stated in RFC3261, UAC MAY receive 570 a 481 response instead of a 200. */ 572 F6 ACK Alice -> Bob 573 /* INVITE is successful, and a CANCEL becomes invalid. RTP streams 574 are established. However, the next BYE request immediately cleans 575 up the dialog just established. */ 577 F7 BYE Alice -> Bob 579 F8 200 OK Bob -> Alice 581 3.1.3 Receiving BYE (Early state) 582 in Moratorium state 584 State Alice Bob State 585 | | 586 | ini-INVITE F1 | 587 Pre |------------------------------->| Pre 588 | 180 F2 | 589 Ear |<-------------------------------| Ear 590 | | 591 | BYE F4 200(INVITE) F3| 592 Mort |------------- --------------| Mora 593 | \ / | 594 | X | 595 | / \ | 596 |<------------ ------------->| Mort & *race* 597 | | 598 | ACK F5 200(BYE) F6 | 599 |------------- --------------| 600 | \ / ^ | 601 | X | | 602 | / \ | | 603 |<------------ ------------->| 604 | ^ | | 605 | | Timer K | | 606 | V | | 607 Morg | Timer J | | 608 | V | 609 | | Morg 610 | | 612 This scenario illustrates the race condition which occurs when 613 UAS receives an Early message (BYE) in Moratorium state. 614 Alice sends a BYE on the early dialog and Bob sends a 200 OK 615 response to the initial INVITE message at the same time. Bob 616 receives a BYE on the Confirmed dialog though Alice sended a 617 BYE on the Early dialog. A BYE functions normally even if it 618 is received after the INVITE transaction terminates because a 619 BYE differs from a CANCEL, and is sent to not the request but 620 the dialog. Alice gets into a Mortal state on receiving the 621 BYE response, and remains Mortal until the Timer K timeout 622 occurs. In Mortal state, UAC does not establish a session, 623 even though it receives a 200 response for INVITE. Even so, 624 it sends an ACK to 200 for completion of INVITE transaction. 626 Editor's Note: 627 ACK was not sent in the previous version of this draft. Since both 628 dialog usage and session were finished, it was thought that it is not 629 necessary to send ACK. In this version ACK is sent, according to 630 RFC3261 which states that the INVITE transaction consists of the 631 three-way handshake of INVITE/200/ACK. 633 Message Details 635 F1 INVITE Alice -> Bob 637 F2 180 Ringing Bob -> Alice 639 F3 200 OK (ini-INVITE) Bob -> Alice 641 F4 BYE Alice -> Bob 643 /*Alice transits to the Mortal state upon sending BYE. 644 Therefore, after this, she does not begin a session even 645 though she receives a 200 response with an answer./ 647 F5 ACK Alice -> Bob 649 F6 200 OK (BYE) Bob -> Alice 651 3.1.4 Receiving re-INVITE (Established state) 652 in Moratorium state (case 1) 654 State Alice Bob State 655 | | 656 | ini-INVITE F1 | 657 Pre |------------------------------->| Pre 658 | 180 F2 | 659 Ear |<-------------------------------| Ear 660 | | 661 | 200(ini-INV) F3 | 662 Mora |<-------------------------------| Mora 663 | ACK F4(packet loss) | 664 Est |-------------------->X | 665 | | 666 | re-INVITE F6 200(=F3) F5 | 667 |------------- --------------| 668 | \ / | 669 | X | 670 | / \ | 671 |<------------ ------------->| *race* 672 | ACK(=F4) F7 200(re-INV) F8| 673 |------------- --------------| 674 | \ / | 675 | X | 676 | / \ | 677 |<------------ ------------->| Est 678 | ACK F9 | 679 |------------------------------->| 680 | | 681 | | 683 This scenario illustrates the race condition which occurs when 684 UAS receives a message (re-INVITE) sent on Established state in 685 Moratorium state. 686 UAS receives a re-INVITE before receiving an ACK to ini-INVITE. UAS 687 sends a 200 OK to the re-INVITE (F8) because it has sent a 200 OK 688 to the ini-INVITE (F3, F5) and the dialog has already been confirmed. 689 (Because F5 is a retransmission of F3, SDP negotiation is not 690 performed here.) If a 200 OK to the ini-INVITE has an offer and the 691 answer would be in the ACK, UA should return by a 491 to the 692 re-INVITE (refer to 3.1.5). As it can be seen in the section 3.3.2 693 below, the 491 response seems to be closely related to session 694 establishment, even in cases other than INVITE cross-over. This 695 example recommends 200 be sent instead of 491 because it does not 696 influence session. However, a 491 response can lead to the same 697 outcome, so the either response can be used. 698 Moreover, if UAS doesn't receive an ACK for a long time, 699 it should send a BYE and terminate the dialog. 701 Message Details 703 F1 INVITE Alice -> Bob 705 INVITE sip:bob@biloxi.example.com SIP/2.0 706 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 707 Max-Forwards: 70 708 From: Alice ;tag=9fxced76sl 709 To: Bob 710 Call-ID: 3848276298220188511@atlanta.example.com 711 CSeq: 1 INVITE 712 Contact: 713 Content-Type: application/sdp 714 Content-Length: 137 716 v=0 717 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 718 s=- 719 c=IN IP4 192.0.2.101 720 t=0 0 721 m=audio 49172 RTP/AVP 0 722 a=rtpmap:0 PCMU/8000 724 /* ini-INVITE contains an offer. */ 725 F2 180 Ringing Bob -> Alice 727 SIP/2.0 180 Ringing 728 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 729 ;received=192.0.2.101 730 From: Alice ;tag=9fxced76sl 731 To: Bob ;tag=8321234356 733 Call-ID: 3848276298220188511@atlanta.example.com 734 CSeq: 1 INVITE 735 Contact: 736 Content-Length: 0 738 F3 200 OK Bob -> Alice 740 SIP/2.0 200 OK 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 745 Call-ID: 3848276298220188511@atlanta.example.com 746 CSeq: 1 INVITE 747 Contact: 748 Content-Type: application/sdp 749 Content-Length: 133 751 v=0 752 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 753 s=- 754 c=IN IP4 192.0.2.201 755 t=0 0 756 m=audio 3456 RTP/AVP 0 757 a=rtpmap:0 PCMU/8000 759 F4 ACK Alice -> Bob 761 ACK sip:bob@client.biloxi.example.com SIP/2.0 762 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 763 Max-Forwards: 70 764 From: Alice ;tag=9fxced76sl 765 To: Bob ;tag=8321234356 766 Call-ID: 3848276298220188511@atlanta.example.com 767 CSeq: 1 ACK 768 Content-Length: 0 770 /* A ACK request is lost. */ 771 F5 200 OK (=F3) Bob -> Alice (retransmission) 772 /* UAS retransmits a 200 OK to an ini-INVITE since it didn't receive 773 a ACK. */ 775 F6 re-INVITE Alice -> Bob 777 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 778 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 779 Max-Forwards: 70 780 From: Alice ;tag=9fxced76sl 781 To: Bob ;tag=8321234356 782 Call-ID: 3848276298220188511@atlanta.example.com 783 CSeq: 2 INVITE 784 Content-Length: 147 786 v=0 787 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 788 s=- 789 c=IN IP4 192.0.2.101 790 t=0 0 791 m=audio 49172 RTP/AVP 0 792 a=rtpmap:0 PCMU/8000 793 a=sendonly 795 F7 ACK (=F4) Alice -> Bob (retransmission) 797 F8 200 OK (re-INVITE) Bob -> Alice 799 SIP/2.0 200 OK 800 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 801 Max-Forwards: 70 802 From: Alice ;tag=9fxced76sl 803 To: Bob ;tag=8321234356 804 Call-ID: 3848276298220188511@atlanta.example.com 805 CSeq: 2 INVITE 806 Content-Length: 143 808 v=0 809 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com 810 s=- 811 c=IN IP4 192.0.2.201 812 t=0 0 813 m=audio 3456 RTP/AVP 0 814 a=rtpmap:0 PCMU/8000 815 a=recvonly 817 F9 ACK Alice -> Bob 818 ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 819 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f2.1 820 Max-Forwards: 70 821 From: Alice ;tag=9fxced76sl 822 To: Bob ;tag=8321234356 823 Call-ID: 3848276298220188511@atlanta.example.com 824 CSeq: 2 ACK 825 Content-Length: 0 827 3.1.5 Receiving re-INVITE (Established state) 828 in Moratorium state (case 2) 830 State Alice Bob State 831 | | 832 | ini-INVITE F1 | 833 Pre |------------------------------->| Pre 834 | 180 F2 | 835 Ear |<-------------------------------| Ear 836 | | 837 | 200(ini-INV) F3 | 838 Mora |<-------------------------------| Mora 839 | ACK F4(packet loss) | 840 Est |-------------------->X | 841 | | 842 | re-INVITE F6 200(=F3) F5 | 843 |------------- --------------| 844 | \ / | 845 | X | 846 | / \ | 847 |<------------ ------------->| 848 | ACK(=F4) F7 491(re-INV) F8| 849 |------------- --------------| 850 | \ / | 851 | X | 852 | / \ | 853 |<------------ ------------->| Est 854 | ACK F9 | 855 |------------------------------->| 856 | | 857 | | 859 This scenario is basically the same with 3.1.4, but differs in 860 sending an offer in 200 and an answer in ACK. Different to the 861 previous case, the offer in the 200 (F3) and the offer in the 862 re-INVITE (F6) collide with each other. 863 Bob sends 491 to re-INVITE since he is not able to properly 864 handle a new request until he receives an answer. 866 Message Details 868 F1 INVITE Alice -> Bob 870 INVITE sip:bob@biloxi.example.com SIP/2.0 871 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 872 Max-Forwards: 70 873 From: Alice ;tag=9fxced76sl 874 To: Bob 875 Call-ID: 3848276298220188511@atlanta.example.com 876 CSeq: 1 INVITE 877 Contact: 878 Content-Length: 0 880 /* The request does not contain an offer. */ 882 F2 180 Ringing Bob -> Alice 884 F3 200 OK Bob -> Alice 886 SIP/2.0 200 OK 887 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 888 ;received=192.0.2.101 889 From: Alice ;tag=9fxced76sl 890 To: Bob ;tag=8321234356 891 Call-ID: 3848276298220188511@atlanta.example.com 892 CSeq: 1 INVITE 893 Contact: 894 Content-Type: application/sdp 895 Content-Length: 133 897 v=0 898 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 899 s=- 900 c=IN IP4 192.0.2.201 901 t=0 0 902 m=audio 3456 RTP/AVP 0 903 a=rtpmap:0 PCMU/8000 905 /* An offer is made in 200 */ 907 F4 ACK Alice -> Bob 909 ACK sip:bob@client.biloxi.example.com SIP/2.0 910 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 911 Max-Forwards: 70 912 From: Alice ;tag=9fxced76sl 913 To: Bob ;tag=8321234356 914 Call-ID: 3848276298220188511@atlanta.example.com 915 CSeq: 1 ACK 916 Content-Type: application/sdp 917 Content-Length: 137 919 v=0 920 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 921 s=- 922 c=IN IP4 192.0.2.101 923 t=0 0 924 m=audio 49172 RTP/AVP 0 925 a=rtpmap:0 PCMU/8000 927 /* The request contains an answer. ACK request is lost. */ 929 F5 200 OK (=F3) Bob -> Alice (retransmission) 930 /* UAS retransmits a 200 OK to an ini-INVITE since it didn't receive 931 an ACK. */ 933 F6 re-INVITE Alice -> Bob 935 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 937 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 938 Max-Forwards: 70 939 From: Alice ;tag=9fxced76sl 940 To: Bob ;tag=8321234356 941 Call-ID: 3848276298220188511@atlanta.example.com 942 CSeq: 2 INVITE 943 Content-Length: 147 945 v=0 946 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 947 s=- 948 c=IN IP4 192.0.2.101 949 t=0 0 950 m=audio 49172 RTP/AVP 0 951 a=rtpmap:0 PCMU/8000 952 a=sendonly 954 /* The request contains an offer. */ 956 F7 ACK (=F4) Alice -> Bob (retransmission) 957 /* A retransmission triggered by the reception of a retransmitted 958 200. */ 959 F8 491 (re-INVITE) Bob -> Alice 960 /* Bob sends 491 (Request Pending), since Bob has a pending 961 offer. */ 963 F9 ACK Alice -> Bob 965 3.1.6 Receiving BYE (Established state) 966 in Moratorium state 968 State Alice Bob State 969 | | 970 | INVITE F1 | 971 Pre |-------------------------->| Pre 972 | 180 Ringing F2 | 973 Ear |<--------------------------| Ear 974 | | 975 | 200 OK F3 | 976 Mora |<--------------------------| Mora 977 | ACK F4(packet loss) | 978 Est |--------------->X | 979 | Both Way RTP Media | 980 |<=========================>| 981 | BYE F6 200(=F3) F5| 982 Mort |----------- -----------| 983 | \ / | 984 | X | 985 | / \ | 986 |<---------- ---------->| Mort & *race* 987 |ACK(=F4) F7 200(BYE) F8| 988 |----------- -----------| 989 | \ / | 990 | X | 991 | / \ | 992 |<---------- ---------->| 993 | ^ ^ | 994 | | Timer K | | 995 | V | | 996 Morg | Timer J | | 997 | V | 998 | | Morg 999 | | 1001 This scenario illustrates the race condition which occurs when 1002 UAS receives an Established message (BYE) in Moratorium state. 1003 An ACK request to a 200 OK response is lost (or delay), 1004 immediately after Bob sends the retransmitted 200 OK to 1005 ini-INVITE and Alice sends a BYE at the same time. 1006 Depending on the implement of a SIP user agent, Alice may start 1007 a session again by reception of the retransmitted 200 OK with SDP 1008 since she has already terminated a session by sending a BYE. In 1009 that case, if UAC receives a retransmitted 200 OK after sending a 1010 BYE, you should not start a session again since the session which 1011 is not associated with dialog remains. Moreover, in the case where 1012 UAS sends an offer with a 200 OK, if UAS receives a retransmitted 1013 ACK after receiving a BYE, UAS should not start a session again 1014 for the same reason. 1016 Message Details 1018 F1 INVITE Alice -> Bob 1020 F2 180 Ringing Bob -> Alice 1022 F3 200 OK Bob -> Alice 1024 F4 ACK Alice -> Bob 1026 ACK sip:bob@client.biloxi.example.com SIP/2.0 1027 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1028 Max-Forwards: 70 1029 From: Alice ;tag=9fxced76sl 1030 To: Bob ;tag=8321234356 1031 Call-ID: 3848276298220188511@atlanta.example.com 1032 CSeq: 1 ACK 1033 Content-Length: 0 1035 /* An ACK request is lost. */ 1037 F5 200 OK (retransmission) Bob -> Alice 1039 SIP/2.0 200 OK 1040 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1041 ;received=192.0.2.101 1042 From: Alice ;tag=9fxced76sl 1043 To: Bob ;tag=8321234356 1044 Call-ID: 3848276298220188511@atlanta.example.com 1045 CSeq: 1 INVITE 1046 Contact: 1047 Content-Type: application/sdp 1048 Content-Length: 133 1050 v=0 1051 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1052 s=- 1053 c=IN IP4 192.0.2.201 1054 t=0 0 1055 m=audio 3456 RTP/AVP 0 1056 a=rtpmap:0 PCMU/8000 1058 /* UAS retransmits a 200 OK to an ini-INVITE since it didn't receive 1059 an ACK. */ 1061 F6 BYE Alice -> Bob 1063 BYE sip:bob@client.biloxi.example.com SIP/2.0 1064 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 1065 Max-Forwards: 70 1066 From: Alice ;tag=9fxced76sl 1067 To: Bob ;tag=8321234356 1068 Call-ID: 3848276298220188511@atlanta.example.com 1069 CSeq: 2 BYE 1070 Content-Length: 0 1072 /* Bob retransmits a 200 OK and Alice sends a BYE at the same time. 1073 Alice has transited to the Mortal state, so she does not begin a 1074 session after this even though she receives a 200 response to 1075 the re-INVITE. */ 1077 F7 ACK(=F4) Alice -> Bob 1079 F8 200 OK (BYE) Bob -> Alice 1081 SIP/2.0 200 OK 1082 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 1083 ;received=192.0.2.101 1084 From: Alice ;tag=9fxced76sl 1085 To: Bob ;tag=8321234356 1086 Call-ID: 3848276298220188511@atlanta.example.com 1087 CSeq: 2 BYE 1088 Content-Length: 0 1090 /* Bob sends a 200 OK to a BYE. */ 1092 3.2 Receiving message in the Mortal State 1094 This section shows some examples of call flow in race condition 1095 when receiving the message from other states in the Mortal state. 1097 3.2.1 Receiving BYE (Establish state) 1098 in Mortal state 1100 State Alice Bob 1101 | | 1102 | INVITE F1 | 1103 Pre |----------------------->| Pre 1104 | 180 Ringing F2 | 1105 Ear |<-----------------------| Ear 1106 | | 1107 | 200 OK F3 | 1108 Mora |<-----------------------| Mora 1109 | ACK F4 | 1110 Est |----------------------->| Est 1111 | Both Way RTP Media | 1112 |<======================>| 1113 | | 1114 | BYE F5 BYE F6 | 1115 Mort |--------- ----------| Mort 1116 | \ / | 1117 | X | 1118 | / \ | 1119 |<-------- --------->| *race* 1120 | | 1121 | 200 F8 200 F7 | 1122 |--------- ----------| 1123 | \ / | 1124 | X | 1125 | / \ | 1126 |<-------- --------->| 1127 | ^ ^ | 1128 | | Timer K | | 1129 | V | | 1130 Morg | Timer J | | 1131 | V | 1132 | | Morg 1133 | | 1135 This scenario illustrates the race condition which occurs when 1136 UAS receives an Established message (BYE) in Mortal state. 1137 Alice and Bob send a BYE at the same time. A dialog and session 1138 is ended shortly after a BYE request is passed to a client 1139 transaction. As shown in section 2, UA remains in Mortal state. 1140 UAs in Mortal state return error responses to the requests that 1141 operate dialog or session, such as re-INVITE, UPDATE, or REFER. 1142 However, UA shall return 200 OK to the BYE because the use case 1143 is taken into consideration that a BYE message are sent by both 1144 a caller and a callee to exchange reports about the session 1145 when it is being terminated. 1146 (Since the dialogue and the session both terminate when a BYE 1147 is sent, the choice of sending 200 or error response upon 1148 receiving BYE in Mortal state does not affect the resulting 1149 termination. Therefore, even though this example uses a 200 1150 response, other responses can be used.) 1152 Message Details 1154 F1 INVITE Alice -> Bob 1156 F2 180 Ringing Bob -> Alice 1158 F3 200 OK Bob -> Alice 1160 F4 ACK Alice -> Bob 1162 F5 BYE Alice -> Bob 1164 BYE sip:bob@client.biloxi.example.com SIP/2.0 1165 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1166 Max-Forwards: 70 1167 From: Alice ;tag=9fxced76sl 1168 To: Bob ;tag=8321234356 1169 Call-ID: 3848276298220188511@atlanta.example.com 1170 CSeq: 2 BYE 1171 Content-Length: 0 1173 /* The session is terminated at the moment Alice sends a BYE. 1174 The dialog still exists then, but it is certain to be 1175 terminated in a short period of time. The dialog is 1176 completely terminated when the timeout of the BYE request 1177 occurs. */ 1179 F6 BYE Bob -> Alice 1181 BYE sip:alice@client.atlanta.example.com SIP/2.0 1182 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1183 Max-Forwards: 70 1184 From: Bob ;tag=8321234356 1185 To: Alice ;tag=9fxced76sl 1186 Call-ID: 3848276298220188511@atlanta.example.com 1187 CSeq: 1 BYE 1188 Content-Length: 0 1190 /* Bob has also transmitted a BYE simultaneously with Alice. 1191 Bob terminates a session and a dialog. */ 1193 F7 200 OK Bob -> Alice 1195 SIP/2.0 200 OK 1196 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1197 ;received=192.0.2.201 1198 From: Alice ;tag=9fxced76sl 1199 To: Bob ;tag=8321234356 1200 Call-ID: 3848276298220188511@atlanta.example.com 1201 CSeq: 2 BYE 1202 Content-Length: 0 1204 /* Since the dialog is Moratorium state, Bob responds with 1205 a 200 to the BYE. */ 1207 F8 200 OK Alice -> Bob 1209 SIP/2.0 200 OK 1210 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1211 ;received=192.0.2.201 1212 From: Bob ;tag=8321234356 1213 To: Alice ;tag=9fxced76sl 1214 Call-ID: 3848276298220188511@atlanta.example.com 1215 CSeq: 1 BYE 1216 Content-Length: 0 1218 /* Since Alice has transited from the established state to Mortal 1219 state by sending a BYE, Alice responds with a 200 to a BYE. */ 1221 3.2.2 Receiving re-INVITE (Establish state) 1222 in Mortal state 1224 State Alice Bob 1225 | | 1226 | INVITE F1 | 1227 Pre |----------------------->| Pre 1228 | 180 Ringing F2 | 1229 Ear |<-----------------------| Ear 1230 | | 1231 | 200 OK F3 | 1232 Mora |<-----------------------| Mora 1233 | ACK F4 | 1234 Est |----------------------->| Est 1235 | Both Way RTP Media | 1236 |<======================>| 1237 | | 1238 | BYE F5 re-INVITE F6| 1239 Mort |--------- ----------| 1240 | \ / | 1241 | X | 1242 | / \ | 1243 *race* |<-------- --------->| Mort 1244 | | 1245 | 481 F8 200 F7 | 1246 |--------- ----------| 1247 | \ / |^ 1248 | X || 1249 | / \ ||Timer J 1250 |<-------- --------->|| 1251 ^| ACK F9 || 1252 ||<-----------------------|| 1253 Timer K|| || 1254 || || 1255 V| || 1256 Morg | |V 1257 | | Morg 1258 | | 1260 This scenario illustrates the race condition which occurs when 1261 UAS receives an Established message (re-INVITE) in Mortal state. 1262 Bob sends a re-INVITE, and Alice sends a BYE at the same time. 1263 The re-INVITE of Bob is returned by a 481, since TU of Alice has 1264 transited from Established state to Mortal state by sending a BYE. 1265 Bob sends ACK to the 481 response, because ACK for error responses 1266 is handled by the transaction layer, and at the point of receiving 1267 the 481 the INVITE client transaction still remains (even though 1268 the dialog has been terminated). 1270 Message Details 1272 F1 INVITE Alice -> Bob 1274 F2 180 Ringing Bob -> Alice 1276 F3 200 OK Bob -> Alice 1278 F4 ACK Alice -> Bob 1280 F5 BYE Alice -> Bob 1282 BYE sip:bob@client.biloxi.example.com SIP/2.0 1283 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1284 Max-Forwards: 70 1285 From: Alice ;tag=9fxced76sl 1286 To: Bob ;tag=8321234356 1287 Call-ID: 3848276298220188511@atlanta.example.com 1288 CSeq: 2 BYE 1289 Content-Length: 0 1291 /* Alice sends a BYE and terminates a session, and transits from 1292 Established state to Mortal state. */ 1294 F6 re-INVITE Bob -> Alice 1296 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1297 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1298 Session-Expires: 300;refresher=uac 1299 Supported: timer 1300 Max-Forwards: 70 1301 From: Bob ;tag=8321234356 1302 To: Alice ;tag=9fxced76sl 1303 Call-ID: 3848276298220188511@atlanta.example.com 1304 CSeq: 1 INVITE 1305 Content-Length: 0 1307 /* Alice sends a BYE, and Bob sends a re-INVITE at the same time. 1308 The state of dialog transits to Mortal state at the moment 1309 Alice sends a BYE, but Bob doesn't know it until he receives 1310 the BYE. Therefore, the dialog is Terminated state from 1311 Alice's point of view, but the dialog is Confirmed state 1312 from Bob's point of view. A race condition occurs. */ 1314 F7 200 OK Bob -> Alice 1316 SIP/2.0 200 OK 1317 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1318 ;received=192.0.2.201 1319 From: Alice ;tag=9fxced76sl 1320 To: Bob ;tag=8321234356 1321 Call-ID: 3848276298220188511@atlanta.example.com 1323 CSeq: 2 BYE 1324 Content-Length: 0 1326 F8 481 Call/Transaction Does Not Exist Alice -> Bob 1328 SIP/2.0 481 Call/Transaction Does Not Exist 1329 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1330 ;received=192.0.2.201 1331 From: Bob ;tag=8321234356 1332 To: Alice ;tag=9fxced76sl 1333 Call-ID: 3848276298220188511@atlanta.example.com 1334 CSeq: 1 INVITE 1335 Content-Length: 0 1337 /* Since Alice is in Mortal state, she responds with a 481 to the 1338 re-INVITE. */ 1340 F9 ACK Bob -> Alice 1342 /* ACK for an error response is handled by Bob's INVITE client 1343 transaction. */ 1345 3.2.3 Receiving 200OK for re-INVITE (Established state) 1346 in Mortal state 1348 State Alice Bob 1349 | | 1350 | INVITE F1 | 1351 Pre |----------------------->| Pre 1352 | 180 Ringing F2 | 1353 Ear |<-----------------------| Ear 1354 | | 1355 | 200 OK F3 | 1356 Mora |<-----------------------| Mora 1357 | ACK F4 | 1358 Est |----------------------->| Est 1359 | Both Way RTP Media | 1360 |<======================>| 1361 | | 1362 | re-INVITE F5 | 1363 |<-----------------------| 1364 | 200 F7 BYE F6 | 1365 |--------- ----------| Mort 1366 | \ / | 1367 | X | 1368 | / \ | 1369 Mort |<-------- --------->| *race* 1370 | 200 F8 ACK F9 | 1371 |--------- ----------| 1372 | ^ \ / | 1373 | | X | 1374 | | / \ | 1375 |<-------- --------->| 1376 | | ^ | 1377 | | Timer K | | 1378 | | V | 1379 | | Timer J | Morg 1380 | V | 1381 Morg | | 1382 | | 1384 This scenario illustrates the race condition which occurs when 1385 UAS receives an Established message (200 to re-INVITE) in Mortal 1386 state. Bob sends a BYE immediately after sending a re-INVITE. 1387 (A user is not conscious that refresher sends a re-INVITE 1388 automatically. For example, in the case of a telephone application, 1389 it is possible that a user places a receiver immediately after 1390 refresher.) 1391 Bob sends ACK for a 2xx response when he receives 200 to INVITE 1392 in the Mortal state, so that he completes the INVITE transaction. 1394 Message Details 1396 F1 INVITE Alice -> Bob 1398 F2 180 Ringing Bob -> Alice 1400 F3 200 OK Bob -> Alice 1402 F4 ACK Alice -> Bob 1404 F5 re-INVITE Bob -> Alice 1406 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1407 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1408 Session-Expires: 300;refresher=uac 1409 Supported: timer 1410 Max-Forwards: 70 1411 From: Bob ;tag=8321234356 1412 To: Alice ;tag=9fxced76sl 1413 Call-ID: 3848276298220188511@atlanta.example.com 1414 CSeq: 1 INVITE 1415 Content-Length: 0 1417 F6 BYE Bob -> Alice 1419 BYE sip:alice@client.atlanta.example.com SIP/2.0 1420 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8 1421 Max-Forwards: 70 1422 From: Bob ;tag=8321234356 1423 To: Alice ;tag=9fxced76sl 1424 Call-ID: 3848276298220188511@atlanta.example.com 1425 CSeq: 2 BYE 1426 Content-Length: 0 1428 /* Bob sends a BYE immediately after sending of a re-INVITE. 1429 Bob terminates a session and transits from Established 1430 state to Mortal state. */ 1432 F7 200 OK (re-INVITE) Alice -> Bob 1433 SIP/2.0 200 OK 1434 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds7 1435 ;received=192.0.2.201 1436 From: Bob ;tag=8321234356 1437 To: Alice ;tag=9fxced76sl 1438 Call-ID: 3848276298220188511@atlanta.example.com 1439 CSeq: 1 INVITE 1440 Content-Length: 0 1442 /* Bob sends a BYE, and Alice responds with a 200 OK to re-INVITE. 1443 A race condition occurs. */ 1445 F8 200 OK (BYE) Alice -> Bob 1447 SIP/2.0 200 OK 1448 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8 1449 ;received=192.0.2.201 1450 From: Bob ;tag=8321234356 1451 To: Alice ;tag=9fxced76sl 1452 Call-ID: 3848276298220188511@atlanta.example.com 1453 CSeq: 2 BYE 1454 Content-Length: 0 1456 F9 ACK Bob -> Alice 1458 /* Bob sends ACK in the Mortal state to complete the three-way handshake 1459 of the INVITE transaction */ 1461 3.2.4 Receiving ACK (Moratorium state) 1462 in Mortal state 1464 State Alice Bob State 1465 | | 1466 | ini-INVITE F1 | 1467 Pre |------------------------------->| Pre 1468 | 180 F2 | 1469 Ear |<-------------------------------| Ear 1470 | 200 F3 | 1471 Mora |<-------------------------------| Mora 1472 | | 1473 | ACK F4 BYE F5 | 1474 Est |------------- --------------| Mort 1475 | \ / | 1476 | X | 1477 | / \ | 1478 Mort |<------------ ------------->| *race* 1479 | 200 F6 | 1480 |------------------------------->| 1481 | ^ ^ | 1482 | | Timer K | | 1483 | | V | 1484 | | Timer J | Morg 1485 | V | 1486 Morg | | 1487 | | 1489 This scenario illustrates the race condition which occurs when 1490 UAS receives an Established message (ACK to 200) in Mortal state. 1491 Alice sends an ACK and Bob sends a BYE at the same time. When the 1492 offer is in a 2xx, and the answer is in an ACK, this example is 1493 in a race condition. Do not begin the session by receiving an ACK 1494 because Bob has already terminated the session by sending the BYE. 1495 The answer of ACK is just ignored. 1497 F1 INVITE Alice -> Bob 1499 F2 180 Ringing Bob -> Alice 1501 F3 200 OK Bob -> Alice 1503 F4 ACK Alice -> Bob 1505 ACK sip:bob@client.biloxi.example.com SIP/2.0 1506 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 1507 Max-Forwards: 70 1508 From: Alice ;tag=9fxced76sl 1509 To: Bob ;tag=8321234356 1510 Call-ID: 3848276298220188511@atlanta.example.com 1511 CSeq: 1 ACK 1512 Content-Length: 0 1514 /* RTP streams are established between Alice and Bob */ 1516 F5 BYE Alice -> Bob 1518 BYE sip:bob@client.biloxi.example.com SIP/2.0 1519 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1520 Max-Forwards: 70 1521 From: Alice ;tag=9fxced76sl 1522 To: Bob ;tag=8321234356 1523 Call-ID: 3848276298220188511@atlanta.example.com 1524 CSeq: 2 BYE 1525 Content-Length: 0 1526 /* Alice sends a BYE and terminates a session and dialog. */ 1528 F6 200 OK Bob -> Alice 1530 SIP/2.0 200 OK 1531 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 1532 ;received=192.0.2.201 1533 From: Alice ;tag=9fxced76sl 1534 To: Bob ;tag=8321234356 1535 Call-ID: 3848276298220188511@atlanta.example.com 1536 CSeq: 2 BYE 1537 Content-Length: 0 1539 3.3 Other race condition 1541 Here, examples in race condition that doesn't relate directly 1542 to the dialog state transition are shown. In this section, it 1543 is shown that how to treat the race condition which generated 1544 when UAs treat "What is established by SIP" which related 1545 closely with dialog. 1547 3.3.1 re-INVITE crossover 1549 Alice Bob 1550 | | 1551 | INVITE F1 | 1552 |--------------------------->| 1553 | 180 Ringing F2 | 1554 |<---------------------------| 1555 | | 1556 | 200 OK F3 | 1557 |<---------------------------| 1558 | ACK F4 | 1559 |--------------------------->| 1560 | Both Way RTP Media | 1561 |<==========================>| 1562 | | 1563 |re-INVITE F5 re-INVITE F6 | 1564 |------------ -------------| 1565 | \ / | 1566 | X | 1567 | / \ | 1568 |<----------- ------------>| 1569 | 491 F8 491 F7 | 1570 |------------ -------------| 1571 | \ / | 1572 | X | 1573 | / \ | 1574 |<----------- ------------>| 1575 | ^ ACK F9 ^ ACK F10| 1576 |--|--------- ----|--------| 1577 | | \ / | | 1578 | | X | | 1579 | | / \ | | 1580 |<-|---------- ---|------->| 1581 | | | | 1582 | |0-2.0 sec | | 1583 | | | | 1584 | v re-INVITE(=F6) F11 | 1585 |<------------------|--------| 1586 | 200 OK F12 | | 1587 |-------------------|------->| 1588 | ACK F13 | | 1589 |<------------------|--------| 1590 | | | 1591 | |2.1-4.0 sec 1592 | | | 1593 |re-INVITE(=F5) F14 v | 1594 |--------------------------->| 1595 | 200 OK F15 | 1596 |<---------------------------| 1597 | ACK F16 | 1598 |--------------------------->| 1599 | | 1600 | | 1602 In this scenario, Alice and Bob send a re-INVITE at the same 1603 time. When two re-INVITEs cross in the same dialog, they resend 1604 re-INVITEs after different intervals. (RFC3261, 14.1) When Alice 1605 sends an initial INVITE, an INVITE will be sent again after 1606 2.1-4.0 seconds because she generated the Call-ID (owner of the 1607 Call-ID). Bob will send an INVITE again after 0.0-2.0 seconds, 1608 because Bob isn't the owner of the Call-ID. Therefore, each user 1609 agent must remember whether they has generated the Call-ID of the 1610 dialog or not, in case INVITEs may be crossed by another INVITE. 1611 In this example, Alice's re-INVITE is for session modification 1612 and Bob's re-INVITE is for session refresh. In this case, after 1613 the 491 responses, Bob retransmits re-INVITE for session refresh 1614 earlier than Alice. If Alice was to retransmit her re-INVITE (that 1615 is, if she was not the owner of Call-ID), the request would refresh 1616 and modify the session at the same time. Then Bob would know that 1617 he would not need to retransmit his re-INVITE to refresh the session. 1618 In another instance where two re-INVITEs for session modification 1619 cross over, retransmitting the same re-INVITE again after 491 by the 1620 Call-ID holder (the UA which retransmits his re-INVITE after the 1621 other UA) may result in a behavior different from what the user 1622 originally intended to, so the UA needs to decide if the 1623 retransmission of re-INVITE is necessary. 1624 (For example, when a call hold and an addition of video cross over, 1625 mere retransmission of the re-INVITE at the firing of the timer may 1626 result in the situation where the video is transmitted immediately 1627 after the holding of the audio. This behavior is probably not 1628 intended by the users.) 1630 Message Details 1632 F1 INVITE Alice -> Bob 1634 F2 180 Ringing Bob -> Alice 1636 F3 200 OK Bob -> Alice 1638 F4 ACK Alice -> Bob 1640 F5 re-INVITE Alice -> Bob 1642 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1643 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1644 Max-Forwards: 70 1645 From: Alice ;tag=9fxced76sl 1646 To: Bob ;tag=8321234356 1647 Call-ID: 3848276298220188511@atlanta.example.com 1648 CSeq: 2 INVITE 1649 Content-Length: 147 1651 v=0 1652 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1653 s=- 1654 c=IN IP4 192.0.2.101 1655 t=0 0 1656 m=audio 49172 RTP/AVP 0 1657 a=rtpmap:0 PCMU/8000 1658 a=sendonly 1660 /* re-INVITE for session modification. (a=sendrecv -> sendonly) */ 1662 F6 re-INVITE Bob -> Alice 1664 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1665 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1666 Session-Expires: 300;refresher=uac 1667 Supported: timer 1668 Max-Forwards: 70 1669 From: Bob ;tag=8321234356 1670 To: Alice ;tag=9fxced76sl 1671 Call-ID: 3848276298220188511@atlanta.example.com 1672 CSeq: 1 INVITE 1673 Content-Length: 0 1675 /* A case where a re-INVITE for a session refresh and a re-INVITE for 1676 hold are sent at the same time. */ 1678 F7 491 Request Pending Bob -> Alice 1679 /* Since an INVITE is in progress, a 491 response are returned. */ 1681 F8 491 Request Pending Alice -> Bob 1683 F9 ACK (INVITE) Alice -> Bob 1685 F10 ACK (INVITE) Bob -> Alice 1687 F11 re-INVITE Bob -> Alice 1689 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1690 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1 1691 Session-Expires: 300;refresher=uac 1692 Supported: timer 1693 Max-Forwards: 70 1694 From: Bob ;tag=8321234356 1695 To: Alice ;tag=9fxced76sl 1696 Call-ID: 3848276298220188511@atlanta.example.com 1697 CSeq: 2 INVITE 1698 Content-Type: application/sdp 1699 Content-Length: 133 1701 v=0 1702 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1703 s=- 1704 c=IN IP4 192.0.2.201 1705 t=0 0 1706 m=audio 3456 RTP/AVP 0 1707 a=rtpmap:0 PCMU/8000 1709 /* Since Bob is not the owner of Call-ID, Bob sends an INVITE again 1710 after 0.0-2.0 seconds. */ 1712 F12 200 OK Alice -> Bob 1714 F13 ACK Bob -> Alice 1716 F14 re-INVITE Alice -> Bob 1717 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 1718 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 1719 Max-Forwards: 70 1720 From: Alice ;tag=9fxced76sl 1721 To: Bob ;tag=8321234356 1722 Call-ID: 3848276298220188511@atlanta.example.com 1723 CSeq: 3 INVITE 1724 Content-Length: 147 1726 v=0 1727 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1728 s=- 1729 c=IN IP4 192.0.2.101 1730 t=0 0 1731 m=audio 49172 RTP/AVP 0 1732 a=rtpmap:0 PCMU/8000 1733 a=sendonly 1735 /* Since Alice is the owner of Call-ID, Alice sends an INVITE again 1736 after 2.1-4.0 seconds. */ 1738 F15 200 OK Bob -> Alice 1740 F16 ACK Alice -> Bob 1742 3.3.2 UPDATE and re-INVITE crossover 1744 Alice Bob 1745 | | 1746 | INVITE F1 | 1747 |--------------------------->| 1748 | 180 Ringing F2 | 1749 |<---------------------------| 1750 | | 1751 | 200 OK F3 | 1752 |<---------------------------| 1753 | ACK F4 | 1754 |--------------------------->| 1755 | Both Way RTP Media | 1756 |<==========================>| 1757 | | 1758 | UPDATE F5 re-INVITE F6 | 1759 |------------ -------------| 1760 | \ / | 1761 | X | 1762 | / \ | 1763 |<----------- ------------>| 1764 | 491 F8 491 F7 | 1765 |------------ -------------| 1766 | \ / | 1767 | X | 1768 | / \ | 1769 |<----------- ------------>| 1770 | ^ ACK F9 ^ | 1771 |<-|----------------|--------| 1772 | | | | 1773 | |0-2.0 sec | | 1774 | | | | 1775 | v re-INVITE F10 | | 1776 |<------------------|--------| 1777 | 200 OK F11 | | 1778 |-------------------|------->| 1779 | ACK F12 | | 1780 |<------------------|--------| 1781 | | | 1782 | |2.1-4.0 sec 1783 | | | 1784 | UPDATE F13 v | 1785 |--------------------------->| 1786 | 200 OK F14 | 1787 |<---------------------------| 1788 | | 1789 | | 1791 In this scenario, the UPDATE contains SDP offer, therefore UPDATE 1792 and re-INVITE are returned error response (491) as in the case of 1793 "re-INVITE crossover". When an UPDATE for refresher which doesn't 1794 contain a session description and the re-INVITE crossed each 1795 other, both request don't fail by 491 and succeed with 200 because 1796 491 means that UA have a pending request. Moreover, the same is 1797 equally true of UPDATE crossover, in case that either UPDATE 1798 contains a session description fail with 491, other cases 1799 succeed with 200. 1801 Editor's Note: 1802 A 491 response is considered a result that UA judged the 1803 effectiveness of request to "What is established by SIP". 1804 Therefore, it is considered that 491 will be used in all the 1805 requests that demand operation to "What is established by SIP". 1807 Message Details 1809 F1 INVITE Alice -> Bob 1811 F2 180 Ringing Bob -> Alice 1812 F3 200 OK Bob -> Alice 1814 F4 ACK Alice -> Bob 1816 F5 UPDATE Alice -> Bob 1818 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1819 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1820 Max-Forwards: 70 1821 From: Alice ;tag=9fxced76sl 1822 To: Bob ;tag=8321234356 1823 Call-ID: 3848276298220188511@atlanta.example.com 1824 CSeq: 2 UPDATE 1825 Content-Length: 147 1827 v=0 1828 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1829 s=- 1830 c=IN IP4 192.0.2.101 1831 t=0 0 1832 m=audio 49172 RTP/AVP 0 1833 a=rtpmap:0 PCMU/8000 1834 a=sendonly 1836 F6 re-INVITE Bob -> Alice 1838 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1839 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1840 Session-Expires: 300;refresher=uac 1841 Supported: timer 1842 Max-Forwards: 70 1843 From: Bob ;tag=8321234356 1844 To: Alice ;tag=9fxced76sl 1845 Call-ID: 3848276298220188511@atlanta.example.com 1846 CSeq: 1 INVITE 1847 Content-Length: 0 1849 /* A case where a re-INVITE for a session refresh and a re-INVITE for 1850 hold are sent at the same time. */ 1852 F7 491 Request Pending Bob -> Alice 1853 /* Since an INVITE is in process, a 491 response are returned. */ 1855 F8 491 Request Pending Alice -> Bob 1857 F9 ACK (re-INVITE) Alice -> Bob 1859 F10 re-INVITE Bob -> Alice 1860 INVITE sip:alice@client.atlanta.example.com SIP/2.0 1861 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1 1862 Session-Expires: 300;refresher=uac 1863 Supported: timer 1864 Max-Forwards: 70 1865 From: Bob ;tag=8321234356 1866 To: Alice ;tag=9fxced76sl 1867 Call-ID: 3848276298220188511@atlanta.example.com 1868 CSeq: 2 INVITE 1869 Content-Type: application/sdp 1870 Content-Length: 133 1872 v=0 1873 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 1874 s=- 1875 c=IN IP4 192.0.2.201 1876 t=0 0 1877 m=audio 3456 RTP/AVP 0 1878 a=rtpmap:0 PCMU/8000 1880 /* Since Bob is not the owner of Call-ID, Bob sends an INVITE again 1881 after 0.0-2.0 seconds. */ 1883 F11 200 OK Alice -> Bob 1885 F12 ACK Bob -> Alice 1887 F13 UPDATE Alice -> Bob 1889 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 1890 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 1891 Max-Forwards: 70 1892 From: Alice ;tag=9fxced76sl 1893 To: Bob ;tag=8321234356 1894 Call-ID: 3848276298220188511@atlanta.example.com 1895 CSeq: 3 UPDATE 1896 Content-Length: 147 1898 v=0 1899 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com 1900 s=- 1901 c=IN IP4 192.0.2.101 1902 t=0 0 1903 m=audio 49172 RTP/AVP 0 1904 a=rtpmap:0 PCMU/8000 1905 a=sendonly 1907 /* Since Alice is the owner of Call-ID, Alice sends an INVITE again 1908 after 2.1-4.0 seconds. */ 1910 F14 200 OK Bob -> Alice 1912 3.3.3 Receiving REFER (Establish state) 1913 in Mortal state 1915 State Alice Bob State 1916 | | 1917 | INVITE F1 | 1918 Pre |----------------------->| Pre 1919 | 180 Ringing F2 | 1920 Ear |<-----------------------| Ear 1921 | | 1922 | 200 OK F3 | 1923 Mora |<-----------------------| Mora 1924 | ACK F4 | 1925 Est |----------------------->| Est 1926 | Both Way RTP Media | 1927 |<======================>| 1928 | | 1929 | BYE F5 REFER F6 | 1930 Mort |--------- ----------| 1931 | \ / | 1932 | X | 1933 | / \ | 1934 *race* |<-------- --------->| Mort 1935 | | 1936 | 481 F8 200 F7 | 1937 |--------- ----------| 1938 | \ / ^ | 1939 | X | | 1940 | / \ | | 1941 |<-------- --------->| 1942 | ^ | | 1943 | | Timer K | | 1944 | V | | 1945 Morg | Timer J | | 1946 | V | 1947 | | Morg 1948 | | 1950 This scenario illustrates the race condition which occurs when 1951 UAS receives an Established message (REFER) in Mortal state. 1952 Bob sends a REFER, and Alice sends a BYE at the same time. Bob 1953 send a REFER in the same dialog. Alice sends an error response 1954 to request like a REFER which operates the session, because, 1955 by sending a BYE, Alice had terminated the session which would 1956 have corresponded to the REFER. For handling of dialogs with 1957 multiple usages, as can be seen in the use of REFER method, 1958 see the draft on dialog usage [8]. 1960 Message Details 1962 F1 INVITE Alice -> Bob 1964 F2 180 Ringing Bob -> Alice 1966 F3 200 OK Bob -> Alice 1968 F4 ACK Alice -> Bob 1970 F5 BYE Alice -> Bob 1971 /* Alice sends a BYE and terminates a session, and transits from 1972 Confirmed state to Terminnated state. */ 1974 F6 REFER Bob -> Alice 1976 REFER sip:alice@client.atlanta.example.com SIP/2.0 1977 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 1978 Max-Forwards: 70 1979 From: Bob ;tag=8321234356 1980 To: Alice ;tag=9fxced76sl 1981 Call-ID: 3848276298220188511@atlanta.example.com 1982 Refer-To: sip:carol@cleveland.example.org 1983 Contact: 1984 CSeq: 1 REFER 1985 Content-Length: 0 1987 /* Alice sends a BYE, and Bob sends a REFER at the same time. 1988 Bob sends a REFER on the INVITE dialog. 1989 The state of dialog transits to Mortal state at the moment 1990 Alice sends a BYE, but Bob doesn't know it until he receives 1991 the BYE. A race condition occurs. */ 1993 F7 200 OK Bob -> Alice 1995 F8 481 Call/Transaction Does Not Exist Alice -> Bob 1996 /* Since Alice is terminated the session, she responds with a 481 1997 to the REFER. */ 1999 Appendix A - BYE on the Early Dialog 2001 This section, related to 3.1.3, explains why BYE is not recommended 2002 in Early state, illustrating the case in which BYE in Early dialog 2003 triggers confusion. 2005 Alice Proxy Bob Carol 2006 | | | | 2007 | INVITE F1 | | | 2008 |--------------->| INVITE F2 | | 2009 | 100 F3 |----------------->| | 2010 |<---------------| 180(To-tag=1) F4 | | 2011 | 180(1) F5 |<-----------------| | 2012 |<---------------| | | 2013 | | INVITE(Fork) F6 | 2014 | |------------------------>| 2015 | | 100 F7 | 2016 | BYE(1) F8 |<------------------------| 2017 |--------------->| BYE(1) F9 | | 2018 | |----------------->| | 2019 | | 200(1) F10 | | 2020 | 200(1) F11 |<-----------------| | 2021 |<---------------| 487(1) F12 | | 2022 | |<-----------------| | 2023 | | ACK(1) F13 | | 2024 | |----------------->| | 2025 | | | | 2026 | | | 2027 | | 200(To-tag=2) F13 | 2028 | 200(2) F14 |<------------------------| 2029 |<---------------| | 2030 | ACK(2) F15 | | 2031 |--------------->| ACK(2) F16 | 2032 | |------------------------>| 2033 | BYE(2) F17 | | 2034 |--------------->| BYE(2) F18 | 2035 | |------------------------>| 2036 | | 200(2) F19 | 2037 | 200(2) F20 |<------------------------| 2038 |<---------------| | 2039 | | | 2040 | | | 2042 Care is advised in sending of BYE in Early state 2043 when a proxy may fork. In the example, the BYE request 2044 progresses normally, and it succeeds in correctly terminating 2045 the dialog with Bob. After Bob terminates the dialog by 2046 sending BYE, he sends 487 to the ini-INVITE. According to 2047 Section 15.1.2 of RFC3261 [1], it is RECOMMENDED for UAS to 2048 generate 487 to any pending requests after receiving BYE. 2049 In the example, Bob sends 487 to ini-INVITE since he receives 2050 BYE with the ini-INVITE in pending state. 2052 However, Alice receives a final response for INVITE (a 200 2053 from Carol) even though she has successfully terminated the 2054 dialog with Bob. This means that, regardless of the success/ 2055 failure of the BYE in Early state, Alice MUST be prepared for 2056 the establishment of a new dialog until receiving the final 2057 response for the INVITE and terminating the INVITE transaction. 2059 The choice of BYE or CANCEL in the early state must be made 2060 carefully. CANCEL is appropriate when the goal is to abandon 2061 the call attempt entirely. BYE is appropriate when the goal is 2062 to abandon a particular early dialog while allowing the call 2063 to be completed to other destinations. When using either BYE 2064 or CANCEL the UAC must be prepared for the possibility that 2065 a call may still be established to one (or more) destinations. 2067 Appendix B - BYE request overlapped on re-INVITE 2069 UAC UAS 2070 | | 2071 The session has been already established 2072 ========================== 2073 | F1 re-INVITE | 2074 |--------------------->| 2075 | F2 BYE | 2076 |--------------------->| 2077 | F3 200(BYE) | 2078 |<---------------------| 2079 | F4 INVITE(=F1) | 2080 |--------------------->| 2081 | | 2082 | | 2084 This case could look similar to the one in 3.2.3. However, it is 2085 not a race condition but the behavior where there is no response 2086 for INVITE for some reasons. The appendix explains the behavior 2087 in this case and its rationale behind, since this case is likely 2088 to cause confusion. 2089 First of all, it is important not to confuse the behavior of the 2090 transaction layer and that of the dialog layer. RFC3261 details 2091 the Transaction layer behavior, and this document explains the 2092 dialog layer behavior. It has to be noted that these behaviors are 2093 independent of each other, even though the both layers transit 2094 their states triggered by sending or receiving of the same SIP 2095 messages (A dialog can be terminated even though a transaction is 2096 still remaining, and vice versa). 2097 In the sequence above, there is no response for F1, and F2 (BYE) 2098 is sent immediately after F1 (F1 is a mid-dialog request. If F1 2099 was ini-INVITE, BYE could not be sent before UAC received a 2100 provisional response with To-tag for the request). 2102 Below is a figure which illustrates UAC's dialog state and 2103 transaction state. 2105 BYE INV dialog UAC UAS 2106 : | | 2107 : | | 2108 | | F1 re-INVITE | 2109 o | |--------------------->| 2110 | | | F2 BYE | 2111 o | (Mortal) |--------------------->| 2112 | | | | F3 200(BYE) | 2113 | | | |<---------------------| 2114 | | | | F4 INVITE(=F1) | 2115 | | | |--------------------->| 2116 | | | | F5 481(INV) | 2117 | | | |<---------------------| 2118 | | | | F6 ACK(INV) | 2119 | | | |--------------------->| 2120 | | | | | 2121 o | o | | 2122 | | | 2123 o | | 2124 | | 2126 For UAC, the INVITE client transaction begins at the point F1 is 2127 sent. The UAC sends BYE (F2) immediately after F1. This is a 2128 legitimate behavior. (Usually the usage of each SIP method is 2129 independent, for BYE and others. However, it should be noted that 2130 it is prohibited to send a request with a SDP offer while the 2131 previous offer is in progress.) 2132 After that, F2 triggers the BYE client transaction. At the same 2133 time, the dialog state transits to the Mortal state and since 2134 then only a BYE or its response can be handled. 2135 It is permitted to send F4 (a retransmission of INVITE) in the 2136 Mortal state, because the retransmission of F1 is handled by the 2137 transaction layer, and the INVITE transaction has not yet 2138 transited to the Terminated state. As it is mentioned above, the 2139 dialog and the transaction behave independently each other. 2140 Therefore the transaction handling has to be continued even though 2141 the dialog moved to the Terminated state. 2143 Next, UAS's state is shown below. 2145 UAC UAS dialog INV BYE 2146 | | : 2147 | | : 2148 | F1 re-INVITE | | 2149 |-------------->x | | 2150 | F2 BYE | | 2151 |--------------------->| (Mortal) o 2152 | F3 200(BYE) | | | 2153 |<---------------------| | |<-Start TimerJ 2154 | F4 INVITE(=F1) | | | 2155 |--------------------->| | o | 2156 | F5 4xx(INV) | o | o 2157 |<---------------------| | 2158 | F6 ACK(INV) | | 2159 |--------------------->| |<-Start TimerI 2160 | | | 2161 | | | 2162 | | o 2163 | | 2165 For UAS, it can be regarded that F1 packet is lost or delayed. 2166 (Here the behavior is explained for the case UAS receives F2 BYE 2167 before F1 INVITE) Therefore, F2 triggers the BYE transaction for 2168 UAS, and simultaneously the dialog moves to the Mortal state. 2169 Then, upon the reception of F4 the INVITE server transaction begins. 2170 (It is allowed to start the INVITE server transaction in the Mortal 2171 state. The INVITE server transaction begins for handling received 2172 SIP request regardless of dialog state.) 2173 UAS's TU sends an appropriate error response (probably 481) for F4 2174 INVITE, because the TU knows that the dialog which matches to the 2175 INVITE is in the Terminated state. 2176 (It is mentioned above that F4 (and F1) INVITE is a mid-dialog 2177 request. Mid-dialog requests have a To-tag. It should be noted that 2178 UAS's TU does not begin a new dialog upon the reception of INVITE 2179 with a To-tag.) 2181 Appendix C - UA's behaviour for CANCEL 2183 This section explains the CANCEL and the Expires header behaviors 2184 which indirectly involve in the dialog state transition in the Early 2185 state. CANCEL does not have any influence on UAC's dialog state. 2186 However, the request has indirect influence on the dialog state 2187 transition because it has a significant effect on ini-INVITE. 2188 Similarly, the Expires header does not have direct influence on the 2189 dialog state transition, but it indirectly affect the state 2190 transition because its expiration triggers the sending of CANCEL. 2191 For UAS the CANCEL request and the Expires header timeout have more 2192 direct effects on the dialog than the sending of CANCEL by UAC, 2193 because they can be a trigger to send the 487 response. The figure3 2194 explains UAS's behavior in the Early state. This flow diagram is 2195 only explanatory figure, and the actual dialog state transition is 2196 as illustrated in Figure 1, 2. 2198 In the flow, full lines are related to dialog state transition, and 2199 dotted lines are involved with CANCEL. (r) represents the reception 2200 of signals, and (s) means sending. There is no dialog state for 2201 CANCEL, but here the Cancelled state is virtually handled just for 2202 the ease of understanding of UA's behavior when it sends and 2203 receives CANCEL. 2205 Next, UAS's flow is explained. 2207 +------------+ 2208 | Proceeding |----+ 2209 +------------+ | 2210 : | 1xx(s) | 2211 : V | 2212 : +-------+ | 2xx(s) 2213 : | Early |-----+------+ 2214 : +-------+ | 2215 : : V 2216 : : +-----------+ 2217 : : | Confirmed |<... 2218 :.....: +-----------+ : 2219 : | : : 2220 : BYE(r)| : : 2221 : CANCEL(r) | :.......: 2222 V | CANCEL(r) 2223 ............. | 2224 : Cancelled : | 2225 :...........: | 2226 | 487(s) | 2227 | | 2228 +--------------------+ 2229 | 2230 V 2231 +------------+ 2232 | Terminated | 2233 +------------+ 2235 figure 3. CANCEL flow diagram for UAS 2237 There are two cases for UAS depending on the state when it receives 2238 CANCEL. 2239 One is when UAS receives CANCEL in the Proceeding and Early states. 2240 In this case the UAS immediately sends 487 for the INVITE, and the 2241 dialog transits to the Terminated state. 2242 The other is the case in which UAS receives CANCEL in the Confirmed 2243 state. In this case the dialog state transition does not occur 2244 because UAS has already sent the final response for the INVITE to 2245 which the CANCEL is targeted. 2246 (Note that, from the point of UAC's behavior, it can be expected 2247 that UAS receives BYE immediately after the reception of CANCEL and 2248 moves to the Terminated state. However, the UAS's state does not 2249 transit until it actually receives BYE.) 2251 Appendix D - Notes on the request in Mortal state 2253 This section describes UA's behavior in the Mortal state which 2254 need careful attention. 2255 In the Mortal state, only a BYE or its response can be handled, and 2256 no other messages can be received. However, sending of ACK and the 2257 authentication procedure for BYE are conducted in this state. 2259 ACK for error responses is handled by the transactiuon layer, so the 2260 handling is not related to the dialog state. Unlike ACK for error 2261 responses, ACK for 2xx responses is a request newly generated by TU. 2262 However, the ACK for 2xx and the one for error responses are both a 2263 part of the INVITE transaction, even though their hadlings differ. 2264 (Section 17.1.1.1 of RFC3261 [1]) 2265 Therefore, the INVITE transaction is completed by three-way 2266 handshake, which includes ACK, even in the Mortal state. 2268 BYE authentication procedure shall be processed in the Mortal state. 2269 When anthentication is requested by 401 or 407 response, UAC resends 2270 BYE with an appropriate certificate. Also UAS handles the 2271 retransmission of the BYE which it requested anthentication itself. 2273 References 2275 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2276 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2277 Session Initiation Protocol", RFC 3261, June 2002. 2279 [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2280 SDP", RFC 3264, April 2002. 2282 [3] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 2283 Summers, "Session Initiation Protocol (SIP) Basic Call Flow 2284 Examples", BCP 75, RFC 3665, December 2003. 2286 [4] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 2287 Summers, "Session Initiation Protocol (SIP) Public Switched 2288 Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December 2289 2003. 2291 [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2292 Method", RFC 3515, April 2003. 2294 [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 2295 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 2296 June 2002. 2298 [7] Rosenberg, J., Schulzrinne, H., Mahy, R., "An INVITE-Initiated 2299 Dialog Event Package for the Session Initiation Protocol (SIP)", 2300 RFC 4235, November 2005. 2302 [8] Sparks, R., "Multiple Dialog Usages in the Session Initiation 2303 Protocol", draft-ietf-sipping-dialogusage-03 (work in progress), 2304 August 29, 2006. 2306 Author's Addresses 2308 All listed authors actively contributed large amounts of text to this 2309 document. 2311 Miki Hasebe 2312 NTT-east Corporation 2313 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2315 EMail: hasebe.miki@east.ntt.co.jp 2317 Jun Koshiko 2318 NTT-east Corporation 2319 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2321 EMail: j.koshiko@east.ntt.co.jp 2323 Yasushi Suzuki 2324 NTT-east Corporation 2325 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2327 EMail: suzuki.yasushi@east.ntt.co.jp 2329 Tomoyuki Yoshikawa 2330 NTT-east Corporation 2331 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 2333 EMail: tomoyuki.yoshikawa@east.ntt.co.jp 2334 Paul H. Kyzivat 2335 Cisco Systems, Inc. 2336 1414 Massachusetts Avenue 2337 Boxborough, MA 01719 2338 USA 2340 Email: pkyzivat@cisco.com 2342 Intellectual Property Statement 2344 The IETF takes no position regarding the validity or scope of any 2345 Intellectual Property Rights or other rights that might be claimed to 2346 pertain to the implementation or use of the technology described in 2347 this document or the extent to which any license under such rights 2348 might or might not be available; nor does it represent that it has 2349 made any independent effort to identify any such rights. Information 2350 on the procedures with respect to rights in RFC documents can be 2351 found in BCP 78 and BCP 79. 2353 Copies of IPR disclosures made to the IETF Secretariat and any 2354 assurances of licenses to be made available, or the result of an 2355 attempt made to obtain a general license or permission for the use of 2356 such proprietary rights by implementors or users of this 2357 specification can be obtained from the IETF on-line IPR repository at 2358 http://www.ietf.org/ipr. 2360 The IETF invites any interested party to bring to its attention any 2361 copyrights, patents or patent applications, or other proprietary 2362 rights that may cover technology that may be required to implement 2363 this standard. Please address the information to the IETF at 2364 ietf-ipr@ietf.org. 2366 Disclaimer of Validity 2368 This document and the information contained herein are provided on an 2369 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2370 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2371 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2372 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2373 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2376 Copyright Statement 2378 Copyright (C) The Internet Society (2006). This document is subject 2379 to the rights, licenses and restrictions contained in BCP 78, and 2380 except as set forth therein, the authors retain all their rights. 2382 Acknowledgment 2384 Funding for the RFC Editor function is currently provided by the 2385 Internet Society.