Re: [MMUSIC] Faster ICE by role reversal?

[Emil Ivov <[e-mail]>]

On Fri, Nov 7, 2014 at 12:29 AM, Martin Thomson
<[e-mail]> wrote:
> On 6 November 2014 13:47, Justin Uberti <[e-mail]> wrote:
>> I looked into how MICE works; I think that continuous nomination might be
>> able to effectively support that use case, as well as the case that Brandon
>> was interested in, namely picking the route that uses the best set of TURN
>> servers.
>
> I've always believe that continuous ICE operation was the only way to
> ensure proper reliability.  Multipath or otherwise.  You just need to
> work out when it is safe to completely stop on any given pair,
> assuming that you don't want to be testing the complete mesh all the
> time.  But you also might want multiple paths available, or maybe
> backup paths.

There are two aspects here:

1. Obtaining multiple valid paths as a result of ICE processing (and
leaving it up to apps to use one or more) and
2. Handling events where new candidates become available and need to
be communicated to the remote party.

"1" can definitely be very useful so that would be a great feature to
add to ICE.

I agree that, especially with mobiles, "2" is also important. That
said, what is the problem of doing this with Trickle ICE today?

Starting a new Trickle ICE negotiation is a very light-weight process.
It is basically a matter of sending a new ufrag/pwd pair.  It is also
a non-disruptive process as media continues during ICE processing and
failure results in falling back to whatever one had before.

Also note that, if new candidates appear as a result of mobility
event, it might be worth rechecking your previous pairs anyway because
some of them may have become invalid or, on the contrary, more
relevant.

On the other hand, having a clear "start" and "end" in ICE processing
also has value as it allows one to declare failure in a deterministic
way, as opposed to just waiting out magic timers.

I other words, I think we already have everything that is necessary
for continuous ICE operation, don't we?

Emil

-- 
https://jitsi.org