Re: [MMUSIC] Trickle ICE and frozen candidates

[Emil Ivov <[e-mail]>]

Hey Martin,

On 09.07.13, 21:45, Martin Thomson wrote:
> On 9 July 2013 05:44, Emil Ivov <[e-mail]> wrote:
>> While 1 and especially 2 may be preferable in terms of efficiency,
>> personally, I am worried that getting it right in terms of spec and
>> implementation is non-trivial and this may become a common reason for
>> interoperability problems. Therefore, 3 does seem like the simplest way to
>> go.
>
> You are going to want to ensure that both peers check in the same
> order.

What exactly do you mean by "in the same order"? Do you mean that:

a) they should try and make sure that they are checking the candidate 
pair that is symmetric to the one their peer is testing and
b) all other components for the involved foundations should be frozen?

Do you have a better wording?

> 3 seems a little too loose for me.

It is indeed loose but I can't think of a reason why it wouldn't work 
even with several seconds of RTT. So, unless you are going to manually 
paste every new candidate into a mail and then do the the same on the 
remote side, you should probably be fine.

Ekr, I believe you mentioned you were doing this in Firefox? How is it 
working?

> I think that some sort of
> mechanism is going to be needed to avoid problems with races, since
> both peers will have different sets of candidate pairs at every point
> in the process.

OK. Do you mean something like 2. or do you have another mechanism in mind?

Emil


-- 
https://jitsi.org