Subject: [dispatch] Expanded dialog/session example

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 10 Nov 2011 12:06:51 -0500

1. Alice calls Bob.  This call goes through an SBC, a B2BUA on the
boundary between two administrative domains which desires to minimize
the passage of signaling events between the domains.  Thus, there are
two dialogs, Alice-SBC and SBC-Bob.

2. Alice places the call on hold.  Alice's UA creates a dialog
Alice-MOH-1 with the music-on-hold server, and uses 3PCC techniques
(SDP relaying) to cause MOH to send its RTP to the far end of
Alice-SBC (that is, the SBC), which then relays it to Bob.

3. Alice takes the call off hold.  Alice's UA terminates the dialog
Alice-MOH-1, and updates the SDP of Alice-SBC so media is sent to/from
Alice's UA.

4. Alice wants to do an attended transfer of the call to Carol.  She
puts the dialog with Bob on hold.  Alice's UA creates a new dialog
Alice-MOH-2 with the music-on-hold server, and uses 3PCC techniques
(SDP relaying) to cause MOH to send its RTP to the far end of
Alice-SBC (that is, the SBC), which then relays it to Bob.

5. Alice's UA initiates a call to sip:carol.  This call forks to two
UAs.  Carol answers the call on one UA, creating the dialog
Alice-Carol.

6. Dave answers the call on the other UA, creating a dialog Alice-Dave
(which has the same Call-Id as Alice-Carol, but a different to-tag).

7. Alice ends the Alice-Dave dialog, because she does not want to
transfer the call with Bob to Dave.

8. Alice executes the transfer between the calls to Bob (Alice-SBC)
and Carol (Alice-Carol), by sending a REFER to Carol specifying SBC's
contact URI with a Replaces header-parameter identifying Alice-SBC.

9. Carol's UA sends an INVITE to SBC, creating a dialog Carol-SBC.
The dialog Carol-SBC replaces the dialog Carol-Alice on Carol's UA
interface.

10. The SBC "shortstops" the INVITE-with-Replaces, changing its
relaying so that SBC-Bob relays to/from Carol-SBC rather than
Alice-SBC.  The dialog SBC-Bob continues.

11. The dialogs Alice-SBC and Alice-Carol are terminated by one or both
of their UAs.  Alice's UA terminates Alice-MOH-2.

12. Carol places the call on hold.  Carol's UA creates a dialog
Carol-MOH with the same music-on-hold server that Alice used, and uses
3PCC techniques (SDP relaying) to cause MOH to send its RTP to the far
end of Carol-SBC (that is, the SBC), which then relays it to Bob.

Eight dialogs are created:
	Alice-SBC
	SBC-Bob
	Alice-MOH-1
	Alice-MOH-2
	Alice-Carol
	Alice-Dave
	Carol-SBC
	Carol-MOH

How do the "sessions" group the dialogs?  Does any dialog change its
session association over time?  Which elements assign session
identifiers based on what criteria, and how do those identifiers get
communicated to the other elements?

Dale

"In cooperation with an intelligent joiner I would undertake to defeat
any definition of chair or chairishness that you gave me."
-- H. G. Wells, "A Modern Utopia"

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 10 Nov 2011 16:11:58 -0600

>Eight dialogs are created:

the above two dialogs would use 1 Session-ID

When Alice call gets diverted or transferred to another UA (Carol, 
Dave or MOH1 or MOH2) she retains her half of the same Session-ID, 
but since each far end UA is different, the *whole* Session-ID would 
be different for each combination of UAs

>         Carol-SBC

Once the Alice to Carol Session-ID is constructed, it traverses 
B2BUAs and SBCs without changing, which is unlike what happens to 
Dialog IDs (and Call-IDs).

>         Carol-MOH

In other words, once Alice (using Session-ID 'A') creates a session 
(through any type of SIP server) with Bob (using Session-ID 'B'), 
each retains use of that Session-ID half even if the session is 
transferred to another entity (to Carol using Session-ID 'C', or 
MOH-1 server using Session-ID '1') (and so on...).

Thus, you get these Session-IDs:

Alice to Bob   -> whole Session-ID = AB
Alice to MOH-1 -> whole Session-ID = A1
Alice to Carol -> whole Session-ID = AC
Alice to Dave  -> whole Session-ID = AD

And if Bob is transferred by Alice to Carol or Dave, but first has a 
session with MOH-2, it would be either

Bob to MOH-2   -> whole Session-ID = B2 then
Bob to Carol   -> whole Session-ID = BC

or

Bob to MOH-2   -> whole Session-ID = B2 then
Bob to Dave    -> whole Session-ID = BD

I admit I haven't covered every one of your 12 example scenarios, but 
this comes close to all of them. I hope you get the idea from this, 
and can fill in the rest.

>session association over time?

>Which elements assign session identifiers

I think this is either within the UA for user or MOH server (which is 
a UA), or if a B2BUA controls much of what UAs do (as is the case in 
most enterprise environments - it's the B2BUA that assigns or creates 
the Session-ID half for each UA on their side of the session.

>based on what criteria,

This would be what the new Session-ID WG would decide, but I imagine 
it would/might include:

         - one for every new (media) dialog (I'm not sure
         SUB/NOT needs this, but there could be viable
         use-cases.

         - might depend on who this UA is bringing up a
         session with.

         - etc...

>and how do those identifiers get communicated to the other elements?

This would be what the new Session-ID WG would decide, but I imagine 
it would be in a new SIP "Session-ID" header.

Some of this I could be wrong, but other parts - this is the proposal.

Comments?

James

>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 10 Nov 2011 18:21:35 -0500

> From: James M. Polk [[email-masked]]
> 

Now, you don't get to cheat and say "And the rest can be filled in
similarly", because the whole point of the exercise is to verify that
a proposed system can handle all of the ugly cases.  If you skip a
case, you're admitting you don't know how to handle it.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Nov 2011 18:46:59 -0500

James,

We need to refine this to an operational model that each device can 
follow to get an expected result, such as you outline. Trying to fill 
that in below:

>> two dialogs, Alice-SBC and SBC-Bob.

Alice sends an ID of A* toward Bob via the SBC
SBC propagates A* to Bob
Bob returns an ID of AB toward Alice via the SBC
The SBC propagates AB to Alice

>> Alice-SBC (that is, the SBC), which then relays it to Bob.

Alice sends an ID of A* toward MOH-1.
(Why not a new one? There must be logic that decides this is part of the 
same session.)
MOH-1 returns an ID of A1 to Alice
Alice then sends a reinvite with new offer toward Bob,
with the SDP from MOH-1, but *does not* change the ID.
(What logic determines when to do this and when not?)

>> Alice-MOH-1, and updates the SDP of Alice-SBC so media is sent to/from

Not so interesting if the ID was not changed above.
(It still isn't changed here.)

>> Alice-SBC (that is, the SBC), which then relays it to Bob.

Alice sends an ID of A* toward MOH-2.
(Why not a new one? There must be logic that decides this is part of the 
same session.)
MOH-2 returns an ID of A2 to Alice
Alice then sends a reinvite with new offer toward Bob,
with the SDP from MOH-2, but *does not* change the ID.
(What logic determines when to do this and when not?)

>> UAs. Carol answers the call on one UA, creating the dialog

Alice sends an ID of A* toward Carol.
(Why not a new one? There must be logic that decides this is part of the 
same session.)
Carol returns an ID of AC to Alice.

>> (which has the same Call-Id as Alice-Carol, but a different to-tag).

Dave returns an ID of AD to Alice.

>> transfer the call with Bob to Dave.

Not interesting.

>> contact URI with a Replaces header-parameter identifying Alice-SBC.

Don't think there is anything interesting here.

>> The dialog Carol-SBC replaces the dialog Carol-Alice on Carol's UA

Carol sends and ID of C* toward Bob via Alice's SBC.
(I guess it knows to use C rather than a new id because this is a 
Replaces of a dialog that has C as Carol's part of the ID.)

>> Alice-SBC. The dialog SBC-Bob continues.

The SBC has to return *something* as the ID back to Carol.
I guess it could return CB because this is resplicing the existing AB 
session, replacing A.

But unless the SBC sends a new ID to Bob, he will still think it is AB.
So maybe the SBC must send a reinvite to Bob with CB as the ID, using 
similar logic to above. (It might need this anyway if it doesn't want to 
terminate and relay the media.)

>> of their UAs. Alice's UA terminates Alice-MOH-2.

Not interesting.

>> end of Carol-SBC (that is, the SBC), which then relays it to Bob.

Nothing new here.

There are some key things to work out:

- When a UA is making multiple calls, when does it use a common
   value for its half of the ID, and when does it use a different one?
   This seems to depend on knowing whether the "new" call is to be
   part of an existing call, or not. The MOH call should be clear
   in this regard. But the call to Carol in step 4 is not so clear.
   In some common phone UIs, at the time the call to Carol is made
   the phone doesn't know if this is for a transfer, or is an
   independent call. That isn't known until later.

- When should a B2BUA form a new ID from parts of existing ones,
   and when should it not?

There are probably more such issues.

	Thanks,
	Paul

> When Alice call gets diverted or transferred to another UA (Carol, Dave
> or MOH1 or MOH2) she retains her half of the same Session-ID, but since
> each far end UA is different, the *whole* Session-ID would be different
> for each combination of UAs
>
>> Alice-MOH-1
>> Alice-MOH-2
>> Alice-Carol
>> Alice-Dave
>> Carol-SBC
>
> Once the Alice to Carol Session-ID is constructed, it traverses B2BUAs
> and SBCs without changing, which is unlike what happens to Dialog IDs
> (and Call-IDs).
>
>> Carol-MOH
>
> (through any type of SIP server) with Bob (using Session-ID 'B'), each
> retains use of that Session-ID half even if the session is transferred
> to another entity (to Carol using Session-ID 'C', or MOH-1 server using
> Session-ID '1') (and so on...).
>
> this comes close to all of them. I hope you get the idea from this, and
> can fill in the rest.
>
>
>
> I think this is either within the UA for user or MOH server (which is a
> UA), or if a B2BUA controls much of what UAs do (as is the case in most
> enterprise environments - it's the B2BUA that assigns or creates the
> Session-ID half for each UA on their side of the session.
>
>> based on what criteria,
>
> This would be what the new Session-ID WG would decide, but I imagine it
> would/might include:
>
> This would be what the new Session-ID WG would decide, but I imagine it
> would be in a new SIP "Session-ID" header.
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 10 Nov 2011 18:12:50 -0600

>case, you're admitting you don't know how to handle it.

well - this certainly isn't true, I just left out the order and the 
interaction with MOH-2 I think.

So, to cover this (for you and others, but knowing this certainly 
isn't going to be the last time I or someone else needs to cover this 
exact topic  ;-).

I'll order the 12 for you, as long as you allow the same Session-ID 
construction to continue as each creates or provides each half of the 
overall Session-ID, as follows:

Alice's half Session-ID = 'A'
Bob's half Session-ID   = 'B'
Carol's 1st UA half Session-ID = 'Cc'
Carol's 2nd UA half Session-ID = 'Ccc'
Dave's half Session-ID  = 'D'
MOH-1's half Session-ID = '1'
MOH-2's half Session-ID = '2'

1.  = AB from Alice to Bob (regardless of SIP servers)
2.  = A1 to Alice, 1B to Bob
3.  = "...so media to/from Alice's UA" and what? You don't say.
       Though if Bob, this goes back to AB
4.  = 2B (if I understand you correctly). IOW, it's 2B if the
       RTP is between Bob and MOH-2.
5.  = ACc
6.  = ACcc - but here you have two forked UAs answering the
       same call from Alice. Isn't the forking proxy supposed
       to kill the latter  of these sessions (i.e., a second
       200 OK causes a BYE from the forking proxy?)
7.  = "Alice ends the Alice-Dave dialog" why isn't that a BYE?
       If so, why are you proposing to send Dave to Bob?
       Terminating a dialog terminates the Session-ID; but
       I'm not sure where you're going here.
8.  = BCc
9.  = In step 8, Alice REFER'd Bob to Carol, thereby removing
       Alice from any dialogs, and therefore any Session-IDs
       (if I'm following you correctly.
10. = SBCs have no affect on the Session-ID construction, and
       as Bob and Carol are already talking to each other from
       step 8, there is no Session-ID to give here; BCc remains
       up.
11. = the ACcc was terminated in step 7. The ACc was
       transferred to BCc in step 8, so there is no Alice-SBC
       anything at this point. I don't see where "Alice's UA
       terminates Alice-MOH-2" can happen because A2 was never
       up, unless it occurred in step 4. If you propose that it
       was in step 4, then how did Alice discover the Alice-Carol
       was forked to both Carol and (specifically) Dave (that
       she didn't want Bob to talk to in step 7)? Wouldn't see
       have had to talk to Dave to know it was him?
       At the end of the day, when you put Alice-SBC and
       Carol-SBC you seem to think this is a full Session-ID
       and it is not.
12. = Carol to MOH (which? server-1 or server-2) would be
       either Cc1 or Cc2. Bob to MOH (which? server-1 or
       server-2) would be either B1 or B2. I can't tell which
       at this point you want it to be to.

no cheating...

comments?

James

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 10 Nov 2011 18:30:38 -0600

Paul

While I can appreciate what you are asking for, it seems like Dale's 
example (perhaps minus the few small errors I found in it, or just 
misunderstandings in it) would pretty much solve 80-90-95-99% of the 
problem space. Do you want me to accomplish all that in one email?

(of course you would, it would make everything easy!)

;-)

Seriously - review the note I just send that did go through 12 steps 
(hmmm, a 12 step program... I wonder if that was a consciously 
determined number of steps), and let me know if and where I'm wet 
behind the ears.

I think that if I satisfy everyone with this 12 step problem, the WG 
(if it becomes a WG) will have little more to do than the ABNF... 
(I'm only half kidding, and with someone else kidding that will make 
a fully Session-ID of kidding).

I couldn't help myself, sorry

James

At 05:46 PM 11/10/2011, Paul Kyzivat wrote:
>follow to get an expected result, such as you outline. Trying to 
>fill that in below:
>
>(Why not a new one? There must be logic that decides this is part of 
>the same session.)
>(Why not a new one? There must be logic that decides this is part of 
>the same session.)
>(Why not a new one? There must be logic that decides this is part of 
>the same session.)
>I guess it could return CB because this is resplicing the existing 
>AB session, replacing A.
>
>So maybe the SBC must send a reinvite to Bob with CB as the ID, 
>using similar logic to above. (It might need this anyway if it 
>doesn't want to terminate and relay the media.)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Nov 2011 23:57:20 -0500

James,

Its not sufficient to say how you want the ID assignments to end up. You 
have to explain how they come to be that way.
That is what is different about my prior mail.

	Thanks,
	Paul

On 11/10/11 7:12 PM, James M. Polk wrote:
> So, to cover this (for you and others, but knowing this certainly isn't
> going to be the last time I or someone else needs to cover this exact
> topic ;-).
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 11 Nov 2011 12:52:52 -0500

> > ...

Now remember that there are two dialogs between Alice and one MOH
server, one created to service each on-hold interval.  So though
Alice-MOH-1 and Alice-MOH-2 are two different dialogs, they are
between the same "endpoint" devices.

If you want Alice to use the same half-session-Id for both dialogs,
but does MOH use the same half-session-Id for both dialogs?  If it
does, how does it arrange to do so?

And when the Alice-Bob call is put on hold, what session-Id does Bob
see?  In a sense, Bob is still calling Alice, but in reality, the
media he is hearing comes from MOH.  What is the session-Id that Bob
sees at that time?

> Bob to Carol   -> whole Session-ID = BC

(Actually, it's Carol who creates the 3rd dialog to MOH, but that
doesn't change the essence of the situation.)

The point here is that when Bob is transferred to Carol, he does not
have a change of dialog.  So if the session-Id when Bob is talking to
Alice is AB and the session-Id when Bob is talking to Carol is BC (or
equivalently, CB), then there must be some mechanism for changing the
session-Id of a dialog.

More importantly, this violates the assumption that many people have
that session-Ids *group* dialogs, so every dialog is part of *exactly*
one session.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 11 Nov 2011 14:34:49 -0500

You're proposing a version of the "call end identifier" model.  I
think that it can be defined and implemented (unlike many of the
other approaches).

> Carol's 2nd UA half Session-ID = 'Ccc'

Strictly speaking, Scc is the half-session-Id used by Dave's UA.

> MOH-2's half Session-ID = '2'

| 1. Alice calls Bob.  This call goes through an SBC, a B2BUA on the
| boundary between two administrative domains which desires to minimize
| the passage of signaling events between the domains.  Thus, there are
| two dialogs, Alice-SBC and SBC-Bob.

> 1.  = AB from Alice to Bob (regardless of SIP servers)

So Alice-SBC and SBC-Bob are given session-Id AB.

| 2. Alice places the call on hold.  Alice's UA creates a dialog
| Alice-MOH-1 with the music-on-hold server, and uses 3PCC techniques
| (SDP relaying) to cause MOH to send its RTP to the far end of
| Alice-SBC (that is, the SBC), which then relays it to Bob.

> 2.  = A1 to Alice, 1B to Bob

Here we have to decide whether Alice-MOH-1 is part of the same session
as Alice-SBC and SBC-Bob.

If they are part of the same session, then all 3 dialogs Alice-MOH-1,
Alice-SBC, and SBC-Bob must be given the same session-Id, 1B, since
one end of the media chain is MOH and the other is Bob.  In that case,
there must be a way of changing the session-Id assigned to Alice-SBC
and SBC-Bob.

If they are not part of the same session, the session-Id of Alice-SBC
and SBC-Bob does not change (AB), and Alice-MOH-1 gets the session-Id
A1.

| 3. Alice takes the call off hold.  Alice's UA terminates the dialog
| Alice-MOH-1, and updates the SDP of Alice-SBC so media is sent to/from
| Alice's UA.

>        Though if Bob, this goes back to AB

I meant "... so media is sent between Alice's UA and SBC."

| 4. Alice wants to do an attended transfer of the call to Carol.  She
| puts the dialog with Bob on hold.  Alice's UA creates a new dialog
| Alice-MOH-2 with the music-on-hold server, and uses 3PCC techniques
| (SDP relaying) to cause MOH to send its RTP to the far end of
| Alice-SBC (that is, the SBC), which then relays it to Bob.

>        RTP is between Bob and MOH-2.

What makes this interesting is that it returns to the same
configuration that existed at the end of step 2.  Alice's UA has
established a *new* dialog to the *same* MOH server.

Do we expect the MOH server to use the *same* identification for its
end as it used in step 2?

| 5. Alice's UA initiates a call to sip:carol.  This call forks to two
| UAs.  Carol answers the call on one UA, creating the dialog
| Alice-Carol.

> 5.  = ACc

This probably depends on whether Alice's UA, at this time, knows that
the call to Carol is intended to be part of an attended transfer.

If the UA does *not* know, then it probably should select a *new*
endpoint identification, A'.  The reason for this is that if it does
not follow this policy, the UA will be using the same endpoint
identification for a long series of calls, causing the endpoint reveal
"internal" information and giving service providers an incentive to
block transmission of session-Ids.

| 6. Dave answers the call on the other UA, creating a dialog Alice-Dave
| (which has the same Call-Id as Alice-Carol, but a different to-tag).

>        200 OK causes a BYE from the forking proxy?)

Normally, a forking proxy will cancel one fork when the other fork is
answered.  But the INVITE can have a Caller-Preferences to prevent
that, and in any case, if Carol and Dave answer simultaneously, a race
condition allows both 200s to reach Alice.

| 7. Alice ends the Alice-Dave dialog, because she does not want to
| transfer the call with Bob to Dave.

> 7.  = "Alice ends the Alice-Dave dialog" why isn't that a BYE?

It is.  How else do you end a dialog?

>        If so, why are you proposing to send Dave to Bob?

I'm not.

>        I'm not sure where you're going here.

| 8. Alice executes the transfer between the calls to Bob (Alice-SBC)
| and Carol (Alice-Carol), by sending a REFER to Carol specifying SBC's
| contact URI with a Replaces header-parameter identifying Alice-SBC.

> 8.  = BCc

I think you're describing the INVITE sent in step 9.

| 9. Carol's UA sends an INVITE to SBC, creating a dialog Carol-SBC.
| The dialog Carol-SBC replaces the dialog Carol-Alice on Carol's UA
| interface.

>        (if I'm following you correctly.

| 10. The SBC "shortstops" the INVITE-with-Replaces, changing its
| relaying so that SBC-Bob relays to/from Carol-SBC rather than
| Alice-SBC.  The dialog SBC-Bob continues.

>        step 8, there is no Session-ID to give here; BCc remains

I'm not quite sure what you mean by "Bob and Carol are already talking
to each other from step 8".  Step 8 is where Alice sends the REFER to
Carol, step 9 is where Carol then sends the prescribed INVITE to SBC,
and step 10 is when SBC receives the INVITE and acts on it.

In any case, according to this scheme, Carol-SBC has the session-Id
BCc.  But that means that Bob-SBC should now have the session-Id BCc
as well.  We are requiring a mechanism to change the session-Id of an
existing dialog, and we are also adding a complexity to the data
model:  A dialog can be part of multiple sessions over time.

| 11. The dialogs Alice-SBC and Alice-Carol are terminated by one or both
| of their UAs.  Alice's UA terminates Alice-MOH-2.

>        anything at this point.

I'm not sure I'm following you here.  The dialog Alice-Carol gets
terminated as part of cleaning up the consultative transfer, but
different phones do the cleaning up in different ways.  With some
phones, when Alice's UA is gets the NOTIFY from Carol's UA that
Carol's UA has received the 200 response for the INVITE to SBC,
Alice's UA sends a BYE on Alice-Carol.  With other phones, the BYE on
Alice-Carol is sent by Carol's UA when it receives the 200.  In any
case, Alice-Carol is not (should not be) terminated until SBC has sent
the 200 to the INVITE (step 10).

>        I don't see where "Alice's UA
>        up, unless it occurred in step 4.

Yes.  Most phones put the current call on hold when the user indicates
he wants to do a consultative transfer, and that on-hold operation
starts a dialog to the MOH server to retrieve MOH.

>        If you propose that it

Yes.  I'm presuming here that both Alice-Carol and Alice-Dave are
presented on Alice's UA's interface.

Alternatively, we can assume that Alice's UA received the 200 from
Carol first, and automatically sent a BYE to the dialog created by the
200 from Dave.

The message flow is the same in either case.

>        Carol-SBC you seem to think this is a full Session-ID

I'm losing you here.  What do you mean by "when you put"?  Do you mean
"when you say"?

"Alice-SBC" is the name I'm using for the SIP dialog between Alice's
UA and SBC.  As I said in step 1, "Thus, there are two dialogs,
Alice-SBC and SBC-Bob."

| 12. Carol places the call on hold.  Carol's UA creates a dialog
| Carol-MOH with the same music-on-hold server that Alice used, and uses
| 3PCC techniques (SDP relaying) to cause MOH to send its RTP to the far
| end of Carol-SBC (that is, the SBC), which then relays it to Bob.

>        at this point you want it to be to.

I want it to be to the *same* server as Alice used in steps 2 and 4.
That's what I meant by "with the same music-on-hold server that Alice
used".  The reason for this is that after step 12, the dialog chain is
MOH -> Carol -> SBC -> Bob, and more specifically, the two *endpoint
devices* are MOH and Bob, just as they were after step 2.

Now if we require that there always be the same session-Id when a
session runs between the same *endpoint devices*, this session would
have session-Id AB.  The trouble with this is that no element is in a
position to know that this session duplicates the previous one.

The alternative is that half-session-Ids are "call ends", and that
initiating an INVITE and receiving an INVITE both create *new* call
ends with new identifiers, with the exceptions (I think):

- when a call goes through a B2BUA, the B2BUA passes the call end
  identifiers through in both directions

- when a UA acts on an in-dialog REFER, the new INVITE uses the same
  call end identifier that the UA used for the dialog containing the
  REFER

- when a UA acts on an INVITE-with-Replaces, the new dialog uses the
  same call end identifier as the UA used for the dialog that has been
  replaced

Call ends generally match the "call slots" on a UAs user interface.

Dale

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 11 Nov 2011 15:02:55 -0500

Dale,

> Alice-MOH-1 and Alice-MOH-2 are two different dialogs, they are between
> the same "endpoint" devices.
>
> If you want Alice to use the same half-session-Id for both dialogs, but
> does MOH use the same half-session-Id for both dialogs?  If it does, how
> does it arrange to do so?

If the MoH is a callable entity, it would receive an INVITE and respond with
a 200.  For the MoH server, this is effectively a new "call" and it would
use a different Session-UUID for each "call".  If the MoH server is merely
serving media for another device that controls it (through some means I
don't care), then it's not an issue as the call is still anchored at the
called device.  I assume you're suggesting alice does send an INVITE to the
MoH server, so each "call" would result in the MoH server using a different
UUID back to Alice.

> see?  In a sense, Bob is still calling Alice, but in reality, the media
> he is hearing comes from MOH.  What is the session-Id that Bob sees at
> that time?

If the call remains fixed between Bob and Alice, then the Session-ID never
changes.  If Alice puts Bob on hold by referring him to a MOH server, then
the Session-ID would change.  If Alice puts Bob on hold by invoking a MoH
server herself and just sending Bob and INVITE with the media information,
then the call actually never moves: it's still between Alice and Bob.  The
fact media is sourced somewhere else is a different matter.

Having said that, if we want to associate media flows with signaling, then
perhaps Alice would convey to Bob a new Session ID.  So, we might have this:

Alice         Bob         MOH Server
  |            |               |     <-- Call in steady state
  INVITE ---------------------->
  |            |               |
  <----------------------------- 200 (SDP)
  |            |               |
  INVITE ------>
  |            |               |
  <------------- 200 
  |            |               |
               ===== Music =====
  |            |               |

There would be a Session-ID between Alice and the MOH server that would be
an entirely different Session-ID.  This scenario is actually like the B2BUA
examples where Alice is now an intermediary.  So, what she could do is send
Bob's Session-UUID to the MOH server and send the MOH server's UUID to Bob.
That way, the MOH server and Bob (and Alice) have a common view.  We could
then let the MOH server use the resulting Session-ID in protocols like RSVP.

I prefer that, now that I think about it.
 
> > to another entity (to Carol using Session-ID 'C', or
> > Alice to MOH-1 -> whole Session-ID = A1 Alice to Carol -> whole
> > Session-ID = AC Alice to Dave  -> whole Session-ID = AD
> >

The Session-ID likely will change with any kind of transfer (signaled
transfer or behind-the-scenes).
 
> that session-Ids *group* dialogs, so every dialog is part of *exactly*

Every dialog, I think, is part of exactly one Session-ID at any given point
in time, I think.  A dialog between Alice and a PBX might never change as
far as Alice is concerned, but the Session-ID might change many times with
various service interactions.

Paul

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 11 Nov 2011 15:15:21 -0600

>between the same "endpoint" devices.

because they are different dialogs, the MOH server would assign 
different half keys to each, while each may have the same half key 
from Alice's UA.

This does open up an interesting scenario in which the Alice-MOH-1 
takes one path through SIP servers (which may or may not include a 
B2BUA), and Alice-MOH-2 takes another path through SIP servers (which 
may or may not include B2BUA different from the other dialog). I 
expect that to be a requirement the Session-ID work (group) would 
have to resolve. I don't have an answer off the top of my head 
(though I am a bit distracted this afternoon, so one might be obvious 
that I'm just not thinking about).

>does, how does it arrange to do so?

one goal of this effort is to replicate what differing dialog-IDs 
were supposed to be (i.e., without B2BUAs or SBCs in between UAs in a 
session). Therefore, the way I see it, wherever there should be or 
are two dialogs without a B2BUA or SBC in between the UAs, there 
needs to be distinct Session-IDs per dialog.

>see?

he see the existing one until it is replaced by the one mentioned 
immediately below.

>In a sense, Bob is still calling Alice, but in reality, the

Bob would have a new overall Session-ID, consisting of his half key 
that he used in the dialog to Alice, and the new half key that the 
MOH server provides.

>have a change of dialog.

so Bob's half Session-ID remains the same. It's Carol's half key that 
makes the Session-ID unique to this session (i.e., Alice's half key 
goes away from the Bob-Carol session).

>So if the session-Id when Bob is talking to

Yep, the INVITE from Bob to Carol (after Alice REFERed Bob to Alice) 
will only include Bob's existing half key. It's up to Carol to append 
her new half key to make a full Session-ID for this new dialog.

>that session-Ids *group* dialogs, so every dialog is part of *exactly*

They group two halves of a session, i.e., the dialog between Bob and 
the B2BUA, and the other dialog between the B2BUA and Carol. Here you 
have two dialogs and only one Session-ID.

James