Re: [maitai] Roles of Sender and Receiver

["Allyn Romanow (allyn)" <[e-mail]>]

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


----------