Re: [MMUSIC] ICE options: need new optional and/or required attributes?

[Emil Ivov <[e-mail]>]

On Sun, Mar 2, 2014 at 12:55 AM, Ari Keränen <[e-mail]> wrote:
> On 3/1/14 10:08 AM, Emil Ivov wrote:
>>
>>
>> On 28.02.2014, at 17:58, Ari Keränen <[e-mail]> wrote:
>>
>>> Hi all,
>>>
>>> One open issue regarding ICE-bis has been the semantics of the
>>> ice-options attribute. Currently there is no way of saying "do aggressive
>>> ICE even if you don't understand this option" or "reject my offer if you
>>> don't understand this option".
>>>
>>> One way of solving this would be to introduce a new attribute like:
>>>
>>> a=ice-options-required:foo
>>>
>>> That is, if "foo" is unknown option to the answerer, the offer is
>>> rejected. In addition to solving the second case, it could also be used to
>>> test for the first and if option was not understood, simply leave it out of
>>> the new offer. Of course this would result in one signaling exchange of
>>> delay, and hence for the first case (do still aggressive) we could also
>>> introduce yet another option:
>>>
>>> a=ice-options-optional:bar
>>
>>
>> I don't have a strong opinion on this but the latter seems to be the only
>> one offering consistency with existing implementations.
>
> Do you mean that existing implementations ignore unknown options and still
> do aggressive ICE?

No, the opposite actually.

> The first one, understand or fail, is what Martin Thomson requested at the
> previous meeting. With that you can actually accomplish both, but with some
> penalty.

I might be misunderstanding the semantics you imply in
ice-options-optional and ice-options-requied so let's get that
clarified first:

Are you suggesting them as alternatives (which is what I thought you
meant) or that we adopt both of them together?

My point was that "ice-opitons-optional" fits nicely with what we have
right now. Trickle is a good example of how you could be lacking
support for an option and still be perfectly capable of nominating
aggressively.

I am a bit confused with "ice-options-required" because a) it kind of
overlaps with the SIP Requires header and b) I am not a big fan of
"let's try an offer *this* way and if it fails we'll try it *that*
way". This inevitably leads to the question "are we sure we actually
know why it failed?" (and the common answer "... eer ... not really".

Then again, I don't really mind that much. Still, if people have cases
where this is necessary, I'd be curious to hear them.

Cheers,
Emil

-- 
https://jitsi.org