Re: [MMUSIC] Trickle ICE and frozen candidates

[Emil Ivov <[e-mail]>]

Hey Martin, all,

On 10.07.13, 18:50, Martin Thomson wrote:
> On 9 July 2013 18:58, Emil Ivov <[e-mail]> wrote:
>> OK. Do you mean something like 2. or do you have another mechanism in mind?
>
> I don't have any particular mechanism in mind, though 2 might be
> workable (I initially read "priority" there, which isn't quite right,
> I think that you mean something like "preference order", since it's
> the component ordering that would matter).

Yes and the idea was that component ordering is generally the only thing 
that would influence "priority" within a single foundation. That said, I 
agree there's no reason not to say this directly.

So to summarize. The algorithm would look like this:

We start by unfreezing the first available pair for a foundation. Any 
new pairs would be:

a) automatically unfrozen if they belong to a component that precedes 
that of an unfrozen pair.

b) automatically unfrozen if other checks in that foundation already 
succeeded

c) kept frozen and then handled by regular 5245 unfreezing if they 
belong to components that come after the last currently unfrozen but not 
yet completed check

d) kept frozen if checks for unfrozen pairs in this same foundation have 
already failed.

Obviously "d" is kind of murky. We need it in order for the freezing 
algorithm to have any sense but it could still lead to race conditions 
and premature failures.

So, at least now this doesn't seem like a great way to go forward.

Therefore, it seems to me that the only way to keep "freezing" is to 
mandate that candidates be trickled by component order. This way we 
would be able to pretty much reuse the vanilla ICE algorithm.

Thoughts?

Emil


-- 
https://jitsi.org