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

[Emil Ivov <[e-mail]>]

On Thu, Jul 24, 2014 at 10:03 AM, Ari Keränen <[e-mail]> wrote:
> 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?

USE-CANDIDATE-CONFIRMATION (or whatever name we want) sounds like the
most unambiguous and easy to implement option.

I don't think priorities should play a role at this stage, just as
they don't with regular nomination.

Resending USE-CANDIDATE looks slightly more messy to me (especially
when trying to make sense of wireshark traces) but it would still
work.

Emil





-- 
https://jitsi.org