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

[Roman Shpount <[e-mail]>]

On Sat, Jul 6, 2019 at 8:17 AM Christer Holmberg <
[e-mail]> wrote:

> >>So, what timer value do people want?
> >
> >Any number significantly larger than zero will improve the current
> situation. I think 30.5 seconds was mentioned - that's a fine number to me.
>
> I am not sure I understand what you mean by "larger than zero". Nobody
> today declares ICE failure at the same time as the begin ICE, do they?
>

This is exactly what happens and this what we are trying to fix.


> >> And, assuming the timer value is not going to be based on the number of
> streams, what do we do if the timer expires before
> >> we have tested all pairs for all streams? I think we need to specify
> that.
> >
> > Exactly what we do today.
> > If I interpret the situation correctly, the timer is to catch the state
> when we don't have remote candidates to try, so if the timer
> > expires while we have remote candidates to try, we will just go on
> trying them; if the timer expires when we have no remote candidates,
> > we go to "failed" state, exactly as we do today.
>
> In that case, why can't we start the timer once we don't have any remote
> candidates left?
>
> Because, ff we DO have remote candidates, the timer is meaningless,
> because if the timer expires we will ignore it and go on testing them.
>

If there are remote candidates to check, then ICE should continue checking
them. Part of the problem is that when ICE is starting, it is unclear if
remote candidate have not been received yet, no usable remote candidates
where received, or remote candidates are not going to be sent at all.
Also, checking remote candidates can end very quickly if remote candidates
are unreachable (fail immediately with ICMP remote address unreachable
message).

_____________
Roman Shpount