Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis

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

On 7/23/14 6:28 PM, Emil Ivov wrote:
>>>>>  > For the benefits, currently with SIP you are allowed to release the
>>>>> not selected candidate resources after 3 seconds from concluding ICE
>>>>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>>>>>
>>>>> And that is the whole point because currently with aggressive
>>>>> nomination
>>>>> you simply don't know exactly when ICE has concluded.
>>>>
>>>> So if you assume aggressive ICE has concluded after you've got your
>>>> first USE-CANDIDATE checks done (as the text currently says), and you
>>>> stop doing keep-alives on all except the selected candidate pair and
>>>> let
>>>> your relayed and reflexive candidates die away. You still have some
>>>> time
>>>> to switch between the candidates since the candidates are still alive
>>>> for at least some (tens of?) seconds. Isn't that OK?
>>>
>>> If I assume ICE has concluded after my *first* USE-CANDIDATE and let
>>> everything die away then, with aggressive nomination, how am I ever
>>> going to get a second?
>>
>> It takes a while before your server reflexive and relayed candidates die
>> out so you have some time to get more checks through. Of course you
>> shouldn't close the local sockets immediately. However, if you want to
>> do that considerably (> tens of second) later, and perhaps multiple
>> times, it may get more complicated (something like mobility with ICE).
>
> These are exactly the kinds of hacks that implementations try to do
> today. Magic timers and proprietary logic. This is exactly what I was
> hoping we could remove by replicating the same feature in aggressive
> that we already have for regular nomination. As Justin put it:  giving a
> way to the controlling agent to communicate it's selection to the
> controlled.

We could of course recommend some values on how long to wait to take 
away some of the magic.

> It simply doesn't make sense not to have it and it would simplify things
> a lot so the argument "it would add complexity" doesn't really hold.

Makes sense. I'm still wondering what's the best way to do this though.

Would the semantics of the new attribute be "I'm no longer trying to 
find better candidate pairs; use the highest priority with 
USE-CANDIDATE" or "don't use the highest priority pair but use X", or 
something else?


Cheers,
Ari