Subject: RE: [Sipping] Re: I-DACTION:draft-loreto-sipping-dialog-correlation-00.txt

From: "Even, Roni" <[email-masked]>
Date: Fri, 24 Mar 2006 19:10:28 +0200

Hi Gonzalo,
The example in the email thread 
"For example, I walk into a meeting room while talking on my audio-only mobile terminal and I want to add video using the fixed camera and large screen in the meeting room." 
Is a good example. I am aware that using a phone for audio and a separate appliance or web camera for video is available in real products. The correlation is done in a central entity and you cannot easily achieve the scenario you describe in the above example being of ad-hoc relationship. The need to the correlation in this case is important, for example, for lip-synch or in multipoint for voice activated video switch.
I think that the draft lacks the support of transferring the initial dialog (the phone) to a different phone while keeping the same session relationship continue.

Roni Even 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Adam Roach <[email-masked]>
Date: Fri, 24 Mar 2006 11:21:41 -0600

>Is a good example. I am aware that using a phone for audio and a separate appliance or web camera for video is available in real products. The correlation is done in a central entity and you cannot…

I think you're right. It sounds like we need "a light-weight
message-oriented coordination protocol for group communication between
application components." To support this specific use case in a
transparent fashion, it sounds like it need to provide "automatic
location of communication peers."

Text in quotes is not my own. I attribute it to the abstract of
http://www.ietf.org/rfc/rfc3259.txt

My point being: we solved this problem already. We're hearing from
multiple people that we need multi-device coordination. Let's leverage
the wheel that we've already invented instead of starting from scratch.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Mar 2006 13:24:47 -0500

We can get hung up on what protocols are used, but fundamentally there 
are two different architectures for this situation:

1)	A ------------------ B
	                     |
	C -------------------|

2)	A ------------------ B
	|
	C

In the above, A is the node that wants to use a camera, C is the camera, 
and B is the other participant in the call, and largely a passive bystander.

It is architecture (1) that is advocated by this draft. I have suggested 
that (2) is a better architecture that can be achieved using sip 3pcc. 
Adam is, I think, suggesting (2) using mbus for the A-C link.

A key difference is how much is expected of B to make this work. I hear 
some say that this is really easy for B to do. But I'm not so sure that 
is true. For instance, suppose that C is included using approach (1), 
and then B decides to transfer "the call" to node D. Is it the 
responsibility of B to transfer both A and C, or only A. If it is 
expected to transfer both A and C, then the complexity for B has been 
increased.

I also don't see how A uses approach (1) if A and B are in session and B 
sends a reinvite to A proposing to add video to the existing session.

	Paul

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 28 Mar 2006 16:29:55 +0200

Paul,

I agree that  2 sounds more reasonable, but I am slightly uncomfortable 
when I think about media. Does media flow from C to B directly? If so, 
do we have any issues with A putting B's IP address and port in the 
signalling to C?

Or is A a media repeater?

Hisham

On Mar 24, 2006, at 7:24 PM, Paul Kyzivat wrote:

> In the above, A is the node that wants to use a camera, C is the 
> camera, and B is the other participant in the call, and largely a 
> passive bystander.
>
> It is architecture (1) that is advocated by this draft. I have 
> suggested that (2) is a better architecture that can be achieved using 
> sip 3pcc. Adam is, I think, suggesting (2) using mbus for the A-C 
> link.
>
> A key difference is how much is expected of B to make this work. I 
> hear some say that this is really easy for B to do. But I'm not so 
> sure that is true. For instance, suppose that C is included using 
> approach (1), and then B decides to transfer "the call" to node D. Is 
> it the responsibility of B to transfer both A and C, or only A. If it 
> is expected to transfer both A and C, then the complexity for B has 
> been increased.
>
> I also don't see how A uses approach (1) if A and B are in session and 
> B sends a reinvite to A proposing to add video to the existing 
> session.
>
> 	Paul
>
>
> Adam Roach wrote:
>> Even, Roni wrote:
>>> Hi Gonzalo,
>>> The example in the email thread "For example, I walk into a meeting 
>>> room while talking on my audio-only mobile terminal and I want to 
>>> add video using the fixed camera and large screen in the meeting 
>>> room." Is a good example. I am aware that using a phone for audio 
>>> and a separate appliance or web camera for video is available in 
>>> real products. The correlation is done in a central entity and you 
>>> cannot easily achieve the scenario you describe in the above example 
>>> being of ad-hoc relationship. The need to the correlation in this 
>>> case is important, for example, for lip-synch or in multipoint for 
>>> voice activated video switch.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Mar 2006 12:39:18 -0500

Hisham Khartabil wrote:
> when I think about media. Does media flow from C to B directly?

That would be my expectation.

> If so, 

Why? This is "normal" 3pcc stuff.

> Or is A a media repeater?

If it wants to it can, but that wouldn't be my choice.

	Paul

>> sip 3pcc. Adam is, I think, suggesting (2) using mbus for the A-C link.
>>
>> B sends a reinvite to A proposing to add video to the existing session.
>>
>>     Paul
>>
>>
>> Adam Roach wrote:
>>
>>> Even, Roni wrote:
>>>
>>>> Hi Gonzalo,

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Mar 2006 19:42:12 -0800

I generally prefer the architecture in 1. The architecture in 2 results in A
having all the limitations of a B2BUA with a media relay. Take the case
below for example: If A is an 802.11 wireless audio only phone, now all the
video needs to flow across the wireless network, twice. I'm not saying that
no one will ever implement 2 (my employer does for example), I'm just saying
there are situations where 1 has many advantages over 2.

And either way A and C might need some coordination protocol but that seem
like an orthogonal issue.

On 3/24/06 12:24 PM, "Paul Kyzivat" <[email-masked]> wrote:

>>> "For example, I walk into a meeting room while talking on my audio-only
>>> mobile terminal and I want to add video using the fixed camera and large
>>> screen in the meeting room."
>>> Is a good example. I am aware that using a phone for audio and a separate
>>> appliance or web camera for video is available in real products. The
>>> correlation is done in a central entity and you cannot easily achieve the
>>> scenario you describe in the above example being of ad-hoc relationship. The
>>> need to the correlation in this case is important, for example, for
>>> lip-synch or in multipoint for voice activated video switch.
>>> 
>>> 
>> 
>>

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 30 Mar 2006 00:06:45 -0500

inline
----- Original Message ----- 
From: "Cullen Jennings" <[email-masked]>

>
> I generally prefer the architecture in 1. The architecture
> in 2 results in A having all the limitations of a B2BUA
> with a media relay. Take the case below for example: If A
> is an 802.11 wireless audio only phone, now all the video
> needs to flow across the wireless network, twice.

There is no need for media relay. A sends a REFER to C with a Refer-To of A 
itself. When A receives the INVITE from C, it constructs SDP with its audio 
and copies the m/c/a lines for the video from the SDP received from C. A 
sends the SDP in an INVITE to B. When the SDP answer from B comes, A 
extracts the video portion and constructs and SDP answer to send to C. The 
audio goes between A and B, and the video goes between C and B. A is 
esentially doing 3pcc for its camera. All this can be done today without any 
extentions.

Am I missing something that would make this not work?

> I'm not
> saying that no one will ever implement 2 (my employer does
> for example), I'm just saying there are situations where
> 1 has many advantages over 2.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 30 Mar 2006 08:39:07 +0300

Hi,

as I pointed out in the meeting, 3pcc works... it is just more complex. 
A lot of terminals cannot perform 3pcc. However, they can do REFER.

In 3pcc, the signalling over the air interface is also heavier. 
Moreover, if you use something like preconditions, the complexity and 
the number of messages increases dramatically.

Another disadvantage of 3pcc is that the controller (i.e., your user 
agent) needs to understand all the SIP extensions applied to both 
dialogs. That is, even if A and C support foo, they cannot use it 
because all the signalling flows thru B, which does not understand foo.

In any case, we have discussed the differences between 3pcc and a more 
peer-to-peer call control model many times in the past. I do not 
understand why we need to revisit those discussions now. Both models 
have pros and cons. I do not think we should mandate only one of them.

Cheers,

Gonzalo

Bob Penfield wrote:
> inline
> ----- Original Message ----- From: "Cullen Jennings" <[email-masked]>
> 
>>
> There is no need for media relay. A sends a REFER to C with a Refer-To 
> of A itself. When A receives the INVITE from C, it constructs SDP with 
> its audio and copies the m/c/a lines for the video from the SDP received 
> from C. A sends the SDP in an INVITE to B. When the SDP answer from B 
> comes, A extracts the video portion and constructs and SDP answer to 
> send to C. The audio goes between A and B, and the video goes between C 
> and B. A is esentially doing 3pcc for its camera. All this can be done 
> today without any extentions.
> 
>> And either way A and C might need some coordination protocol but that 
>> seem like an orthogonal issue.
>>

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Mar 2006 09:47:15 -0500

> because all the signalling flows thru B, which does not understand foo.

Those arguments apply to a general 3pcc model, which isn't the case 
here. The case here is simply a desire for A to delegate video to C. 
That is a much simpler problem.

> have pros and cons. I do not think we should mandate only one of them.

The reason it is coming up here is because there is a proposal for an 
extension in order to allow the "peer-to-peer" model to do what the 3pcc 
model can do without any extensions. We already have a wheel here - do 
we need another one?

For the feature implementation proposed in this draft to be useful, it 
would have to be widely implemented, even by UAs that otherwise have no 
need for it. (E.g. by every UA that supports both voice and video.) And 
the impact of the implementation would extend beyond the immediate 
feature, to other things such as call transfer.

A 3pcc implementation affects only the device that wants to delegate 
support for a medium to some other device.

	Paul

>> its audio and copies the m/c/a lines for the video from the SDP 
>> received from C. A sends the SDP in an INVITE to B. When the SDP 
>> answer from B comes, A extracts the video portion and constructs and 
>> SDP answer to send to C. The audio goes between A and B, and the video 
>> goes between C and B. A is esentially doing 3pcc for its camera. All 
>> this can be done today without any extentions.
>>
>>>> camera,
>>>> suggested

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Mar 2006 13:58:25 -0600

Cullen Jennings wrote:

>having all the limitations of a B2BUA with a media relay.
>

No; the diagram is *signaling* relationships, not *media* relationships.
A no more needs to relay media for C than a Media Gateway Controller
needs to relay media for the Media Gateway(s) it is controlling.

A key issue -- for me at least -- is that the ability for *me* to use
multiple devices in a call should be predicated on the capabilities of
*my* *own* devices, not the capabilities of whomever I'm calling.
Approach 1 has such a characteristic. Approach 2 does not.

/a

> Take the case

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Mar 2006 16:31:56 -0500

> *my* *own* devices, not the capabilities of whomever I'm calling.

Yes, this is key for me as well.

> Approach 1 has such a characteristic. Approach 2 does not.

How does that follow? IMO the converse is true.

	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Mar 2006 15:34:13 -0600

> How does that follow? IMO the converse is true.

Whoops! You're right. I got the numbers backwards.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 31 Mar 2006 14:46:39 -0800

> Am I missing something that would make this not work?

That sounds like it will work but A still has to act as a B2BUA here to pull
this off. I agree that it does not need to relay media. I imagine you and a
very few others have considered what the call flow looks like when you  need
to do ICE between B and C but I suspect most people have not considered what
that call flow will look like. I agree it is possible and that the SBC
vendors might pull it off. I don't expect to see it on many phones any time
soon. 

I understand Alan's point about better if worked without requiring anything
but 3261 on the the B device. Given we have hashed through this problem many
times before, I think it is fair to say there are people that want to do it
both ways.