Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+   SearchTech-invite World Map Symbol

RFC 7989

 
 
 

End-to-End Session Identification in IP-Based Multimedia Communication Networks

Part 2 of 3, p. 17 to 37
Prev Section       Next Section

 


prevText      Top      ToC       Page 17 
10.  Examples of Various Call Flow Operations

   Seeing something frequently makes understanding easier.  With that in
   mind, this section includes several call flow examples with the
   initial UUID and the complete session identifier indicated per
   message, as well as examples of when the session identifier changes
   according to the rules within this document during certain
   operations/functions.

   This section is for illustrative purposes only and is non-normative.
   In the following flows, "RTP" refers to the Real-time Transport
   Protocol [RFC3550].

   In the examples in this section, "N" represents a nil UUID and other
   letters represent the unique UUID values corresponding to endpoints
   or MCUs.

Top      Up      ToC       Page 18 
10.1.  Basic Call with Two UUIDs

   Session-ID
     ---     Alice            B2BUA             Bob            Carol
    {A,N}      |---INVITE F1--->|                |
    {A,N}      |                |---INVITE F2--->|
    {B,A}      |                |<---200 OK F3---|
    {B,A}      |<---200 OK F4---|                |
    {A,B}      |-----ACK F5---->|                |
    {A,B}      |                |-----ACK F6---->|
               |<==============RTP==============>|

            Figure 1: Session-ID Creation When Alice Calls Bob

   General operation of this example:

   o  UA-Alice populates the "local-uuid" portion of the Session-ID
      header field value.

   o  UA-Alice sends its UUID in the SIP INVITE request and populates
      the "remote" parameter with a nil value (32 zeros).

   o  The B2BUA receives an INVITE request with both a "local-uuid"
      portion of the Session-ID header field value from UA-Alice as well
      as the nil "remote-uuid" value and transmits the INVITE request
      towards UA-Bob with an unchanged Session-ID header field value.

   o  UA-Bob receives the Session-ID and generates its "local-uuid"
      portion of the Session-ID header field value UUID to construct the
      whole/complete Session-ID header field value, at the same time
      transferring UA-Alice's UUID unchanged to the "remote-uuid"
      portion of the Session-ID header field value in the 200 OK SIP
      response.

   o  The B2BUA receives the 200 OK response with a complete Session-ID
      header field value from UA-Bob and transmits the 200 OK response
      towards UA-Alice with an unchanged Session-ID header field value.

   o  UA-Alice, upon reception of the 200 OK from the B2BUA, transmits
      the ACK towards the B2BUA.  The construction of the Session-ID
      header field in this ACK is that of UA-Alice's UUID is the "local-
      uuid", and UA-Bob's UUID populates the "remote-uuid" portion of
      the header-value.

   o  The B2BUA receives the ACK with a complete Session-ID header field
      from UA-Alice and transmits the ACK towards UA-Bob with an
      unchanged Session-ID header field value.

Top      Up      ToC       Page 19 
   Below is a SIP message exchange illustrating proper use of the
   Session-ID header field.  For the sake of brevity, non-essential
   headers and message bodies are omitted.


   F1 INVITE Alice -> B2BUA

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhds
   Max-Forwards: 70
   To: Bob <sip:bob@biloxi.example.com>
   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   Session-ID: ab30317f1a784dc48ff824d0d3715d86
    ;remote=00000000000000000000000000000000
   CSeq: 314159 INVITE
   Contact: <sip:alice@pc33.atlanta.example.com>
   Content-Type: application/sdp
   Content-Length: 142

   (Alice's SDP not shown)

Top      Up      ToC       Page 20 
   F2 INVITE B2BUA -> Bob

   INVITE sip:bob@192.168.10.20 SIP/2.0
   Via: SIP/2.0/UDP server10.biloxi.example.com
    ;branch=z9hG4bK4b43c2ff8.1
   Via: SIP/2.0/UDP pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhds;received=10.1.3.33
   Max-Forwards: 69
   To: Bob <sip:bob@biloxi.example.com>
   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   Session-ID: ab30317f1a784dc48ff824d0d3715d86
    ;remote=00000000000000000000000000000000
   CSeq: 314159 INVITE
   Contact: <sip:alice@pc33.atlanta.example.com>
   Record-Route: <sip:server10.biloxi.example.com;lr>
   Content-Type: application/sdp
   Content-Length: 142

   (Alice's SDP not shown)


   F3 200 OK Bob -> B2BUA

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP server10.biloxi.example.com
    ;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1
   Via: SIP/2.0/UDP pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhds;received=10.1.3.33
   To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   Session-ID: 47755a9de7794ba387653f2099600ef2
    ;remote=ab30317f1a784dc48ff824d0d3715d86
   CSeq: 314159 INVITE
   Contact: <sip:bob@192.168.10.20>
   Record-Route: <sip:server10.biloxi.example.com;lr>
   Content-Type: application/sdp
   Content-Length: 131

   (Bob's SDP not shown)

Top      Up      ToC       Page 21 
   F4 200 OK B2BUA -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP pc33.atlanta.example.com
    ;branch=z9hG4bK776asdhds;received=10.1.3.33
   To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   Session-ID: 47755a9de7794ba387653f2099600ef2
    ;remote=ab30317f1a784dc48ff824d0d3715d86
   CSeq: 314159 INVITE
   Contact: <sip:bob@192.168.10.20>
   Record-Route: <sip:server10.biloxi.example.com;lr>
   Content-Type: application/sdp
   Content-Length: 131

   (Bob's SDP not shown)


   F5 ACK Alice -> B2BUA

   ACK sip:bob@192.168.10.20 SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.example.com
    ;branch=z9hG4bKnashds8
   Route: <sip:server10.biloxi.example.com;lr>
   Max-Forwards: 70
   To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   Session-ID: ab30317f1a784dc48ff824d0d3715d86
    ;remote=47755a9de7794ba387653f2099600ef2
   CSeq: 314159 ACK
   Content-Length: 0

Top      Up      ToC       Page 22 
   F6 ACK B2BUA -> Bob

   ACK sip:bob@192.168.10.20 SIP/2.0
   Via: SIP/2.0/UDP server10.biloxi.example.com
    ;branch=z9hG4bK4b43c2ff8.2
   Via: SIP/2.0/UDP pc33.atlanta.example.com
    ;branch=z9hG4bKnashds8;received=10.1.3.33
   Max-Forwards: 70
   To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
   Session-ID: ab30317f1a784dc48ff824d0d3715d86
    ;remote=47755a9de7794ba387653f2099600ef2
   CSeq: 314159 ACK
   Content-Length: 0


   The remaining examples in this section do not display the complete
   SIP message exchange.  Instead, they simply use the set notation
   described in Section 4.2 to show the session identifier exchange
   throughout the particular call flow being illustrated.

10.2.  Basic Call Transfer Using REFER

   From the example built within Section 10.1, we proceed to this 'Basic
   Call Transfer using REFER' example.  Note that this is a mid-dialog
   REFER in contrast with the out-of-dialog REFER in Section 10.9.

Top      Up      ToC       Page 23 
      Session-ID
         ---     Alice            B2BUA             Bob            Carol
                   |                |                |               |
                   |<==============RTP==============>|               |
        {B,A}      |                |<---re-INVITE---|               |
        {B,A}      |<---re-INVITE---| (puts Alice on Hold)           |
        {A,B}      |-----200 OK---->|                |               |
        {A,B}      |                |-----200 OK---->|               |
        {B,A}      |                |<-----ACK-------|               |
        {B,A}      |<-----ACK-------|                |               |
                   |                |                |               |
        {B,A}      |                |<----REFER------|               |
        {B,A}      |<----REFER------|                |               |
        {A,B}      |-----200 OK---->|                |               |
        {A,B}      |                |-----200 OK---->|               |
        {A,B}      |-----NOTIFY---->|                |               |
        {A,B}      |                |-----NOTIFY---->|               |
        {B,A}      |                |<----200 OK-----|               |
        {B,A}      |<----200 OK-----|                |               |
                   |                |                |               |
        {A,N}      |-----INVITE---->|                                |
        {A,N}      |                |-----INVITE-------------------->|
        {C,A}      |                |<----200 OK---------------------|
        {C,A}      |<----200 OK-----|                                |
        {A,C}      |------ACK------>|                                |
        {A,C}      |                |------ACK---------------------->|
                   |                |                |               |
                   |<======================RTP======================>|
                   |                |                |               |
        {A,B}      |-----NOTIFY---->|                |               |
        {A,B}      |                |-----NOTIFY---->|               |
        {B,A}      |                |<----200 OK-----|               |
        {B,A}      |<----200 OK-----|                |               |
        {B,A}      |                |<-----BYE-------|               |
        {B,A}      |<-----BYE-------|                |               |
        {A,B}      |-----200 OK---->|                |               |
        {A,B}      |                |-----200 OK---->|               |
                   |                |                |               |

                    Figure 2: Call Transfer Using REFER

Top      Up      ToC       Page 24 
   General operation of this example:

   Starting from the existing Alice/Bob call described in Figure 1 of
   this document, which established an existing Session-ID header field
   value:

   o  UA-Bob requests Alice to call Carol, using a REFER transaction, as
      described in [RFC3515].  UA-Alice is initially put on hold, then
      told in the REFER who to contact with a new INVITE, in this case
      UA-Carol.  This Alice-to-Carol dialog will have a new Call-ID;
      therefore, it requires a new Session-ID header field value.  The
      wrinkle here is we can, and will, use Alice's UUID from her
      existing dialog with Bob in the new INVITE request to Carol.

   o  UA-Alice retains her UUID from the Alice-to-Bob call {A} when
      requesting a call with UA-Carol.  This is placed in the "local-
      uuid" portion of the Session-ID header field value, at the same
      time inserting a nil "remote-uuid" value (because Carol's UA has
      not yet received the UUID value).  This same UUID traverses the
      B2BUA unchanged.

   o  UA-Carol receives the INVITE request with a session identifier
      UUID {A,N}, replaces the "A" UUID value into the "remote-uuid"
      portion of the Session-ID header field value and creates its own
      UUID {C}, and places this value in the "local-uuid" portion of the
      Session-ID header field value, thereby removing the "N" (nil)
      value altogether.  This combination forms a full session
      identifier {C,A} in the 200 OK to the INVITE.  This Session-ID
      header field traverses the B2BUA unchanged towards UA-Alice.

   o  UA-Alice receives the 200 OK with the session identifier {C,A} and
      responds to UA-Carol with an ACK (just as in Figure 1, this
      switches the places of the two UUID fields), and generates a
      NOTIFY request to Bob with a session identifier {A,B} indicating
      that the call transfer was successful.

   o  It does not matter which UA terminates the Alice-to-Bob call;
      Figure 2 shows UA-Bob terminating the call.

10.3.  Basic Call Transfer Using Re-INVITE

   From the example built within Section 10.1, we proceed to this 'Basic
   Call Transfer using re-INVITE' example.

   Alice is talking to Bob.  Bob pushes a button on his phone to
   transfer Alice to Carol via the B2BUA (using re-INVITE).

Top      Up      ToC       Page 25 
      Session-ID
         ---     Alice            B2BUA             Bob            Carol
                   |                |                |               |
                   |<==============RTP==============>|               |
                   |                |                |               |
                   |                | <--- (non-standard signaling)  |
        {A,B}      |                |---re-INVITE--->|               |
        {B,A}      |                |<-----200 OK----|               |
        {A,B}      |                |-----ACK------->|               |
                   |                |                |               |
        {A,N}      |                |-----INVITE-------------------->|
        {C,A}      |                |<----200 OK---------------------|
        {A,C}      |                |------ACK---------------------->|
                   |                |                |               |
                   |<======================RTP======================>|
                   |                |                |               |
        {A,B}      |                |------BYE------>|               |
        {B,A}      |                |<----200 OK-----|               |
                   |                |                |               |
        {C,A}      |<--re-INVITE----|                |               |
        {A,C}      |----200 OK----->|                |               |
        {C,A}      |<-----ACK-------|                |               |
                   | (Suppose Alice modifies the session)            |
        {A,C}      |---re-INVITE--->|                |               |
        {A,C}      |                |---re-INVITE------------------->|
        {C,A}      |                |<---200 OK----------------------|
        {C,A}      |<---200 OK------|                |               |
        {A,C}      |------ACK------>|                |               |
        {A,C}      |                |------ACK---------------------->|
                   |                |                |               |

                  Figure 3: Call Transfer Using Re-INVITE

   General operation of this example:

   o  We assume the call between Alice and Bob from Section 10.1 is
      operational with session identifier {A,B}.

   o  Bob uses non-standard signaling to the B2BUA to initiate a call
      transfer from Alice to Carol.  This could also be initiated via a
      REFER message from Bob, but the signaling that follows might still
      be similar to the above flow.  In either case, Alice is completely
      unaware of the call transfer until a future point in time when
      Alice receives a message from Carol.

   o  The B2BUA sends a re-INVITE request with the session identifier
      {"local-uuid" = "A", "remote-uuid" = "B"} to renegotiate the
      session with Bob.

Top      Up      ToC       Page 26 
   o  The B2BUA sends a new INVITE request with Alice's UUID {"local-
      uuid" = "A"} to Carol.

   o  Carol receives the INVITE request and accepts the request and adds
      her UUID {C} to the session identifier for this session {"local-
      uuid" = "C", "remote-uuid" = "A"}.

   o  The B2BUA then terminates the call to Bob with a BYE using the
      session identifier {"local-uuid" = "A", "remote-uuid" = "B"}.

   o  The B2BUA sends a re-INVITE request to Alice to update Alice's
      view of the session identifier.

   o  When Alice later attempts to modify the session with a re-INVITE,
      Alice will send "remote-uuid" = "C" toward Carol because it had
      previously received the updated UUID in the re-INVITE request from
      the B2BUA.  The B2BUA maintains the session identifier {"local-
      uuid" = "A", "remote-uuid" = "C"}.  Carol replies with the "local-
      uuid" = "C", "remote-uuid" = "A" to reflect what was received in
      the INVITE request (which Carol already knew from previous
      exchanges with the B2BUA).  Alice then includes "remote-uuid" =
      "C" in the subsequent ACK message.

10.4.  Single Focus Conferencing

   Multiple users call into a conference server (for example, an MCU) to
   attend one of many conferences hosted on or managed by that server.
   Each user has to identify which conference they want to join, but
   this information is not necessarily in the SIP messaging.  It might
   be done by having a dedicated address for the conference or via an
   Interactive Voice Response (IVR), as assumed in this example and
   depicted with the use of M1, M2, and M3.  Each user in this example
   goes through a two-step process of signaling to gain entry onto their
   conference call, which the conference focus identifies as "M".

Top      Up      ToC       Page 27 
      Session-ID                Conference
         ---     Alice            Focus             Bob            Carol
                   |                |                |               |
                   |                |                |               |
        {A,N}      |----INVITE----->|                |               |
        {M1,A}     |<---200 OK------|                |               |
        {A,M1}     |-----ACK------->|                |               |
                   |<====RTP=======>|                |               |
        {M',A}     |<---re-INVITE---|                |               |
        {A,M'}     |-----200 OK---->|                |               |
        {M',A}     |<-----ACK-------|                |               |
                   |                |                |               |
                   |                |                |               |
        {B,N}      |                |<----INVITE-----|               |
        {M2,B}     |                |-----200 OK---->|               |
        {B,M2}     |                |<-----ACK-------|               |
                   |                |<=====RTP======>|               |
        {M',B}     |                |---re-INVITE--->|               |
        {B,M'}     |                |<----200 OK-----|               |
        {M',B}     |                |------ACK------>|               |
                   |                |                |               |
                   |                |                |               |
        {C,N}      |                |<--------------------INVITE-----|
        {M3,C}     |                |---------------------200 OK---->|
        {C,M3}     |                |<---------------------ACK-------|
                   |                |<=====================RTP======>|
        {M',C}     |                |-------------------re-INVITE--->|
        {C,M'}     |                |<--------------------200 OK-----|
        {M',C}     |                |----------------------ACK------>|

                 Figure 4: Single Focus Conference Bridge

   General operation of this example:

   Alice calls into a conference server to attend a certain conference.
   This is a two-step operation since Alice cannot include the
   conference ID at this time and/or any passcode in the INVITE request.
   The first step is Alice's UA calling another UA to participate in a
   session.  This will appear to be similar as the call flow in Figure 1
   (in Section 10.1).  What is unique about this call is the second
   step: the conference server sends a re-INVITE request with its second
   UUID, but maintaining the UUID Alice sent in the first INVITE.  This
   subsequent UUID from the conference server will be the same for each
   UA that calls into this conference server participating in this same
   conference bridge/call, which is generated once Alice typically
   authenticates and identifies which bridge she wants to participate
   on.

Top      Up      ToC       Page 28 
   o  Alice sends an INVITE request to the conference server with her
      UUID {A} and a "remote-uuid" = "N".

   o  The conference server responds with a 200 OK response, which
      replaces the "N" UUID with a temporary UUID ("M1") as the "local-
      uuid" and a "remote-uuid" = "A".

   NOTE: this 'temporary' UUID is a real UUID; it is only temporary to
   the conference server because it knows that it is going to generate
   another UUID to replace the one just sent in the 200 OK response.

   o  Once Alice, the user, gains access to the IVR for this conference
      server, she enters a specific conference ID and whatever passcode
      (if needed) to enter a specific conference call.

   o  Once the conference server is satisfied Alice has identified which
      conference she wants to attend (including any passcode
      verification), the conference server re-INVITEs Alice to the
      specific conference and includes the Session-ID header field value
      component "local-uuid" = "M'" (and "remote-uuid" = "A") for that
      conference.  All valid participants in the same conference will
      receive this same UUID for identification purposes and to better
      enable monitoring and tracking functions.

   o  Bob goes through this two-step process of an INVITE transaction,
      followed by a re-INVITE transaction to get this same UUID ("M'")
      for the conference.

   o  In this example, Carol (and each additional user) goes through the
      same procedures as Alice and Bob to get on this same conference.

10.5.  Single Focus Conferencing Using a Web-Based Conference Service

   Alice, Bob, and Carol call into the same web-based conference.  Note
   that this is one of many ways of implementing this functionality, and
   it should not be construed as the preferred way of establishing a
   web-based conference.

Top      Up      ToC       Page 29 
      Session-ID                Conference
         ---     Alice            Focus             Bob            Carol
                   |                |                |               |
                   |<** HTTPS *****>|                |               |
                   |  Transaction   |                |               |
                   |                |                |               |
        {M,N}      |<----INVITE-----|                |               |
        {A,M}      |-----200 OK---->|                |               |
        {M,A}      |<-----ACK-------|                |               |
                   |<=====RTP======>|                |               |
                   |                |                |               |
                   |                |<** HTTPS *****>|               |
                   |                |  Transaction   |               |
                   |                |                |               |
        {M,N}      |                |-----INVITE---->|               |
        {B,M}      |                |<----200 OK-----|               |
        {M,B}      |                |------ACK------>|               |
                   |                |<=====RTP======>|               |
                   |                |                |               |
                   |                |<****************** HTTPS *****>|
                   |                |                   Transaction  |
                   |                |                |               |
        {M,N}      |                |--------------------INVITE----->|
        {C,M}      |                |<-------------------200 OK------|
        {M,C}      |                |---------------------ACK------->|
                   |                |<====================RTP=======>|

                Figure 5: Single Focus Web-Based Conference

   General operation of this example:

   o  Alice communicates with the web server that she wants to join a
      certain meeting by using a meeting number and including UA-Alice's
      contact information (phone number, URI, and/or IP address, etc.)
      for each device she wants for this conference call.  For example,
      the audio and video (A/V) play-out devices could be separate
      units.

   o  The Conference Focus server sends the INVITE request (Session-ID
      header field value components "local-uuid" = "M" and a remote UUID
      of "N", where "M" equals the "local-uuid" for each participant on
      this conference bridge) to UA-Alice to start a session with that
      server for this A/V conference call.

Top      Up      ToC       Page 30 
   o  Upon receiving the INVITE request from the conference focus
      server, Alice responds with a 200 OK.  Her UA moves the "local-
      uuid" unchanged into the "remote-uuid" field, generates her own
      UUID, and places that into the "local-uuid" field to complete the
      Session-ID construction.

   o  Bob and Carol perform same function to join this same A/V
      conference call as Alice.

10.6.  Cascading Conference Bridges

10.6.1.  Establishing a Cascaded Conference

   Expanding conferencing capabilities requires cascading conference
   bridges.  A conference bridge, or MCU, needs a way to identify itself
   when contacting another MCU.  [RFC4579] defines the "isfocus" Contact
   header field value parameter just for this purpose.


      Session-ID
         ---     MCU-1            MCU-2            MCU-3           MCU-4
                   |                |                |               |
        {M',N}     |----INVITE----->|                |               |
        {J,M'}     |<---200 OK------|                |               |
        {M',J}     |-----ACK------->|                |               |

      Figure 6: MCUs Communicating Session Identifier UUID for Bridge

   Regardless of which MCU (1 or 2) a UA contacts for this conference,
   once the above exchange has been received and acknowledged, the UA
   will get the same {M',N} UUID pair from the MCU for the complete
   session identifier.

   A more complex form would be a series of MCUs all being informed of
   the same UUID to use for a specific conference.  This series of MCUs
   can be informed in one of two ways:

   o  All by one MCU (that initially generates the UUID for the
      conference).

   o  The MCU that generates the UUID informs one or several MCUs of
      this common UUID, and then they inform downstream MCUs of this
      common UUID that each will be using for this one conference.

Top      Up      ToC       Page 31 
      Session-ID
         ---     MCU-1            MCU-2            MCU-3           MCU-4
                   |                |                |               |
        {M',N}     |----INVITE----->|                |               |
        {J,M'}     |<---200 OK------|                |               |
        {M',J}     |-----ACK------->|                |               |
                   |                |                |               |
        {M',N}     |---------------------INVITE----->|               |
        {K,M'}     |<--------------------200 OK------|               |
        {M',K}     |----------------------ACK------->|               |
                   |                |                |               |
        {M',N}     |-------------------------------------INVITE----->|
        {L,M'}     |<------------------------------------200 OK------|
        {M',L}     |--------------------------------------ACK------->|

                        Figure 7: MCU Communicating
               Session Identifier UUID to More Than One MCU

   General operation of this example:

   o  The MCU generating the session identifier UUID communicates this
      in a separate INVITE, having a Contact header with the "isfocus"
      Contact header field value parameter.  This will identify the MCU
      as what [RFC4579] calls a "conference-aware" SIP entity.

   o  An MCU that receives this {M',N} UUID pair in an inter-MCU
      transaction can communicate the M' UUID in a manner in which it
      was received to construct a hierarchical cascade (though this time
      this second MCU would be the UAC MCU).

   o  Once the conference is terminated, the cascaded MCUs will receive
      a BYE message to terminate the cascade.

10.6.2.  Calling Into Cascaded Conference Bridges

   Here is an example of how a UA, Robert for example, calls into a
   cascaded conference focus.  Because MCU-1 has already contacted MCU-3
   (the MCU where Robert is going to join the conference), MCU-3 already
   has the Session-ID (M') for this particular conference call.

Top      Up      ToC       Page 32 
      Session-ID
         ---     MCU-1            MCU-2            MCU-3          Robert
                   |                |                |               |
        {M',N}     |----INVITE----->|                |               |
        {J,M'}     |<---200 OK------|                |               |
        {M',J}     |-----ACK------->|                |               |
                   |                |                |               |
        {M',N}     |---------------------INVITE----->|               |
        {K,M'}     |<--------------------200 OK------|               |
        {M',K}     |----------------------ACK------->|               |
                   |                |                |               |
        {R,N}      |                |                |<---INVITE-----|
        (M',R}     |                |                |----200 OK---->|
        {R,M'}     |                |                |<----ACK-------|

              Figure 8: A UA Calling Into a Cascaded MCU UUID

   General operation of this example:

   o  The UA, Robert in this case, INVITEs the MCU to join a particular
      conference call.  Robert's UA does not know anything about whether
      this is the main MCU of the conference call or a cascaded MCU.
      Robert likely does not know MCUs can be cascaded, he just wants to
      join a particular call.  As is the case with any standard
      implementation, he includes a nil "remote-uuid".

   o  The cascaded MCU, upon receiving this INVITE request from Robert,
      replaces the nil UUID with the UUID value communicated from MCU-1
      for this conference call as the "local-uuid" in the SIP response,
      thus moving Robert's UUID "R" to the "remote-uuid" value.

   o  The ACK has the Session-ID {R,M'}, completing the three-way
      handshake for this call establishment.  Robert has now joined the
      conference call originated from MCU-1.

   o  Once the conference is terminated, the cascaded MCUs will receive
      a BYE message to terminate the cascade.

Top      Up      ToC       Page 33 
10.7.  Basic 3PCC for Two UAs

   An external entity sets up calls to both Alice and Bob for them to
   talk to each other.

      Session-ID
         ---     Alice            B2BUA             Bob            Carol
                   |                |                |
        {X,N}      |<----INVITE-----|                |
        {A,X}      |-----200 OK---->|                |
        {A,N}      |                |----INVITE----->|
        {B,A}      |                |<---200 OK------|
        {B,A}      |<-----ACK-------|                |
        {A,B}      |                |------ACK------>|
                   |<==============RTP==============>|

            Figure 9: 3PCC-Initiated Call between Alice and Bob

   General operation of this example:

   o  Some out-of-band procedure directs a B2BUA (or other SIP server)
      to have Alice and Bob talk to each other.  In this case, the SIP
      server has to be transaction stateful, if not dialog stateful.

   o  The SIP server INVITEs Alice to a session and uses a temporary
      UUID {X} and a nil UUID pairing.

   o  Alice receives and accepts this call setup and replaces the nil
      UUID with her UUID {A} in the session identifier, now {A,X}.

   o  The transaction-stateful SIP server receives Alice's UUID {A} in
      the local UUID portion and keeps it there; and it discards its own
      UUID {X}, replacing this with a nil UUID value in the INVITE
      request to Bob as if this came from Alice originally.

   o  Bob receives and accepts this INVITE request and adds his own UUID
      {B} to the session identifier, now {B,A}, for the response.

   o  The session is established.

10.8.  Handling in 100 Trying SIP Response and CANCEL Request

   The following two subsections show examples of the session identifier
   for a 100 Trying response and a CANCEL request in a single call flow.

Top      Up      ToC       Page 34 
10.8.1.  Handling in a 100 Trying SIP Response

   The following 100 Trying response is taken from [RFC5359],
   Section 2.9 ("Call Forwarding - No Answer").

    Session-ID   Alice         SIP Server        Bob-1            Bob-2
                   |                |              |                |
      {A,N}        |----INVITE----->|              |                |
      {A,N}        |                |---INVITE---->|                |
      {N,A}        |<--100 Trying---|              |                |
      {B1,A}       |                |<-180 Ringing-|                |
      {B1,A}       |<--180 Ringing--|              |                |
                   |                |              |                |
                   |                *Request Timeout*               |
                   |                |              |                |
      {A,N}        |                |---CANCEL---->|                |
      {B1,A}       |                |<--200 OK-----|                |
      {B1,A}       |                |<---487-------|                |
      {A,B1}       |                |---- ACK ---->|                |
                   |                |              |                |
      {N,A}        |<-181 Call Fwd--|              |                |
                   |                |              |                |
      {A,N}        |                |------------------INVITE------>|
      {B2,A}       |                |<----------------180 Ringing---|
      {B2,A}       |<-180 Ringing---|              |                |
      {B2,A}       |                |<-----------------200 OK ------|
      {B2,A}       |<--200 OK-------|              |                |
      {A,B2}       |----ACK-------->|              |                |
      {A,B2}       |                |------------------ACK--------->|
                   |                |              |                |
                   |<=========== Both way RTP Established =========>|
                   |                |              |                |
      {A,B2}       |----BYE-------->|              |                |
      {A,B2}       |                |--------------------BYE------->|
      {B2,A}       |                |<------------------200 OK------|
      {B2,A}       |<--200 OK-------|              |                |
                   |                |              |                |

   Figure 10: Session Identifier in the 100 Trying and CANCEL Messaging

   Below is the explanatory text from RFC 5359, Section 2.9, detailing
   what the desired behavior is in the above call flow (i.e., what the
   call flow is attempting to achieve).

      Bob wants calls to B1 forwarded to B2 if B1 is not answered
      (information is known to the SIP server).  Alice calls B1, and no
      one answers.  The SIP server then places the call to B2.

Top      Up      ToC       Page 35 
   General operation of this example:

   o  Alice generates an INVITE request because she wants to invite Bob
      to join her session.  She creates a UUID as described in
      Section 10.1, and she places that value in the "local-uuid" field
      of the Session-ID header field value.  Alice also generates a
      "remote-uuid" of nil and sends this along with the "local-uuid".

   o  The SIP server (imagine this is a B2BUA), upon receiving Alice's
      INVITE request, generates the optional provisional response 100
      Trying.  Since the SIP server has no knowledge of Bob's UUID for
      his part of the session identifier value, it cannot include his
      "local-uuid".  Rather, any 100 Trying response includes Alice's
      UUID in the "remote-uuid" portion of the Session-ID header-value
      with a nil "local-uuid" value in the response.  This is consistent
      with what Alice's UA expects to receive in any SIP response
      containing this UUID.

10.8.2.  Handling a CANCEL SIP Request

   In the same call flow example as the 100 Trying response is a CANCEL
   request.  Please refer to Figure 10 for the CANCEL request example.

   General operation of this example:

   o  In Figure 10 above, Alice generates an INVITE request with her
      UUID value in the Session-ID header field.

   o  Bob-1 responds to this INVITE request with a 180 Ringing.  In that
      response, he includes his UUID in the Session-ID header field
      value (i.e., {B1,A}); thus completing the Session-ID header field
      for this session, even though no final response has been generated
      by any of Bob's UAs.

   o  While this means that if the SIP server were to generate a SIP
      request within this session it could include the complete
      SessionID, the server sends a CANCEL request and a CANCEL request
      always uses the same Session-ID header field as the original
      INVITE request.  Thus, the CANCEL request would have a session
      identifier with the "local-uuid" = "A", and the "remote-uuid" =
      "N".

   o  As it happens with this CANCEL, the SIP server intends to invite
      another UA of Bob's (i.e., B2) for Alice to communicate with.

   o  In this example call flow, taken from RFC 5359, Section 2.9, a 181
      Call is Being Forwarded response is sent to Alice.  Since the SIP
      server generated this SIP request, and has no knowledge of Bob-2's

Top      Up      ToC       Page 36 
      UUID value, it cannot include that value in this 181.  Thus, and
      for the exact reasons the 100 Trying including the session
      identifier value, only Alice's UUID is included in the remote-uuid
      component of the Session-ID header field value, with a nil UUID
      present in the "local-uuid" component.

10.9.  Out-of-Dialog REFER Transaction

   The following call flow was extracted from Section 6.1 of [RFC5589]
   ("Successful Transfer"), with the only changes being the names of the
   UAs to maintain consistency within this document.

         Alice is the transferee
         Bob is the transferer
         and Carol is the transfer-target

     Session-ID     Bob                 Alice                 Carol
                     |                    |                     |
        {A,N}        |<-----INVITE--------|                     |
        {B,A}        |------200 OK------->|                     |
        {A,B}        |<------ACK----------|                     |
                     |                    |                     |
        {B,A}        |--INVITE {hold}---->|                     |
        {A,B}        |<-200 OK------------|                     |
        {B,A}        |--- ACK ----------->|                     |
                     |                    |                     |
        {B,A}        |--REFER------------>|(Refer-To:Carol)     |
        {A,B}        |<-202 Accepted------|                     |
                     |                    |                     |
        {A,B}        |<NOTIFY {100 Trying}|                     |
        {B,A}        |-200 OK------------>|                     |
                     |                    |                     |
        {A,N}        |                    |--INVITE------------>|
        {C,A}        |                    |<-200 OK-------------|
        {A,C}        |                    |---ACK-------------->|
                     |                    |                     |
        {A,B}        |<--NOTIFY {200 OK}--|                     |
        {B,A}        |---200 OK---------->|                     |
                     |                    |                     |
        {B,A}        |--BYE-------------->|                     |
        {A,B}        |<-200 OK------------|                     |
        {C,A}        |                    |<------------BYE-----|
        {A,C}        |                    |-------------200 OK->|

                  Figure 11: Out-Of-Dialog Call Transfer

Top      Up      ToC       Page 37 
   General operation of this example:

   o  Just as in Section 10.2, Figure 2, Alice invites Bob to a session,
      and Bob eventually transfers Alice to communicate with Carol.

   o  What is different about the call flow in Figure 11 is that Bob's
      REFER is not in-dialog.  Even so, this is treated as part of the
      same communication session and, thus, the session identifier in
      those messages is {A,B}.

   o  Alice will use her existing UUID and the nil UUID ({A,N}) in the
      INVITE request towards Carol (who generates UUID "C" for this
      session), thus maintaining the common UUID within the session
      identifier for this new Alice-to-Carol session.



(page 37 continued on part 3)

Next Section