Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations

From: James Polk <[email-masked]>
Date: Fri, 11 Jan 2013 15:55:04 -0600

Brett

Not trying to compound this scenario you have (and sorry for being 
late to the party, but PK's message pointed me towards yours - and I 
realized I had missed it while out on PTO), but I have a different 
angle/take on Paul Jones's series of questions (that have not been 
answered yet, BTW).

In your diagram, which I'll recreate here

 > Session-ID
 > ----  Alice        B2BUA     Bob-phone Bob-computer
 >   {A}   |---INVITE--->|            |          |
 >   {A}   |             |---INVITE-->|          |
 >   {A}   |             |---INVITE------------->|
 >  {Bp,A} |             |<--200 OK---|          |
 >  {Bc,A} |             |<--200 OK--------------|
 >  {Bp,A} |<--200 OK----|            |          |
 >  {A,Bp} |-----ACK---->|            |          |
 >  {A,Bp} |             |---ACK----->|          |
 >  {A,Bc} |             |---ACK---------------->|

Why is there a Bp and not a B? I mean, B is all Alice is every going 
to see, and the B2BUA has to be in charge of this recording by 
transmitting a nearly replicative INVITE to Bob's computer, right?

What header-values are changed in the INVITE transaction to and from 
Bob's computer relative to that of the transaction to and from the phone?

         - The R-URI can't be the same.
         - the Via can't be the same.
         - the To can't be the same.
         - the From can't be the same?
         - is the CSeq the same?
         - the Contact can't be the same.
         - is the SDP the same, given that the media packets
           are to be going through the B2BUA?

I suspect that this is an entirely new transaction with new/different 
header-values, and not merely a different Session-ID header-value. 
Not knowing SIPREC as well as I should, does this INVITE to Bob's 
computer need to be in parallel like the call flow shows?

For example could it be like this instead?

 > Session-ID
 > ----  Alice        B2BUA     Bob-phone Bob-computer
 >   {A}   |---INVITE--->|            |          |
 >   {A}   |             |---INVITE-->|          |
 >   {B,A} |             |<--200 OK---|          |
 >   {B,A} |<--200 OK----|            |          |
 >   {A,B} |-----ACK---->|            |          |
 >   {A,B} |             |---ACK----->|          |
 >   {A}   |             |---INVITE------------->|
 >  {Bc,A} |             |<--200 OK--------------|
 >  {A,Bc} |             |---ACK---------------->|

James

At 12:13 AM 11/21/2012, Paul E. Jones wrote:
>Brett,
>
>Well, this is certainly different.  Does the phone ring?  Does the computer
>ring?  Does the user independently answer each one of those devices?  And
>what would happen if the PC has only audio?  I assume only the B2BUA knows
>the capabilities of devices in advance?
>
>Basically, what we have on the right-hand side of the B2BUA is two
>completely independent SIP sessions that are more-or-less "conferenced" via
>the B2BUA.  The media might be going directly to the endpoints, but it is
>still very much like a conference server where there is Alice, Bob, and
>Carol all in a conference.
>
>So, given that, I would expect to see these three Session-IDs:
>{A,F} - Session ID between Alice and the B2BUA (F)
>{F,Bp} - Session ID between the B2BUA and Bob's phone
>{F,Bc} - Session ID between the B2BUA and Bob's computer
>
>This means there are three unique identifiers, but there still exists the
>possibility to correlate the calls since F is in common across all sessions.
>
>There are limits to the utility of having F in all sessions.  For example, A
>is not present anywhere on the right-hand side.  If A happened to be an MCU
>that had 100 calls in conference, it might be possible to relate all the
>sessions on the left side of the B2BUA, but the diagnostic / monitoring
>equipment looking at the right side would never see A.  Thus, it's not
>perfect.  Even so, I think that approach would provide a "better than
>nothing" solution.
>
>Paul
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Brett Tate
> > Sent: Tuesday, November 13, 2012 3:20 PM
> > To: [email-masked]
> > Subject: [Insipid] Session-ID when B2BUA forks INVITE for audio and
> > video to different locations
> >
> > Hi,
> >
> > What Session-ID should be communicated when a B2BUA forks a video call
> > so INVITE for audio and INVITE for video go to different locations?  For
> > instance, the INVITE for video is sent the computer and INVITE for audio
> > is sent to the phone.
> >
> > The concept is mentioned within draft-ietf-straw-b2bua-taxonomy-00
> > section 3.1.3.
> >
> > The following uses draft-jones-insipid-session-id-01 to indicate
> > Session-ID.  Hopefully the picture doesn't get too corrupted.
> >
> > Session-ID
> > ----  Alice        B2BUA     Bob-phone Bob-computer
> >   {A}   |---INVITE--->|            |          |
> >   {A}   |             |---INVITE-->|          |
> >   {A}   |             |---INVITE------------->|
> >  {Bp,A} |             |<--200 OK---|          |
> >  {Bc,A} |             |<--200 OK--------------|
> >  {Bp,A} |<--200 OK----|            |          |
> >  {A,Bp} |-----ACK---->|            |          |
> >  {A,Bp} |             |---ACK----->|          |
> >  {A,Bc} |             |---ACK---------------->|
> >
> > Is this the expected use of draft-jones-insipid-session-id-01?  Note: Bc
> > does not get communicated to Alice and the B2BUA adjusts the Session-ID
> > before sending ACK to Bob-computer.
> >
> > There is a similar call flow when Bob-phone originates a call to Alice.
> > Bob-computer is pulled into the call setup so both audio and video can
> > be offered to Alice.  However, I will ask about that one later.
> >
> > Thanks,
> > Brett
> >
> > This email is intended solely for the person or entity to which it is
> > addressed and may contain confidential and/or privileged information. If
> > you are not the intended recipient and have received this email in error,
> > please notify BroadSoft, Inc. immediately by replying to this message,
> > or by sending an email to [email-masked], and destroy all copies
> > of this message, along with any attachment, prior to reading,
> > distributing or copying it.
> > _______________________________________________
> > insipid mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/insipid
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: Brett Tate <[email-masked]>
Date: Sun, 13 Jan 2013 19:28:46 +0000

Thanks for responses.  Reply is inline.

> Paul Jones's series of questions (that have not been
> answered yet, BTW).

My apologies.  The reply is also inline.

> Why is there a Bp and not a B?

I didn't think that the draft provided the B2BUA the flexibility to reclassify the service to fall into a conferencing classification so that it wouldn't need to relay Bp or Bc.  More specifically, this B2BUA service modifies the SDP; however it does not send/receive media.

> I mean, B is all Alice is every going to see, 
> and the B2BUA has to be in charge of this recording 
> by transmitting a nearly replicative INVITE to 
> Bob's computer, right?

This isn't a recording service; the B2BUA does not see the media.  It is a service to break apart the SDP so that audio is offered to the phone and video is offered to the computer.

> What header-values are changed in the INVITE 
> transaction to and from Bob's computer relative 
> to that of the transaction to and from the phone?

Excluding any current/future restrictions placed upon B2BUAs, it is mostly at the discretion of the B2BUA.

>          - the From can't be the same?

It at the discretion of the B2BUA.

>            are to be going through the B2BUA?

The media packets do not go through the B2BUA.  The SDP is different.

> computer need to be in parallel like the call flow shows?

It is not required; however it simplifies the SDP offer/answer exchanges.

> For example could it be like this instead?

Not exactly; the B2BUA will need to provide Bob's video answer SDP to Alice.

> > Well, this is certainly different.  Does the phone ring?

Yes; however I guess that it actually depends upon other services and configuration.

> > Does the computer ring?  

Yes; however I guess that it actually depends upon other services and configuration.

> > Does the user independently answer each one of those devices?

Yes; however I guess that it actually depends upon other services and configuration.

> > And what would happen if the PC has only audio?

It would reject the offer with 488 or 606.

> > I assume only the B2BUA knows the capabilities of 
> > devices in advance?

It can know the capabilities; however the B2BUA is mostly just acting per service configuration.

---

From: James Polk <[email-masked]>
Date: Mon, 14 Jan 2013 18:37:20 -0600

At 01:28 PM 1/13/2013, Brett Tate wrote:
>I didn't think that the draft provided the B2BUA the flexibility to 
>reclassify the service to fall into a conferencing classification so 
>that it wouldn't need to relay Bp or Bc.  More specifically, this 
>B2BUA service modifies the SDP; however it does not send/receive media.
>
>This isn't a recording service; the B2BUA does not see the media.

I obviously misinterpreted the flow's intent.

>It is a service to break apart the SDP so that audio is offered to 
>the phone and video is offered to the computer.

What if one endpoint is available and the other is not? I'm sure 
folks can imagine audio without video, but is video without audio acceptable?

>mostly at the discretion of the B2BUA.

If the B2BUA isn't in the media path, this is taking one INVITE and 
turning into two INVITE's, one of which doesn't get the benefit of 
having any feedback. Imagine an INVITE from Alice with two audio 
codecs and two video codecs. This INVITE is split how you say it is. 
The B2BUA cannot return a second "final response" (200 OK) with Bob's 
computer UA's "answer". That presents an unworkable offer/answer exchange.

>It at the discretion of the B2BUA.

I'm thinking that this second INVITE is a whole new INVITE with new 
header-values in each header in the request.

>Not exactly; the B2BUA will need to provide Bob's video answer SDP to Alice.

For every SIP request, there can be only one final response, 
therefore this B2BUA (in the signaling path only) will have to 
eat/consume/terminate/'not send on' any additional final responses 
received within this transaction. While I agree the message flow 
below isn't right (I thought you were describing a SIPREC flow), 
you're gonna have a hard time reconciling this 'alice has to receive 
a second SDP from bob's computer' issue.

In SIP, there's forking and then there's conferencing. What you're 
describing is a hybrid, and not standard.

IMHO, we here in INSIPID shouldn't take on the additional scope that 
this would entail.

However, I've been wrong about what Brett's tried to convey once 
before. I could be wrong again.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jan 2013 21:19:42 -0500

James,

We should try to separate the general principle from the engineering 
details required to produce a reasonable product.

There are many possible variations on this design pattern, some of which 
could be reasonable products, and some of which would be unusable.

Some plausible variants:

- Instead of Bob-computer, it is Bob-TV. The TV can do both audio
   and video, but the audio is then via speakerphone, and isn't very
   good. So the phone is involved in order to provide an audio handset.
   The offer to the TV is both audio/video, and to the phone is just
   audio.

   If the phone answers first, then an audio-only answer is sent to
   Alice, and a revised offer is sent to the TV, removing audio.
   (Assumes the TV sent a 183 with an answer.) If the TV refuses the
   call, then the call stays audio only with the phone. If the TV
   answers (with video), then the B2BUA does a reinvite and adds
   video back into the call with Alice.

   If the TV answers first (audio/video) then the B2BUA cancels
   the call to the phone, and completes the call to Alice with the
   answer from the TV.

   If the TV answers first, then an answer is sent to Alice with
   the audio and video from the TV. If the TV answered with
   active audio, then the call to the phone is canceled. If the
   TV refused the audio, or with it set to recvonly or inactive,
   then the B2BUA lets the phone continue to ring. If it is
   eventually answered, then the B2BUA reinvites the TV to disable
   audio, and Alice to move the audio to the phone.

- The B2BUA is in Bob's computer. It *can* handle both audio and
   video. But Bob prefers his desk phone for audio. The B2BUA
   generates a call with just the audio to the phone, and also
   alerts on the PC (via a popup). If Bob answers on the phone,
   then the PC handles just the video part of the call itself,
   and makes a merged answer back to alice. If Bob answers on
   the PC, then the PC cancels the call to the phone, and handles
   both audio and video on the PC.
   So, does the "leg" to the phone get the same session-id?

The point is that "pieces" of the call with Alice are spread around.

My team (at Cisco) had a proto of this kind for thing running about 10 
years ago.

	Thanks,
	Paul

On 1/14/13 7:37 PM, James Polk wrote:
>> It is a service to break apart the SDP so that audio is offered to the
>> phone and video is offered to the computer.
>
> What if one endpoint is available and the other is not? I'm sure folks
> can imagine audio without video, but is video without audio acceptable?
>
>
> having any feedback. Imagine an INVITE from Alice with two audio codecs
> and two video codecs. This INVITE is split how you say it is. The B2BUA
> cannot return a second "final response" (200 OK) with Bob's computer
> UA's "answer". That presents an unworkable offer/answer exchange.
>
>
> For every SIP request, there can be only one final response, therefore
> this B2BUA (in the signaling path only) will have to
> received within this transaction. While I agree the message flow below
> isn't right (I thought you were describing a SIPREC flow), you're gonna
> have a hard time reconciling this 'alice has to receive a second SDP
> from bob's computer' issue.
>
> However, I've been wrong about what Brett's tried to convey once before.
> I could be wrong again.
>
> James
>
>
>> >  > Session-ID

---

From: James Polk <[email-masked]>
Date: Mon, 14 Jan 2013 21:16:42 -0600

Paul

Just to clarify, both your scenarios Alice wouldn't be sent any SIP 
response until eveything's decided which way which stream is going to 
which UA, right?

If that's the case, you have put forth an interesting set-up. One I'm 
not going to kneejerk in a quick response - rather I'm going to 
ponder for a day or two (because it could have interesting outcome(s)).

>details required to produce a reasonable product.

notice I stayed in the SIP world, and didn't talk about the 
Session-ID in my response. I guess I couldn't get past a few things 
in the former.

James

>There are many possible variations on this design pattern, some of 
>which could be reasonable products, and some of which would be unusable.
>
>Some plausible variants:
>
>My team (at Cisco) had a proto of this kind for thing running about 
>10 years ago.
>
>         Thanks,
>         Paul
>

---

From: Brett Tate <[email-masked]>
Date: Tue, 15 Jan 2013 13:46:52 +0000

> folks can imagine audio without video, but is video without audio

The behavior would be per configuration or vendor's decision.
 
> computer UA's "answer". That presents an unworkable offer/answer

Similar to the B2BUA splitting the offer SDP for two INVITEs, it can also merge two answer SDPs into a single answer SDP.  However, there are obviously some limitations associated such a service.  For instance if the SDPs cannot be merged without conflicts, the B2BUA would likely release one of the dialogs.

<snip>
 
> For every SIP request, there can be only one final response,

There can be many 2xx responses for an INVITE.  However, that is not what I'm attempting to describe.

> a second SDP from bob's computer' issue.

The B2BUA isn't sending the full SDP from bob's computer.  The answer SDP sent by the B2BUA is basically the merge of the audio answer SDP received from bob's phone and video answer SDP received from bob's computer.

> describing is a hybrid, and not standard.

I'm describing a B2BUA type service/callflow.  And I'm attempting to understand how to apply the INSIPID mandate to the callflow.

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jan 2013 11:48:35 -0500

> response until eveything's decided which way which stream is going to

I tried to indicate. This can vary depending on the strategy the B2BUA 
is following.

> not going to kneejerk in a quick response - rather I'm going to ponder
> for a day or two (because it could have interesting outcome(s)).

There are many ways to implement this, and to think about it. They may 
lead to different answers about the session id. And that may be ok. But 
I hope the choice about when to preserve the session id is not entirely 
subjective. There ought to be some criteria to apply that say whether to 
preserve the session id in each case.

	Thanks,
	Paul

> notice I stayed in the SIP world, and didn't talk about the Session-ID
> in my response. I guess I couldn't get past a few things in the former.
>
> James
>
>

---

From: James Polk <[email-masked]>
Date: Tue, 15 Jan 2013 12:22:21 -0600

At 10:48 AM 1/15/2013, Paul Kyzivat wrote:
>I tried to indicate. This can vary depending on the strategy the 
>B2BUA is following.
>
>There are many ways to implement this, and to think about it. They 
>may lead to different answers about the session id. And that may be 
>ok. But I hope the choice about when to preserve the session id is 
>not entirely subjective. There ought to be some criteria to apply 
>that say whether to preserve the session id in each case.

Paul

 From a Session-ID point of view, I believe if you are wanting the 
service Brett is describing, then it'll look something like this *logically*

                      Bob's Phone
                         /
                        / leg 'a'
                       /
    Alice ======= B2BUA
                       \
                        \ leg 'b'
                         \
                      Bob's computer

Where it is the case that the B2BUA merges the two responses from 
Bob's 2 UAs into a single one response, unless there are conflicts; 
then Brett's right, some choices will need to be made, including 
dropping one signaling leg.

A Session-ID can (right now) only have two parts, and I believe from 
Alice's point of view, she ought to see a consistent other UUID 
making up the full Session-ID.

However,
  - from the B2BUA to Bob's phone, the Session-ID should be (A,Bp)
and
  - from the B2BUA to Bob's computer, the Session-ID should be (A,Bc)

Just as the B2BUA merges the SDPs together (and at least changes 
header-values), it also maintains a single Session-ID towards Alice.

Now, how does the B2BUA pick which of Bob's UAs to send towards 
Alice... do we want to make that uniform? Can we make that uniform?

Answers: probably and probably can't, and the 'can't' wins.

caveat: someone clever might come up with a way, but for every 
scenario of Bob's UAs...

James