Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7989

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

Pages: 45
Proposed Standard
Obsoletes:  7329
Part 2 of 3 – Pages 17 to 37
First   Prev   Next

Top   ToC   RFC7989 - Page 17   prevText

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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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   ToC   RFC7989 - 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