Subject: Re: [Ice] One more idea for how to resolve trickle ICE freezing behavior

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Jun 2016 22:02:21 -0600

On 4/5/16 2:26 PM, Peter Thatcher wrote:
> (With chair hat off)
>
> We still haven't figured out how to handle the freezing algorithm for
> trickle ICE.  I'd be happy with saying "freezing is an optimization left
> to the implementation" and leave it out of the spec, which avoids the
> issue altogether.  But if that doesn't work, here's another idea:
>
> Change the rule from
>
> "attempts to unfreeze all candidates belonging to the first component on
> the first media stream"
>
> to
>
> "attempts to unfreeze all candidates belonging to the first component on
> the first media stream /of the candidates received so far/"

Is that equivalent to the following?

   "attempts to unfreeze all candidates it has received so far
   that belong to the first component on the first media stream"

> This means that if you receive a trickled candidate out of order
> according to the "stream/component order", then its unfrozen.  When you
> receive a trickled candidate later that is earlier in that order, then
> its unfrozen also.   This avoids candidates being frozen indefinitely
> and at worse leads to some candidates being unfrozen prematurely.

That seems reasonable.

> This has solves our problem with little downside.  I propose we use it
> and remove the requirement that candidates be signaled in
> "media/component order".

The trickle spec makes a kind of "nesting" assumption (inherited from 
5245 and 5245bis): a candidate exists within the context of a component, 
which in turn exists within the context of a media stream. I think this 
is what you mean by an "order". However, the trickle spec uses the term 
"media stream" (not "media" vs. "stream"), so I'm not sure how you 
understand the difference between "stream/component order" and 
"media/component order". If you could clarify that, I'd be most grateful.

Thanks!

Peter