Subject: [Insipid] disaggregated media: call origination

From: Brett Tate <[email-masked]>
Date: Fri, 29 Mar 2013 16:34:19 +0000

Hi,

As I mentioned within the November 13 email, there is a similar disaggregated media call flow when Bobs-phone originates a call to Alice.  Bobs-computer is pulled into the call setup so both audio and video can be offered to Alice.

Based upon prior feedback and the slide presented at IETF 86, some within insipid prefer the B2BUA to assign Session-ID like a conferencing server (even though it doesn't send/receive media) during disaggregated media situations.  Thus I assume some prefer the B2BUA to not allow the session-ID values to go end-to-end within the following call flow.  I think that the following indicates their preference.  Hopefully the picture doesn't get too corrupted.

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

Please reply if you have an opinion on the topic.

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, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

---

From: James Polk <[email-masked]>
Date: Fri, 29 Mar 2013 12:46:26 -0500

At 11:34 AM 3/29/2013, Brett Tate wrote:
>Hi,
>
>As I mentioned within the November 13 email, there is a similar 
>disaggregated media call flow when Bobs-phone originates a call to 
>Alice.  Bobs-computer is pulled into the call setup so both audio 
>and video can be offered to Alice.

How in SIP is this done without sending Bob's computer an INVITE?

>Based upon prior feedback and the slide presented at IETF 86, some 
>within insipid prefer the B2BUA to assign Session-ID like a 
>conferencing server (even though it doesn't send/receive media) 
>during disaggregated media situations.  Thus I assume some prefer 
>the B2BUA to not allow the session-ID values to go end-to-end within 
>the following call flow.

To me, it's not a question of allowing the session-UUIDs to go 
end-to-end, it's a question of you have 3 UAs involved, so you have 3 
UUIDs for a 2 UUID field value. How exactly is that reconciled, is 
what I want to know?

>I think that the following indicates their preference.

I have not ever seen anyone describe (let alone display) any call 
flow originating from Bob's side, so if "they" have a preference, 
"they" are keeping it to themselves  ;-)

But I agree that if we're going to show an example from Alice's side 
for Disaggregated Media, we need to include one from Bob's side as well.

James

>Hopefully the picture doesn't get too corrupted.
>
>Session-ID
>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, 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

---

From: Brett Tate <[email-masked]>
Date: Fri, 29 Mar 2013 20:02:19 +0000

> How in SIP is this done without sending Bob's computer an INVITE?

As the diagram shows, an INVITE is sent to Bob's computer.  The B2BUA is providing a call originating service for Bob.  Thus it sent an INVITE to Bob's computer to attempt to obtain a video offer.

> UUIDs for a 2 UUID field value. How exactly is that reconciled, is

I'd like to know that also. :)  I mentioned end-to-end because of REQ3; thus, it is just a matter of deciding how best to ignore that requirement.

 REQ3: The solution must require that the identifier, if present, pass
 unchanged through SIP B2BUAs or other intermediaries.

> "they" are keeping it to themselves  ;-)

My apologies if I was being overly presumptuous.  I was extrapolating the slides and prior comments associated with "disaggregated media" call termination to also apply to "disaggregated media" call origination.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 29 Mar 2013 20:22:37 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brett Tate
> Sent: Friday, March 29, 2013 1:02 PM
> To: James Polk (jmpolk); [email-masked]
> Subject: Re: [Insipid] disaggregated media: call origination
> 
> As the diagram shows, an INVITE is sent to Bob's computer.  The B2BUA is
> providing a call originating service for Bob.  Thus it sent an INVITE to Bob's
> computer to attempt to obtain a video offer.
> 
> I'd like to know that also. :)  I mentioned end-to-end because of REQ3; thus,
> it is just a matter of deciding how best to ignore that requirement.
> 

Perhaps this requirement needs be to expanded a bit to differentiate between proxies and B2BUA. For a proxy, in think the existing wording of Req 3 is fine. For a B2BUA, the requirement needs to be changed to state that 'M', in this example, remains unchanged rather than the entire identifier remains unchanged.

Cheers,
Charles
 
> My apologies if I was being overly presumptuous.  I was extrapolating the
> slides and prior comments associated with "disaggregated media" call
> termination to also apply to "disaggregated media" call origination.
>

---

From: James Polk <[email-masked]>
Date: Sun, 31 Mar 2013 14:52:44 -0500

At 03:22 PM 3/29/2013, Charles Eckel (eckelcu) wrote:
>Perhaps this requirement needs be to expanded a bit to differentiate 
>between proxies and B2BUA. For a proxy, in think the existing 
>wording of Req 3 is fine. For a B2BUA, the requirement needs to be 
>changed to state that 'M', in this example, remains unchanged rather 
>than the entire identifier remains unchanged.

I see what you're saying, but the tricky think is here we want any 
SIP intermediary to pass a received Session-ID header-value unchanged 
through the intermediary, and yet allow B2BUA's that are part of any 
forking or call origination to swap one UUID for another. The best 
example of this is in the solution doc, the 3PCC example. That is not 
the only example of where this will need to occur, but it's a good 
one to point at. If you or everyone agrees (roughly ;-), the wording 
of REQ3 gets more delicate, and longer. I'm not opposed to that 
outcome, just would like to see offered text from someone(s)...

James