RFC 7989
End-to-End Session Identification in IP-Based Multimedia Communication Networks
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.
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.
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)
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)
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
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.
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
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).
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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)
