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

[Justin Uberti <[e-mail]>]

On Mon, Apr 29, 2019 at 6:01 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
> In a non-trickle case, I think it would be very strange if the agent
> didn’t get any candidates front the peer agent.
>
>
> >I have just sent a message to the mmusic list regarding ice-sip-sdp and
> offers with >no candidates. There is nothing that technically prohibits it
> in RFC 5245, so I >thought it makes sense to add a note which explicitly
> allows it in ice-sip-sdp.
> >
> >There is a valid use case for this, when client is behind NAT and it
> would only >communicate with a server on public address. In such cases,
> client does not need >to collect any candidates and simply send the offer.
> Once it gets the answer from >the server with the public address, client
> can send a STUN bind request to server >address using a local socket not
> bound to any address, which will use default >route. There are multiple
> benefits for implementing it this way, one of which >would be client
> privacy.
>
> One option would then be to say that PAC only applies when an agent
> actually has received some candidates from its peer.
>
> If an agent does NOT receive any candidates from the peer, it knows that
> the only  candidates it will get are peer reflexive ones, and how long the
> agent waits for those is an implementation issue.
>
> >Not sure that makes sense, that directly contradicts one of the examples
> >in the actual PAC document.
> >
> >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.

>
> 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, 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.