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

[Justin Uberti <[e-mail]>]

I see your point, but I tend to think you could always encounter some sort
of unrecoverable system error like this (even after seeing that local
candidates exist), and the ICE agent could always blow up ICE in such a
situation.

On Wed, Jul 10, 2019 at 8:34 PM Nils Ohlmeier <[e-mail]> wrote:

>
> > On 10Jul, 2019, at 16:09, Justin Uberti <[e-mail]> wrote:
> >
> > When writing up this text, I realized there are edge cases where you
> might want to discover prflx candidates even if you didn't send any
> candidates (e.g., you don't send any candidates, you get a single IP from
> the remote side, and when you check it, you get a response back from a
> different IP).
> >
> > Ergo, I think we should start the timer as soon as we have local and
> remote ICE credentials, regardless of whether or not we send a candidate.
>
> Technically there is another edge case (for trickle only I believe): if
> you hand out SDP, but then local gathering of host candidates fails for
> some bizarre reason (e.g. application ran out of file descriptors or
> something alike). In that scenario it would be pointless to start the PAC
> timer, or at least you should end it early when you know that the pairing
> table will stay empty forever.
> Unfortunately the other side will have to wait for the PAC timer to expire
> before giving up, as we don’t have any means to indicate that we are
> neither going to send candidates nor are able to check peers candidates.
>
> Or to state it differently: the PAC timer should be started when at least
> local host candidates exist and local and remote ICE credentials have been
> exchanged.
>
> Best regards
>   Nils Ohlmeier
>
>