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

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

Cullen Jennings wrote:

>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.
>

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
>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:
>
>  
>
>>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
>>
>>
>>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.
>>>>
>>>>
>>>>        
>>>>
>>>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
>>>
>>>_______________________________________________
>>>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
>>>
>>>      
>>>
>>_______________________________________________
>>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
>>    
>>
>
>  
>

_______________________________________________
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