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

[Justin Uberti <[e-mail]>]

On Sat, Apr 27, 2019 at 10:42 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.