Internet Engineering Task Force                                M. HASEBE
Internet-Draft                                                  NTT-East
Expiration:August 14th, 2005                                  J. KOSHIKO
                                                                NTT-East
                                                               Y. SUZUKI
                                                                NTT-East
                                                            T. YOSHIKAWA
                                                                NTT-East
                                                            Feb 14, 2005


           Session Initiation Protocol  Semi Regular Examples
             draft-hasebe-sipping-semi-regular-examples-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance
   with RFC 3668.

   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 (2005).  All Rights Reserved.


Abstract

   This document gives examples of Session Initiation Protocol (SIP)
   semi-regular call flows. The elements in these call flows include
   SIP User Agents andü@Clients.  The scenarios include SIP session
   establishment. Call flow diagrams and message details are shown.



Hasebe                                                         [Page 1]


Internet Draft           Semi Regular Examples            Feb 14th,2005

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.  Semi Regular . . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.  CANCEL crossover . . . . . . . . . . . . . . . . . . . .  5
       2.2.  BYE crossover. . . . . . . . . . . . . . . . . . . . . .  8
       2.3.  Session timer crossover(re-INVITE,BYE) . . . . . . . . . 12
       2.4.  REFER crossover(REFER,BYE) . . . . . . . . . . . . . . . 16
       2.5.  A BYE is sent immediately after sending of a re-INVITE . 20
   3.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   4.  Intellectual Property Statement. . . . . . . . . . . . . . . . 25
   5.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25


1.  Overview

   The call flows shown in this document were developed in the design of
   a SIP IP communications network.

   These are some difficult interpretative examples about behavior of user
   agent followed by RFCs.

   In various situations which may happen when SIP is implemented,
   especially,when a situation which serves as a norm of inplementing in
   RFC is not illustrated, by showing operation of a terminal or a server
   as an example, it will be a help to a SIP implementers.

   For a example, the sequence which CANCEL and 200OK for INVITE cross each
   other can be considered. INVITE transaction is obviously present on the
   UAC, when the UAC sends a CANCEL message. And when the UAS sends a 200 OK
   response for INVITE and then receives CANCEL message, there is not INVITE
   transaction on the UAS. In such a case, In such a case, what response
   does UAS reply for the CANCEL.

   This document clarifies SIP UA behavior when messages cross each other
   as semi-regular condition.

   By clarifying operation under semi-regular condition, it is avoided the
   difference of the interpretation between implementations.
   And it is expected that interoperability is more progressed.

   It is the hope of the authors that this document will be useful for
   SIP implementers, designers, and protocol researchers alike and will
   help further 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].


Hasebe                                                         [Page 2]


Internet Draft           Semi Regular Examples            Feb 14th,2005


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 to aid in the understanding of the call
   flow examples.

   These flows show TCP, TLS, and UDP for transport.  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) represent crossover of
   signaling messages. The arrow indicates the direction of message flow.

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

   Messages with parentheses around their name represent optional
   messages.

   Messages are identified in the Figures as F1, F2, etc.  This
   references the message details in the list that follows the Figure.
   Comments in the message details are shown in the following form:

    /* Comments. */


Hasebe                                                         [Page 3]


Internet Draft           Semi Regular Examples            Feb 14th,2005


1.3.  SIP Protocol Assumptions

   This document does not prescribe the flows precisely as they are
   shown, but rather the flows illustrate the principles for best
   practice.  They are best practices usages (orderings, syntax,
   selection of features for the purpose, handling of error) of SIP
   methods, headers and parameters.  IMPORTANT: The exact flows here
   must not be copied as is by an implementer due to specific incorrect
   characteristics that were introduced into the document for
   convenience and are listed below.  To sum up, the basic flows
   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.  For example, Call-IDs are often repeated, and CSeq counts often begin
   at 1.  Header fields are usually shown in the same order.  Usually
   only the minimum required header field set is shown, others that
   would normally be present such as Accept, Allow, etc are
   not shown.

   Actors:

   Element       Display Name   URI                         IP Address
   -------       ------------   ---                         ----------

   User Agent    Alice          alice@atlanta.example.com   192.0.2.101
   User Agent    Bob            bob@biloxi.example.com      192.0.2.201


2.  Semi Regular

   This section details semi-regular between two SIP User
   Agents (UAs): Alice and Bob.  Alice (sip:alice@atlanta.example.com)
   and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or
   SIP-enabled devices.

   When messages cross each other as semi-regular condition, it clarifies
   how SIP UA should behave.

   For a example, the sequence which CANCEL and 200OK for INVITE cross each
   other can be considered. INVITE transaction is obviously present on the
   UAC, when the UAC sends a CANCEL message. And when the UAS sends a 200 OK
   response for INVITE and then receives CANCEL message, there is not INVITE
   transaction on the UAS anymore. Actually, the UAS state-changes itself
   into confirmed dialog already.

   The one of examples for operating in the above semi-regular case is shown
   to below.


Hasebe                                                         [Page 4]


Internet Draft           Semi Regular Examples            Feb 14th,2005


2.1. CANCEL crossover

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


   In this scenario, Alice sends a CANCEL and Bob sends a 200 OK response
   to the initial INVITE message at the same time. And then Bob sends a
   481 response replying to CANCEL from Alice.


Hasebe                                                         [Page 5]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   Message Details

   F1 INVITE Alice -> Bob

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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=tcp>
   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/TCP 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=tcp>
   Content-Length: 0


   F3 CANCEL Alice -> Bob

   CANCEL sip:bob@client.biloxi.example.com;transport=tcp SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   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:alice@client.atlanta.example.com;transport=tcp>
   Content-Length: 0

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


   F4 200 OK Bob -> Alice

   SIP/2.0 481 Call/Transaction Dose Not Exist
   Via: SIP/2.0/TCP 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=tcp>
   Content-Length: 0


Hasebe                                                         [Page 6]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   /* Alice sends a CANCEL and Bob sends a 200 OK response to the
      initial INVITE message at the same time. In the bob side,
      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/TCP 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=tcp>
   Content-Length: 0

   /* The INVITE transaction which is targeted from the CANCEL request
   already sent the final response, so Bob returns a 481 response. */



   F6 ACK Alice -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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

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


Hasebe                                                         [Page 7]


Internet Draft           Semi Regular Examples            Feb 14th,2005


2.2. BYE crossover

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


   In this scenario, Alice and Bob sends 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, an opportunity
   to complete a dialog seems to be a response or timeout of a BYE.
   Therefore, UA can transmit and receive a request normally until it
   receives a response. However, when UA sends a BYE, it is determined
   that the dialog is completed. So, in this scenario, it recommends
   that UA ends a dialog immediately after sending a BYE.
   (In section 2.4, the example from which the result obtained
    depending on the timing of a dialog end differs is shown. )
   Operation of above UA, both a BYE of Alice and Bob is returned by
   a 481.


Hasebe                                                         [Page 8]


Internet Draft           Semi Regular Examples            Feb 14th,2005

   Message Details

   F1 INVITE Alice -> Bob

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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=tcp>
   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/TCP 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=tcp>
   Content-Length: 0


   F3 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 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=tcp>
   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 9]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   F4 ACK Alice -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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 with Alice. 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
      request 1 generated by Bob) */


   F5 BYE Alice -> Bob

   BYE  sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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 terminates a session by having sent a BYE.
      RTP streams are terminated. */

   /* A session is terminated by sending a BYE. Although a dialog is
     completed by receiving a response or a timeout, when UA sends a
     BYE, it is determined that the dialog is completed, a dialog is
     also terminated ignited by BYE sending. */


Hasebe                                                         [Page 10]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   F6 BYE Bob -> Alice

   BYE sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP 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 BYE simultaneously with Alice.
      Bob terminates a session and dialog. */


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

   SIP/2.0 481 Call/Transaction Does Not Exist
   Via: SIP/2.0/TCP 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 already terminated, the BYE is returned
      by a 481. */


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

   SIP/2.0 481 Call/Transaction Does Not Exist
   Via: SIP/2.0/TCP 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 Bob has terminated the dialog by sending a BYE,
      a BYE which Alice sent is also returned by a 481. */


Hasebe                                                         [Page 11]


Internet Draft           Semi Regular Examples            Feb 14th,2005


2.3. Session timer crossover(re-INVITE,BYE)

   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  |
     |---------     ----------|
     |          \ /           |
     |           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.
   Although TU of Bob has terminated the dialog by BYE, since the
   client transaction of a re-INVITE still exists, a client
   transaction sends ACK to 481 responses.


Hasebe                                                         [Page 12]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   Message Details

   F1 INVITE Alice -> Bob

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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=tcp>
   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/TCP 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=tcp>
   Content-Length: 0


Hasebe                                                         [Page 13]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   F3 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 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=tcp>
   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 there was no specification of refresher, Bob sets up
      refresher=uas. */



   F4 ACK Alice -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   Supported: timer
   Session-Expires: 300
   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 with Alice. 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
      request 1 generated by Bob) */


   F5 BYE Alice -> Bob

   BYE  sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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 dialog. */


Hasebe                                                         [Page 14]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   F6 re-INVITE Bob -> Alice

   INVITE sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP 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 same time.
      In the Alice side, the dialog is completed, and in the Bob side,
      the dialog is terminated, the state of a dialog is mismatching. */



   F7 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 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/TCP 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 INVITE
   Content-Length: 0

   /* Since Alice has already terminated the dialog by a BYE,
      it returns a 481. */


   F9 ACK Bob -> Alice

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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: 1 INVITE
   Content-Length: 0


Hasebe                                                         [Page 15]


Internet Draft           Semi Regular Examples            Feb 14th,2005


2.4. REFER crossover(REFER,BYE)

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


   In this scenario, Bob sends REFER, and Alice sends BYE at
   the same time. REFER is sent as a method in the same dialog.
   In the Alice side, as 2.2 described, a dialog is terminated
   ignited by sending a BYE request, and Alice returns a 481 to
   REFER.
   (If a dialog is terminated after receiving the response of a
    BYE (with or timeout), Alice returns 202 to the REFER and the
    REFER method is successful. Also when a dialog is terminated,
    it is not clear whether UA continues call transfer. )


Hasebe                                                         [Page 16]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   Message Details

   F1 INVITE Alice -> Bob

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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=tcp>
   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/TCP 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=tcp>
   Content-Length: 0


   F3 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 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=tcp>
   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 17]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   F4 ACK Alice -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   Supported: timer
   Session-Expires: 300
   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 with Alice. 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
      request 1 generated by Bob) */


   F5 BYE Alice -> Bob

   BYE  sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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 dialog. */



   F6 REFER Bob -> Alice

   REFER sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP 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 REFER
   Content-Length: 0

   /* Alice sends a BYE, and Bob sends a REFER at same time.
      The REFER is sent as a method in the same dialog.
      In the Alice side, the dialog is completed, and in the Bob side,
      the dialog is terminated,the state of a dialog is mismatching. */


Hasebe                                                         [Page 18]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   F7 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 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/TCP 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 has already terminated the dialog by a BYE,
      it returns a 481. */


Hasebe                                                         [Page 19]


Internet Draft           Semi Regular Examples            Feb 14th,2005


2.5. A BYE is sent immediately after sending of a re-INVITE

   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
   of a re-INVITE,
   (A user is not conscious of refresher sent automatically.
    For example, in the case of a telephone application, placing
    a receiver immediately after refresher is considered enough. )
   When Alice receives BYE, even if it terminates a dialog and
   does not receive ACK, it stops resending of 200 OK. Since ACK
   of 2xx responses is not a server transaction, it is that a UAS
   core transmits directly. It differs from the case of an error
   response of 2.4. With a UAS core, since the dialog which matches
   200 OK received is terminated, 200 OK is disregarded, without
   sending ACK.


Hasebe                                                         [Page 20]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   Message Details

   F1 INVITE Alice -> Bob

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP 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=tcp>
   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/TCP 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=tcp>
   Content-Length: 0


Hasebe                                                         [Page 21]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   F3 200 OK Bob -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 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=tcp>
   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/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   Supported: timer
   Session-Expires: 300
   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 with Alice. 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
      request 1 generated by Bob) */


Hasebe                                                         [Page 22]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   F5 re-INVITE Bob -> Alice

   INVITE sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP 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/TCP 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 dialog, without receiving the
      response of re-INVITE. */


   F7 200 OK Alice -> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 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 returns 200 OK to a re-INVITE.
      The state of a dialog is mismatching.*/


Hasebe                                                         [Page 23]


Internet Draft           Semi Regular Examples            Feb 14th,2005


   F8 200 OK Alice -> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 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 resend 200 OK to a re-INVITE.
      (Since the dialog is terminated by reception of BYE, 200 OK dose
      not resend, even if it does not receive ACK from Bob.) */


3.  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.
       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.


Hasebe                                                         [Page 24]


Internet Draft           Semi Regular Examples            Feb 14th,2005


4.  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.


5.  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@rdc.east.ntt.co.jp


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

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


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

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


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

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


Hasebe                                                         [Page 25]


Internet Draft           Semi Regular Examples            Feb 14th,2005


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 implementers 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
   "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 (2004).  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:
August 14th, 2005

Hasebe                                                         [Page 26]

Internet Draft           Semi Regular Examples            Feb 14th,2005