Re: [MMUSIC] Faster ICE by role reversal?

[Emil Ivov <[e-mail]>]

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
b) it is no longer clear when unused candidates (srflx and relay) can be 
released.

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