tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5407

BCP 147
Pages: 60
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIPPING

Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)

Part 1 of 2, p. 1 to 28
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
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.

Top      ToC       Page 4 
   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.

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
    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)

Top      ToC       Page 7 
   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).

Top      ToC       Page 8 
    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

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
   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.

Top      ToC       Page 11 
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.)

Top      ToC       Page 12 
   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

Top      ToC       Page 13 
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].

Top      ToC       Page 14 
   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.  */

Top      ToC       Page 15 
   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

Top      ToC       Page 16 
   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

Top      ToC       Page 17 
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

Top      ToC       Page 18 
   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

Top      ToC       Page 19 
   /* 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

Top      ToC       Page 20 
   /* 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

Top      ToC       Page 21 
   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

Top      ToC       Page 22 
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.

Top      ToC       Page 23 
   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

Top      ToC       Page 24 
   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

Top      ToC       Page 25 
   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

Top      ToC       Page 26 
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.

Top      ToC       Page 27 
   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.  */

Top      ToC       Page 28 
   F8 200 OK (BYE) Bob -> Alice

   /* Bob sends a 200 OK to the BYE.  */



(page 28 continued on part 2)

Next RFC Part