Re: [maitai] Roles of Sender and Receiver

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