GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp147

Network Working Group M. Hasebe Request for Comments: 5407 J. Koshiko BCP: 147 NTT-east Corporation Category: Best Current Practice Y. Suzuki

                                                       NTT Corporation
                                                          T. Yoshikawa
                                                  NTT-east Corporation
                                                            P. Kyzivat
                                                   Cisco Systems, Inc.
                                                         December 2008
            Example Call Flows of Race Conditions in the
                 Session Initiation Protocol (SIP)

Status of This Memo

 This document specifies an Internet Best Current Practices for the
 Internet Community, and requests discussion and suggestions for
 improvements.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (c) 2008 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents (http://trustee.ietf.org/
 license-info) in effect on the date of publication of this document.
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.

Abstract

 This document gives example call flows of race conditions in the
 Session Initiation Protocol (SIP).  Race conditions are inherently
 confusing and difficult to thwart; this document shows the best
 practices to handle them.  The elements in these call flows include
 SIP User Agents and SIP Proxy Servers.  Call flow diagrams and
 message details are given.

Hasebe, et al. Best Current Practice [Page 1] RFC 5407 Example Call Flows of Race Conditions December 2008

Table of Contents

 1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  General Assumptions  . . . . . . . . . . . . . . . . . . .  3
   1.2.  Legend for Message Flows . . . . . . . . . . . . . . . . .  3
   1.3.  SIP Protocol Assumptions . . . . . . . . . . . . . . . . .  4
 2.  The Dialog State Machine for INVITE Dialog Usage . . . . . . .  5
 3.  Race Conditions  . . . . . . . . . . . . . . . . . . . . . . . 10
   3.1.  Receiving Message in the Moratorium State  . . . . . . . . 11
     3.1.1.  Callee Receives Initial INVITE Retransmission
             (Preparative State) While in the Moratorium State  . . 11
     3.1.2.  Callee Receives CANCEL (Early State) While in the
             Moratorium State . . . . . . . . . . . . . . . . . . . 13
     3.1.3.  Callee Receives BYE (Early State) While in the
             Moratorium State . . . . . . . . . . . . . . . . . . . 15
     3.1.4.  Callee Receives re-INVITE (Established State)
             While in the Moratorium State (Case 1) . . . . . . . . 17
     3.1.5.  Callee Receives re-INVITE (Established State)
             While in the Moratorium State (Case 2) . . . . . . . . 22
     3.1.6.  Callee Receives BYE (Established State) While in
             the Moratorium State . . . . . . . . . . . . . . . . . 26
   3.2.  Receiving Message in the Mortal State  . . . . . . . . . . 28
     3.2.1.  UA Receives BYE (Established State) While in the
             Mortal State . . . . . . . . . . . . . . . . . . . . . 28
     3.2.2.  UA Receives re-INVITE (Established State) While in
             the Mortal State . . . . . . . . . . . . . . . . . . . 30
     3.2.3.  UA Receives 200 OK for re-INVITE (Established
             State) While in the Mortal State . . . . . . . . . . . 32
     3.2.4.  Callee Receives ACK (Moratorium State) While in
             the Mortal State . . . . . . . . . . . . . . . . . . . 35
   3.3.  Other Race Conditions  . . . . . . . . . . . . . . . . . . 36
     3.3.1.  Re-INVITE Crossover  . . . . . . . . . . . . . . . . . 36
     3.3.2.  UPDATE and re-INVITE Crossover . . . . . . . . . . . . 40
     3.3.3.  Receiving REFER (Established State) While in the
             Mortal State . . . . . . . . . . . . . . . . . . . . . 45
 4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 46
 5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
 6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
   6.1.  Normative References . . . . . . . . . . . . . . . . . . . 47
   6.2.  Informative References . . . . . . . . . . . . . . . . . . 47
 Appendix A.  BYE in the Early Dialog . . . . . . . . . . . . . . . 48
 Appendix B.  BYE Request Overlapping with re-INVITE  . . . . . . . 49
 Appendix C.  UA's Behavior for CANCEL  . . . . . . . . . . . . . . 52
 Appendix D.  Notes on the Request in the Mortal State  . . . . . . 54
 Appendix E.  Forking and Receiving New To Tags . . . . . . . . . . 54

Hasebe, et al. Best Current Practice [Page 2] RFC 5407 Example Call Flows of Race Conditions December 2008

1. Overview

 The call flows shown in this document were developed in the design of
 a SIP IP communications network.  These examples are of race
 conditions, which stem from transitions in dialog states -- mainly
 transitions during session establishment after the sending of an
 INVITE.
 When implementing SIP, various complex situations may arise.
 Therefore, it is helpful to provide implementors of the protocol with
 examples of recommended terminal and server behavior.
 This document clarifies SIP User Agent (UA) behaviors when messages
 cross each other as race conditions.  By clarifying the operation
 under race conditions, inconsistent interpretations between
 implementations are avoided and interoperability is expected to be
 promoted.
 It is the hope of the authors that this document will be useful for
 SIP implementors, designers, and protocol researchers and will help
 them achieve the goal of a standard implementation of RFC 3261 [1].
 These call flows are based on version 2.0 of SIP, defined in RFC 3261
 [1], with SDP usage as described in RFC 3264 [2].
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in BCP 14, RFC 2119 [3].

1.1. General Assumptions

 A number of architectural, network, and protocol assumptions underlie
 the call flows in this document.  Note that these assumptions are not
 requirements.  They are outlined in this section so that they may be
 taken into consideration and help understanding of the call flow
 examples.
 These flows do not assume specific underlying transport protocols
 such as TCP, TLS, and UDP.  See the discussion in RFC 3261 [1] for
 details of the transport issues for SIP.

1.2. Legend for Message Flows

 Dashed lines (---) and slash lines (/, \) represent signaling
 messages that are mandatory to the call scenario.  (X) represents the
 crossover of signaling messages. (->x, x<-) indicate that the packet
 is lost.  The arrow indicates the direction of message flow.  Double
 dashed lines (===) represent media paths between network elements.

Hasebe, et al. Best Current Practice [Page 3] RFC 5407 Example Call Flows of Race Conditions December 2008

 Messages are identified in the figures as F1, F2, etc.  These numbers
 are used for references to the message details that follow the
 figure.  Comments in the message details are shown in the following
 form:
 /* Comments.  */

1.3. SIP Protocol Assumptions

 This document does not prescribe the flows precisely as they are
 shown, but rather illustrates the principles for best practice.  They
 are best practice usages (orderings, syntax, selection of features
 for the purpose, or handling of errors) of SIP methods, headers, and
 parameters.  Note: The flows in this document must not be copied
 as-is by implementors because additional annotations have been
 incorporated into this document for ease of explanation.  To sum up,
 the procedures described in this document represent well-reviewed
 examples of SIP usage, which exemplify best common practice according
 to IETF consensus.
 For reasons of simplicity in reading and editing the document, there
 are a number of differences between some of the examples and actual
 SIP messages.  For instance, Call-IDs are often replicated, CSeq
 often begins at 1, header fields are usually shown in the same order,
 usually only the minimum required header field set is shown, and
 other headers that would usually be included, such as Accept, Allow,
 etc., are not shown.
 Actors:
 Element     Display Name  URI                            IP Address
 -------     ------------  ---                            ----------
 User Agent  Alice         sip:alice@atlanta.example.com  192.0.2.101
 User Agent  Bob           sip:bob@biloxi.example.com     192.0.2.201
 User Agent  Carol         sip:carol@chicago.example.com  192.0.2.202
 Proxy Server              ss.atlanta.example.com         192.0.2.111
 The term "session" is used in this document in the same way it is
 used in Sections 13-15 of RFC 3261 [1] (which differs somewhat from
 the definition of the term in RFC 3261).  RFC 5057 [6] introduces
 another term, "invite dialog usage", which is more precisely defined.
 The term "session" used herein is almost, but not quite, identical to
 the term "invite dialog usage".  The two have differing definitions
 of when the state ends -- the session ends earlier, when BYE is sent
 or received.

Hasebe, et al. Best Current Practice [Page 4] RFC 5407 Example Call Flows of Race Conditions December 2008

2. The Dialog State Machine for INVITE Dialog Usage

 Race conditions are generated when the dialog state of the receiving
 side differs from that of the sending side.
 For instance, a race condition occurs when a UAC (User Agent Client)
 sends a CANCEL in the Early state while the UAS (User Agent Server)
 is transitioning from the Early state to the Confirmed state by
 sending a 200 OK to an initial INVITE (indicated as "ini-INVITE"
 hereafter).  The DSM (dialog state machine) for the INVITE dialog
 usage is presented as follows to help understanding of the UA's
 behavior in race conditions.
 The DSM clarifies the UA's behavior by subdividing the dialog state
 shown in RFC 3261 [1] into various internal states.  We call the
 state before the establishment of a dialog the Preparative state.
 The Confirmed state is subdivided into two substates, the Moratorium
 and the Established states, and the Terminated state is subdivided
 into the Mortal and Morgue states.  Messages that are the triggers
 for the state transitions between these states are indicated with
 arrows.  In this figure, messages that are not related to state
 transition are omitted.
 Below are the DSMs, first for the caller and then for the callee.

Hasebe, et al. Best Current Practice [Page 5] RFC 5407 Example Call Flows of Race Conditions December 2008

  INV +-----------------------------------------------+
  --->|                 Preparative                   |
      +-----------------------------------------------+
        |                    |                      |
        | 3xx-6xx            | 1xx-tag              | 2xx
        |                    |                      |
        |                    |        1xx-tag       |
        |                    V        w/new tag     |
        |         +-----------------+  [new DSM]    |
        | 3xx-6xx |                 |   | (new DSM  |
        +<--------|      Early      |   |  instance |
        |         |                 |<--+  created) |
        |         +-----------------+               |
        |            |             |                |  2xx w/new tag
        |            | BYE         | 2xx            |   [new DSM]
        |            |             +------------>+<-+      | (new DSM
        |            |                           |         |  instance
  +-----C------------C-----+         +-----------C------+  |  created)
  |     | Terminated |     |         | Confirmed |      |  |
  |     |            +<----C---------|           |      |  |
  |     |            |     | BYE(sr) |           |      |  |
  |     |            V     |         |           V      |  |
  | 2xx |  +-----------+   |         |   +-----------+  |  |
  | +---C--|           |---C-+       |   |           |  |  |
  | |   |  |   Mortal  |   | | BYE(r)|   | Moratorium|<-C--+
  | +---C->|           |<--C-+       |   |           |  |
  | ACK |  +-----------+   |         |   +-----------+  |
  |     |    |             |         |         |        |
  |     |    | Timeout     |         |         | ACK    |
  |     |    |             |         |         |        |
  |     V    V             |         |         V        |
  |   +---------------+    |         |   +-----------+  |
  |   |               |    |         |   |           |--C-+
  |   |     Morgue    |    |         |   |Established|  | | 2xx,ACK
  |   |               |    |         |   |           |<-C-+
  |   +---------------+    |         |   +-----------+  |
  |                        |         |                  |
  +------------------------+         +------------------+
  (r): indicates that only reception is allowed.
       Where (r) is not used as an indicator, "response" means
       receive, and "request" means send.
  (sr): indicates that both sending and reception are allowed.
            Figure 1: DSM for INVITE dialog usage (caller)

Hasebe, et al. Best Current Practice [Page 6] RFC 5407 Example Call Flows of Race Conditions December 2008

 Figure 1 represents the caller's DSM for the INVITE dialog usage.
 The caller MAY send a BYE in the Early state, even though this
 behavior is not recommended.  A BYE sent in the Early state
 terminates the early dialog using a specific To tag.  That is, when a
 proxy is performing forking, the BYE is only able to terminate the
 early dialog with a particular UA.  If the caller wants to terminate
 all early dialogs instead of that with a particular UA, it needs to
 send CANCEL, not BYE.  However, it is not illegal to send BYE in the
 Early state to terminate a specific early dialog if this is the
 caller's intent.  Moreover, until the caller receives a final
 response and terminates the INVITE transaction, the caller MUST be
 prepared to establish a dialog by receiving a new response to the
 INVITE even if it has already sent a CANCEL or BYE and terminated the
 dialog (see Appendix A).

Hasebe, et al. Best Current Practice [Page 7] RFC 5407 Example Call Flows of Race Conditions December 2008

  INV +-----------------------------------------------+
  --->|                 Preparative                   |
      +-----------------------------------------------+
        |                         |                 |
        | 3xx-6xx                 | 1xx-tag         | 2xx
        |                         |                 |
        |                         V                 |
        |         +------------------+              |
        | 3xx-6xx |                  |              |
        +<--------|      Early       |              |
        |         |                  |              |
        |         +------------------+              |
        |            |             |                |
        |            |BYE/487(INV) | 2xx            |
        |            |             +------------>+<-+
        |            |                           |
  +-----C------------C-----+         +-----------C------+
  |     | Terminated |     |         | Confirmed |      |
  |     |            +<----C---------|           |      |
  |     |            |     | BYE(sr) |           |      |
  |     |            V     |         |           V      |
  |     | +------------+   |         |   +-----------+  |
  |     | |            |---C-+       |   |           |--C-+
  |     | |   Mortal   |   | | BYE   |   | Moratorium|  | | 2xx
  |     | |            |<--C-+       |   |           |<-C-+ if ACK not
  |     | +------------+   |         |   +-----------+  |   received
  |     |   |              |         |         |        |
  |     |   | Timeout      |         |         | ACK    |
  |     |   |              |         |         |        |
  |     V   V              |         |         V        |
  |   +---------------+    |         |   +-----------+  |
  |   |               |    |         |   |           |  |
  |   |     Morgue    |    |         |   |Established|  |
  |   |               |    |         |   |           |  |
  |   +---------------+    |         |   +-----------+  |
  |                        |         |                  |
  +------------------------+         +------------------+
   (sr): indicates that both sending and reception are allowed.
        Where (sr) is not used as an indicator, "response" means send,
        and "request" means receive.
            Figure 2: DSM for INVITE dialog usage (callee)
 Figure 2 represents the callee's DSM for the INVITE dialog usage.
 The figure does not illustrate the state transition related to CANCEL
 requests.  A CANCEL request does not cause a dialog state transition.
 However, the callee terminates the dialog and triggers the dialog

Hasebe, et al. Best Current Practice [Page 8] RFC 5407 Example Call Flows of Race Conditions December 2008

 transition by sending a 487 immediately after the reception of the
 CANCEL.  This behavior upon the reception of the CANCEL request is
 further explained in Appendix C.
 The UA's behavior in each state is as follows.
 Preparative (Pre):  The Preparative state is in effect until the
    early dialog is established by sending or receiving a provisional
    response with a To tag after an ini-INVITE is sent or received.
    The dialog does not yet exist in the Preparative state.  If the UA
    sends or receives a 2xx response, the dialog state transitions
    from the Preparative state to the Moratorium state, which is a
    substate of the Confirmed state.  In addition, if the UA sends or
    receives a 3xx-6xx response, the dialog state transitions to the
    Morgue state, which is a substate of the Terminated state.
    Sending an ACK for a 3xx-6xx response and retransmissions of 3xx-
    6xx are not shown on the DSMs because they are sent by the INVITE
    transaction.
 Early (Ear):  The early dialog is established by sending or receiving
    a provisional response except 100 Trying.  The early dialog exists
    even though the dialog does not exist in this state yet.  The
    dialog state transitions from the Early state to the Moratorium
    state, a substate of the Confirmed state, by sending or receiving
    a 2xx response.  In addition, the dialog state transitions to the
    Morgue state, a substate of the Terminated state, by sending or
    receiving a 3xx-6xx response.  Sending an ACK for a 3xx-6xx
    response and retransmissions of 3xx-6xx are not shown on this DSM
    because they are automatically processed on the transaction layer
    and don't influence the dialog state.  The UAC may send a CANCEL
    in the Early state.  The UAC may also send a BYE (although it is
    not recommended).  The UAS may send a 1xx-6xx response.  The
    sending or receiving of a CANCEL request does not have a direct
    influence on the dialog state.  The UA's behavior upon the
    reception of the CANCEL request is explained further in Appendix
    C.
 Confirmed (Con):  The sending or receiving of a 2xx final response
    establishes a dialog.  The dialog starts in this state.  The
    Confirmed state transitions to the Mortal state, a substate of the
    Terminated state, by sending or receiving a BYE request.  The
    Confirmed state has two substates, the Moratorium and the
    Established states, which are different with regard to the
    messages that UAs are allowed to send.

Hasebe, et al. Best Current Practice [Page 9] RFC 5407 Example Call Flows of Race Conditions December 2008

 Moratorium (Mora):  The Moratorium state is a substate of the
    Confirmed state and inherits its behavior.  The Moratorium state
    transitions to the Established state by sending or receiving an
    ACK request.  The UAC may send an ACK and the UAS may send a 2xx
    final response.
 Established (Est):  The Established state is a substate of the
    Confirmed state and inherits its behavior.  Both caller and callee
    may send various messages that influence a dialog.  The caller
    supports the transmission of ACK to the retransmission of a 2xx
    response to an ini-INVITE.
 Terminated (Ter):  The Terminated state is subdivided into two
    substates, the Mortal and Morgue states, to cover the behavior
    when a dialog is being terminated.  In this state, the UA holds
    information about the dialog that is being terminated.
 Mortal (Mort):  The caller and callee enter the Mortal state by
    sending or receiving a BYE.  The UA MUST NOT send any new requests
    within the dialog because there is no dialog.  (Here, the new
    requests do not include ACK for 2xx and BYE for 401 or 407, as
    further explained in Appendix D below.)  In the Mortal state, BYE
    can be accepted, and the other messages in the INVITE dialog usage
    are responded to with an error.  This addresses the case where a
    caller and a callee exchange reports about the session when it is
    being terminated.  Therefore, the UA possesses dialog information
    for internal processing but the dialog shouldn't be externally
    visible.  The UA stops managing its dialog state and changes it to
    the Morgue state when the BYE transaction is terminated.
 Morgue (Morg):  The dialog no longer exists in this state.  The
    sending or receiving of signaling that influences a dialog is not
    performed.  (A dialog is literally terminated.)  The caller and
    callee enter the Morgue state via the termination of the BYE or
    INVITE transaction.

3. Race Conditions

 This section details a race condition between two SIP UAs, Alice and
 Bob.  Alice (sip:alice@atlanta.example.com) and Bob
 (sip:bob@biloxi.example.com) are assumed to be SIP phones or SIP-
 enabled devices.  Only significant signaling is illustrated.  Dialog
 state transitions caused by the sending or receiving of SIP messages
 are shown, and race conditions are indicated by '*race*'.  (For
 abbreviations for the dialog state transitions, refer to Section 2.)
 '*race*' indicates the moment when a race condition occurs.
 Examples of race conditions are described below.

Hasebe, et al. Best Current Practice [Page 10] RFC 5407 Example Call Flows of Race Conditions December 2008

3.1. Receiving Message in the Moratorium State

 This section shows some examples of call flow race conditions when
 receiving messages from other states while in the Moratorium state.

3.1.1. Callee Receives Initial INVITE Retransmission (Preparative

      State) While in the Moratorium State
 State  Alice                               Bob  State
        |                                     |
        |            ini-INVITE F1            |
        |------------------------------------>|
   Pre  |         180 F2(Packet loss)         |  Pre
        |            x<-----------------------|
        |                                     |  Ear
        | ini-INVITE F4(=F1)           200 F3 |
        |------------------     --------------|
        |                   \ /               |  Mora
        |                    X                |
        |                   / \               |
        |<-----------------     ------------->|  *race*
  Mora  |                ACK F5               |
        |------------------------------------>|
   Est  |                                     |  Est
        |                                     |
 This scenario illustrates the race condition that occurs when the UAS
 receives a Preparative message while in the Moratorium state.  All
 provisional responses to the initial INVITE (ini-INVITE F1) are lost,
 and the UAC retransmits an ini-INVITE (F4).  At the same time as this
 retransmission, the UAS generates a 200 OK (F3) to the ini-INVITE and
 terminates the INVITE server transaction, according to Section
 13.3.1.4 of RFC 3261 [1].
 However, it is reported that terminating an INVITE server transaction
 when sending a 200 OK is an essential correction to SIP [7].
 Therefore, the INVITE server transaction is not terminated by F3, and
 F4 MUST be handled properly as a retransmission.
 In RFC 3261 [1], it is not specified whether the UAS retransmits 200
 to the retransmission of ini-INVITE.  Considering the retransmission
 of 200 triggered by a timer (the transaction user (TU) keeps
 retransmitting 200 based on T1 and T2 until it receives an ACK),
 according to Section 13.3.1.4 of RFC 3261 [1], it seems unnecessary
 to retransmit 200 when the UAS receives the retransmission of the
 ini-INVITE.  (For implementation, it does not matter if the UAS sends
 the retransmission of 200, since the 200 does not cause any problem.)

Hasebe, et al. Best Current Practice [Page 11] RFC 5407 Example Call Flows of Race Conditions December 2008

 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 /* 180 response is lost and does not reach Alice.  */
 F3 200 OK Bob -> Alice
 /* According to Section 13.3.1.4 of RFC 3261 [1], the INVITE server
    transaction is terminated at this point.  However, this has been
    reported as an essential correction to SIP, and the UAS MUST
    correctly recognize the ini-INVITE (F4) as a retransmission.  */
 F4 INVITE (retransmission) Alice -> Bob
 /* F4 is a retransmission of F1.  They are exactly the same INVITE
    request.  For UAs that have not dealt with the correction [7] (an
    INVITE server transaction is terminated when sending 200 to
    INVITE), this request does not match the transaction as well as
    the dialog since it does not have a To tag.  However, Bob must
    recognize the retransmitted INVITE correctly, without treating it
    as a new INVITE.  */
 F5 ACK Alice -> Bob

Hasebe, et al. Best Current Practice [Page 12] RFC 5407 Example Call Flows of Race Conditions December 2008

3.1.2. Callee Receives CANCEL (Early State) While in the Moratorium

      State
 State  Alice                        Bob  State
        |                              |
        |          INVITE F1           |
        |----------------------------->|
   Pre  |       180 Ringing F2         |  Pre
        |<-----------------------------|
   Ear  |                              |  Ear
        |CANCEL F3       200(INVITE) F4|
        |------------     -------------|
        |             \ /              |  Mora
        |              X               |
        |             / \              |
        |<-----------     ------------>|  *race*
  Mora  |                              |
        | ACK F6         200(CANCEL) F5|
        |------------     -------------|
   Est  |             \ /              |
        |              X               |
        |             / \              |
        |<-----------     ------------>|
        |                              |  Est
        |       One Way RTP Media      |
        | (Two Way RTP Media possible) |
        |<=============================|
        |            BYE F7            |
        |----------------------------->|
  Mort  |            200 F8            |  Mort
        |<-----------------------------|
        | ^                          ^ |
        | | Timer K                  | |
        | V                          | |
  Morg  |                    Timer J | |
        |                            V |
        |                              |  Morg
        |                              |
 This scenario illustrates the race condition that occurs when the UAS
 receives an Early message, CANCEL, while in the Moratorium state.
 Alice sends a CANCEL, and Bob sends a 200 OK response to the initial
 INVITE message at the same time.  As described in the previous
 section, according to RFC 3261 [1], an INVITE server transaction is
 supposed to be terminated by a 200 response, but this has been
 corrected in [7].

Hasebe, et al. Best Current Practice [Page 13] RFC 5407 Example Call Flows of Race Conditions December 2008

 This section describes a case in which an INVITE server transaction
 is not terminated by a 200 response to the INVITE request.  In this
 case, there is an INVITE transaction that the CANCEL request matches,
 so a 200 response to the request is sent.  This 200 response simply
 means that the next hop receives the CANCEL request (successful
 CANCEL (200) does not mean the INVITE was actually canceled).  When a
 UAS has not dealt with the correction [7], the UAC MAY receive a 481
 response to the CANCEL since there is no transaction that the CANCEL
 request matches.  This 481 simply means that there is no matching
 INVITE server transaction and CANCEL is not sent to the next hop.
 Regardless of the success/failure of the CANCEL, Alice checks the
 final response to the INVITE, and if she receives 200 to the INVITE
 request she immediately sends a BYE and terminates the dialog.  (See
 Section 15, RFC 3261 [1].)
 From the time F1 is received by Bob until the time that F8 is sent by
 Bob, media may be flowing one way from Bob to Alice.  From the time
 that an answer is received by Alice from Bob, there is the
 possibility that media may flow from Alice to Bob as well.  However,
 once Alice has decided to cancel the call, she presumably will not
 send media, so practically speaking the media stream will remain one
 way.
 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 CANCEL Alice -> Bob
 /* Alice sends a CANCEL in the Early state.  */
 F4 200 OK (INVITE) Bob -> Alice
 /* Alice receives a 200 to INVITE (F1) in the Moratorium state.
    Alice has the potential to send as well as receive media, but in
    practice will not send because there is an intent to end the
    call.  */
 F5 200 OK (CANCEL) Bob -> Alice
 /* 200 to CANCEL simply means that the CANCEL was received.  The 200
    response is sent, since this case assumes the correction [7] has
    been made.  If an INVITE server transaction is terminated
    according to the procedure stated in RFC 3261 [1], the UAC MAY
    receive a 481 response instead of 200.  */

Hasebe, et al. Best Current Practice [Page 14] RFC 5407 Example Call Flows of Race Conditions December 2008

 F6 ACK Alice -> Bob
 /* INVITE is successful, and the CANCEL becomes invalid.  Bob
    establishes RTP streams.  However, the next BYE request
    immediately terminates the dialog and session.  */
 F7 BYE Alice -> Bob
 F8 200 OK Bob -> Alice

3.1.3. Callee Receives BYE (Early State) While in the Moratorium State

 State  Alice                          Bob  State
        |                                |
        |         ini-INVITE F1          |
        |------------------------------->|
   Pre  |            180 F2              |  Pre
        |<-------------------------------|
   Ear  |                                |  Ear
        |    BYE F4        200(INVITE) F3|
        |-------------     --------------|
  Mort  |              \ /               |  Mora
        |               X                |
        |              / \               |
        |<------------     ------------->|  *race*
        |                                |  Mort
        |    ACK F5         200(BYE) F6  |
        |-------------     --------------|
        |              \ /            ^  |
        |               X             |  |
        |              / \            |  |
        |<------------     ------------->|
        | ^                           |  |
        | | Timer K                   |  |
        | V                           |  |
  Morg  |                     Timer J |  |
        |                             V  |
        |                                |  Morg
        |                                |
 This scenario illustrates the race condition that occurs when the UAS
 receives an Early message, BYE, while in the Moratorium state.  Alice
 sends a BYE in the Early state, and Bob sends a 200 OK to the initial
 INVITE request at the same time.  Bob receives the BYE in the
 Confirmed dialog state although Alice sent the request in the Early
 state (as explained in Section 2 and Appendix A, this behavior is not
 recommended).  When a proxy is performing forking, the BYE is only
 able to terminate the early dialog with a particular UA.  If the

Hasebe, et al. Best Current Practice [Page 15] RFC 5407 Example Call Flows of Race Conditions December 2008

 caller wants to terminate all early dialogs instead of only that with
 a particular UA, it needs to send CANCEL, not BYE.  However, it is
 not illegal to send BYE in the Early state to terminate a specific
 early dialog if that is the caller's intent.
 The BYE functions normally even if it is received after the INVITE
 transaction termination because BYE differs from CANCEL, and is sent
 not to the request but to the dialog.  Alice enters the Mortal state
 on sending the BYE request, and remains Mortal until the Timer K
 timeout occurs.  In the Mortal state, the UAC does not establish a
 session even though it receives a 200 response to the INVITE.  Even
 so, the UAC sends an ACK to 200 in order to complete the INVITE
 transaction.  The ACK is always sent to complete the three-way
 handshake of the INVITE transaction (further explained in Appendix D
 below).
 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 200 OK (ini-INVITE) Bob -> Alice
 F4 BYE Alice -> Bob
 /* Alice transitions to the Mortal state upon sending BYE.
    Therefore, after this, she does not begin a session even though
    she receives a 200 response with an answer.  */
 F5 ACK Alice -> Bob
 F6 200 OK (BYE) Bob -> Alice

Hasebe, et al. Best Current Practice [Page 16] RFC 5407 Example Call Flows of Race Conditions December 2008

3.1.4. Callee Receives re-INVITE (Established State) While in the

      Moratorium State (Case 1)
 State  Alice                          Bob  State
        |                                |
        |    ini-INVITE w/offer1 F1      |
        |------------------------------->|
   Pre  |             180 F2             |  Pre
        |<-------------------------------|
   Ear  |                                |  Ear
        |   200(ini-INV) w/answer1 F3    |
        |<-------------------------------|
  Mora  |       ACK F4(packet loss)      |  Mora
        |-------------------->x          |
   Est  |                                |
        | re-INVITE F6      200 F5(=F3)  |
        |   w/offer2         w/answer1   |
        |-------------     --------------|
        |              \ /               |
        |               X                |
        |              / \               |
        |<------------     ------------->|  *race*
        |                  200(re-INV) F8|
        | ACK F7(=F4)        w/answer2   |
        |-------------     --------------|
        |              \ /               |
        |               X                |
        |              / \               |
        |<------------     ------------->|
        |         ACK (re-INV) F9        |  Est
        |------------------------------->|
        |                                |
        |                                |
 This scenario illustrates the race condition that occurs when a UAS
 in the Moratorium state receives a re-INVITE sent by a UAC in the
 Established state.
 The UAS receives a re-INVITE (with offer2) before receiving an ACK
 for the ini-INVITE (with offer1).  The UAS sends a 200 OK (with
 answer2) to the re-INVITE (F8) because it has sent a 200 OK (with
 answer1) to the ini-INVITE (F3, F5) and the dialog has already been
 established.  (Because F5 is a retransmission of F3, SDP negotiation
 is not performed here.)
 As can be seen in Section 3.3.2 below, the 491 response seems to be
 closely related to session establishment, even in cases other than
 INVITE crossover.  This example recommends that 200 be sent instead

Hasebe, et al. Best Current Practice [Page 17] RFC 5407 Example Call Flows of Race Conditions December 2008

 of 491 because it does not have an influence on the session.
 However, a 491 response can also lead to the same outcome, so either
 response can be used.
 Moreover, if the UAS doesn't receive an ACK for a long time, it
 should send a BYE and terminate the dialog.  Note that ACK F7 has the
 same CSeq number as ini-INVITE F1 (see Section 13.2.2.4 of RFC 3261
 [1]).  The UA should not reject or drop the ACK on grounds of the
 CSeq number.
 Note: Implementation issues are outside the scope of this document,
 but the following tip is provided for avoiding race conditions of
 this type.  The caller can delay sending re-INVITE F6 for some period
 of time (2 seconds, perhaps), after which the caller can reasonably
 assume that its ACK has been received.  Implementors can decouple the
 actions of the user (e.g., pressing the hold button) from the actions
 of the protocol (the sending of re-INVITE F6), so that the UA can
 behave like this.  In this case, it is the implementor's choice as to
 how long to wait.  In most cases, such an implementation may be
 useful to prevent the type of race condition shown in this section.
 This document expresses no preference about whether or not they
 should wait for an ACK to be delivered.  After considering the impact
 on user experience, implementors should decide whether or not to wait
 for a while, because the user experience depends on the
 implementation and has no direct bearing on protocol behavior.
 Message Details
 F1 INVITE Alice -> Bob
 INVITE sip:bob@biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sip:alice@client.atlanta.example.com;transport=udp>
 Content-Type: application/sdp
 Content-Length: 137
 v=0
 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
 s=-
 c=IN IP4 192.0.2.101
 t=0 0
 m=audio 49172 RTP/AVP 0
 a=rtpmap:0 PCMU/8000

Hasebe, et al. Best Current Practice [Page 18] RFC 5407 Example Call Flows of Race Conditions December 2008

 /* Detailed messages are shown for the sequence to illustrate the
    offer and answer examples.  */
 F2 180 Ringing Bob -> Alice
 SIP/2.0 180 Ringing
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 ;received=192.0.2.101
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sip:bob@client.biloxi.example.com;transport=udp>
 Content-Length: 0
 F3 200 OK Bob -> Alice
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 ;received=192.0.2.101
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sip:bob@client.biloxi.example.com;transport=udp>
 Content-Type: application/sdp
 Content-Length: 133
 v=0
 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
 s=-
 c=IN IP4 192.0.2.201
 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 F4 ACK Alice -> Bob
 ACK sip:bob@client.biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 ACK
 Content-Length: 0

Hasebe, et al. Best Current Practice [Page 19] RFC 5407 Example Call Flows of Race Conditions December 2008

 /* The ACK request is lost.  */
 F5(=F3) 200 OK Bob -> Alice (retransmission)
 /* The UAS retransmits a 200 OK to the ini-INVITE since it has not
    received an ACK.  */
 F6 re-INVITE Alice -> Bob
 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 INVITE
 Content-Length: 147
 v=0
 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
 s=-
 c=IN IP4 192.0.2.101
 t=0 0
 m=audio 49172 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 a=sendonly
 F7(=F4) ACK Alice -> Bob (retransmission)
 /* "(=F4)" of ACK F7 shows that it is equivalent to F4 in that it is
    an ACK for F3.  This doesn't mean that F4 and F7 must be equal in
    Via-branch value.  Although it is ambiguous in RFC 3261 whether
    the Via-branch of ACK F7 differs from that of F4, it doesn't
    affect the UAS's behavior. */
 F8 200 OK (re-INVITE) Bob -> Alice
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 INVITE
 Content-Length: 143

Hasebe, et al. Best Current Practice [Page 20] RFC 5407 Example Call Flows of Race Conditions December 2008

 v=0
 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
 s=-
 c=IN IP4 192.0.2.201
 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 a=recvonly
 F9 ACK (re-INVITE) Alice -> Bob
 ACK sip:sip:bob@client.biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 ACK
 Content-Length: 0

Hasebe, et al. Best Current Practice [Page 21] RFC 5407 Example Call Flows of Race Conditions December 2008

3.1.5. Callee Receives re-INVITE (Established State) While in the

      Moratorium State (Case 2)
 State  Alice                          Bob  State
        |                                |
        |    ini-INVITE (no offer) F1    |
        |------------------------------->|
   Pre  |             180 F2             |  Pre
        |<-------------------------------|
   Ear  |                                |  Ear
        |    200(ini-INV) w/offer1 F3    |
        |<-------------------------------|
  Mora  |  ACK w/answer1 F4(packet loss) |  Mora
        |-------------------->x          |
   Est  |                                |
        | re-INVITE F6      200 F5(=F3)  |
        |   w/offer2         w/offer1    |
        |-------------     --------------|
        |              \ /               |
        |               X                |
        |              / \               |
        |<------------     ------------->|
        | ACK F7(=F4)      491(re-INV) F8|
        |-------------     --------------|
        |              \ /               |
        |               X                |
        |              / \               |
        |<------------     ------------->|
        |        ACK (re-INV) F9         |  Est
        |------------------------------->|
        |                                |
        |                                |
 This scenario is basically the same as that of Section 3.1.4, but
 differs in sending an offer in the 200 and an answer in the ACK.  In
 contrast to the previous case, the offer in the 200 (F3) and the
 offer in the re-INVITE (F6) collide with each other.
 Bob sends a 491 to the re-INVITE (F6) since he is not able to
 properly handle a new request until he receives an answer.  (Note:
 500 with a Retry-After header may be returned if the 491 response is
 understood to indicate request collision.  However, 491 is
 recommended here because 500 applies to so many cases that it is
 difficult to determine what the real problem was.)  The same result
 will be reached if F6 is an UPDATE with offer.

Hasebe, et al. Best Current Practice [Page 22] RFC 5407 Example Call Flows of Race Conditions December 2008

 Note: As noted in Section 3.1.4, the caller may delay sending a re-
 INVITE F6 for some period of time (2 seconds, perhaps), after which
 the caller may reasonably assume that its ACK has been received, to
 prevent this type of race condition.  This document expresses no
 preference about whether or not they should wait for an ACK to be
 delivered.  After considering the impact on user experience,
 implementors should decide whether or not to wait for a while,
 because the user experience depends on the implementation and has no
 direct bearing on protocol behavior.
 Message Details
 F1 INVITE Alice -> Bob
 INVITE sip:bob@biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sip:alice@client.atlanta.example.com;transport=udp>
 Content-Length: 0
 /* The request does not contain an offer.  Detailed messages are
    shown for the sequence to illustrate offer and answer
    examples.  */
 F2 180 Ringing Bob -> Alice
 F3 200 OK Bob -> Alice
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 ;received=192.0.2.101
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sip:bob@client.biloxi.example.com;transport=udp>
 Content-Type: application/sdp
 Content-Length: 133
 v=0
 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
 s=-
 c=IN IP4 192.0.2.201

Hasebe, et al. Best Current Practice [Page 23] RFC 5407 Example Call Flows of Race Conditions December 2008

 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 /* An offer is made in 200.  */
 F4 ACK Alice -> Bob
 ACK sip:bob@client.biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 ACK
 Content-Type: application/sdp
 Content-Length: 137
 v=0
 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
 s=-
 c=IN IP4 192.0.2.101
 t=0 0
 m=audio 49172 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 /* The request contains an answer, but the request is lost.  */
 F5(=F3) 200 OK Bob -> Alice (retransmission)
 /* The UAS retransmits a 200 OK to the ini-INVITE since it has not
    received an ACK.  */
 F6 re-INVITE Alice -> Bob
 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 INVITE
 Content-Length: 147
 v=0
 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
 s=-
 c=IN IP4 192.0.2.101

Hasebe, et al. Best Current Practice [Page 24] RFC 5407 Example Call Flows of Race Conditions December 2008

 t=0 0
 m=audio 49172 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 a=sendonly
 /* The request contains an offer.  */
 F7(=F4) ACK Alice -> Bob (retransmission)
 /* A retransmission triggered by the reception of a retransmitted
    200. "(=F4)" of ACK F7 shows that it is equivalent to the F4 in
    that it is an ACK for F3.  This doesn't mean that F4 and F7 are
    necessarily equal in Via-branch value.  Although it is ambiguous
    in RFC 3261 whether the Via-branch of ACK F7 differs from that of
    F4, it doesn't affect the UAS's behavior.  */
 F8 491 (re-INVITE) Bob -> Alice
 /* Bob sends 491 (Request Pending), since Bob has a pending
    offer.  */
 F9 ACK (re-INVITE) Alice -> Bob

Hasebe, et al. Best Current Practice [Page 25] RFC 5407 Example Call Flows of Race Conditions December 2008

3.1.6. Callee Receives BYE (Established State) While in the Moratorium

      State
 State  Alice                     Bob  State
        |                           |
        |         INVITE F1         |
        |-------------------------->|
   Pre  |      180 Ringing F2       |  Pre
        |<--------------------------|
   Ear  |                           |  Ear
        |         200 OK F3         |
        |<--------------------------|
  Mora  |    ACK F4(packet loss)    |  Mora
        |--------------->x          |
   Est  |   Both Way RTP Media      |
        |<=========================>|
        |   BYE F6       200 F5(=F3)|
        |-----------     -----------|
  Mort  |            \ /            |
        |             X             |
        |            / \            |
        |<----------     ---------->|  *race*
        |ACK F7(=F4)     200(BYE) F8|  Mort
        |-----------     -----------|
        |            \ /            |
        |             X             |
        |            / \            |
        |<----------     ---------->|
        | ^                       ^ |
        | | Timer K               | |
        | V                       | |
  Morg  |                 Timer J | |
        |                         V |
        |                           |  Morg
        |                           |
 This scenario illustrates the race condition that occurs when the UAS
 receives an Established message, BYE, while in the Moratorium state.
 An ACK request for a 200 OK response is lost (or delayed).  Bob
 retransmits the 200 OK to the ini-INVITE, and at the same time Alice
 sends a BYE request and terminates the session.  Upon receipt of the
 retransmitted 200 OK, Alice's UA might be inclined to reestablish the
 session.  But that is wrong -- the session should not be
 reestablished when the dialog is in the Mortal state.  Moreover, in
 the case where the UAS sends an offer in a 200 OK, the UAS should not
 start a session again, for the same reason, if the UAS receives a
 retransmitted ACK after receiving a BYE.

Hasebe, et al. Best Current Practice [Page 26] RFC 5407 Example Call Flows of Race Conditions December 2008

 Note: As noted in Section 3.1.4, implementation issues are outside
 the scope of this document, but the following tip is provided for
 avoiding race conditions of this type.  The caller can delay sending
 BYE F6 for some period of time (2 seconds, perhaps), after which the
 caller can reasonably assume that its ACK has been received.
 Implementors can decouple the actions of the user (e.g., hanging up)
 from the actions of the protocol (the sending of BYE F6), so that the
 UA can behave like this.  In this case, it is the implementor's
 choice as to how long to wait.  In most cases, such an implementation
 may be useful to prevent the type of race condition shown in this
 section.  This document expresses no preference about whether or not
 they should wait for an ACK to be delivered.  After considering the
 impact on user experience, implementors should decide whether or not
 to wait for a while, because the user experience depends on the
 implementation and has no direct bearing on protocol behavior.
 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 200 OK Bob -> Alice
 F4 ACK Alice -> Bob
 /* ACK request is lost.  */
 F5(=F3) 200 OK Bob -> Alice
 /* The UAS retransmits a 200 OK to the ini-INVITE since it has not
    received an ACK.  */
 F6 BYE Alice -> Bob
 /* Bob retransmits a 200 OK and Alice sends a BYE at the same time.
    Alice transitions to the Mortal state, so she does not begin a
    session after this even though she receives a 200 response to the
    re-INVITE.  */
 F7(=F4) ACK Alice -> Bob
 /* "(=F4)" of ACK F7 shows that it is equivalent to the F4 in that it
    is an ACK for F3.  This doesn't mean that F4 and F7 must be equal
    in Via-branch value.  Although it is ambiguous in RFC 3261 whether
    the Via-branch of ACK F7 differs from that of F4, it doesn't
    affect the UAS's behavior.  */

Hasebe, et al. Best Current Practice [Page 27] RFC 5407 Example Call Flows of Race Conditions December 2008

 F8 200 OK (BYE) Bob -> Alice
 /* Bob sends a 200 OK to the BYE.  */

3.2. Receiving Message in the Mortal State

 This section shows some examples of call flow race conditions when
 receiving messages from other states while in the Mortal state.

3.2.1. UA Receives BYE (Established State) While in the Mortal State

 State  Alice                  Bob  State
        |                        |
        |       INVITE F1        |
        |----------------------->|
   Pre  |    180 Ringing F2      |  Pre
        |<-----------------------|
   Ear  |                        |  Ear
        |       200 OK F3        |
        |<-----------------------|
  Mora  |         ACK F4         |  Mora
        |----------------------->|
   Est  |   Both Way RTP Media   |  Est
        |<======================>|
        |                        |
        | BYE F5         BYE F6  |
        |---------     ----------|
  Mort  |          \ /           |  Mort
        |           X            |
        |          / \           |
        |<--------     --------->|  *race*
        |                        |
        | 200 F8         200 F7  |
        |---------     ----------|
        |          \ /           |
        |           X            |
        |          / \           |
        |<--------     --------->|
        | ^                    ^ |
        | | Timer K            | |
        | V                    | |
  Morg  |              Timer J | |
        |                      V |
        |                        |  Morg
        |                        |

Hasebe, et al. Best Current Practice [Page 28] RFC 5407 Example Call Flows of Race Conditions December 2008

 This scenario illustrates the race condition that occurs when the UAS
 receives an Established message, BYE, while in the Mortal state.
 Alice and Bob send a BYE at the same time.  A dialog and session are
 ended shortly after a BYE request is passed to a client transaction.
 As shown in Section 2, the UA remains in the Mortal state.
 UAs in the Mortal state return error responses to the requests that
 operate within a dialog or session, such as re-INVITE, UPDATE, or
 REFER.  However, the UA shall return a 200 OK to the BYE taking the
 use case into consideration where a caller and a callee exchange
 reports about the session when it is being terminated.  (Since the
 dialog and the session both terminate when a BYE is sent, the choice
 of sending a 200 or an error response upon receiving a BYE while in
 the Mortal state does not affect the resulting termination.
 Therefore, even though this example uses a 200 response, other
 responses can also be used.)
 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 200 OK Bob -> Alice
 F4 ACK Alice -> Bob
 F5 BYE Alice -> Bob
 /* The session is terminated at the moment Alice sends a BYE.  The
    dialog still exists then, but it is certain to be terminated in a
    short period of time.  The dialog is completely terminated when
    the timeout of the BYE request occurs.  */
 F6 BYE Bob -> Alice
 /* Bob has also transmitted a BYE simultaneously with Alice.  Bob
    terminates the session and the dialog.  */
 F7 200 OK Bob -> Alice
 /* Since the dialog is in the Moratorium state, Bob responds with a
    200 to the BYE request.  */

Hasebe, et al. Best Current Practice [Page 29] RFC 5407 Example Call Flows of Race Conditions December 2008

 F8 200 OK Alice -> Bob
 /* Since Alice has transitioned from the Established state to the
    Mortal state by sending a BYE, Alice responds with a 200 to the
    BYE request.  */

3.2.2. UA Receives re-INVITE (Established State) While in the Mortal

      State
  State  Alice                  Bob  State
         |                        |
         |       INVITE F1        |
         |----------------------->|
    Pre  |    180 Ringing F2      |  Pre
         |<-----------------------|
    Ear  |                        |  Ear
         |       200 OK F3        |
         |<-----------------------|
   Mora  |         ACK F4         |  Mora
         |----------------------->|
    Est  |   Both Way RTP Media   |  Est
         |<======================>|
         |                        |
         | BYE F5     re-INVITE F6|
         |---------     ----------|
   Mort  |          \ /           |
         |           X            |
         |          / \           |
 *race*  |<--------     --------->|
         |                        |  Mort
         | 481 F8         200 F7  |
         | (re-INV)       (BYE)   |
         |---------     ----------|
         |          \ /           |^
         |           X            ||
         |          / \           ||Timer J
         |<--------     --------->||
        ^|    ACK (re-INV) F9     ||
        ||<-----------------------||
 Timer K||                        ||
        V|                        ||
   Morg  |                        |V
         |                        |  Morg
         |                        |
 This scenario illustrates the race condition that occurs when the UAS
 receives an Established message, re-INVITE, while in the Mortal
 state.  Bob sends a re-INVITE, and Alice sends a BYE at the same

Hasebe, et al. Best Current Practice [Page 30] RFC 5407 Example Call Flows of Race Conditions December 2008

 time.  The re-INVITE receives a 481 response since the TU of Alice
 has transitioned from the Established state to the Mortal state by
 sending BYE.  Bob sends an ACK for the 481 response because the ACK
 for error responses is handled by the transaction layer and, at the
 point of receiving the 481, the INVITE client transaction still
 remains (even though the dialog has been terminated).
 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 200 OK Bob -> Alice
 F4 ACK Alice -> Bob
 F5 BYE Alice -> Bob
 /* Alice sends a BYE and terminates the session, and transitions from
    the Established state to the Mortal state.  */
 F6 re-INVITE Bob -> Alice
 /* Alice sends a BYE, and Bob sends a re-INVITE at the same time.
    The dialog state transitions to the Mortal state at the moment
    Alice sends the BYE, but Bob does not know this until he receives
    the BYE.  Therefore, the dialog is in the Terminated state from
    Alice's point of view, but in the Confirmed state from Bob's point
    of view.  A race condition occurs.  */
 F7 200 OK (BYE) Bob -> Alice
 F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob
 /* Since Alice is in the Mortal state, she responds with a 481 to the
    re-INVITE.  */
 F9 ACK (re-INVITE) Bob -> Alice
 /* ACK for an error response is handled by Bob's INVITE client
    transaction.  */

Hasebe, et al. Best Current Practice [Page 31] RFC 5407 Example Call Flows of Race Conditions December 2008

3.2.3. UA Receives 200 OK for re-INVITE (Established State) While in

      the Mortal State
 State  Alice                  Bob  State
        |                        |
        |       INVITE F1        |
        |----------------------->|
   Pre  |    180 Ringing F2      |  Pre
        |<-----------------------|
   Ear  |                        |  Ear
        |       200 OK F3        |
        |<-----------------------|
  Mora  |         ACK F4         |  Mora
        |----------------------->|
   Est  |   Both Way RTP Media   |  Est
        |<======================>|
        |                        |
        |      re-INVITE F5      |
        |<-----------------------|
        | 200 F7         BYE F6  |
        |---------     ----------|
        |          \ /           |  Mort
        |           X            |
        |          / \           |
        |<--------     --------->|  *race*
  Mort  | 200 F8         ACK F9  |
        | (BYE)         (re-INV) |
        |---------     ----------|
        | ^        \ /           |
        | |         X            |
        | |        / \           |
        |<--------     --------->|
        | |                    ^ |
        | |            Timer K | |
        | |                    V |
        | | Timer J              |  Morg
        | V                      |
  Morg  |                        |
        |                        |
 This scenario illustrates the race condition that occurs when the UAS
 receives an Established message, 200 to a re-INVITE, while in the
 Mortal state.  Bob sends a BYE immediately after sending a re-INVITE.
 (For example, in the case of a telephone application, it is possible
 that a user hangs up the phone immediately after refreshing the
 session.)  Bob sends an ACK for a 200 response to INVITE while in the
 Mortal state, completing the INVITE transaction.

Hasebe, et al. Best Current Practice [Page 32] RFC 5407 Example Call Flows of Race Conditions December 2008

 Note: As noted in Section 3.1.4, implementation issues are outside
 the scope of this document, but the following tip is provided for
 avoiding race conditions of this type.  The UAC can delay sending a
 BYE F6 until the re-INVITE transaction F5 completes.  Implementors
 can decouple the actions of the user (e.g., hanging up) from the
 actions of the protocol (the sending of BYE F6), so that the UA can
 behave like this.  In this case, it is the implementor's choice as to
 how long to wait.  In most cases, such an implementation may be
 useful in preventing the type of race condition described in this
 section.  This document expresses no preference about whether or not
 they should wait for an ACK to be delivered.  After considering the
 impact on user experience, implementors should decide whether or not
 to wait for a while, because the user experience depends on the
 implementation and has no direct bearing on protocol behavior.
 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 200 OK Bob -> Alice
 F4 ACK Alice -> Bob
 F5 re-INVITE Bob -> Alice
 INVITE sip:alice@client.atlanta.example.com SIP/2.0
 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
 Session-Expires: 300;refresher=uac
 Supported: timer
 Max-Forwards: 70
 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Content-Length: 0
 /* Some detailed messages are shown for the sequence to illustrate
    that the re-INVITE is handled in the usual manner in the Mortal
    state.  */
 F6 BYE Bob -> Alice
 /* Bob sends BYE immediately after sending the re-INVITE.  Bob
    terminates the session and transitions from the Established state
    to the Mortal state.  */

Hasebe, et al. Best Current Practice [Page 33] RFC 5407 Example Call Flows of Race Conditions December 2008

 F7 200 OK (re-INVITE) Alice -> Bob
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7
 ;received=192.0.2.201
 Require: timer
 Session-Expires: 300;refresher=uac
 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Content-Length: 0
 /* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE.
    A race condition occurs.  */
 F8 200 OK (BYE) Alice -> Bob
 F9 ACK (re-INVITE) Bob -> Alice
 ACK sip:alice@client.atlanta.example.com SIP/2.0
 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44
 Max-Forwards: 70
 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 ACK
 Content-Length: 0
 /* Bob sends ACK in the Mortal state to complete the three-way
    handshake of the INVITE transaction.  */

Hasebe, et al. Best Current Practice [Page 34] RFC 5407 Example Call Flows of Race Conditions December 2008

3.2.4. Callee Receives ACK (Moratorium State) While in the Mortal State

 State  Alice                          Bob  State
        |                                |
        |         ini-INVITE F1          |
        |------------------------------->|
   Pre  |            180 F2              |  Pre
        |<-------------------------------|
   Ear  |            200 F3              |  Ear
        |<-------------------------------|
  Mora  |                                |  Mora
        |    ACK F4            BYE F5    |
        |-------------     --------------|
   Est  |              \ /               |  Mort
        |               X                |
        |              / \               |
        |<------------     ------------->|  *race*
  Mort  |            200 F6              |
        |------------------------------->|
        | ^                            ^ |
        | |                    Timer K | |
        | |                            V |
        | | Timer J                      |  Morg
        | V                              |
  Morg  |                                |
        |                                |
 This scenario illustrates the race condition that occurs when the UAS
 receives an Established message, ACK to 200, while in the Mortal
 state.  Alice sends an ACK and Bob sends a BYE at the same time.
 When the offer is in a 2xx, and the answer is in an ACK, there is a
 race condition.  A session is not started when the ACK is received
 because Bob has already terminated the session by sending a BYE.  The
 answer in the ACK request is just ignored.
 Note: As noted in Section 3.1.4, implementation issues are outside
 the scope of this document, but the following tip is provided for
 avoiding race conditions of this type.  Implementors can decouple the
 actions of the user (e.g., hanging up) from the actions of the
 protocol (the sending of BYE F5), so that the UA can behave like
 this.  In this case, it is the implementor's choice as to how long to
 wait.  In most cases, such an implementation may be useful in
 preventing the type of race condition described in this section.
 This document expresses no preference about whether or not they
 should wait for an ACK to be delivered.  After considering the impact
 on user experience, implementors should decide whether or not to wait
 for a while, because the user experience depends on the
 implementation and has no direct bearing on protocol behavior.

Hasebe, et al. Best Current Practice [Page 35] RFC 5407 Example Call Flows of Race Conditions December 2008

 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 200 OK Bob -> Alice
 F4 ACK Alice -> Bob
 /* RTP streams are established between Alice and Bob.  */
 F5 BYE Alice -> Bob
 F6 200 OK Bob -> Alice
 /* Alice sends a BYE and terminates the session and dialog.  */

3.3. Other Race Conditions

 This section shows examples of race conditions that are not directly
 related to dialog state transition.  In SIP, processing functions are
 deployed in three layers: dialog, session, and transaction.  They are
 related to each other, but have to be treated separately.  Section 17
 of RFC 3261 [1] details the processing of transactions.  This
 document has tried so far to clarify the processing on dialogs.  This
 section explains race conditions that are related to sessions
 established with SIP.

3.3.1. Re-INVITE Crossover

 Alice                         Bob
   |                            |
   |         INVITE F1          |
   |--------------------------->|
   |      180 Ringing F2        |
   |<---------------------------|
   |          200 OK F3         |
   |<---------------------------|
   |           ACK F4           |
   |--------------------------->|
   |     Both Way RTP Media     |
   |<==========================>|
   |                            |
   |re-INVITE F5   re-INVITE F6 |
   |------------   -------------|

Hasebe, et al. Best Current Practice [Page 36] RFC 5407 Example Call Flows of Race Conditions December 2008

   |            \ /             |
   |             X              |
   |            / \             |
   |<-----------   ------------>|
   |   491 F8        491 F7     |
   |------------   -------------|
   |            \ /             |
   |             X              |
   |            / \             |
   |<-----------   ------------>|
   |  ^ ACK F9         ^ ACK F10|
   |--|---------   ----|--------|
   |  |          \ /   |        |
   |  |           X    |        |
   |  |          / \   |        |
   |<-|----------   ---|------->|
   |  |                |        |
   |  |0-2.0 sec       |        |
   |  |                |        |
   |  v  re-INVITE F11(=F6)     |
   |<------------------|--------|
   |     200 OK F12    |        |
   |-------------------|------->|
   |       ACK F13     |        |
   |<------------------|--------|
   |                   |        |
   |                   |2.1-4.0 sec
   |                   |        |
   |re-INVITE F14(=F5) v        |
   |--------------------------->|
   |         200 OK F15         |
   |<---------------------------|
   |          ACK F16           |
   |--------------------------->|
   |                            |
   |                            |
 In this scenario, Alice and Bob send re-INVITEs at the same time.
 When two re-INVITEs cross in the same dialog, they are retried, each
 after a different interval, according to Section 14.1 of RFC 3261
 [1].  When Alice sends the re-INVITE and it crosses with Bob's, the
 re-INVITE will be retried after 2.1-4.0 seconds because she owns the
 Call-ID (she generated it).  Bob will retry his INVITE again after
 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID.
 Therefore, each User Agent must remember whether or not it has
 generated the Call-ID of the dialog, in case an INVITE may cross with
 another INVITE.

Hasebe, et al. Best Current Practice [Page 37] RFC 5407 Example Call Flows of Race Conditions December 2008

 In this example, Alice's re-INVITE is for session modification and
 Bob's re-INVITE is for session refresh.  In this case, after the 491
 responses, Bob retries the re-INVITE for session refresh earlier than
 Alice.  If Alice was to retry her re-INVITE (that is, if she was not
 the owner of Call-ID), the request would refresh and modify the
 session at the same time.  Then Bob would know that he does not need
 to retry his re-INVITE to refresh the session.
 In another instance, where two re-INVITEs for session modification
 cross over, retrying the same re-INVITE again after a 491 by the
 Call-ID owner (the UA that retries its re-INVITE after the other UA)
 may result in unintended behavior, so the UA must decide if the retry
 of the re-INVITE is necessary.  (For example, when a call hold and an
 addition of video media cross over, mere retry of the re-INVITE at
 the firing of the timer may result in the situation where the video
 is transmitted immediately after the holding of the audio.  This
 behavior is probably not intended by the users.)
 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 200 OK Bob -> Alice
 F4 ACK Alice -> Bob
 F5 re-INVITE Alice -> Bob
 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 INVITE
 Content-Length: 147
 v=0
 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
 s=-
 c=IN IP4 192.0.2.101
 t=0 0
 m=audio 49172 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 a=sendonly

Hasebe, et al. Best Current Practice [Page 38] RFC 5407 Example Call Flows of Race Conditions December 2008

 /* Some detailed messages are shown for the sequence to illustrate
    what sort of INVITE requests crossed over each other.  */
 F6 re-INVITE Bob -> Alice
 INVITE sip:alice@client.atlanta.example.com SIP/2.0
 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
 Session-Expires: 300;refresher=uac
 Supported: timer
 Max-Forwards: 70
 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Content-Length: 0
 /* A re-INVITE request for a session refresh and another for a call
    hold are sent at the same time.  */
 F7 491 Request Pending Bob -> Alice
 /* Since a re-INVITE is in progress, a 491 response is returned.  */
 F8 491 Request Pending Alice -> Bob
 F9 ACK (INVITE) Alice -> Bob
 F10 ACK (INVITE) Bob -> Alice
 F11 re-INVITE Bob -> Alice
 INVITE sip:alice@client.atlanta.example.com SIP/2.0
 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
 Session-Expires: 300;refresher=uac
 Supported: timer
 Max-Forwards: 70
 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 INVITE
 Content-Type: application/sdp
 Content-Length: 133
 v=0
 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
 s=-
 c=IN IP4 192.0.2.201

Hasebe, et al. Best Current Practice [Page 39] RFC 5407 Example Call Flows of Race Conditions December 2008

 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 /* Since Bob is not the owner of the Call-ID, he sends a re-INVITE
    again after 0.0-2.0 seconds.  */
 F12 200 OK Alice -> Bob
 F13 ACK Bob -> Alice
 F14 re-INVITE Alice -> Bob
 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 3 INVITE
 Content-Length: 147
 v=0
 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
 s=-
 c=IN IP4 192.0.2.101
 t=0 0
 m=audio 49172 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 a=sendonly
 /* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE
    again after 2.1-4.0 seconds.  */
 F15 200 OK Bob -> Alice
 F16 ACK Alice -> Bob

3.3.2. UPDATE and re-INVITE Crossover

 Alice                         Bob
   |                            |
   |         INVITE F1          |
   |--------------------------->|
   |      180 Ringing F2        |
   |<---------------------------|
   |                            |
   |          200 OK F3         |

Hasebe, et al. Best Current Practice [Page 40] RFC 5407 Example Call Flows of Race Conditions December 2008

   |<---------------------------|
   |           ACK F4           |
   |--------------------------->|
   |     Both Way RTP Media     |
   |<==========================>|
   |                            |
   |  UPDATE F5    re-INVITE F6 |
   |------------   -------------|
   |            \ /             |
   |             X              |
   |            / \             |
   |<-----------   ------------>|
   |   491 F8        491 F7     |
   |   (re-INVITE)   (UPDATE)   |
   |------------   -------------|
   |            \ /             |
   |             X              |
   |            / \             |
   |<-----------   ------------>|
   |  ^       ACK F9   ^        |
   |<-|----------------|--------|
   |  |                |        |
   |  |0-2.0 sec       |        |
   |  |                |        |
   |  v  re-INVITE F10 |        |
   |<------------------|--------|
   |     200 OK F11    |        |
   |-------------------|------->|
   |       ACK F12     |        |
   |<------------------|--------|
   |                   |        |
   |                   |2.1-4.0 sec
   |                   |        |
   |      UPDATE F13   v        |
   |--------------------------->|
   |         200 OK F14         |
   |<---------------------------|
   |                            |
   |                            |
 In this scenario, the UPDATE contains an SDP offer; therefore, the
 UPDATE and re-INVITE are both responded to with 491 as in the case of
 "re-INVITE crossover".  When an UPDATE for session refresh that
 doesn't contain a session description and a re-INVITE cross each
 other, both requests succeed with 200 (491 means that a UA has a
 pending request).  The same is true for UPDATE crossover.  In the
 former case where either UPDATE contains a session description, the
 requests fail with 491; in the latter cases, they succeed with 200.

Hasebe, et al. Best Current Practice [Page 41] RFC 5407 Example Call Flows of Race Conditions December 2008

 Note: A 491 response is sent because an SDP offer is pending, and 491
 is an error that is related to matters that impact the session
 established by SIP.
 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 200 OK Bob -> Alice
 F4 ACK Alice -> Bob
 F5 UPDATE Alice -> Bob
 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 UPDATE
 Content-Length: 147
 v=0
 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
 s=-
 c=IN IP4 192.0.2.101
 t=0 0
 m=audio 49172 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 a=sendonly
 /* Some detailed messages are shown for the sequence to illustrate
    messages crossing over each other.  */
 F6 re-INVITE Bob -> Alice
 INVITE sip:alice@client.atlanta.example.com SIP/2.0
 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
 Session-Expires: 300;refresher=uac
 Supported: timer
 Max-Forwards: 70
 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE

Hasebe, et al. Best Current Practice [Page 42] RFC 5407 Example Call Flows of Race Conditions December 2008

 Content-Type: application/sdp
 Content-Length: 133
 v=0
 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
 s=-
 c=IN IP4 192.0.2.201
 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 /* This is a case where a re-INVITE for a session refresh and an
    UPDATE for a call hold are sent at the same time.  */
 F7 491 Request Pending (UPDATE) Bob -> Alice
 /* Since a re-INVITE is in process, a 491 response is returned.  */
 F8 491 Request Pending (re-INVITE) Alice -> Bob
 F9 ACK (re-INVITE) Alice -> Bob
 F10 re-INVITE Bob -> Alice
 INVITE sip:alice@client.atlanta.example.com SIP/2.0
 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
 Session-Expires: 300;refresher=uac
 Supported: timer
 Max-Forwards: 70
 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 2 INVITE
 Content-Type: application/sdp
 Content-Length: 133
 v=0
 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
 s=-
 c=IN IP4 192.0.2.201
 t=0 0
 m=audio 3456 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 /* Since Bob is not the owner of the Call-ID, Bob sends an INVITE
    again after 0.0-2.0 seconds.  */

Hasebe, et al. Best Current Practice [Page 43] RFC 5407 Example Call Flows of Race Conditions December 2008

 F11 200 OK Alice -> Bob
 F12 ACK Bob -> Alice
 F13 UPDATE Alice -> Bob
 UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0
 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 3 UPDATE
 Content-Length: 147
 v=0
 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
 s=-
 c=IN IP4 192.0.2.101
 t=0 0
 m=audio 49172 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 a=sendonly
 /* Since Alice is the owner of the Call-ID, Alice sends the UPDATE
    again after 2.1-4.0 seconds.  */
 F14 200 OK Bob -> Alice

Hasebe, et al. Best Current Practice [Page 44] RFC 5407 Example Call Flows of Race Conditions December 2008

3.3.3. Receiving REFER (Established State) While in the Mortal State

  State  Alice                  Bob  State
         |                        |
         |       INVITE F1        |
         |----------------------->|
    Pre  |    180 Ringing F2      |  Pre
         |<-----------------------|
    Ear  |                        |  Ear
         |       200 OK F3        |
         |<-----------------------|
   Mora  |         ACK F4         |  Mora
         |----------------------->|
    Est  |   Both Way RTP Media   |  Est
         |<======================>|
         |                        |
         | BYE F5        REFER F6 |
         |---------     ----------|
   Mort  |          \ /           |
         |           X            |
         |          / \           |
 *race*  |<--------     --------->|
         |                        |  Mort
         | 481 F8         200 F7  |
         | (REFER)        (BYE)   |
         |---------     ----------|
         |          \ /         ^ |
         |           X          | |
         |          / \         | |
         |<--------     --------->|
         | ^                    | |
         | | Timer K            | |
         | V            Timer J | |
   Morg  |                      V |
         |                        |  Morg
         |                        |
 This scenario illustrates the race condition that occurs when the UAS
 receives an Established message, REFER, while in the Mortal state.
 Bob sends a REFER, and Alice sends a BYE at the same time.  Bob sends
 the REFER in the same dialog.  Alice's dialog state moves to the
 Mortal state at the point of sending BYE.  In the Mortal state, the
 UA possesses dialog information for an internal process but the
 dialog shouldn't exist outwardly.  Therefore, the UA sends an error
 response to the REFER, which is transmitted as a mid-dialog request.
 So Alice, in the Mortal state, sends an error response to the REFER.
 However, Bob has already started the SUBSCRIBE usage with REFER, so

Hasebe, et al. Best Current Practice [Page 45] RFC 5407 Example Call Flows of Race Conditions December 2008

 the dialog continues until the SUBSCRIBE usage terminates, even
 though the INVITE dialog usage terminates by receiving BYE.  Bob's
 behavior in this case needs to follow the procedures in RFC 5057 [6].
 Message Details
 F1 INVITE Alice -> Bob
 F2 180 Ringing Bob -> Alice
 F3 200 OK Bob -> Alice
 F4 ACK Alice -> Bob
 F5 BYE Alice -> Bob
 /* Alice sends a BYE request and terminates the session, and
    transitions from the Confirmed state to the Terminated state.  */
 F6 REFER Bob -> Alice
 /* Alice sends a BYE, and Bob sends a REFER at the same time.  Bob
    sends the REFER on the INVITE dialog.  The dialog state
    transitions to the Mortal state at the moment Alice sends the BYE,
    but Bob doesn't know this until he receives the BYE.  A race
    condition occurs.  */
 F7 200 OK (BYE) Bob -> Alice
 F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob
 /* Alice in the Mortal state sends a 481 to the REFER.  */

4. Security Considerations

 This document contains clarifications of behavior specified in RFC
 3261 [1], RFC 3264 [2], and RFC 3515 [4].  The security
 considerations of those documents continue to apply after the
 application of these clarifications.

5. Acknowledgements

 The authors would like to thank Robert Sparks, Dean Willis, Cullen
 Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, Akihiro
 Shimizu, Mayumi Munakata, Yasunori Inagaki, Tadaatsu Kidokoro,
 Kenichi Hiragi, Dale Worley, Vijay K. Gurbani, and Anders Kristensen
 for their comments on this document.

Hasebe, et al. Best Current Practice [Page 46] RFC 5407 Example Call Flows of Race Conditions December 2008

6. References

6.1. Normative References

 [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.
 [2]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
      Session Description Protocol (SDP)", RFC 3264, June 2002.
 [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [4]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
      Method", RFC 3515, April 2003.
 [5]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
      Responses in Session Initiation Protocol (SIP)", RFC 3262,
      June 2002.

6.2. Informative References

 [6]  Sparks, R., "Multiple Dialog Usages in the Session Initiation
      Protocol", RFC 5057, November 2007.
 [7]  Sparks, R., "Correct transaction handling for 200 responses to
      Session Initiation Protocol INVITE requests", Work in Progress,
      July 2008.

Hasebe, et al. Best Current Practice [Page 47] RFC 5407 Example Call Flows of Race Conditions December 2008

Appendix A. BYE in the Early Dialog

 This section, related to Section 3.1.3, explains why BYE is not
 recommended in the Early state, illustrating a case in which a BYE in
 the early dialog triggers confusion.
 Alice            Proxy               Bob   Carol
   |                |                  |      |
   |   INVITE F1    |                  |      |
   |--------------->|    INVITE F2     |      |
   |     100 F3     |----------------->|      |
   |<---------------| 180(To tag=A) F4 |      |
   |    180(A) F5   |<-----------------|      |
   |<---------------|                  |      |
   |                |       INVITE(Fork) F6   |
   |                |------------------------>|
   |                |                100 F7   |
   |    BYE(A) F8   |<------------------------|
   |--------------->|    BYE(A) F9     |      |
   |                |----------------->|      |
   |                |  200(A,BYE) F10  |      |
   | 200(A,BYE) F11 |<-----------------|      |
   |<---------------|  487(A,INV) F12  |      |
   |                |<-----------------|      |
   |                |    ACK(A) F13    |      |
   |                |----------------->|      |
   |                |                  |      |
   |                |                         |
   |                |     200(To tag=B) F13   |
   |   200(B) F14   |<------------------------|
   |<---------------|                         |
   |   ACK(B) F15   |                         |
   |--------------->|            ACK(B) F16   |
   |                |------------------------>|
   |   BYE(B) F17   |                         |
   |--------------->|            BYE(B) F18   |
   |                |------------------------>|
   |                |            200(B) F19   |
   |   200(B) F20   |<------------------------|
   |<---------------|                         |
   |                |                         |
   |                |                         |
 Care is advised in sending BYE in the Early state when forking by a
 proxy is expected.  In this example, the BYE request progresses
 normally, and it succeeds in correctly terminating the dialog with
 Bob.  After Bob terminates the dialog by receiving the BYE, he sends
 a 487 to the ini-INVITE.  According to Section 15.1.2 of RFC 3261

Hasebe, et al. Best Current Practice [Page 48] RFC 5407 Example Call Flows of Race Conditions December 2008

 [1], it is RECOMMENDED for the UAS to generate a 487 to any pending
 requests after receiving a BYE.  In this example, Bob sends a 487 to
 the ini-INVITE since he receives the BYE while the ini-INVITE is in
 pending state.
 However, Alice receives a final response to the INVITE (a 200 from
 Carol) even though she has successfully terminated the dialog with
 Bob.  This means that, regardless of the success/failure of the BYE
 in the Early state, Alice MUST be prepared for the establishment of a
 new dialog until receiving the final response for the INVITE and
 terminating the INVITE transaction.
 It is not illegal to send a BYE in the Early state to terminate a
 specific early dialog -- it may satisfy the intent of some callers.
 However, the choice of BYE or CANCEL in the Early state must be made
 carefully.  CANCEL is appropriate when the goal is to abandon the
 call attempt entirely.  BYE is appropriate when the goal is to
 abandon a particular early dialog while allowing the call to be
 completed with other destinations.  When using either BYE or CANCEL,
 the UAC must be prepared for the possibility that a call may still be
 established to one or more destinations.

Appendix B. BYE Request Overlapping with re-INVITE

   UAC                    UAS
    |                      |
 The session has been already established
   ==========================
    |   re-INVITE F1       |
    |--------------------->|
    |   BYE F2             |
    |--------------------->|
    |   200(BYE) F3        |
    |<---------------------|
    |   INVITE F4(=F1)     |
    |--------------------->|
    |                      |
    |                      |
 This case could look similar to the one in Section 3.2.3.  However,
 it is not a race condition.  This case describes the behavior when
 there is no response to the INVITE for some reason.  The appendix
 explains the behavior in this case and its rationale, since this case
 is likely to cause confusion.
 First of all, it is important not to confuse the behavior of the
 transaction layer and that of the dialog layer.  RFC 3261 [1] details
 the transaction layer behavior.  The dialog layer behavior is

Hasebe, et al. Best Current Practice [Page 49] RFC 5407 Example Call Flows of Race Conditions December 2008

 explained in this document.  It has to be noted that these two
 behaviors are independent of each other, even though both layers may
 be triggered to change their states by sending or receiving the same
 SIP messages.  (A dialog can be terminated even though a transaction
 still remains, and vice versa.)
 In the sequence above, there is no response to F1, and F2 (BYE) is
 sent immediately after F1.  (F1 is a mid-dialog request.  If F1 was
 an ini-INVITE, BYE could not be sent before the UAC received a
 provisional response to the request with a To tag.)
 Below is a figure that illustrates the UAC's dialog state and the
 transaction state.
 BYE   INV  dialog UAC                    UAS
              :     |                      |
              :     |                      |
              |     |   re-INVITE F1       |
        o     |     |--------------------->|
        |     |     |   BYE F2             |
  o     |  (Mortal) |--------------------->|
  |     |     |     |   200(BYE) F3        |
  |     |     |     |<---------------------|
  |     |     |     |   INVITE F4(=F1)     |
  |     |     |     |--------------------->|
  |     |     |     |   481(INV) F5        |
  |     |     |     |<---------------------|
  |     |     |     |   ACK(INV) F6        |
  |     |     |     |--------------------->|
  |     |     |     |                      |
  o     |     o     |                      |
        |           |                      |
        o           |                      |
                    |                      |
 For the UAC, the INVITE client transaction begins at the point F1 is
 sent.  The UAC sends BYE (F2) immediately after F1.  This is a
 legitimate behavior.  (Usually, the usage of each SIP method is
 independent, for BYE and others.  However, it should be noted that it
 is prohibited to send a request with an SDP offer while the previous
 offer is in progress.)
 After that, F2 triggers the BYE client transaction.  At the same
 time, the dialog state transitions to the Mortal state and then only
 a BYE or a response to a BYE can be handled.

Hasebe, et al. Best Current Practice [Page 50] RFC 5407 Example Call Flows of Race Conditions December 2008

 It is permitted to send F4 (a retransmission of INVITE) in the Mortal
 state because the retransmission of F1 is handled by the transaction
 layer, and the INVITE transaction has not yet transitioned to the
 Terminated state.  As is mentioned above, the dialog and the
 transaction behave independently each other.  Therefore, the
 transaction handling has to be continued even though the dialog has
 moved to the Terminated state.
 Note: As noted in Section 3.1.4, implementation issues are outside
 the scope of this document, but the following tip is provided for
 avoiding race conditions of this type.  The UAC can delay sending BYE
 F2 until the re-INVITE transaction F1 completes.  Implementors can
 decouple the actions of the user (e.g., hanging up) from the actions
 of the protocol (the sending of BYE F2), so that the UA can behave
 like this.  In this case, it is the implementor's choice as to how
 long to wait.  In most cases, such an implementation may be useful to
 prevent this case.  This document expresses no preference about
 whether or not they should wait for an ACK to be delivered.  After
 considering the impact on user experience, implementors should decide
 whether or not to wait for a while, because the user experience
 depends on the implementation and has no direct bearing on protocol
 behavior.
 Next, the UAS's state is shown below.
 UAC                    UAS dialog  INV   BYE
  |                      |     :
  |                      |     :
  |   re-INVITE F1       |     |
  |-------------->x      |     |
  |   BYE F2             |     |
  |--------------------->|     |           o
  |   200(BYE) F3        |  (Mortal)       |
  |<---------------------|     |           |<-Start Timer J
  |   INVITE F4(=F1)     |     |           |
  |--------------------->|     |     o     |
  |   4xx/5xx(INV) F5    |     o     |     o
  |<---------------------|           |
  |   ACK(INV) F6        |           |
  |--------------------->|           |<-Start Timer I
  |                      |           |
  |                      |           |
  |                      |           o
  |                      |
 For the UAS, it can be considered that packet F1 is lost or delayed
 (here, the behavior is explained for the case that the UAS receives
 F2 BYE before F1 INVITE).  Therefore, F2 triggers the BYE transaction

Hasebe, et al. Best Current Practice [Page 51] RFC 5407 Example Call Flows of Race Conditions December 2008

 for the UAS, and simultaneously the dialog moves to the Mortal state.
 Then, upon the reception of F4, the INVITE server transaction begins.
 (It is permitted to start the INVITE server transaction in the Mortal
 state.  The INVITE server transaction begins to handle the received
 SIP request regardless of the dialog state.)  The UAS's TU sends an
 appropriate error response for the F4 INVITE, either 481 (because the
 TU knows that the dialog that matches the INVITE is in the Terminated
 state) or 500 (because the re-sent F4 has an out-of-order CSeq).  (It
 is mentioned above that INVITE message F4 (and F1) is a mid-dialog
 request.  Mid-dialog requests have a To tag.  It should be noted that
 the UAS's TU does not begin a new dialog upon the reception of INVITE
 with a To tag.)

Appendix C. UA's Behavior for CANCEL

 This section explains the CANCEL behaviors that indirectly impact the
 dialog state transition in the Early state.  CANCEL does not have any
 influence on the UAC's dialog state.  However, the request has an
 indirect influence on the dialog state transition because it has a
 significant effect on ini-INVITE.  For the UAS, the CANCEL request
 has more direct effects on the dialog than on the sending of a CANCEL
 by the UAC, because it can be a trigger to send the 487 response.
 Figure 3 explains the UAS's behavior in the Early state.  This flow
 diagram is only an explanatory figure, and the actual dialog state
 transition is as illustrated in Figures 1 and 2.
 In the flow, full lines are related to dialog state transition, and
 dotted lines are involved with CANCEL. (r) represents the reception
 of signaling, and (s) means sending.  There is no dialog state for
 CANCEL, but here the Cancelled state is handled virtually just for
 the ease of understanding of the UA's behavior when it sends and
 receives CANCEL.

Hasebe, et al. Best Current Practice [Page 52] RFC 5407 Example Call Flows of Race Conditions December 2008

                +-------------+
                | Preparative |---+
                +-------------+   |
                  :   | 1xx(s)    |
                  :   V           |
                  : +-------+     | 2xx(s)
                  : | Early |-----+------+
                  : +-------+            |
                  :     :                V
                  :     :           +-----------+
                  :     :           | Confirmed |<...
                  :.....:           +-----------+   :
                     :                   |  :       :
                     :             BYE(r)|  :       :
                     : CANCEL(r)         |  :.......:
                     V                   |    CANCEL(r)
                 .............           |
                 : Cancelled :           |
                 :...........:           |
                    | 487(s)             |
                    |                    |
                    +--------------------+
                               |
                               V
                         +------------+
                         | Terminated |
                         +------------+
                 Figure 3: CANCEL flow diagram for UAS
 There are two behaviors for the UAS depending on the state when it
 receives a CANCEL.
 The first behavior is when the UAS receives a CANCEL in the Early
 state.  In this case, the UAS immediately sends a 487 for the INVITE,
 and the dialog transitions to the Terminated state.
 The other is the case in which the UAS receives a CANCEL while in the
 Confirmed state.  In this case, the dialog state transition does not
 occur, because the UAS has already sent a final response to the
 INVITE to which the CANCEL is targeted.  (Note that, because of the
 UAC's behavior, a UAS that receives a CANCEL in the Confirmed state
 can expect to receive a BYE immediately and move to the Terminated
 state.  However, the UAS's state does not transition until it
 actually receives a BYE.)

Hasebe, et al. Best Current Practice [Page 53] RFC 5407 Example Call Flows of Race Conditions December 2008

Appendix D. Notes on the Request in the Mortal State

 This section describes the UA's behavior in the Mortal state, which
 needs careful attention.  Note that every transaction completes
 independently of others, following the principle of RFC 3261 [1].
 In the Mortal state, only a BYE can be accepted, and the other
 messages in the INVITE dialog usage are responded to with an error.
 However, sending of ACK and the authentication procedure for BYE are
 conducted in this state.  (The handling of messages concerning
 multiple dialog usages is out of the scope of this document.  Refer
 to RFC 5057 [6] for further information.)
 ACK for error responses is handled by the transaction layer, so the
 handling is not related to the dialog state.  Unlike the ACK for
 error responses, ACK for 2xx responses is a request newly generated
 by a TU.  However, the ACK for 2xx and the ACK for error responses
 are both part of the INVITE transaction, even though their handling
 differs (Section 17.1.1.1, RFC 3261 [1]).  Therefore, the INVITE
 transaction is completed by the three-way handshake, which includes
 ACK, even in the Mortal state.
 Considering actual implementation, the UA needs to keep the INVITE
 dialog usage until the Mortal state finishes, so that it is able to
 send ACK for a 2xx response in the Mortal state.  If a 2xx to INVITE
 is received in the Mortal state, the duration of the INVITE dialog
 usage will be extended to 64*T1 seconds after the receipt of the 2xx,
 to cope with the possible 2xx retransmission.  (The duration of the
 2xx retransmission is 64*T1, so the UA needs to be prepared to handle
 the retransmission for this duration.)  However, the UA shall send an
 error response to other requests, since the INVITE dialog usage in
 the Mortal state is kept only for the sending of ACK for 2xx.
 The BYE authentication procedure shall be processed in the Mortal
 state.  When authentication is requested by a 401 or 407 response,
 the UAC resends BYE with appropriate credentials.  Also, the UAS
 handles the retransmission of the BYE for which it requested
 authentication.

Appendix E. Forking and Receiving New To Tags

 This section details the behavior of the TU when it receives multiple
 responses with different To tags to the ini-INVITE.
 When an INVITE is forked inside a SIP network, there is a possibility
 that the TU receives multiple responses to the ini-INVITE with
 differing To tags (see Sections 12.1, 13.1, 13.2.2.4, 16.7, 19.3,

Hasebe, et al. Best Current Practice [Page 54] RFC 5407 Example Call Flows of Race Conditions December 2008

 etc., of RFC 3261 [1]).  If the TU receives multiple 1xx responses
 with different To tags, the original DSM forks and a new DSM instance
 is created.  As a consequence, multiple early dialogs are generated.
 If one of the multiple early dialogs receives a 2xx response, it
 naturally transitions to the Confirmed state.  No DSM state
 transition occurs for the other early dialogs, and their sessions
 (early media) terminate.  The TU of the UAC terminates the INVITE
 transaction after 64*T1 seconds, starting at the point of receiving
 the first 2xx response.  Moreover, all mortal early dialogs that do
 not transition to the Established state are terminated (see Section
 13.2.2.4 of RFC 3261 [1]).  By "mortal early dialog", we mean any
 early dialog that the UA will terminate when another early dialog is
 confirmed.
 Below is an example sequence in which two 180 responses with
 different To tags are received, and then a 200 response for one of
 the early dialogs (dialog A) is received.  Dotted lines (..) in the
 sequences are auxiliary lines to represent the influence on dialog B.

Hasebe, et al. Best Current Practice [Page 55] RFC 5407 Example Call Flows of Race Conditions December 2008

                                 UAC
                  dialog(A)       |    INVITE F1
                   Pre o          |------------------------->
                       |          |    100 F2
                       |          |<-------------------------
                       |          |    180(To tag=A) F3
                   Ear |          |<-------------------------
        dialog(B)      |          |
    forked new DSM     |          |    180(To tag=B) F4
        Ear o..........|..........|<-------------------------
            |          |          |
            |          |          |    200(A) F5
 terminate->|.....Mora |..........|<-------------------------
   early    |          | ^        |    ACK(A) F6
    media   |      Est | |        |------------------------->
            |          | |        |
            |          | |64*T1   |
            |          | |(13.2.2.4 of RFC 3261 [1])
            |          | |        |
            |          | |        |
            |          | V        |
            o..........|.(terminate INVITE transaction)
        terminated     |          |
         dialog(B)     |          |
                       |          |
       Figure 4: Receiving 1xx responses with different To tags
 The figure above shows the DSM inside a SIP TU.  Triggered by the
 reception of a provisional response with a different To tag (F4
 180(To tag=B)), the DSM forks and the early dialog B is generated.
 64*T1 seconds later, dialog A receives a 200 OK response.  Dialog B,
 which does not transition to the Established state, terminates.
 Next, the behavior of a TU that receives multiple 2xx responses with
 different To tags is explained.  When a mortal early dialog that did
 not match the first 2xx response that the TU received receives
 another 2xx response that matches its To tag before the 64*T1 INVITE
 transaction timeout, its DSM transitions to the Confirmed state.
 However, the session on the mortal early dialog is terminated when
 the TU receives the first 2xx to establish a dialog, so no session is
 established for the mortal early dialog.  Therefore, when the mortal
 early dialog receives a 2xx response, the TU sends an ACK and,
 immediately after, the TU usually sends a BYE to terminate the DSM.
 (In special cases, e.g., if a UA intends to establish multiple
 dialogs, the TU may not send the BYE.)

Hasebe, et al. Best Current Practice [Page 56] RFC 5407 Example Call Flows of Race Conditions December 2008

 The handling of the second early dialog after receiving the 200 for
 the first dialog is quite appropriate for a typical device, such as a
 phone.  It is important to note that what is being shown is a typical
 useful action and not the only valid one.  Some devices might want to
 handle things differently.  For instance, a conference focus that has
 sent out an INVITE that forks may want to accept and mix all the
 dialogs it gets.  In that case, no early dialog is treated as mortal.
 Below is an example sequence in which two 180 responses with a
 different To tag are received and then a 200 response for each of the
 early dialogs is received.
                                 UAC
                  dialog(A)       |    INVITE F1
                   Pre o          |----------------------->
                       |          |    100 F2
                       |          |<-----------------------
                       |          |    180(To tag=A) F3
       dialog(B)   Ear |          |<-----------------------
   forked new DSM      |          |    180(To tag=B) F4
        Ear o..........|..........|<-----------------------
            |          |          |
            |          |          |    200(A) F5
 terminate->|.....Mora |..........|<-----------------------
   early    |          | ^        |    ACK(A) F6
    media   |      Est | |        |----------------------->
            |          | |64*T1   |
            |          | |        |    200(B) F7
       Mora |..........|.|........|<-----------------------
            |          | |        |    ACK(B) F8
        Est |..........|.|........|----------------------->
            |          | |        |    BYE(B) F9
       Mort |..........|.|........|----------------------->
        ^   |          | |        |    200(B) F10
        |   |          | |        |<-----------------------
        |Timer K       | |        |
        |   |          | V        |
        |   |          | (terminate INVITE transaction)
        V   |          |          |
       Morg o          |          |
                       |          |
   Figure 5: Receiving 1xx and 2xx responses with different To tags
 Below is an example sequence when a TU receives multiple 200
 responses with different To tags before the 64*T1 timeout of the
 INVITE transaction in the absence of a provisional response.  Even
 though a TU does not receive a provisional response, the TU needs to

Hasebe, et al. Best Current Practice [Page 57] RFC 5407 Example Call Flows of Race Conditions December 2008

 process the 2xx responses (see Section 13.2.2.4 of RFC 3261 [1]).  In
 that case, the DSM state is forked at the Confirmed state, and then
 the TU sends an ACK for the 2xx response and, immediately after, the
 TU usually sends a BYE.  (In special cases, e.g., if a UA intends to
 establish multiple dialogs, the TU may not send the BYE.)
                               UAC
                dialog(A)       |    INVITE F1
                 Pre o          |----------------------->
                     |          |    100 F2
                     |          |<-----------------------
                     |          |    180(To tag=A) F3
                 Ear |          |<-----------------------
                     |          |
                     |          |    200(A) F4
                Mora |..........|<-----------------------
                     | ^        |    ACK(A) F5
                 Est | |        |----------------------->
                     | |        |
     dialog(B)       | |64*T1   |
 forked new DSM      | |        |    200(To tag=B) F6
     Mora o..........|.|........|<-----------------------
          |          | |        |    ACK(B) F7
      Est |..........|.|........|----------------------->
          |          | |        |    BYE(B) F8
     Mort |..........|.|........|----------------------->
      ^   |          | |        |    200(B) F9
      |   |          | |        |<-----------------------
      |   |          | V        |
      |Timer K       | (terminate INVITE transaction)
      |   |          |          |
      V   |          |          |
     Morg o          |          |
                     |          |
       Figure 6: Receiving 2xx responses with different To tags
 Below is an example sequence in which the option tag 100rel (RFC 3262
 [5]) is required by a 180.
 If a forking proxy supports 100rel, it transparently transmits to the
 UAC a provisional response that contains a Require header with the
 value of 100rel.  Upon receiving a provisional response with 100rel,
 the UAC establishes the early dialog (B) and sends PRACK (Provisional
 Response Acknowledgement).  (Here, also, every transaction completes
 independently of others.)

Hasebe, et al. Best Current Practice [Page 58] RFC 5407 Example Call Flows of Race Conditions December 2008

 As in Figure 4, the early dialog (B) terminates at the same time the
 INVITE transaction terminates.  In the case where a proxy does not
 support 100rel, the provisional response will be handled in the usual
 way (a provisional response with 100rel is discarded by the proxy,
 not to be transmitted to the UAC).
                              UAC
               dialog(A)       |    INVITE F1
                Pre o          |------------------------->
                    |          |    100 F2
                    |          |<-------------------------
                    |          |    180(To tag=A) F3
                Ear |          |<-------------------------
                    |          |    200(A) F4
               Mora |..........|<-------------------------
                    | ^        |    ACK(A) F5
                Est | |        |------------------------->
     dialog(B)      | |        |
 forked new DSM     | |        |    180(To tag=B) w/100rel F6
     Ear o..........|.|........|<-------------------------
         |          | |        |    PRACK(B) F7
         |          | |        |------------------------->
         |          | |        |    200(B,PRACK) F8
         |          | |        |<-------------------------
         |          | |64*T1   |
         |          | |(13.2.2.4 of RFC 3261 [1])
         |          | |        |
         |          | |        |
         |          | |        |
         |          | V        |
         o..........|.(terminate INVITE transaction)
     terminated     |          |
      dialog(B)     |          |
                    |          |
       Figure 7: Receiving 1xx responses with different To tags
 when using the mechanism for reliable provisional responses (100rel)

Hasebe, et al. Best Current Practice [Page 59] RFC 5407 Example Call Flows of Race Conditions December 2008

Authors' Addresses

 Miki Hasebe
 NTT-east Corporation
 19-2 Nishi-shinjuku 3-chome
 Shinjuku-ku, Tokyo  163-8019
 JP
 EMail: hasebe.miki@east.ntt.co.jp
 Jun Koshiko
 NTT-east Corporation
 19-2 Nishi-shinjuku 3-chome
 Shinjuku-ku, Tokyo  163-8019
 JP
 EMail: j.koshiko@east.ntt.co.jp
 Yasushi Suzuki
 NTT Corporation
 9-11, Midori-cho 3-Chome
 Musashino-shi, Tokyo  180-8585
 JP
 EMail: suzuki.yasushi@lab.ntt.co.jp
 Tomoyuki Yoshikawa
 NTT-east Corporation
 19-2 Nishi-shinjuku 3-chome
 Shinjuku-ku, Tokyo  163-8019
 JP
 EMail: tomoyuki.yoshikawa@east.ntt.co.jp
 Paul H. Kyzivat
 Cisco Systems, Inc.
 1414 Massachusetts Avenue
 Boxborough, MA  01719
 US
 EMail: pkyzivat@cisco.com

Hasebe, et al. Best Current Practice [Page 60]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp147.txt · Last modified: 2008/12/08 21:31 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki