Re: [maitai] Roles of Sender and Receiver

[Peter Musgrave <[e-mail]>]

Hi Keith, 

What I vaguely recall from reading BFCP was that the modes were client, server or client-server. That was the part I was attempting to draw a parallel with...

I agree that centralization is not model that can be applied to all the TP use cases. 

Thx

Peter

On 2010-12-04, at 3:22 PM, DRAGE, Keith (Keith) wrote:

> I'm not sure how BFCP will help you with this.
>  
> BFCP works round a model of a centralised request server, which grants floors either automatically or under chair control, or as some combination of the two.
>  
> Or are you saying that this will only work with a centralised conference server, which also contains the telepresence server.
>  
> Keith
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Peter Musgrave
> Sent: Saturday, December 04, 2010 4:17 PM
> To: Allyn Romanow (allyn)
> Cc: [e-mail]
> Subject: Re: [maitai] Roles of Sender and Receiver
> 
> Hi Allyn, 
> 
> I agree. I always start with bright-eyed optimism that the world can be simplified, but then the real-world intrudes. 
> 
> A agree that we will need modes which are in the pattern of client, server and peer (or client-server). Then we need modal specification of who can dictate or request what of whom....
> 
> Some of the semantics of BFCP might apply here. I need to go re-re-read that. (I'm not saying we'll use BFCP - just that is a model of the type of interaction we may need)
> 
> This also means that a representation format needs to fully encompass cameras, displays and audio sources and that an endpoint needs to be able to fully interpret a far ends capabilities in this regards. I was looking for simplifications where this could be fairly abstract or simplified (i.e. I  only need to tell the far end about my displays, I'll decide what do do with my cameras) but this seems to not be practical. 
> 
> Regards, 
> 
> Peter
> 
>  
> 
> 
> On 2010-12-03, at 5:47 PM, Allyn Romanow (allyn) wrote:
> 
>> Hi Peter,
>> I agree with Marshall’s later comment that “we have to accommodate both models”.
>> It seems to me that different systems may work differently – some may use a subscription model, others can have it pre-set that either the sender (including MCU), or receiver (as in current Cisco system) may decide how to do the layout. In the primary spec that we are developing, we just need to be able to give coherent information for whichever implementation policy is being followed. So, we have to check that our descriptive model works for different implementation methods.
>> The second aspect of the charter is to see what extensions  in our protocols may be necessary to be able to carry out one or another policy.  But for the spec that we are doing to describe the relationships between multiple streams so that they can be reasonably rendered, I think we need to have that description work for any of the composition models (meaning sender composed or receiver composed).
>> What do you think?
>> Allyn
>> 
>>  ----------
>> From: Peter Musgrave <[e-mail]>
>> Date: Thu, Dec 2, 2010 at 2:02 PM
>> To: "Mike Hammer (hmmr)" <[e-mail]>
>> Cc: [e-mail]
>> 
>> 
>> I think this is actually a different, very interesting issue. This speaks to control DURING the call and the need for that to be dynamic. I completely agree - but as understand the charter it's out of scope...although I think it is inevitable that we will need to look at what exists (BFCP, conference event      etc.) and determine if it can be used or start to define something new.
>> 
>> This might be subverted by sending all and letting the receiver take them on and off hold quickly...clunky but avoid protocol work.
>> 
>> My specific question relates to the initial setup where I have two 3 display, 3 camera systems from different vendors. Who decides which stream goes where? Sender or receiver?
>> 
>> Peter
>> 
>> ----------
>>  
>