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

[Nils Ohlmeier <[e-mail]>]

> On Apr 25, 2019, at 11:25, Roman Shpount <[e-mail]> wrote:
> 
> On Thu, Apr 25, 2019 at 2:17 PM Christer Holmberg <[e-mail] <mailto:[e-mail]>> wrote:
> >The timer should start when the connectivity checks start by the remote ICE agent. The timer is needed to make sure local candidate addresses continue
> 
> 
> >to accept STUN binding requests for at least some minimal time, so technically timer should start from the time remote ICE agent was informed about
> 
> >candidate addresses and started connectivity checks. There is some signaling delay involved here, so it needs to accounted by the timer value.
> 
>  
> 
> An agent doesn’t know when the peer agent will start - especially not the offerer. If it sends an INVITE with its candidates, it may take a while before the INVITE even reaches the peer agent, due to network services, call forwarding etc etc etc.
> 
> 
> 
> 
> This was actually one of the issues raised related to the timer start. The offerer can start the timer when it got the first remote candidate or end of candidates notification. Answerer is trickier, since there is no signaling indication when offerer actually got the answer. This is why I was thinking that an extra signaling message (https://github.com/cdh4u/draft-ice-pac/issues/11 <https://github.com/cdh4u/draft-ice-pac/issues/11>), indicating end of sending candidate checks might work better then a timer.

It’s not a perfect solution, but in Firefox we do start the timer when we receive the first ICE candidate from the remote peer. Be it as part of the SDP or separate via trickle ICE. Note: this needs to happen though for valid and invalid candidates (e.g. if the ICE agent can’t handle mDNS candidates, but all candidates it receives are mDNS it needs to start the timer on the first candidate).
We can not make this depend on end of candidates, because it’s quite likely today that an ICE agent will never receive end of candidates, especially with trickle ICE.

I see ICE pac only as a not perfect workaround to cover for some corner cases. While solving this via an extra signaling message might be the better solution I think such a proposal should be done via a separate draft if desired/needed.

Best
  Nils Ohlmeier