Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

[Christer Holmberg <[e-mail]>]

Hi,

...

>>> Overall I think the Firefox approach makes the most sense - the PAC timer 
>>> starts when you have either a local or remote candidate. 
>>
>> That would mean that PAC becomes a the-maximum-time-to-run-ICE timer. If that's what people want, fine.
>
> Maybe this is what you meant, but I think it's a "minimum-time-to-run-ICE" timer. 

I guess so, yes.

However, as I said before, I think an agent shall still be allowed to stop earlier, and not be required to wait for peer reflexive candidates, if it already has working pairs.

>> However, you can have a local candidate long before the remote peer gets it, so starting the timer once you 
>> have a candidate sounds strange to me. I think we should at least wait until the agent has sent the agent to the peer. 
>
> This is an important observation - we don't want to start the timer until we think both us and the peer agent are running 
> ICE processing (e.g., if we just gathered candidates but didn't send an offer, we shouldn't start the timer). I'm not totally sure 
> what you meant above,

That is one example: gather candidates but don't yet send an offer.

> but one way to ensure we're in the right state would be to start the timer when both of the below are true:
> 1) We have sent or received an answer.
> 2) Local candidate gathering has completed (including the case when zero candidates have been gathered).
>
> #2 may not be strictly necessary, but gives us more flexibility in trickle cases if gathering takes a very long time (10+ seconds) for some reason.

What about starting the timer after the agent has sent its last set of candidates? That would cover both trickle and non-trickle: in non-trickle there is only one set of candidates, and in trickle it doesn't matter how long it takes to provide all candidates since the timer doesn’t start until the last set of candidates have been sent?

Regards,

Christer