Re: [MMUSIC] Faster ICE by role reversal?

[Emil Ivov <[e-mail]>]

On 9.11.14, 22:22, Emil Ivov wrote:
> 1. Ability for ICE to yield multiple paths
> 2. The ability to use these paths simultaneously or exclusively
> 3. Switching between available paths with no non-ICE signalling
> 4. (?) If paths are used exclusively, the ability for either path to do
> a switch (we may want to limit this to switches that only change the
> local candidate and not the remote one.
> 5. As interfaces come up: ability to add new candidates without
> disrupting ongoing communication
> 6. As interfaces go down: ability to update without disrupting the
> communication (well ... to whatever extent that is possible).
>
> I think those are the main set. And then there's also one that is more
> MICE-specific:
>
> 7. In the case of a mobility event: the ability to attempt to quickly
> recover at least partial connectivity (as opposed to restoring all paths).

I'd like to add one more here:

8. Preserve the possibility to detect an end of the candidate trickling. 
That is: end of the candidates that are currently available to a peer.

This options allows us to:

a) quickly recognize failure when it occurs and
b) release candidates that are not used as a result of ICE processing.

Emil

-- 
https://jitsi.org