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

[Ari Keränen <[e-mail]>]

On 3/2/14 1:17 AM, Emil Ivov wrote:
> 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?

I was suggesting (potentially) both, but perhaps the 
ice-options-optional alone makes more sense as you point out below.

> 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.

Good point. And I would assume this applies to many other extensions too.

> 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".

This seems to indicate that the -required may not necessarily be a good 
idea. Would be great to hear more opinions on this though.

> 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.

Martin, do you happen to remember what kind of case you had in mind for 
this? And would that be solvable with the SIP Requires header?


Cheers,
Ari