Re: [maitai] Roles of Sender and Receiver

Might be nice to have some sort of use cases, requirements, architecture
documents first before diving into the protocols.

Any wind is a good wind, if you don't know what direction to go.  :)

Mike

-----Original Message-----
From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] 
Sent: Tuesday, December 07, 2010 10:10 AM
To: Mike Hammer (hmmr)
Cc: bruno.chatras@orange-ftgroup.com; maitai@ietf.org
Subject: Re: [maitai] Roles of Sender and Receiver

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: maitai-bounces@ietf.org [mailto:maitai-bounces@ietf.org] On
Behalf
> Of Peter Musgrave
> Sent: Tuesday, December 07, 2010 6:07 AM
> To: bruno.chatras@orange-ftgroup.com
> Cc: maitai@ietf.org
> Subject: Re: [maitai] Roles of Sender and Receiver
> 
> 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, <bruno.chatras@orange-ftgroup.com> 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
> maitai@ietf.org
> https://www.ietf.org/mailman/listinfo/maitai