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

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Apr 2019 08:27:09 +0000

Bringing an issue that came up in GitHub (https://github.com/cdh4u/draft-ice-pac/issues/8) to the list.

The question is: when does an agent start the “PAC timer” (perhaps we should give the timer a name)?

  1.  When the connectivity checks start; OR
  2.  When the agent has performed all checks and reaches a state where it normally would declare ICE failure?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Apr 2019 13:36:33 -0400

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.

Regards,
_____________
Roman Shpount

On Thu, Apr 25, 2019 at 4:27 AM Christer Holmberg <
[email-masked]> wrote:

> Bringing an issue that came up in GitHub (
> https://github.com/cdh4u/draft-ice-pac/issues/8) to the list.
>
>
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Apr 2019 18:17:41 +0000

Hi,

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

Regards,

Christer

On Thu, Apr 25, 2019 at 4:27 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Bringing an issue that came up in GitHub (https://github.com/cdh4u/draft-ice-pac/issues/8) to the list.

Regards,

Christer

_______________________________________________
Ice mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ice

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Apr 2019 14:25:05 -0400

On Thu, Apr 25, 2019 at 2:17 PM Christer Holmberg <
[email-masked]> 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
>
> about
> >candidate addresses and started connectivity checks. There is some
> 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.
_____________
Roman Shpount

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 25 Apr 2019 12:45:03 -0700

> On Apr 25, 2019, at 11:25, Roman Shpount <[email-masked]> wrote:
> 
> On Thu, Apr 25, 2019 at 2:17 PM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> 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

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Apr 2019 18:26:23 -0400

On Thu, Apr 25, 2019 at 3:45 PM Nils Ohlmeier <[email-masked]> wrote:

> 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

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 25 Apr 2019 17:37:46 -0700

> On Apr 25, 2019, at 15:26, Roman Shpount <[email-masked]> wrote:
> 
> On Thu, Apr 25, 2019 at 3:45 PM Nils Ohlmeier <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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.

Option 2 is basically what was implemented in Firefox for quite some time. But we got too many failure reports from the field. So we switched to something similar to Option 1. Thus I would advice against trying option 2.

Option 1 appears to be the reasonable although not perfect solution.

Best
  Nils Ohlmeier

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Apr 2019 07:05:57 +0000

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 <[email-masked]>
Date: Friday, 26 April 2019 at 1.26
To: Nils Ohlmeier <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
On Apr 25, 2019, at 11:25, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Apr 2019 11:07:50 -0400

Hi Christer,

On Fri, Apr 26, 2019 at 3:06 AM Christer Holmberg <
[email-masked]> wrote:

> 4) Start the timer when the agent would otherwise declare ICE failure,
> i.e., when it has tested all available candidate pairs.
>
>
>
I think this option does not work quite well. With option 4, when ICE agent
has a list of valid remote candidates and all these candidates do not fail
immediately with ICMP error, ICE agent will spend enough time trying those
candidates before failing for any remote binding attempts to arrive. So,
option 4 ends up adding extra time when it is not needed.  On the other
hand, when ICE agent does not get any remote candidates, it can go into a
failed state and start timeout before local candidates collected by this
agent were delivered to remote over signaling causing a premature failure.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Apr 2019 20:28:16 +0000

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.

Regards,

Christer
________________________________
From: Roman Shpount <[email-masked]>
Sent: Friday, April 26, 2019 6:07:50 PM
To: Christer Holmberg
Cc: Nils Ohlmeier; [email-masked]
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

Hi Christer,

On Fri, Apr 26, 2019 at 3:06 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

I think this option does not work quite well. With option 4, when ICE agent has a list of valid remote candidates and all these candidates do not fail immediately with ICMP error, ICE agent will spend enough time trying those candidates before failing for any remote binding attempts to arrive. So, option 4 ends up adding extra time when it is not needed.  On the other hand, when ICE agent does not get any remote candidates, it can go into a failed state and start timeout before local candidates collected by this agent were delivered to remote over signaling causing a premature failure.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Apr 2019 16:46:39 -0400

Hi Christer,

On Fri, Apr 26, 2019 at 4:28 PM Christer Holmberg <
[email-masked]> wrote:

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

Regards,
_____________
Roman Shpount

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 26 Apr 2019 14:18:28 -0700

> On Apr 26, 2019, at 13:46, Roman Shpount <[email-masked]> wrote:
> 
> Hi Christer,
> 
> On Fri, Apr 26, 2019 at 4:28 PM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> 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.

Intersting idea. I think this actually works more generally in case the other side indicates to be ice-lite, or if it’s know to be ice-lite.
In other words: this should also work the client being the SDP answerer.
But in any of these cases you would need to know that the other side supports ICE PAC, or?

Best
  Nils Ohlmeier

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Apr 2019 17:33:32 -0400

On Fri, Apr 26, 2019 at 5:18 PM Nils Ohlmeier <[email-masked]> wrote:

> Intersting idea. I think this actually works more generally in case the
> other side indicates to be ice-lite, or if it’s know to be ice-lite.

Currently this works very well with ice-lite server for both offer and
answer. We actually have this deployed with ice-lite server and slightly
"lobotomized" client (i.e. client which starts trickle but never sends
collected candidates to the server). Once we get ICE PAC done, this would
be consistently usable with full ICE on the server side as well.

One thing I was considering is that we should make ICE PAC mandatory for
anything that includes ice-options: ice2. I think it is already implied
with my latest pull request to ice-sip-sdp.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Apr 2019 09:24:07 +0000

Hi,

>One thing I was considering is that we should make ICE PAC mandatory for anything that includes ice-options: ice2. 
>I think it is already implied with my latest pull request to ice-sip-sdp.

'ice2' is defined by RFC 8445. It is not ice-sip-sdp specific.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Apr 2019 17:42:37 +0000

Hi,

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

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Sun, 28 Apr 2019 18:59:52 -0700

On Sat, Apr 27, 2019 at 10:42 AM Christer Holmberg <
[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Apr 2019 13:01:47 +0000

Hi,

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

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.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Mon, 29 Apr 2019 11:07:56 -0700

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 Apr 2019 15:14:39 -0400

On Sat, Apr 27, 2019 at 5:24 AM Christer Holmberg <
[email-masked]> wrote:

> anything that includes ice-options: ice2.
You are correct, ice2 is defined in RFC 8445. This being said, anything
which implements ice-sip-sdp must include ice-options ice2, which means if
ice2 option is negotiated via ice-sip-sdp, all ice-sip-sdp procedures must
be used. If ice-sip-sdp will require PAC, then this would be pulled in as
well. We can deliberately separate and add another ice extension for PAC or
empty candidate lists, but this would be  mostly redundant.

In any case, anything which  implements RFC 8445 would likely need to
implement PAC, since PAC is a specification fix/clarification, not some
additional functionality.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 Apr 2019 15:31:50 -0400

Hi,

> cases if gathering takes a very long time (10+ seconds) for some reason.

There are two approaches that we can take:

First would be "practical" approach. If we assume that number of candidates
is reasonable, local candidate collection takes less then 1-2 seconds, TURN
candidates are returned in couple of seconds, and signaling delays are less
then a second or two, then entire candidate collection and delivery to
remote agent should take less then few seconds. In this case, if minimal
ice time to run is set to reasonably large time (like STUN bind request
timeout, which is 32 sec), then it would give both agents more then enough
time to send a several connectivity checks on all potential ICE candidate
pairs. In any case, if entire procedure would take much longer caller will
hung up and walk away.

Another approach would be "formally correct" approach, which would try to
make sure that ICE nomination succeeds when a valid candidate pair exists.
It will need to deal with large numbers of local candidates (50 candidates
with only candidate 40-something having access to public internet), slow
TURN candidate allocation which takes tens of seconds, and signaling delays
that introduce tens of seconds delays on candidate delivery. If you need to
deal with such setups, then ICE nomination should only fail after the last
STUN binding request from remote agent have failed. In case of ice-sip-sdp,
this will require an additional signaling message. In case of WebRTC this
would mean ICE would never fail unless it was explicitly told to stop by an
application.

We can also try to address something in between and start ICE minimal
time-out after last candidate was sent to the remote agent, but, in cases
with reasonable assumptions this should not make any difference, and in
extreme cases this would not be enough.

My preference would be to go with reasonable assumptions and start the
timer when the last local candidate (or indication that there are no local
candidates) was sent to the remote party.

Regards,
_____________
Roman Shpount

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 29 Apr 2019 13:31:12 -0700

> On Apr 29, 2019, at 11:07, Justin Uberti <[email-masked]> wrote:
> 
> 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:
> 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.

Just as warning here: the worst case scenario is that a TURN and/or STUN server was provided/configured which is not reachable. In that case local gathering will only end after the STUN transactions to these unreachable servers have timed out, which by default is 32 seconds.

Doesn’t it make more sense to have #2 be something like: have received at least one remote candidate, even it turns out to be in an locally unsupported format, or an end-of-canditates with no candidates provided at all.

This would result though in situations where you never start the timer if you receive an answer SDP, but never any ICE candidate or end-of-candidates. Which to me looks some strange edge case where the remote agent has crashed or otherwise failed to gather anything including end-of-candidates.

Best
  Nils Ohlmeier

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Apr 2019 10:30:51 +0000

Hi,

...

> Maybe this is what you meant, but I think it's a "minimum-time-to-run-ICE" timer. 

I guess so, yes.

However, as I said before, I think an agent shall still be allowed to stop earlier, and not be required to wait for peer reflexive candidates, if it already has working pairs.

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

That is one example: gather candidates but don't yet send an offer.

> but one way to ensure we're in the right state would be to start the timer when both of the below are true:

What about starting the timer after the agent has sent its last set of candidates? That would cover both trickle and non-trickle: in non-trickle there is only one set of candidates, and in trickle it doesn't matter how long it takes to provide all candidates since the timer doesn’t start until the last set of candidates have been sent?

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Tue, 30 Apr 2019 10:03:32 -0700

On Tue, Apr 30, 2019 at 3:30 AM Christer Holmberg <
[email-masked]> wrote:

> However, as I said before, I think an agent shall still be allowed to stop
> earlier, and not be required to wait for peer reflexive candidates, if it
> already has working pairs.
>

Sure, this is not a point of contention, but a SHOULD-level directive may
make sense here.

> >> 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,
>
> > #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.
>
> What about starting the timer after the agent has sent its last set of
> candidates? That would cover both trickle and non-trickle: in non-trickle
> there is only one set of candidates, and in trickle it doesn't matter how
> long it takes to provide all candidates since the timer doesn’t start until
> the last set of candidates have been sent?
>
>
That's basically the same thing I was proposing in 2), with the
clarification that the candidates were also actually transmitted. I do
think Nils' point is important though, i.e., if we have a bad server it
will take a very long time to decide on 'last set of candidates', which is
probably not helpful. As such I think the potential positions we can take
are:
a) Start the timer as soon as we have an answer, regardless of any
candidates.
b) a) + receipt of at least one remote candidate (or remote EOC). (This is
Nils' suggestion).
c) a) + sending at least one local candidate (or local EOC).

b) has a problem if the remote side doesn't send any candidates, which we
want to explicitly allow.

I tend to lean towards a) as the simplest option.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 30 Apr 2019 13:50:53 -0400

> I tend to lean towards a) as the simplest option.

What about the answering agent? Does the timer starts as soon as it sends
the answer?
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Tue, 30 Apr 2019 11:56:51 -0700

On Tue, Apr 30, 2019 at 10:51 AM Roman Shpount <[email-masked]> wrote:

>> b) a) + receipt of at least one remote candidate (or remote EOC). (This
>> is Nils' suggestion).

I think so; this would be a). The other possibility to consider is c),
since it is probably the case that only clients who send candidates will
discover prflx candidates from the remote side.