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

From: Emil Ivov <[email-masked]>
Date: Sat, 1 Mar 2014 12:08:38 +0200

On 28.02.2014, at 17:58, Ari Keränen <[email-masked]> 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.

Emil

> 
> Opinions?
> 
> 
> Cheers,
> Ari
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
https://jitsi.org

---

From: Ari Keränen <[email-masked]>
Date: Sun, 2 Mar 2014 00:55:38 +0000

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

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.

Cheers,
Ari

---

From: Emil Ivov <[email-masked]>
Date: Sun, 2 Mar 2014 01:17:55 +0000

On Sun, Mar 2, 2014 at 12:55 AM, Ari Keränen <[email-masked]> wrote:
>>> 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".
>>>
>>> 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:
>>>
>> 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

---

From: Ari Keränen <[email-masked]>
Date: Sun, 2 Mar 2014 01:34:57 +0000

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

> support for an option and still be perfectly capable of nominating

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

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

> 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