Internet DRAFT - draft-hasebe-sipping-exceptional-procedure-example

draft-hasebe-sipping-exceptional-procedure-example





Internet Engineering Task Force                                M. HASEBE
Internet-Draft                                                  NTT-East
Expiration: Sep 3th, 2006                                     J. KOSHIKO
                                                                NTT-East
                                                               Y. SUZUKI
                                                                NTT-East
                                                            T. YOSHIKAWA
                                                                NTT-East
                                                           Mar 3th, 2006


       Session Initiation Protocol Exceptional Procedure Examples
         draft-hasebe-sipping-exceptional-procedure-example-03


Status of this Memo

   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79.  

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet- Drafts.  

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress."  

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt.  

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html.  

Copyright Notice

   Copyright (C) The Internet Society (2006).


Abstract

   This document gives examples of Session Initiation Protocol (SIP)
   call flows in race condition. Call flows in race conditions are
   confusing and this document shows the best practices to handle
   them. The elements in these call flows include SIP User Agents
   and SIP Proxies. Call flow diagrams and message details are shown.





Hasebe                                                           [Page 1]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


Table of Contents

   1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
      1.1 General Assumptions. . . . . . . . . . . . . . . . . . . . . 3
      1.2 Legend for Message Flows . . . . . . . . . . . . . . . . . . 3
      1.3 SIP Protocol Assumptions . . . . . . . . . . . . . . . . . . 4
   2. The Dialog State Machine(for Race Condition) . . . . . . . . . . 4
   3. Race condition . . . . . . . . . . . . . . . . . . . . . . . . . 7
      3.1 Receiving message in the Moratorium State. . . . . . . . . . 8
        3.1.1 Receiving Initial INVITE retransmission(Trying state). . 8
	(old name: Initial INVITE retransmission)
        3.1.2 Receiving CANCEL(Trying state) . . . . . . . . . . . .  11
	(old name: CANCEL crossover)
        3.1.3 Receiving CANCEL(Trying state) via a stateful proxy. .  14
	(old name: CANCEL crossover via a stateful proxy)
        3.1.4 Receiving BYE (Early state). . . . . . . . . . . . . .  21
	(old name: BYE crossover on the early dialog)
        3.1.5 Receiving re-INVITE (Established state). . . . . . . .  23
	(old name: re-INVITE on the moratorium dialog)
        3.1.6 Receiving BYE (Established state). . . . . . . . . . .  27
	(old name: A retransmitted 200 OK after sending a BYE)
      3.2 Receiving message in the Mortal State. . . . . . . . . . .  31
        3.2.1 Receiving BYE(Established state) . . . . . . . . . . .  31
	(old name: BYE crossover)
        3.2.2 Receiving re-INVITE(Established state) . . . . . . . .  35
	(old name: Session timer crossover (re-INVITE, BYE) )
        3.2.3 Receiving REFER(Established state) . . . . . . . . . .  39
	(old name: REFER crossover (REFER, BYE) )
        3.2.4 Receiving 200OK for re-INVITE(Established state) . . .  43
	(old name: A BYE is sent immediately after sending of a re-INVITE )
        3.2.5 Receiving ACK (Moratorium state) . . . . . . . . . . .  46
      3.3 other race condition . . . . . . . . . . . . . . . . . . .  49
	3.3.1 Early Dialog . . . . . . . . . . . . . . . . . . . . .  49
	3.3.2 A BYE on the early dialog. . . . . . . . . . . . . . .  57
	3.3.3 re-INVITE crossover. . . . . . . . . . . . . . . . . .  60
	3.3.4 UPDATE and re-INVITE crossover . . . . . . . . . . . .  67
   4. References . . . . . . . . . . . . . . . . . . . . . . . . . .  73
   5. Intellectual Property Statement. . . . . . . . . . . . . . . .  74
   6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  74


1. Overview

   The call flows shown in this document were derived in the design of
   a SIP IP communications network. These examples are difficult to
   interpret the behaviors of user agent based on RFCs.

   In various situations which may happen when SIP is implemented,
   especially, when a situation which serves as a norm of implementing in
   RFC is not illustrated, by showing operation of a terminal or a server


Hasebe                                                           [Page 2]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   as an example, it will be a help to a SIP implementors.

   For example, the sequence which CANCEL and 200 OK for INVITE cross each
   other is possible. INVITE transaction obviously exists from UAC's point
   of view, when the UAC sends a CANCEL message. However, when the UAS
   sends a 200 OK response for INVITE and then receives CANCEL message,
   there is not INVITE transaction anymore from UAS's point of view. In
   such a case, it's not easy to specify the response from the UAS in RFCs.

   This document clarifies SIP UA behaviors when messages cross each other
   as race conditions.
   By clarifying operation under race conditions,
   different 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 the current version 2.0 of SIP in RFC
   3261 [1] with SDP usage 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 [4].


1.1 General Assumptions

   A number of architecture, 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 in 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 for details
   on 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 crossover of
   signaling messages. Arrow indicate the direction of message flow.

   Double dashed lines (===) represent media paths between network
   elements.

   Messages with parentheses around their name represent optional


Hasebe                                                           [Page 3]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   messages.

   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 error) of SIP methods,
   headers and parameters. NOTE: The flows in this document must not
   be copied as they are by implementors because additional
   characteristics were incorporated into the document for ease of
   explanation. To sum up, the procedures described in this document
   represent well-reviewed examples of SIP usage, which are best common
   practice according to IETF consensus.

   For simplicity in reading and editing the document, there are a
   number of differences between some of the examples and actual SIP
   messages. Examples are: Call-IDs are often repeated; 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
   and 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


2. The Dialog State Machine(for Race Condition)

   Race conditions are generated when the dialog state of the receiving
   side differs from the dialog state of the sending side.
   Thus race conditions are generated on both UAs when caller's signal
   and callee's signal are intersected in the network.
   For instance, a race condition occurs when UAC (User Agent Client)
   sends a CANCEL on Early state while UAS (User Agent Server) is
   transitting from Early state to Confirmed state by sending a


Hasebe                                                           [Page 4]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   200 OK to ini-INVITE.
   The dialog state machine (DSM) is represented as follows to help
   the understanding of UA's behavior in such race conditions.


        +-----------------------------------------------+
        |                   Preparative                 |
        |   +-----------+           +---------------+   |
        |   |           | 1xx-notag |               |---C--+
        |   |   Trying  |---------->|   Proceeding  |   |  | 1xx-notag
        |   |           |           |               |<--C--+
        |   +-----------+           +---------------+   |
        |                                               |
        +-----------------------------------------------+
          |                         |                 |
          | 3xx-6xx                 | 1xx-tag         | 2xx
          |                         |                 |
          |                         V                 |
          |         +-------------------+             |
          |  3xx-6xx|                   |---+         |
          +<--------|       Early       |   | 1xx-tag |
          |         |                   |<--+         |
          |         +-------------------+             |
          |            |              |               |
          |            | BYE          | 2xx           |
          |            |              +----------+----+
          |            |                         |
    +-----C------------C-----+       +-----------C-------+
    |     | Terminated |     |       | Confirmed |       |
    |     |            +<----C-------|           |       |
    |     |            |     |  BYE  |           |       |
    |     |            V     |       |           V       |
    |     | +------------+   |       |   +-----------+   |
    |     | |            |---C-+     |   |           |---C--+
    |     | |   Mortal   |   | | BYE |   | Moratorium|   |  | 2xx
    |     | |            |<--C-+     |   |           |<--C--+
    |     | +------------+   |       |   +-----------+   |
    |     |   |              |       |         |         |
    |     |   | Timeout      |       |         | ACK     |
    |     |   |              |       |         |         |
    |     V   V              |       |         V         |
    |   +---------------+    |       |   +-----------+   |
    |   |               |    |       |   |           |   |
    |   |     Morgue    |    |       |   |Established|   |
    |   |               |    |       |   |           |   |
    |   +---------------+    |       |   +-----------+   |
    |                        |       |                   |
    +------------------------+       +-------------------+

                          figure 1


Hasebe                                                           [Page 5]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   Figure 1 shows a DSM for race conditions.

   This document clarifies UA's behavior by subdividing some internal
   states showed on FSM (Finate State Machine) for dialog state of the
   dialog-package[7], without changing the states of the dialog,
   "early", "confirmed", and "terminated" shown in RFC3261.

   Preparative state is put before the Ealy state, which includes
   Trying and Proceeding. Moreover, Confirmed state is devided into
   two sub-states, Moratorium and Established. In addition, 
   Terminated state is subdivided into two states, Mortal and Morgue.

   The following is UA's behaviors in each state.

      Preparative: Preparative is a state until the Early dialog is
         established by sending and receiving a provisional response
	 with To-tag after an ini-INVITE is sent and received. 
	 The dialog has not existed yet in Preparative state. The
	 dialog state transit from the Preparative to the Early by
	 sending or receiving a provisional response with To-tag.
	 Moreover, the dialog state transit to Moratorium which is a
	 substate of Confirmed state, if UA sends or receives a 2xx
	 response. In addition, the dialog state transit to Morgue
	 state which is a substate of Terminated state, if UA sends
	 or receives a 3xx-6xx response. Sending an ACK to a 3xx-6xx
	 response and retransmissions of 3xx-6xx are not expressed on
	 this DSM because they are sent by INVITE transactions.

      Trying: Trying is substate of Preparative and inherits the
         behavior of Preparative. Trying is started by sending and
	 receiving an ini-INVITE. It transits to Proceeding by sending
	 or receiving a 1xx (usually 100 trying) without To-tag.
	 UAC may retransmit an INVITE on transaction layer and UAC
	 must not send a CANCEL request. UAS may send a 1xx-6xx
	 response.

      Proceeding: Proceeding is substate of Preparative and inherits
         the behavior of Preparative. Dialog becomes Proceeding state
	 if dialogs in Trying state send or receive a 1xx without
	 To-tag (usually 100 trying). UAC may send a CANCEL, and UAS
	 may send a 1xx-6xx response in Proceeding state. 

      Early: The early dialog is established by sending or receiving
         a provisional response with To-tag. The early dialog exists
	 though the dialog has not existed in this state yet. The
         dialog state transits from Early to Moratorium, substate of
         Confirmed by sending or receiving a 2xx response. In addition,
	 the dialog state transits to the Morgue subdivided internally
         in the Terminated by sending and receiving a 3xx-6xx response.


Hasebe                                                           [Page 6]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


	 Sending an ACK to a 3xx-6xx response and retransmissions of
	 3xx-6xx are not expressed on this DSM because they are sent
	 by INVITE transactions. UAC may send CANCEL in Proceeding
	 state. UAC may send BYE (although it is not recommended.)
	 UAS may send a 1xx-6xx response.

      Confirmed: Sending or receiving 2xx final response establishes
         a dialog. Dialog exists in this state. BYE message changes
	 state from Confirmed to Mortal, substate of Terminated.
	 Confirmed has two substates, Moratorium and Established,
	 they are different in messages UA are allowed to send.

      Moratorium: Moratorium is a substate of Confirmed and inherits
         the behavior of Confirmed. Moratorium transits to Established
	 by sending or receiving an ACK request. UAC may send an ACK
	 and UAS may send a 2xx final response.

      Established: Established is a substate of Confirmed and inherits
         the behavior of Confirmed. Both caller and callee may send
	 various messages which influences a dialog. Caller supports
	 the transmission of ACK to a retransmission of a 2xx response
	 to an ini-INVITE.

      Terminated: Terminated state is devided into two substates,
         Mortal and Morgue, to consider a behavior when a dialog is
	 being terminated. In this state, UAs hold information about
	 the dialog which is being terminated. Confirmed transits to
	 Mortal, a substate of Terminated, by sending or receiving a
	 BYE request.

      Mortal: Caller and callee becomes Mortal state by sending or
         receiving a BYE. Only a BYE or its response can be handled in
	 this state, and no other messages can be received. This is
	 because the use case is taken into consideration that a BYE
	 message are sent by both a caller and a callee to exchange
	 reports about the session when it is being terminated.
	 Therefore, UA possesses dialog information for internal process
	 but dialog shouldn't exist outwardly. UA stops managing dialog
	 state and changes it to Morgue state, when the BYE transaction
	 is done by timer. (Timer F or Timer K for UAC. Timer J for UAS.)

      Morgue: Dialog doesn't exist any more in this state. Sending or
         receiving a signal which influences a dialog is not performed.
         (It is literally terminated.)


3. Race condition

   This section details race condition between two SIP User
   Agents (UAs): Alice and Bob. Alice (sip:alice@atlanta.example.com)


Hasebe                                                           [Page 7]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or
   SIP-enabled devices. 

   In case that CANCEL and 200 OK to INVITE intersect, INVITE
   transaction obviously exists in UAC. On the other side, there is not
   INVITE transaction anymore in UAS when it sends a 200 OK response to
   the INVITE and then receives a CANCEL request. This is an example of
   UA's behavior in Moratorium state, a substate of Confirmed.

   Examples of such race conditions are shown below.


3.1 Receiving message in the Moratorium State

   This section shows some examples of call flow in race condition
   when receiving the message from other states in the Moratorium state.

3.1.1 Receiving Initial INVITE retransmission(Trying state)
      in Moratorium state

   Alice                             Bob
     |                                |
     |         ini-INVITE F1          |
     |------------------------------->|
     |      180 F2(Packet loss)       |
     |         X<---------------------|
     |                                |
     | ini-INVITE F4           200 F3 |
     |-------------     --------------| Terminate(ServerTransaction)
     |              \ /               |
     |               X                |
     |              / \               |
     |<------------     ------------->|
     |             ACK F5             |
     |------------------------------->|
     |                                |
     |                                |


   In this scenario, all provisional responses to the initial INVITE
   (ini-INVITE) are lost, and UAC retransmits an ini-INVITE. At the
   same time as retransmission, UAS generates a 200 OK to the
   ini-INVITE and it terminate an INVITE server transaction.
   (RFC3261, 13.3.1.4) After sending a 200 OK, a TU of UAS processes
   ACK and retransmission of 200 OK. (RFC3261, 17.1) A TU of UAS
   processes a retransmitted ini-INVITE, but it doesn't have a To-tag,
   therefore the TU cannot use a mechanism to recognize the dialog by
   From-tag, Call-ID and To-tag. However, it must recognize a
   retransmitted ini-INVITE correctly by From-tag and Call-ID.
   (It must not construct a new dialog in response to a retransmitted


Hasebe                                                           [Page 8]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   ini-INVITE regarding it as a request outside dialog.)
   Since TU of UAS retransmits a 200 OK according to the timer during
   it waits for ACK, it doesn't need to retransmit 200 OK for the
   retransmitted ini-INVITE.


   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: 151

   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


   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

   /* A 180 response is lost and does not reach Alice. */


   F3 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9


Hasebe                                                           [Page 9]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


    ;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: 147

   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

   /* Bob sends a 200 OK and terminates the INVITE transaction at the
      same time. TU performs retransmitting of a 200 OK directly.*/


   F4 INVITE(retransmission) 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: 151

   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

   /* Since F2 is lost, Alice retransmits an ini-INVITE. The retransmitted
      INVITE does not match any existing transaction because Bob has
      already sent a 200 OK. Moreover, the retransmitted ini-INVITE does
      not have a To-tag, so it doesn't match any existing dialog.
      Therefore, Bob have to recognize the retransmitted INVITE correctly,
      without treating with the new INVITE. */




Hasebe                                                           [Page 10]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   F5 ACK Alice -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   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


3.1.2 Receiving CANCEL(Trying state)
      in Moratorium state

   Alice                     Bob
     |                        |
     |       INVITE F1        |
     |----------------------->|
     |    180 Ringing F2      |
     |<-----------------------|
     |                        |
     |CANCEL F3     200 OK F4 |
     |---------     ----------|
     |          \ /           |
     |           X            |
     |          / \           |
     |<--------     --------->|
     |                        |
     | ACK F6         481 F5  |
     |---------     ----------|
     |          \ /           |
     |           X            |
     |          / \           |
     |<--------     --------->|
     |                        |
     |   Both Way RTP Media   |
     |<======================>|
     |         BYE F7         |
     |----------------------->|
     |         200 F8         |
     |<-----------------------|
     |                        |
     |                        |


   In this scenario, Alice sends a CANCEL and Bob sends a 200 OK response
   to the initial INVITE message at the same time. Then Bob sends a 481
   response in response to the CANCEL from Alice. UAC can terminate the
   session by sending a BYE immediately after receiving 200 OK for INVITE.


Hasebe                                                           [Page 11]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   By transmitting a BYE after 200 OK, "it just means that the software
   in his phone needs to maintain state for a short while in order to
   clean up properly." (RFC3261, 15)
   In this sequence, it is recommended that caller terminates the session
   by sending a BYE.


   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: 151

   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


   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 CANCEL Alice -> Bob

   CANCEL sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>


Hasebe                                                           [Page 12]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0

   /* When Alice sends a CANCEL, INVITE transaction exists. */


   F4 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: 147

   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


   /* Alice sends a CANCEL and Bob sends a 200 OK response to the
      initial INVITE message at the same time. From Bob's point of view,
      an INVITE transaction is completed by sending of the final
      response (200 OK). A 200 OK and a CANCEL crossed each other and
      inconsistency has arisen in the state of INVITE transaction
      of Alice and Bob. */


   F5 481 Call/Transaction Dose Not Exist Bob -> Alice

   SIP/2.0 481 Call/Transaction Dose Not Exist
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
    ;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 CANCEL
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Content-Length: 0

   /* The final respons to INVITE transaction has already sent while


Hasebe                                                           [Page 13]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


      CANCEL request targeting this INVITE transaction is received, 
      so Bob returns a 481 response. */


   F6 ACK Alice -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
   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

   /* Bob has sent the final response, and a CANCEL becomes invalid.
      RTP streams are established.*/


   F7 BYE Alice -> Bob

   BYE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
   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 BYE
   Content-Length: 0


   F8 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
    ;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: 2 BYE
   Content-Length: 0


3.1.3 Receiving CANCEL(Trying state) via a stateful proxy
      in Moratorium state


     Alice                Proxy                   Bob
     |                      |                      |
     |      INVITE F1       |                      |


Hasebe                                                           [Page 14]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |--------------------->|      INVITE F2       |
     |    100 Trying F3     |--------------------->|
     |<---------------------|    180 Ringing F4    |
     |        180 F5        |<---------------------|
     |<---------------------|                      |
     |                      |                      |
     |      CANCEL F6       |                      |
     |--------------------->| CANCEL F7     200 F8 |
     |   200(CANCEL) F9     |---------     --------|
     |<---------------------|          \ /         |
     |                      |           X          |
     |                      |          / \         |
     |   200(INVITE) F10    |<--------     ------->|
     |<---------------------|   481(CANCEL) F11    |
     |       ACK F12        |<---------------------|
     |--------------------->|       ACK F13        |
     |                      |--------------------->|
     |       BYE F14        |                      |
     |--------------------->|       BYE F15        |
     |                      |--------------------->|
     |                      |       200 F16        |
     |       200 F17        |<---------------------|
     |<---------------------|                      |
     |                      |                      |
     |                      |                      |


   If a CANCEL crosses a 200 OK to an INVITE between Bob and a stateful
   proxy, the UAC may receive a 200 OK to the INVITE after receiving 200
   OK to the CANCEL. TU must manage a CANCEL transaction and an INVITE
   transaction independently, and even if a CANCEL is successful, TU
   cannot terminate an INVITE transaction, as described on 9.1 of RFC3261.
   Like "3.1.2 Receiving CANCEL(Trying state)", the UAC may send a BYE and
   terminate the session immediately after receiving 200 OK to an INVITE.


   Message Details

   F1 INVITE Alice -> Proxy

   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: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=udp>
   Content-Type: application/sdp
   Content-Length: 151


Hasebe                                                           [Page 15]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   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


   F2 INVITE Proxy -> Bob

   INVITE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Max-Forwards: 69
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=udp>
   Content-Type: application/sdp
   Content-Length: 151

   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


   F3 100 Trying Proxy -> Alice

   SIP/2.0 100 Trying
   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>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Content-Length: 0


   F4 180 Ringing Bob -> Proxy

   SIP/2.0 180 Ringing


Hasebe                                                           [Page 16]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1
    ;received=192.0.2.233
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Content-Length: 0


   F5 180 Ringing Proxy -> Alice

   SIP/2.0 180 Ringing
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Content-Length: 0


   F6 CANCEL Alice -> Proxy

   CANCEL sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0


   F7 CANCEL Proxy -> Bob

   CANCEL sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0

   /* Proxy sent a 200 OK to the CANCEL and Bob sent INVITE at the same
      time. */


Hasebe                                                           [Page 17]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006




   F8 200 OK(INVITE) Bob -> Proxy

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1
    ;received=192.0.2.233
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Content-Type: application/sdp
   Content-Length: 148

   v=0
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
   s=-
   c=IN IP4 192.0.2.100
   t=0 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000


   F9 200 OK(CANCEL) Proxy -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0

   /* Since CANCEL requests are hop-by-hop, the proxy answers with a
      200 OK to the CANCEL of Alice. Note that the 200 OK doesn't mean
      the success of the CANCEL to the INVITE. */


   F10 200 OK(INVITE) Proxy -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159


Hasebe                                                           [Page 18]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Content-Type: application/sdp
   Content-Length: 148

   v=0
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
   s=-
   c=IN IP4 192.0.2.100
   t=0 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000


   F11 481 Call/Transaction Does Not Exist Bob -> Proxy

   SIP/2.0 481 Call/Transaction Does Not Exist
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0

   /* Since Bob has already sent 200 OK to INVITE, CANCEL fails with 481
      response. */


   F12 ACK Alice -> Proxy

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bq9
   Max-Forwards: 70
   Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 ACK
   Content-Length: 0


   F13 ACK Proxy -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bq9
    ;received=192.0.2.101
   Max-Forwards: 69
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl


Hasebe                                                           [Page 19]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 ACK
   Content-Length: 0


   F14 BYE Alice -> Proxy

   BYE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5
   Max-Forwards: 70
   Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 2 BYE
   Content-Length: 0

   /* Alice may send a BYE and terminate the sessin immediately on
      receipt of a 200 OK after the CANCEL. */


   F15 BYE Proxy -> Bob

   BYE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK739578.1
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5
    ;received=192.0.2.101
   Max-Forwards: 69
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 2 BYE
   Content-Length: 0


   F16 200 OK Bob -> Proxy

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK739578.1
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5
    ;received=192.0.2.101
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 2 BYE
   Content-Length: 0


   F17 200 OK Proxy -> Alice


Hasebe                                                           [Page 20]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5
    ;received=192.0.2.101
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 2 BYE
   Content-Length: 0


3.1.4 Receiving BYE (Early state)
      in Moratorium state

   Alice                             Bob
     |                                |
     |         ini-INVITE F1          |
     |------------------------------->|
     |            180 F2              |
     |<-------------------------------|
     |                                |
     |    BYE F4        200(INVITE) F3|
     |-------------     --------------|
     |              \ /               |
     |               X                |
     |              / \               |
     |<------------     ------------->|
     |                                |
     |           200(BYE) F5          |
     |<-------------------------------|
     |                                |
     |                                |


   In this scenario, Alice sends a BYE on the early dialog and Bob
   sends a 200 OK response to the initial INVITE message at the
   same time. Bob receives a BYE on the Confirmed dialog though
   Alice sended a BYE on the Early dialog. A BYE functions normally
   even if it is received after the INVITE transaction terminates
   because a BYE differs from a CANCEL, and is sent to not request
   but the dialog. Alice gets into a Mortal state on receiving the
   BYE response, and remains Mortal until the Timer K timeout occurs.
   Therefore, UA don't send an ACK if it receives a 200 to INVITE.


   Message Details

   F1 INVITE Alice -> Bob

   INVITE sip:bob@biloxi.example.com SIP/2.0


Hasebe                                                           [Page 21]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   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: 151

   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


   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(ini-INVITE) 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: 147

   v=0
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
   s=-
   c=IN IP4 192.0.2.201
   t=0 0


Hasebe                                                           [Page 22]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000


   F4 BYE Alice -> Bob

   BYE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 BYE
   Content-Length: 0

   F5 200 OK(BYE) Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
    ;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: 2 BYE
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Content-Length: 0


3.1.5 Receiving re-INVITE (Established state)
      in Moratorium state

   Alice                             Bob
     |                                |
     |         ini-INVITE F1          |
     |------------------------------->|
     |             180 F2             |
     |<-------------------------------|
     |                                |
     |             200 F3             |
     |<-------------------------------|
     |       ACK F4(packet loss)      |
     |-------------------->X          |
     |                                |
     | re-INVITE F6         200 F5    |
     |-------------     --------------|
     |              \ /               |
     |               X                |
     |              / \               |
     |<------------     ------------->|
     |   ACK F7             200 F8    |
     |-------------     --------------|


Hasebe                                                           [Page 23]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |              \ /               |
     |               X                |
     |              / \               |
     |<------------     ------------->|
     |             ACK F9             |
     |------------------------------->|
     |                                |
     |                                |


   In this scenario, UAS receives a re-INVITE before receiving an ACK
   to ini-INVITE. UAS sends a 200 OK to the re-INVITE (F8) because
   it has sent a 200 OK to the ini-INVITE (F3, F5) and the dialog
   has already been confirmed. However, if a 200 OK to the ini-INVITE
   has an offer and the answer would be in the ACK, UA should return
   by a 491 to the re-INVITE. If UAS doesn't receive an ACK for
   a long time, it should send a BYE and terminate the dialog.

Editor's Note:
 In this sequence, UAS comes to know that UAC receives a 200 OK to the
 ini-INVITE, when UAS receives a re-INVITE on the dialog. Therefore,
 it's believed that UA may view an ACK to be received already if it has
 received a mid-dialog request such as a re-INVITE even though it hasn't
 actually received an ACK. (However, only provided an ACK plays a role
 to transmit that UAC receives the 200 OK. In other words, in case that
 an ACK doesn't have an answer. )
 It is a difficult problem if UAS in Moratorium state accepts the
 message generated by Established state.
 Therefore, this example may be corrected.


   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: 151

   v=0
   o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
   s=-
   c=IN IP4 192.0.2.101


Hasebe                                                           [Page 24]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000


   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: 147

   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=z9hG4bKnashds8
   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


Hasebe                                                           [Page 25]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Content-Length: 0

   /* A ACK request is lost. */


   F5 200 OK Bob -> Alice (retransmission)

   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: 147

   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

   /* UAS retransmits a 200 OK to an ini-INVITE since it didn't receive
      a 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=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: 151

   v=0
   o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
   s=-
   c=IN IP4 192.0.2.101
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   a=sendonly


Hasebe                                                           [Page 26]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006




   F7 ACK Alice -> Bob (retransmission)

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
   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


   F8 200 OK(re-INVITE) Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
   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: 151

   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 Alice -> Bob

   ACK sip:sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f2.1
   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


3.1.6 Receiving BYE (Established state)
      in Moratorium state



Hasebe                                                           [Page 27]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Alice                     Bob
     |                        |
     |       INVITE F1        |
     |----------------------->|
     |    180 Ringing F2      |
     |<-----------------------|
     |                        |
     |       200 OK F3        |
     |<-----------------------|
     |   ACK F4(packet loss)  |
     |-------------->X        |
     |   Both Way RTP Media   |
     |<======================>|
     | BYE F6         200 F5  |
     |---------     ----------|
     |          \ /           |
     |           X            |
     |          / \           |
     |<--------     --------->|
     |       200 OK F7        |
     |<-----------------------|
     |                        |
     |                        |


   In this scenario, a ACK request to a 200 OK response is lost
   (or delay), immediately after Bob sends the retransmitted 200
   OK to ini-INVITE and Alice sends a BYE at the same time.
   Depending on the implement of a SIP user agent, Alice may start
   a session again by reception of the retransmitted 200 OK with SDP
   since she has already terminated a session by sending a BYE. In
   that case, if UAC receives a retransmitted 200 OK after sending a
   BYE, you should not start a session again since the session which
   is not associated with dialog remains. Moreover, in the case where
   UAS sends an offer with a 200 OK, if UAS receives a retransmitted
   ACK after receiving a BYE, UAS should not start a session again
   for the same reason.


   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


Hasebe                                                           [Page 28]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Contact: <sip:alice@client.atlanta.example.com;transport=udp>
   Content-Type: application/sdp
   Content-Length: 151

   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


   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: 147

   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



Hasebe                                                           [Page 29]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
   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

   /* A ACK request is lost. */


   F5 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: 147

   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

   /* UAS retransmits a 200 OK to an ini-INVITE since it didn't receive
      a ACK. */


   F6 BYE Alice -> Bob

   BYE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
   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 BYE
   Content-Length: 0

   /* Bob retransmits a 200 OK and Alice sends a BYE at the same time. */



Hasebe                                                           [Page 30]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   F7 200 OK(BYE) Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
    ;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: 2 BYE
   Content-Length: 0

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

Editor's Note
 In the old version, Alice responds with an ACK when she have sent an
 ACK to the first 200 OK once. However, this version was modified
 that TU don't send an ACK to the retransmited 200 because TU
 understands oneself is in Mortal state.


3.2 Receiving message in the Mortal State

   This section shows some examples of call flow in race condition
   when receiving the message from other states in the Mortal state.


3.2.1 Receiving BYE(Establish state)
      in Mortal state

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


Hasebe                                                           [Page 31]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |                        |
     | 200 F8         200 F7  |
     |---------     ----------|
     |          \ /           |
     |           X            |
     |          / \           |
     |<--------     --------->|
     |                        |
     |                        |


   In this scenario, Alice and Bob send a BYE at the same time.
   A session is ended shortly after a BYE request is passed to a
   client transaction. According to 15.1.1 of RFC3261, a dialog
   seems to be completed by a response or timeout of a BYE.
   As shown in section 2, UA remains in Mortal state after sending
   a BYE until sending a BYE to actually terminating the dialog.
   (Any requests or responses which influence dialogs or sessions
   are invalid even though the dialog exists.) UAs in Mortal state
   return error responses to the requests that operate dialog or
   session, such as re-INVITE, or REFER. Exception is a BYE message.
   UA shall return 200 OK to the BYE because it can give the dialog
   in Mortal State a finishing stroke and send it to the Morgue.


   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: 151

   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


   F2 180 Ringing Bob -> Alice


Hasebe                                                           [Page 32]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   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: 147

   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=z9hG4bK74bd5
   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

   /* RTP streams are established between Alice and Bob */

   /* Bob hangs up. Note that the CSeq is NOT 2, since
      Alice and Bob maintain their own independent CSeq counts.
      (The INVITE was request 1 generated by Alice, and the BYE is


Hasebe                                                           [Page 33]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


      request 1 generated by Bob) */


   F5 BYE Alice -> Bob

   BYE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
   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 BYE
   Content-Length: 0

   /* 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

   BYE sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
   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 BYE
   Content-Length: 0

   /* Bob has also transmitted a BYE simultaneously with Alice.
      Bob terminates a session and a dialog. */


   F7 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
    ;received=192.0.2.201
   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 BYE
   Content-Length: 0

   /* Since the dialog is Moratorium state, Bob responds with
      a 200 to the BYE. */



Hasebe                                                           [Page 34]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


Editor's Note:
 In the old version, UA sends a 481 since the dialog is terminated by
 sending a BYE request. 
 (draft-hasebe-sipping-exceptional-procedure-example-02.txt)
 In this draft, UA's behavior in the example is modified to return
 200 OK. It is an advantage of returning of 200 over 481 that
 information when the dialog is terminated can be passed on by the
 BYE response. 


   F8 200 OK Alice -> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
    ;received=192.0.2.201
   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 BYE
   Content-Length: 0

   /* Since Alice has transited from the established state to Mortal
      state by sending a BYE, Alice responds with a 200 to a BYE. */      


3.2.2 Receiving re-INVITE(Establish state)
      in Mortal state

   Alice                     Bob
     |                        |
     |       INVITE F1        |
     |----------------------->|
     |    180 Ringing F2      |
     |<-----------------------|
     |                        |
     |       200 OK F3        |
     |<-----------------------|
     |         ACK F4         |
     |----------------------->|
     |   Both Way RTP Media   |
     |<======================>|
     |                        |
     | BYE F5     re-INVITE F6|
     |---------     ----------|
     |          \ /           |
     |           X            |
     |          / \           |
     |<--------     --------->|
     |                        |
     | 481 F8         200 F7  |


Hasebe                                                           [Page 35]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |---------     ----------|
     |          \ /           |
     |           X            |
     |          / \           |
     |<--------     --------->|
     |         ACK F9         |
     |<-----------------------|
     |                        |


   In this scenario, Bob sends a re-INVITE, and Alice sends a BYE
   at the same time. The re-INVITE of Bob is returned by a 481,
   since TU of Alice has transited from Established state to Mortal
   state by sending a BYE. Bob sends an ACK to a 481 response,
   because a client transaction of a re-INVITE remains still.


   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
   Supported: timer
   Session-Expires: 300
   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: 151

   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


   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


Hasebe                                                           [Page 36]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   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
   Require: timer
   Session-Expires: 300;refresher=uas
   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: 147

   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

   /* In this sequence, Bob sets refresher=uas since there was no
      specification of refresher. */


   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=z9hG4bK74bd5
   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

   /* RTP streams are established between Alice and Bob */


   F5 BYE Alice -> Bob

   BYE sip:bob@client.biloxi.example.com SIP/2.0


Hasebe                                                           [Page 37]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
   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 BYE
   Content-Length: 0

   /* Alice sends a BYE and terminates a session, and transits from
      the confirmed state to the terminnated state. */


   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=z9hG4bKnashds7
   Session-Expires: 300;refresher=uac
   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

   /* Alice sends a BYE, and Bob sends a re-INVITE at the same time.
      The state of dialog transits to Mortal state at the moment
      Alice sends a BYE, but Bob doesn't know it until he receives
      the BYE. Therefore, the dialog is Terminated state from
      Alice's point of view, but the dialog is Confirmed state
      from Bob's point of view. A race condition occurs. */


   F7 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
    ;received=192.0.2.201
   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 BYE
   Content-Length: 0


   F8 481 Call/Transaction Does Not Exist Alice -> Bob

   SIP/2.0 481 Call/Transaction Does Not Exist
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
    ;received=192.0.2.201


Hasebe                                                           [Page 38]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   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

   /* Since Alice is in Mortal state, she responds with a 481 to the
      re-INVITE. */


   F9 ACK Bob -> Alice

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
   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
   Content-Length: 0


3.2.3 Receiving REFER(Establish state)
      in Mortal state

   Alice                     Bob
     |                        |
     |       INVITE F1        |
     |----------------------->|
     |    180 Ringing F2      |
     |<-----------------------|
     |                        |
     |       200 OK F3        |
     |<-----------------------|
     |         ACK F4         |
     |----------------------->|
     |   Both Way RTP Media   |
     |<======================>|
     |                        |
     | BYE F5        REFER F6 |
     |---------     ----------|
     |          \ /           |
     |           X            |
     |          / \           |
     |<--------     --------->|
     |                        |
     | 481 F8         200 F7  |
     |---------     ----------|
     |          \ /           |
     |           X            |
     |          / \           |


Hasebe                                                           [Page 39]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |<--------     --------->|
     |                        |
     |                        |


   In this scenario, Bob sends a REFER, and Alice sends a BYE at
   the same time. Bob send a REFER in the same dialog.
   Alice sends an error response to request like a REFER which
   operates the dialog (or session) , because Alice is in Mortal
   state by sending a BYE.


   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
   Supported: timer
   Session-Expires: 300
   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: 151

   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


   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



Hasebe                                                           [Page 40]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   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
   Require: timer
   Session-Expires: 300;refresher=uas
   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: 147

   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=z9hG4bK74bd5
   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

   /* RTP streams are established between Alice and Bob */


   F5 BYE Alice -> Bob

   BYE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
   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 BYE
   Content-Length: 0



Hasebe                                                           [Page 41]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   /* Alice sends a BYE and terminates a session, and transits from
      Confirmed state to Terminnated state. */


   F6 REFER Bob -> Alice

   REFER sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
   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
   Refer-To: sip:carol@cleveland.example.org
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   CSeq: 1 REFER
   Content-Length: 0

   /* Alice sends a BYE, and Bob sends a REFER at the same time.
      Bob sends a REFER on the INVITE dialog.
      The state of dialog transits to Mortal state at the moment
      Alice sends a BYE, but Bob doesn't know it until he receives
      the BYE. A race condition occurs. */


   F7 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
    ;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: 2 BYE
   Content-Length: 0


   F8 481 Call/Transaction Does Not Exist Alice -> Bob

   SIP/2.0 481 Call/Transaction Does Not Exist
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
    ;received=192.0.2.201
   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 REFER
   Content-Length: 0

   /* Since Alice is in Mortal state, she responds with a 481 to the
      REFER. */



Hasebe                                                           [Page 42]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



3.2.4 Receiving 200OK for re-INVITE(Establish state)
      in Mortal state

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


   In this scenario, Bob sends a BYE immediately after sending
   a re-INVITE, (A user is not conscious that refresher sends a
   re-INVITE automatically. For example, in the case of a
   telephone application, it is possible that a user places a
   receiver immediately after refresher.) When Alice receives a
   BYE other than ACK,she stops retransmitting of 200 OK. Since
   ACK for 2xx responses is not a server transaction, it is that
   UAS core transmits directly.  With UAS core, since the
   dialog which matches 200 OK received is terminated, 200 OK is
   ignored, without sending ACK.


   Message Details

   F1 INVITE Alice -> Bob


   INVITE sip:bob@biloxi.example.com SIP/2.0


Hasebe                                                           [Page 43]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Supported: timer
   Session-Expires: 300
   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: 151

   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


   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
   Require: timer
   Session-Expires: 300;refresher=uas
   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: 147

   v=0


Hasebe                                                           [Page 44]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   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=z9hG4bK74bd5
   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

   /* RTP streams are established between Alice and 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=z9hG4bKnashds7
   Session-Expires: 300;refresher=uac
   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


   F6 BYE Bob -> Alice

   BYE sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8
   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 BYE
   Content-Length: 0

   /* Bob sends a BYE immediately after sending of a re-INVITE.
      Bob terminates a session and transits from Established
      state to Mortal state. */



Hasebe                                                           [Page 45]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   F7 200 OK(re-INVITE) Alice -> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds7
    ;received=192.0.2.201
   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 a BYE, and Alice responds with a 200 OK to re-INVITE.
      A race condition occurs. */


   F8 200 OK(BYE) Alice -> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8
    ;received=192.0.2.201
   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 BYE
   Content-Length: 0

   /* The UAC core of Bob does not send a ACK after receiving 200 OK to 
      a re-INVITE.(Bob has terminated the dialog by sending of a BYE.)
      The UAS core of Alice does not retransmit 200 OK to a re-INVITE.
      (Since the dialog is terminated by reception of BYE, Alice does
      not retransmit 200 OK even if she does not receive ACK from Bob.)
      */


3.2.5 Receiving ACK (Moratorium state)
      in Mortal state

   Alice                             Bob
     |                                |
     |         ini-INVITE F1          |
     |------------------------------->|
     |            180 F2              |
     |<-------------------------------|
     |            200 F3              |
     |<-------------------------------|
     |                                |
     |    ACK F4            BYE F5    |
     |-------------     --------------|
     |              \ /               |


Hasebe                                                           [Page 46]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |               X                |
     |              / \               |
     |<------------     ------------->|
     |            200 F6              |
     |------------------------------->|
     |                                |
     |                                |


   In this scenario, 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, this example is in a race condition. Do not begin the
   session by receiving an ACK because Bob has already terminated
   the session by sending the BYE. The answer of ACK is just
   ignored.


   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
   Supported: timer
   Session-Expires: 300
   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: 151

   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


   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


Hasebe                                                           [Page 47]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   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
   Require: timer
   Session-Expires: 300;refresher=uas
   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: 147

   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=z9hG4bK74bd5
   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

   /* RTP streams are established between Alice and Bob */


   F5 BYE Alice -> Bob

   BYE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
   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


Hasebe                                                           [Page 48]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   CSeq: 2 BYE
   Content-Length: 0

   /* Alice sends a BYE and terminates a session and dialog. */


   F6 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
    ;received=192.0.2.201
   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 BYE
   Content-Length: 0


3.3 Other race condition

   Here, examples in race condition that doesn't relate directly
   to the dialog state transition are shown. In this section, it
   is shown that how to treat the race condition which generated
   when UAs treat "What is established by SIP" which related
   closely with dialog.

3.3.1 Early Dialog

     Alice                Proxy                   Bob   Carol
     |                      |                      |      |
     |   INVITE(sdp1) F1    |                      |      |
     |--------------------->|   INVITE(sdp1) F2    |      |
     |     100 Trying F3    |--------------------->|      |
     |<---------------------| 183(sdp2)To-tag=1 F4 |      |
     | 183(sdp2)To-tag=1 F5 |<---------------------|      |
     |<---------------------|                      |      |
     |       PRACK F6       |                      |      |
     |--------------------->|       PRACK F7       |      |
     |                      |--------------------->|      |
     |                      |    200(PRACK) F8     |      |
     |    200(PRACK) F9     |<---------------------|      |
     |<---------------------|                      |      |
     |<=============Both Way RTP Media============>|      |
     |                      |      CANCEL F10      |      |
     |                      |--------------------->|      |
     |                      |   200(CANCEL) F11    |      |
     |                      |<---------------------|      |
     |                      |   487(INVITE) F12    |      |
     |                      |<---------------------|      |
     |                      |   ACK(INVITE) F13    |      |


Hasebe                                                           [Page 49]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |                      |--------------------->|      |
     |                      |                      |      |
     |                      |                             |
     |                      |      INVITE(sdp1) F14       |
     |                      |---------------------------->|
     |                      |      180 To-tag=2 F15       |
     |   180 To-tag=2 F16   |<----------------------------|
     |<---------------------|                             |
     |                      |    200(sdp3)To-tag=2 F17    |
     | 200(sdp3)To-tag=2 F18|<----------------------------|
     |<---------------------|                             |
     |       ACK F19        |                             |
     |--------------------->|           ACK F20           |
     |                      |---------------------------->|
     |<================Both Way RTP Media================>|
     |                      |                             |
     |                      |                             |


   In this scenario, a proxy is forking to another address (Carol),
   if Bob don't return final response. When a proxy sends INVITEs
   to two or more addresses, two or more early dialogs may be
   established at UAC. At UAC, all early dialogs are released when
   the final response of ini-INVITE is received. (RFC3261, 13.2.2.4)
   Only the confirmed dialog continues after a 200 OK reception.
   Even if Bob is replaced by Media Server, you have the result
   appear to UAC just as this call flow. In this sequence, Bob can
   terminate the early media when he receives CANCEL, but Alice does
   not have the trigger to terminate the early dialog. When Bob stops
   sending RTP by the CANCEL from Proxy, it seems to Alice that RTP
   breaks off suddenly.


   Message Details

   F1 INVITE Alice -> Proxy

   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: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=udp>
   Supported: 100rel
   Content-Type: application/sdp
   Content-Length: 151

   v=0


Hasebe                                                           [Page 50]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   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


   F2 INVITE Proxy -> Bob

   INVITE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9

    ;received=192.0.2.101
   Max-Forwards: 69
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=udp>
   Supported: 100rel
   Content-Type: application/sdp
   Content-Length: 151

   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


   F3 100 Trying Proxy -> Alice

   SIP/2.0 100 Trying
   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>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Content-Length: 0


   F4 183 Session Progress Bob -> Proxy

   SIP/2.0 183 Session Progress


Hasebe                                                           [Page 51]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1
    ;received=192.0.2.233
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Require: 100rel
   Content-Type: application/sdp
   Content-Length: 148

   v=0
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
   s=-
   c=IN IP4 192.0.2.100
   t=0 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000


   F5 183 Session Progress Proxy -> Alice

   SIP/2.0 183 Session Progress
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   RSeq: 1
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Require: 100rel
   Content-Type: application/sdp
   Content-Length: 148

   v=0
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
   s=-
   c=IN IP4 192.0.2.100
   t=0 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

   /* Early dialog is established between Alice and Bob, and early
      media is also established at the same time. */



Hasebe                                                           [Page 52]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   F6 PRACK Alice -> Proxy

   PRACK sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 2 PRACK
   RAck: 1 1 INVITE
   Content-Length: 0


   F7 PRACK Proxy -> Bob

   PRACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 2 PRACK
   RAck: 1 1 INVITE
   Content-Length: 0


   F8 200 OK(PRACK) Bob -> Proxy

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 2 PRACK
   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Content-Length: 0


   F9 200 OK(PRACK) Proxy -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 2 PRACK
   Content-Length: 0



Hasebe                                                           [Page 53]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   F10 CANCEL Proxy -> Bob

   CANCEL sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0

   /* The proxy cancels the INVITE to Bob, and sends an INVITE to Carol.
      Although the continuation of early media after CANCEL reception
      depends on the implementation of the user agent, Alice does not
      know that the proxy cancels the INVITE, therefore,  when Bob stops
      early media after CANCEL reception, it seems to her that the sound
      stops suddenly. */


   F11 200 OK(CANCEL) Bob -> Proxy

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0


   F12 487 Request Terminated(INVITE) Bob -> Proxy

   SIP/2.0 487 Request Terminated
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1
   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=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Content-Length: 0


   F13 ACK(INVITE) Proxy -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com


Hasebe                                                           [Page 54]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   CSeq: 1 ACK
   Content-Length: 0


   F14 INVITE Proxy -> Carol

   INVITE sip:carol@client.chicago.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK83749a.1
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Max-Forwards: 69
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=udp>
   Supported: 100rel
   Content-Type: application/sdp
   Content-Length: 151

   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


   F15 180 Ringing Carol -> Proxy

   SIP/2.0 180 Ringing
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK83749a.1
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=456654
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:carol@client.chicago.example.com>
   Content Length:0


   F16 180 Ringing Proxy -> Alice

   SIP/2.0 180 Ringing
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101


Hasebe                                                           [Page 55]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=456654
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:carol@client.chicago.example.com>
   Content Length:0

   /* Proxy and Alice establish the second Early dialog when they
      receive a 180 response from Carol. */


   F17 200 OK Carol -> Proxy


   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK83749a.1
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=456654
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:carol@client.chicago.example.com>
   Content Length: 151

   v=0

   o=carol 2890844922 2890844922 IN IP4 client.chicago.example.com
   s=Session SDP
   c=IN IP4 client.chicago.example.com
   t=3034423619 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000


   F18 200 OK Proxy -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=456654
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:carol@client.chicago.example.com>
   Content Length: 151



Hasebe                                                           [Page 56]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   v=0
   o=carol 2890844922 2890844922 IN IP4 client.chicago.example.com
   s=Session SDP
   c=IN IP4 client.chicago.example.com
   t=3034423619 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

   /* By 200 OK response, all early dialogs are terminated except
      for one that was confirmed. */


   F19 ACK Alice -> Proxy

   ACK sip:carol@client.chicago.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bq9
   Max-Forwards: 70
   Route: <sip:ss.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=456654
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 ACK
   Content-Length: 0


   F20 ACK Proxy -> Carol

   ACK sip:carol@client.chicago.example.com SIP/2.0
   Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bq9
    ;received=192.0.2.101
   Max-Forwards: 69
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=456654
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 ACK
   Content-Length: 0


3.3.2 A BYE on the early dialog

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


Hasebe                                                           [Page 57]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |    200 OK(BYE) F4      |
     |<-----------------------|
     |         487 F5         |
     |<-----------------------|
     |         ACK F6         |
     |----------------------->|
     |                        |
     |                        |


   In this scenario, Alice establishes an early dialog with the
   receiving 180 response. Alice sends a BYE on the early dialog.
   According to Section 15 of RFC3261, callee's UA MUST NOT send
   a BYE on early dialogs, but the caller's UA MAY send a BYE on
   early dialogs.


   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: 151

   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


   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


Hasebe                                                           [Page 58]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Contact: <sip:bob@client.biloxi.example.com;transport=udp>
   Content-Length: 0

   /* Alice forms an early dialog by receiving a 180 response to ini-INVITE.
      However Bob is not sure that Alice received the 180 response. */


   F3 BYE Alice -> Bob

   BYE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
   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 BYE
   Content-Length: 0

   /* Alice sends a BYE on the early dialog and Alice terminates
      a session (if any). */


   F4 200 OK(BYE) Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
    ;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: 2 BYE
   Content-Length: 0

   /* Bob sends a 200 OK to a BYE of Alice, and Bob terminates
      a session (if any). */


   F5 487 Request Terminated(INVITE) Bob -> Alice

   SIP/2.0 487 Request Terminated
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
    ;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

   /* Bob should terminate the early dialog when he receives a BYE.


Hasebe                                                           [Page 59]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


      Bob sends a 487 response to terminate a INVITE transaction
      in the similar way to handle a CANCEL from Alice, because the
      INVITE transaction remains after terminating the early dialog. */


   F6 ACK Alice -> Bob

   ACK 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 ACK
   Contact: <sip:alice@client.atlanta.example.com;transport=udp>
   Content-Length: 0

   /* Alice sends an ACK to a 487 response as processing of the
      ini-INVITE transaction. (The dialog has been already terminated,
      but the ini-INVITE transaction remains) */


3.3.3 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 |
     |------------   -------------|
     |            \ /             |
     |             X              |
     |            / \             |
     |<-----------   ------------>|
     |   491 F8        491 F7     |
     |------------   -------------|
     |            \ /             |
     |             X              |
     |            / \             |
     |<-----------   ------------>|


Hasebe                                                           [Page 60]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |  ^ ACK F9         ^ ACK F10|
     |--|---------   ----|--------|
     |  |          \ /   |        |
     |  |           X    |        |
     |  |          / \   |        |
     |<-|----------   ---|------->|
     |  |                |        |
     |  |0-2.0 sec       |        |
     |  |                |        |
     |  v  re-INVITE F11 |        |
     |<------------------|--------|
     |     200 OK F12    |        |
     |-------------------|------->|
     |       ACK F13     |        |
     |<------------------|--------|
     |                   |        |
     |                   |2.1-4.0 sec
     |                   |        |
     |   re-INVITE F14   v        |
     |--------------------------->|
     |         200 OK F15         |
     |<---------------------------|
     |          ACK F16           |
     |--------------------------->|
     |                            |
     |                            |


   In this scenario, Alice and Bob send a re-INVITE at the same
   time. When two re-INVITEs cross in the same dialog, they resend
   re-INVITEs after different intervals.(RFC3261, 14.1) When Alice
   sends an initial INVITE, an INVITE will be sent again after
   2.1-4.0 seconds because she generated the Call-ID (owner of the
   Call-ID). Bob will send an 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 they has generated the Call-ID of the
   dialog or not, in case INVITEs may be crossed by another INVITE.


   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
   Supported: timer
   Session-Expires: 300
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>


Hasebe                                                           [Page 61]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=udp>
   Content-Type: application/sdp
   Content-Length: 151

   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


   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
   Require: timer
   Session-Expires: 300;refresher=uas
   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: 147

   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


Hasebe                                                           [Page 62]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006




   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=z9hG4bK74bd5
   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

   /* RTP streams are established between Alice and 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: 151

   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


   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=z9hG4bKnashds7
   Session-Expires: 300;refresher=uac
   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 case where a re-INVITE for a session refresh and a re-INVITE for


Hasebe                                                           [Page 63]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


      hold are sent at the same time. */


   F7 491 Request Pending Bob -> Alice

   SIP/2.0 491 Request Pending
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   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: 0

   /* Since an INVITE is in progress, a 491 response are returned. */


   F8 491 Request Pending Alice -> Bob

   SIP/2.0 491 Request Pending
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
   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


   F9 ACK(INVITE) Alice -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
   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


   F10 ACK(INVITE) Bob -> Alice

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   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 ACK
   Content-Length: 0


   F11 re-INVITE Bob -> Alice


Hasebe                                                           [Page 64]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   INVITE sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1
   Session-Expires: 300;refresher=uac
   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: 147

   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 Call-ID, Bob sends an INVITE again
      after 0.0-2.0 seconds. */


   F12 200 OK Alice -> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1
   Session-Expires: 300;refresher=uac
   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: 151

   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


   F13 ACK Bob -> Alice

   ACK sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44


Hasebe                                                           [Page 65]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Session-Expires: 300;refresher=uac
   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


   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=z9hG4bK74bf9.1
   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: 151

   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 Call-ID, Alice sends an INVITE again
      after 2.1-4.0 seconds. */


   F15 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
   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: 151

   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


Hasebe                                                           [Page 66]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   a=rtpmap:0 PCMU/8000
   a=recvonly


   F16 ACK Alice -> Bob

   ACK sip:sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f2.1
   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 ACK
   Content-Length: 0


3.3.4 UPDATE and re-INVITE crossover

   Alice                         Bob
     |                            |
     |         INVITE F1          |
     |--------------------------->|
     |      180 Ringing F2        |
     |<---------------------------|
     |                            |
     |          200 OK F3         |
     |<---------------------------|
     |           ACK F4           |
     |--------------------------->|
     |     Both Way RTP Media     |
     |<==========================>|
     |                            |
     |  UPDATE F5    re-INVITE F6 |
     |------------   -------------|
     |            \ /             |
     |             X              |
     |            / \             |
     |<-----------   ------------>|
     |   491 F8        491 F7     |
     |------------   -------------|
     |            \ /             |
     |             X              |
     |            / \             |
     |<-----------   ------------>|
     |  ^       ACK F9   ^        |
     |--|----------------|------->|
     |  |                |        |
     |  |0-2.0 sec       |        |
     |  |                |        |
     |  v  re-INVITE F10 |        |


Hasebe                                                           [Page 67]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


     |<------------------|--------|
     |     200 OK F11    |        |
     |-------------------|------->|
     |       ACK F12     |        |
     |<------------------|--------|
     |                   |        |
     |                   |2.1-4.0 sec
     |                   |        |
     |      UPDATE F13   v        |
     |--------------------------->|
     |         200 OK F14         |
     |<---------------------------|
     |                            |
     |                            |


   In this scenario, the UPDATE contains SDP offer, therefore UPDATE
   and re-INVITE are returned error response(491) as in the case of
   "re-INVITE crossover". When an UPDATE for refresher which doesn't
   contain a session description and the re-INVITE crossed each
   other, both request don't fail by 491 and succeed with 200 because
   491 means that UA have a pending request. Moreover, the same is
   equally true of UPDATE crossover, in case that either UPDATE
   contains a session description fail with 491, other cases
   succeed with 200.

Editor's Note:
 A 491 response is considered a result that UA judged the
 effectiveness of request to "What is established by SIP".
 Therefore, it is considered that 491 will be used in all the
 requests that demand operation to "What is established by SIP".


   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
   Supported: timer
   Session-Expires: 300
   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: 151



Hasebe                                                           [Page 68]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   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


   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
   Require: timer
   Session-Expires: 300;refresher=uas
   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: 147

   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=z9hG4bK74bd5


Hasebe                                                           [Page 69]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   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

   /* RTP streams are established between Alice and 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: 151

   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


   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=z9hG4bKnashds7
   Session-Expires: 300;refresher=uac
   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 case where a re-INVITE for a session refresh and a re-INVITE for
      hold are sent at the same time. */


   F7 491 Request Pending Bob -> Alice

   SIP/2.0 491 Request Pending


Hasebe                                                           [Page 70]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   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: 0

   /* Since an INVITE is in process, a 491 response are returned. */


   F8 491 Request Pending Alice -> Bob

   SIP/2.0 491 Request Pending
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
   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


   F9 ACK(INVITE) Alice -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   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 ACK
   Content-Length: 0


   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=z9hG4bKnashds7.1
   Session-Expires: 300;refresher=uac
   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: 147

   v=0
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
   s=-
   c=IN IP4 192.0.2.201
   t=0 0


Hasebe                                                           [Page 71]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

   /* Since Bob is not the owner of Call-ID, Bob sends an INVITE again
      after 0.0-2.0 seconds. */


   F11 200 OK Alice -> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1
   Session-Expires: 300;refresher=uac
   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: 151

   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


   F12 ACK Bob -> Alice

   ACK sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44
   Session-Expires: 300;refresher=uac
   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

   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=z9hG4bK74bf9.1
   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


Hasebe                                                           [Page 72]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   Content-Length: 151

   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 Call-ID, Alice sends an INVITE again
      after 2.1-4.0 seconds. */


   F14 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
   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: 151

   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


4.  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
       SDP", RFC 3264, April 2002.

   [3]  Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K.
         Summers, "Session Initiation Protocol (SIP) Basic Call Flow
         Examples", BCP 75, RFC 3665, December 2003.

   [4] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K.


Hasebe                                                           [Page 73]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


       Summers, "Session Initiation Protocol (SIP) Public Switched
       Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December
       2003.

   [5]   Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
       Responses in the Session Initiation Protocol (SIP)", RFC 3262,
       June 2002.

   [7] Rosenberg, J., Schulzrinne, H., Mahy, R., "An INVITE-Initiated
       Dialog Event Package for the Session Initiation Protocol (SIP)",
       RFC 4235, November 2005.


5.  Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


6.  Authors' Addresses

   All listed authors actively contributed large amounts of text to this
   document.

   Miki Hasebe
   NTT-east Corporation
   19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan

   EMail: hasebe.miki@east.ntt.co.jp



Hasebe                                                           [Page 74]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006



   Jun Koshiko
   NTT-east Corporation
   19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan

   EMail: j.koshiko@east.ntt.co.jp


   Yasushi Suzuki
   NTT-east Corporation
   19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan

   EMail: suzuki.yasushi@east.ntt.co.jp


   Tomoyuki Yoshikawa
   NTT-east Corporation
   19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan

   EMail: tomoyuki.yoshikawa@east.ntt.co.jp


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an


Hasebe                                                           [Page 75]
Internet Draft        Exceptional Procedure Examples         Mar 3th,2006


   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


The Expiration date for this Internet Draft is:
Aug 27th, 2006




























Hasebe                                                           [Page 76]