Re: [MMUSIC] Faster ICE by role reversal?

[Justin Uberti <[e-mail]>]

On Sat, Nov 8, 2014 at 5:50 PM, Emil Ivov <[e-mail]> wrote:

>
>
> On 8.11.14, 7:08, Justin Uberti wrote:
>
>> Yeah, I'm of the same opinion. If you are going to allow tricking of new
>> candidates, you only have two choices:
>> a) ICE never ends, or
>> b) ICE restart
>>
>> But ICE restart invalidates existing candidates,
>>
>
> Existing candidates can very well be part of the new ICE negotiation and
> if they are confirmed as "still working", no invalidation needs to occur.
>
> 5245 even already mentions this:
>    Consequently, the set of candidates MAY include some,
>    none, or all of the previous candidates for that stream and MAY
>    include a totally new set of candidates gathered as described in
>    Section 4.1.1.
>
>
>
>  which is a serious issue.
>>
>> Therefore I think continuous nomination is the simplest solution to this
>> problem.
>>
>
> Continuous nomination has at least two serious problems:
>
> a) we lose the possibility to clearly detect failures and we need to
> resort to magic timers
>

It's timers one way or another (e.g. how do you know when to give up on
retransmitting ICE checks?). I don't think this is a salient point.


> b) it is no longer clear when unused candidates (srflx and relay) can be
> released.
>

This is explicitly discussed in my proposal.

>
> We could obivously work on resolving the above issues by preserving the
> end-of-candidates indication and then allowing new candidates to still
> arrive after it. We could also work on clearing out a few other points,
> like for example, how receiving a trickled candidate means one needs to
> potentially re-gather and re-trickle and re-check local candidates.
>
> While this is certainly a possibility ... it is likely to simply take us
> to something very similar to ICE restarts. Potentially even the exact same
> thing, only triggered with something other and a ufrag/pwd update. :)
>
> So, it might be more productive to just rename "ICE restarts" to something
> that scares us less and see if and how we need to address any actual issues
> there.
>
> Emil
>
>
> --
> https://jitsi.org
>