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

[Christer Holmberg <[e-mail]>]

Hi,

There is one more option (which has been my assumption):

4) Start the timer when the agent would otherwise declare ICE failure, i.e., when it has tested all available candidate pairs.

Regards,

Christer

From: Roman Shpount <[e-mail]>
Date: Friday, 26 April 2019 at 1.26
To: Nils Ohlmeier <[e-mail]>
Cc: Christer Holmberg <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

On Thu, Apr 25, 2019 at 3:45 PM Nils Ohlmeier <[e-mail]<mailto:[e-mail]>> wrote:
On Apr 25, 2019, at 11:25, Roman Shpount <[e-mail]<mailto:[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), 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.

It is possible that agent will never receive any candidates since it is technically legal to never send any candidates to the remote party when doing trickle ICE. I guess timer does not start in this case so ICE will wait before going into the failure state indefinitely.

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.

I understand the desire to limit the scope of this draft. From what I can see there are 3 options:

1. Start timer when local ICE candidates collection was complete and at least one ICE candidates was received from the remote via signaling message or STUN bind request (timer starts when both conditions must be satisfied). The problem with this is timer might never start and agent will wait indefinitely.

2. Start timer when ICE candidates collection was complete or an ICE candidates was received from the remote via signaling message or STUN bind request (timer starts when either condition is satisfied). The problem here is that if signaling messages are delivered too slowly, ICE nomination will fail even when working candidate pair is potentially present.

3. Add some sort of extra signaling to indicate when ICE checks were complete. In case of WebRTC this option can be implemented via option 1 and some sort of application specific communications which will stop the indefinite wait.

Based on this I would prefer going with option 1.
_____________
Roman Shpount