Re: [maitai] Roles of Sender and Receiver

[Paul Kyzivat <[e-mail]>]

On 12/7/2010 10:58 AM, [e-mail] wrote:
> I see. Unless the initiator has means to get information on the capabilities of the remote endpoint prior to initiate a session, it looks like we will have to use RFC5939 and include information that can be undertsood by an "ordinary" device as part of the "actual configuration" and telepresence specific information as part of the "potential configurations"...

I don't know that its *necessary* to use 5939, but that might be a good 
way to accomplish the result. While that is new and presumably not much 
implemented, there will be new implementation for maitai in any case, so 
it might be acceptable to build on it here.

	Thanks,
	Paul

>> -----Message d'origine-----
>> De : [e-mail] [mailto:[e-mail]]
>> De la part de Paul Kyzivat
>> Envoyé : mardi 7 décembre 2010 16:30
>> À : [e-mail]
>> Objet : 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Peter Musgrave
>>>> Sent: Tuesday, December 07, 2010 6:07 AM
>>>> To: [e-mail]
>>>> Cc: [e-mail]
>>>> 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,<[e-mail]>   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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/maitai
>>>
>>> _______________________________________________
>>> maitai mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/maitai
>>>
>> _______________________________________________
>> maitai mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/maitai
>>
>