Re: [maitai] Roles of Sender and Receiver

IMO the initial call setup and o/a should do something reasonable if one 
of the two parties is a telepresence device and the other is an 
"ordinary" device. In particular, it ought to allow the establishment of 
a session at the level the "ordinary" device can sustain. And that 
should work regardless of which is the caller and which is the offerer.

If it happens that both parties are telepresence devices, then the 
initial call setup should either sort all the media out appropriately, 
or else enable mechanisms to permit it to be done subsequently. That is 
probably the meat of the maitai work.

	Thanks,
	Paul

On 12/7/2010 10:09 AM, Peter Musgrave wrote:
> 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
>
> _______________________________________________
> maitai mailing list
> maitai@ietf.org
> https://www.ietf.org/mailman/listinfo/maitai
>