Re: [MMUSIC] actpass redux

[Roman Shpount <[e-mail]>]

On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat <[e-mail]>
wrote:

> On 6/9/17 2:23 PM, Roman Shpount wrote:
>
>> On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     On 6/9/17 9:17 AM, Cullen Jennings wrote:
>>
>>
>>             On Jun 8, 2017, at 6:49 PM, Roman Shpount <[e-mail]
>>             <mailto:[e-mail]>> wrote:
>>
>>                Because of this, I think for the best interop, offerer
>>             MUST specify actpass for both initial and subsequent offers
>>             but answerer MUST be able to handle active and passive setup
>>             roles as well.
>>
>>
>>         that works for me
>>
>>
>>     I don't understand what this accomplishes. If you must be able to
>>     accept anything in a received offer, then what is gained by
>>     restricting what can be used in an offer?
>>
>>
>> This is all because of legacy interop. There are legacy end points that
>> send non-actpass, so end point MUST be able to accept active and passive to
>> interop with such legacy devices. There are also legacy end points that
>> only expect actass so end point MUST only send actpass to interop with such
>> devices.
>>
>
> I understand that. But if you accept that legacy interop is needed, then
> there ceases to be any reason to mandate actpass for things that conform to
> this spec. It would be different if you were proposing a path to
> deprecating and then dropping the legacy support. If that is the intent
> then it is worth saying something explicit about it.
>

The situation right now is that there are implementations that send offers
with setup role set to active or passive. So, my suggestion for the
language (subject to future wordsmithing) is: End points MUST set setup
role to actpass in all offers. End points SHOULD accept setup role active
or passive in an offer if interoperability with legacy end points is
desired.

Does this work?
_____________
Roman Shpount