Re: [MMUSIC] Trickle ICE and frozen candidates

[Martin Thomson <[e-mail]>]

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.  3 seems a little too loose for me.  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.  And signaling is slow enough for this to be a real
problem.