Subject: Re: [clue] [maitai] Roles of Sender and Receiver

From: "Roni Even" <[email-masked]>
Date: Thu, 6 Jan 2011 12:09:07 +0200

Hi Allyn,

I think that are current view as described in the use cases are based on
receiver composed. We describe the streams that can be sent but are not
discussing the composition at the receiver. If the sender will decide which
streams to send it may need to know not only the number of monitors on the
receiver but also if the receiver can compose multiple streams to one
display or have some PIP capabilities.

I think that one such example of sender decision base on receiver capability
is "send me only the stream from the camera of the active speaker". This is
not a simple selection like the current offer answer. I think that if we go
this way (sender composed) it may require to be able to define many
different policies that may be requested by the receiver.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Allyn Romanow (allyn)
Sent: Saturday, December 04, 2010 12:47 AM
To: Peter Musgrave
Cc: [email-masked]
Subject: Re: [maitai] Roles of Sender and Receiver

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 <[email-masked]>
Date: Thu, Dec 2, 2010 at 2:02 PM
To: "Mike Hammer (hmmr)" <[email-masked]>
Cc: [email-masked]

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

----------

---

From: "Roni Even" <[email-masked]>
Date: Thu, 6 Jan 2011 12:09:28 +0200

Hi,
I think this is an important point. We may need to look at the changes
during the call which may be temporary and I do not think that using offer
answer for it will be the optimal solution.
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Musgrave
> Sent: Tuesday, December 07, 2010 5:10 PM
> To: Mike Hammer (hmmr)
> Cc: [email-masked]
> Nope.
> I think there are several bridges. The first is the initial call setup
> and mapping streams. The second is adding/removing/making changes as
> the meeting proceeds and the need for specific stream content
> changes...
> 
> Peter
> 
> On 2010-12-07, at 10:01 AM, Mike Hammer (hmmr) wrote:
> 
> > Better to use a new attribute than overload an existing attribute.
> >
> > But, this also assumes we are using SDP and SIP to provide dynamic
> > controls during call.
> > Have we crossed that bridge yet?
> >
> > Mike
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Peter Musgrave
> > Sent: Tuesday, December 07, 2010 6:07 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > I think this causes confusion with hold/resume. I can have a camera
> and
> > display but choose not to receive your video temporarily as I e.g.
> use
> > the display to look at something else.
> >
> > Hence I don't see it a suitable for describing the static endpoint
> > physical configuration.
> >
> > In principle a new SDP attribute could be used (e.g. a=device:camera)
> > but this will cause all kinds of backwards compatibility issues with
> > calls to devices which do not understand this. I suspect some use of
> the
> > SDP grouping framework might come into play here...
> >
> > Peter
> >
> >
> > On 2010-12-07, at 3:49 AM, <[email-masked]> wrote:
> >
> >>>
> >>> In fact in the first exchange we also need to provide some
> >>> information about media asymmetry (e.g. I may have three
> >>> screens, but 4 cameras or three screens and two cameras). so
> >>> my video m lines do not necessarily imply anything my ability
> >>> to send that many videos....
> >>>
> >>
> >> Why can't we use one m= line per unidirectional stream and use
> >> a=sendonly/a=recvonly to discrimate between screens and cameras?
> >
> > _______________________________________________
> > maitai mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/maitai
> 
> _______________________________________________
> maitai mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/maitai

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 6 Jan 2011 13:09:45 -0800

Hi Roni,

Yes, I agree with you. I was just looking at how to update the use cases
to reflect this, as I believe we have to encompass both receiver based
layouts, which probably include subscription, and sender based layouts,
in which the sender needs to know something about the receiver's display
capabilities.

Best regards,

Allyn

From: Roni Even [mailto:[email-masked]] 
Sent: Thursday, January 06, 2011 1:17 AM
To: Allyn Romanow (allyn); 'Peter Musgrave'
Cc: [email-masked]
Subject: RE: [maitai] Roles of Sender and Receiver

Hi Allyn,

I think that are current view as described in the use cases are based on
receiver composed. We describe the streams that can be sent but are not
discussing the composition at the receiver. If the sender will decide
which streams to send it may need to know not only the number of
monitors on the receiver but also if the receiver can compose multiple
streams to one display or have some PIP capabilities.

I think that one such example of sender decision base on receiver
capability is "send me only the stream from the camera of the active
speaker". This is not a simple selection like the current offer answer.
I think that if we go this way (sender composed) it may require to be
able to define many different policies that may be requested by the
receiver.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Allyn Romanow (allyn)
Sent: Saturday, December 04, 2010 12:47 AM
To: Peter Musgrave
Cc: [email-masked]
Subject: Re: [maitai] Roles of Sender and Receiver

Hi Peter,

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

 ----------

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

----------