tech-invite   World Map     

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

RFC 5407

 
 
 

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

Part 2 of 2, p. 28 to 60
Prev RFC Part

 


prevText      Top      Up      ToC       Page 28 
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
          |                        |

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

Top      Up      ToC       Page 30 
   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

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

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

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

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

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

Top      Up      ToC       Page 36 
   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 |
     |------------   -------------|

Top      Up      ToC       Page 37 
     |            \ /             |
     |             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.

Top      Up      ToC       Page 38 
   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

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

Top      Up      ToC       Page 40 
   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         |

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

Top      Up      ToC       Page 42 
   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

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

Top      Up      ToC       Page 44 
   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

Top      Up      ToC       Page 45 
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

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

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

Top      Up      ToC       Page 48 
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

Top      Up      ToC       Page 49 
   [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

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

Top      Up      ToC       Page 51 
   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

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

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

Top      Up      ToC       Page 54 
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,

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

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

Top      Up      ToC       Page 57 
   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

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

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

Top      Up      ToC       Page 60 
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