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

From: Peter Thatcher <[email-masked]>
Date: Mon, 1 Jul 2019 17:56:15 -0700

I agree.  The options you present seem reasonable and I think we should
move ahead with them.

On Mon, Jun 24, 2019 at 6:20 AM Harald Alvestrand <[email-masked]>
wrote:

> On 6/24/19 12:06 PM, Christer Holmberg wrote:
>
> Hi,
>
>
>
> Go for what? 😊
>
> I was noting the month of silence, and thinking that I should encoruage a
> decision to be taken - "analysis paralysis" is not a good thing!
>
>
>
> Regarding 1), eventhough it’s not my personal preference to start the
> timer when the first offer/answer is sent, I could live with it.
>
>
> It's a well defined time, and is observable by the entity that has to act
> when the timer expires, so I think it is much better than "undefined".
>
> That's my requirement :-)
>
>
>
>
> Regarding 2), however, I would really like some input on whether the
> duration should be independent of the number of streams, components etc.
>
> I think having a single number is preferable to having a complex number
> that could change over time (for instance, if we don't reset the timer when
> adding streams, then adding or removing streams after the timer started
> will lead to hard-to-define behavior).
>
>
> But my main concern is that we get this stuff done and get the basic timer
> mechanism into interoperable code - having a spec to implement from now is
> better than having a spec that has had slightly more discussion, but no
> fundamental changes, 6 months from now.
>
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *Harald Alvestrand <[email-masked]> <[email-masked]>
> *Date: *Sunday, 23 June 2019 at 9.08
> *To: *Christer Holmberg <[email-masked]>
> <[email-masked]>, Justin Uberti <[email-masked]>
> <[email-masked]>, Nils Ohlmeier <[email-masked]>
> <[email-masked]>
> *Cc: *Roman Shpount <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for
> possible peer reflexive candidates? - discussion restart
>
>
>
> On 5/28/19 1:54 PM, Christer Holmberg wrote:
>
> Hi,
>
>
>
> We need to move forward with this.
>
>
>
> There are two main questions at the moment:
>
>
>
>    1. When does an endpoint start the timer ("minimum-time-to-run-ICE"
>    timer, based on previous discussions)?
>    2. What is the duration of the timer?
>
>
>
> Regarding 1), my understanding is that people suggest alternative c),
> which starts the timer when an endpoint has sent (in an offer or answer) at
> least one local candidate (or EOC).
>
>
>
>
>
> Regarding 2), it has been suggested that the duration would be the same as
> the max duration of a connectivity check transaction. Do we think that is
> enough, no matter how many media streams and components are used?
>
>
>
> Go for it. It is much better than having nothing.
>
>
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Ice <[email-masked]> <[email-masked]> on behalf of
> Christer Holmberg <[email-masked]>
> <[email-masked]>
> *Date: *Friday, 3 May 2019 at 15.02
> *To: *Justin Uberti <[email-masked]> <[email-masked]>, Nils
> Ohlmeier <[email-masked]> <[email-masked]>
> *Cc: *Roman Shpount <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for
> possible peer reflexive candidates?
>
>
>
> Hi,
>
>
>
> I don’t think there will be any interoperability issues. At the end of the
> day PAC is only about how long to wait for candidates, so the worse thing
> that can happen is than an agent declares ICE failure too early.
>
>
>
> And, no matter whether an agent knows that the peer supports PAC or not,
>  it should aim at sending it’s candidates to its peer as soon as possible,
> depending on whatever local policies. The agent should not delay sending
> candidates just because it assumes that the peer will anyway wait for them.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *Justin Uberti <[email-masked]> <[email-masked]>
> *Date: *Thursday, 2 May 2019 at 22.28
> *To: *Nils Ohlmeier <[email-masked]> <[email-masked]>
> *Cc: *Christer Holmberg <[email-masked]>
> <[email-masked]>, Roman Shpount <[email-masked]>
> <[email-masked]>, "[email-masked]" <[email-masked]> <[email-masked]>
> <[email-masked]>
> *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for
> possible peer reflexive candidates?
>
>
>
>
>
>
>
> On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier <[email-masked]>
> wrote:
>
>
>
>
>
>
>
> On May 2, 2019, at 12:13, Justin Uberti <[email-masked]> wrote:
>
>
>
>
>
>
>
> On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <[email-masked]>
> wrote:
>
>
> >> 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).
>
> As we are mostly concerned about the remote side: 1) not providing us with
> candidates, or 2) providing us with unusable candidates or 3) providing us
> with candidates really late I don’t see how option c) would help in any of
> these scenarios.
> From my point of view we should choose either a) or b).
>
>
>
> c) is just a clarification of a), in that you can't expect to receive
> prflx candidates until you've at least provided the other side with a
> candidate, so that may be the right time for the timer to start. I don't
> feel super strongly about this though.
>
>
>
> Ok. I hadn’t looked at it from that angle. So c) being a stronger a) I
> guess it would be okay.
>
>
>
> I guess my only concern is that in Firefox we stopped doing a) because it
> caused to many problems. With that in mind would it cause interop problems
> if we leave up to the implementor to choose to implement either b) or c)?
>
>
>
> I'd be fine with that, but I'd want to describe what to watch out for. Can
> you explain a bit more?
>
>
>
>
>
>
> >> b) has a problem if the remote side doesn't send any candidates, which
> we want to explicitly allow.
> >
> > True.
>
> Just to make sure we are all on the same page: b) is only a problem in the
> scenario where the remote side doesn’t send any candidates but also does
> not send EOC.
>
>
> The EOC should allow agents which explicitly don’t want to provide
> candidate to get the timer started soon.
> I think that leaves us with scenarios where the remote doesn’t provide
> host candidates, and it’s reflexive or relay candidates take for ever
> because of slow servers.
>
>
>
> Correct, but we can't control which endpoints will send us an EOC or not.
> So that will always be a possibility.
>
>
>
> Fair enough.
>
>
>
>
>
>
> >> I tend to lean towards a) as the simplest option.
> >
> > Keep in mind that RFC 8445 is generic, so we need to to define what we
> mean by "answer". I guess it means some kind of indication that makes the
> agent assume that the remote peer has been contacted. In ice-sip-sdp we can
> then map that to an SDP answer.
>
> Good point. We basically treat the SDP answer here to be something like an
> beginning of ICE, because we don’t have an explicit signal for that. I
> think in SDP based worlds there is no need for an extra signal like that.
> Not sure if other use cases of ICE would benefit from an explicit begin
> signal.
>
>
>
> The answer in some ways is an explicit begin signal, because it contains
> the username/password information needed to start ICE checks.
>
>
>
> Yeah I didn’t see your reply before hitting send on mine. Using the
> availability sounds like a good idea as the minimum gating function/signal.
>
>
>
> Best
>
>   Nils
>
>
>
>
>
> _______________________________________________
>
> Ice mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/ice
>
>
>
> --
>
> Surveillance is pervasive. Go Dark.
>
>
> --
> Surveillance is pervasive. Go Dark.
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Jul 2019 20:02:05 +0000

So, what timer value do people want?

And, assuming the timer value is not going to be based on the number of streams, what do we do if the timer expires before we have tested all pairs for all streams? I think we need to specify that.

Regards,

Christer

From: Peter Thatcher <[email-masked]>
Sent: 02 July 2019 03:56
To: Harald Alvestrand <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Justin Uberti <[email-masked]>; Nils Ohlmeier <[email-masked]>; Roman Shpount <[email-masked]>; [email-masked]
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

I agree.  The options you present seem reasonable and I think we should move ahead with them.

On Mon, Jun 24, 2019 at 6:20 AM Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
On 6/24/19 12:06 PM, Christer Holmberg wrote:
Hi,

Go for what? 😊

I was noting the month of silence, and thinking that I should encoruage a decision to be taken - "analysis paralysis" is not a good thing!

Regarding 1), eventhough it’s not my personal preference to start the timer when the first offer/answer is sent, I could live with it.

It's a well defined time, and is observable by the entity that has to act when the timer expires, so I think it is much better than "undefined".

Regarding 2), however, I would really like some input on whether the duration should be independent of the number of streams, components etc.

I think having a single number is preferable to having a complex number that could change over time (for instance, if we don't reset the timer when adding streams, then adding or removing streams after the timer started will lead to hard-to-define behavior).

But my main concern is that we get this stuff done and get the basic timer mechanism into interoperable code - having a spec to implement from now is better than having a spec that has had slightly more discussion, but no fundamental changes, 6 months from now.

Regards,

Christer

From: Harald Alvestrand <[email-masked]><mailto:[email-masked]>
Date: Sunday, 23 June 2019 at 9.08
To: Christer Holmberg <[email-masked]><mailto:[email-masked]>, Justin Uberti <[email-masked]><mailto:[email-masked]>, Nils Ohlmeier <[email-masked]><mailto:[email-masked]>
Cc: Roman Shpount <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

  1.  When does an endpoint start the timer ("minimum-time-to-run-ICE" timer, based on previous discussions)?
  2.  What is the duration of the timer?

Regarding 1), my understanding is that people suggest alternative c), which starts the timer when an endpoint has sent (in an offer or answer) at least one local candidate (or EOC).

Regarding 2), it has been suggested that the duration would be the same as the max duration of a connectivity check transaction. Do we think that is enough, no matter how many media streams and components are used?

Regards,

Christer

From: Ice <[email-masked]><mailto:[email-masked]> on behalf of Christer Holmberg <[email-masked]><mailto:[email-masked]>
Date: Friday, 3 May 2019 at 15.02
To: Justin Uberti <[email-masked]><mailto:[email-masked]>, Nils Ohlmeier <[email-masked]><mailto:[email-masked]>
Cc: Roman Shpount <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

Hi,

I don’t think there will be any interoperability issues. At the end of the day PAC is only about how long to wait for candidates, so the worse thing that can happen is than an agent declares ICE failure too early.

And, no matter whether an agent knows that the peer supports PAC or not,  it should aim at sending it’s candidates to its peer as soon as possible, depending on whatever local policies. The agent should not delay sending candidates just because it assumes that the peer will anyway wait for them.

Regards,

Christer

From: Justin Uberti <[email-masked]><mailto:[email-masked]>
Date: Thursday, 2 May 2019 at 22.28
To: Nils Ohlmeier <[email-masked]><mailto:[email-masked]>
Cc: Christer Holmberg <[email-masked]><mailto:[email-masked]>, Roman Shpount <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier <[email-masked]<mailto:[email-masked]>> wrote:

On May 2, 2019, at 12:13, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <[email-masked]<mailto:[email-masked]>> wrote:

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

As we are mostly concerned about the remote side: 1) not providing us with candidates, or 2) providing us with unusable candidates or 3) providing us with candidates really late I don’t see how option c) would help in any of these scenarios.
From my point of view we should choose either a) or b).

c) is just a clarification of a), in that you can't expect to receive prflx candidates until you've at least provided the other side with a candidate, so that may be the right time for the timer to start. I don't feel super strongly about this though.

Ok. I hadn’t looked at it from that angle. So c) being a stronger a) I guess it would be okay.

I guess my only concern is that in Firefox we stopped doing a) because it caused to many problems. With that in mind would it cause interop problems if we leave up to the implementor to choose to implement either b) or c)?

I'd be fine with that, but I'd want to describe what to watch out for. Can you explain a bit more?

>> b) has a problem if the remote side doesn't send any candidates, which we want to explicitly allow.
>
> True.
Just to make sure we are all on the same page: b) is only a problem in the scenario where the remote side doesn’t send any candidates but also does not send EOC.

The EOC should allow agents which explicitly don’t want to provide candidate to get the timer started soon.
I think that leaves us with scenarios where the remote doesn’t provide host candidates, and it’s reflexive or relay candidates take for ever because of slow servers.

Correct, but we can't control which endpoints will send us an EOC or not. So that will always be a possibility.

Fair enough.

> Keep in mind that RFC 8445 is generic, so we need to to define what we mean by "answer". I guess it means some kind of indication that makes the agent assume that the remote peer has been contacted. In ice-sip-sdp we can then map that to an SDP answer.

Good point. We basically treat the SDP answer here to be something like an beginning of ICE, because we don’t have an explicit signal for that. I think in SDP based worlds there is no need for an extra signal like that. Not sure if other use cases of ICE would benefit from an explicit begin signal.

The answer in some ways is an explicit begin signal, because it contains the username/password information needed to start ICE checks.

Yeah I didn’t see your reply before hitting send on mine. Using the availability sounds like a good idea as the minimum gating function/signal.

Best
  Nils

Ice mailing list

[email-masked]<mailto:[email-masked]>

--

--

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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Jul 2019 16:38:25 -0400

Christer,

All we are doing here is a solution which is better then existing situation
but still not ideal. No matter how we set the timer or when we start it,
there are going to be situations when ICE nomination fails when it should
have succeeded if it waited longer. In practice it does not matter, if call
setup does not complete in 39.5 seconds (default STUN BIND request
timeout), caller would likely give up much earlier then that. So, to
summarize, if ICE nomination does not fail for default STUN BIND request
timeout from the time first candidate or EOC was received from the remote,
solution will be good enough.

If you do want something that works correctly with large signaling delays,
long TURN server allocation times, and arbitrary number of candidates or
streams, then what is needed is an additional signaling exchange that
negotiates that ICE nomination is complete and unused candidate can be
released. Something where controlling agent sends a signaling message
asking if ICE nomination is done and controlled agent responding true or
false. When response is true, ICE nomination is complete and unused
candidates can be removed. This message can be sent on timer and can be
combined with trickle ICE. However, I think we have decided previously that
this was out of scope.

Best Regards,
_____________
Roman Shpount

On Wed, Jul 3, 2019 at 4:02 PM Christer Holmberg <
[email-masked]> wrote:

> And, assuming the timer value is not going to be based on the number of
> streams, what do we do if the timer expires before we have tested all pairs
> for all streams? I think we need to specify that.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Peter Thatcher <[email-masked]>
> *Sent:* 02 July 2019 03:56
> *To:* Harald Alvestrand <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; Justin Uberti <
> [email-masked]>; Nils Ohlmeier <[email-masked]>; Roman Shpount
> <[email-masked]>; [email-masked]
> *Subject:* Re: [Ice] ICE PAC: When to start the timer waiting for

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Jul 2019 21:22:10 -0700

For #1, I don't think the proposed solution is correct. The "alternative
c)" that I proposed is to "Start the timer as soon as we have received a
remote offer or answer and have also sent a local candidate to the remote
side", which is different than what is mentioned in the OP.

The rationale for this is:
A) we can't start ICE processing (checks) until we get a remote
offer/answer with ICE credentials
B) we can't receive an incoming check that could create a prflx candidate
unless we sent a candidate to the remote side

Tracking this issue in https://github.com/cdh4u/draft-ice-pac/issues/12.

For #2, I agree we should use the "max duration of a connectivity check
transaction". I think this value will work just fine in real world
scenarios. And if the timer expires before we have tested all pairs (this
can certainly happen, in the case of two hosts with no connectivity to each
other), we just resume existing ICE processing, and fail when everything
moves to the failed state (i.e., every pair has timed out). The timer is
simply there to prevent premature failures.

Tracking in https://github.com/cdh4u/draft-ice-pac/issues/13

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 6 Jul 2019 09:27:59 +0200

> So, what timer value do people want?
Any number significantly larger than zero will improve the current
situation. I think 30.5 seconds was mentioned - that's a fine number to me.

>  
>
> And, assuming the timer value is not going to be based on the number
> of streams, what do we do if the timer expires before we have tested
> all pairs for all streams? I think we need to specify that.
>

Exactly what we do today.

If I interpret the situation correctly, the timer is to catch the state
when we don't have remote candidates to try, so if the timer expires
while we have remote candidates to try, we will just go on trying them;
if the timer expires when we have no remote candidates, we go to
"failed" state, exactly as we do today.

>  
>
> Regards,
>
>  
>
> Christer
>
>  
>
> *From:*Peter Thatcher <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; Justin
> Uberti <[email-masked]>; Nils Ohlmeier <[email-masked]>;
> Roman Shpount <[email-masked]>; [email-masked]
> On Mon, Jun 24, 2019 at 6:20 AM Harald Alvestrand
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I was noting the month of silence, and thinking that I should
>     encoruage a decision to be taken - "analysis paralysis" is not a
>     good thing!
>
>          
>
>         Regarding 1), eventhough it’s not my personal preference to
>         start the timer when the first offer/answer is sent, I could
>         live with it.
>
>      
>
>     It's a well defined time, and is observable by the entity that has
>     to act when the timer expires, so I think it is much better than
>     "undefined".
>
>         Regarding 2), however, I would really like some input on
>         whether the duration should be independent of the number of
>         streams, components etc.
>
>     I think having a single number is preferable to having a complex
>     number that could change over time (for instance, if we don't
>     reset the timer when adding streams, then adding or removing
>     streams after the timer started will lead to hard-to-define behavior).
>
>      
>
>     But my main concern is that we get this stuff done and get the
>     basic timer mechanism into interoperable code - having a spec to
>     implement from now is better than having a spec that has had
>     slightly more discussion, but no fundamental changes, 6 months
>     from now.
>
>      
>
>          
>
>         Regards,
>
>          
>
>         Christer
>
>          
>
>         *From: *Harald Alvestrand <[email-masked]>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>, Justin Uberti
>         <[email-masked]> <mailto:[email-masked]>, Nils
>         Ohlmeier <[email-masked]> <mailto:[email-masked]>
>         *Cc: *Roman Shpount <[email-masked]>
>         <mailto:[email-masked]>, "[email-masked]"
>         <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>         *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting
>         for possible peer reflexive candidates? - discussion restart
>
>          
>
>              1. When does an endpoint start the timer
>                 ("minimum-time-to-run-ICE" timer, based on previous
>                 discussions)?
>             Regarding 1), my understanding is that people suggest
>             alternative c), which starts the timer when an endpoint
>             has sent (in an offer or answer) at least one local
>             candidate (or EOC).
>
>              
>
>              
>
>             Regarding 2), it has been suggested that the duration
>             would be the same as the max duration of a connectivity
>             check transaction. Do we think that is enough, no matter
>             how many media streams and components are used?
>
>          
>
>             *From: *Ice <[email-masked]>
>             <mailto:[email-masked]> on behalf of Christer
>             Holmberg <[email-masked]>
>             <mailto:[email-masked]>
>             *To: *Justin Uberti <[email-masked]>
>             <mailto:[email-masked]>, Nils Ohlmeier
>             <[email-masked]> <mailto:[email-masked]>
>             *Cc: *Roman Shpount <[email-masked]>
>             <mailto:[email-masked]>, "[email-masked]"
>             <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>             *Subject: *Re: [Ice] ICE PAC: When to start the timer
>             waiting for possible peer reflexive candidates?
>
>              
>
>             Hi,
>
>              
>
>             I don’t think there will be any interoperability issues.
>             At the end of the day PAC is only about how long to wait
>             for candidates, so the worse thing that can happen is than
>             an agent declares ICE failure too early.
>
>              
>
>             And, no matter whether an agent knows that the peer
>             supports PAC or not,  it should aim at sending it’s
>             candidates to its peer as soon as possible, depending on
>             whatever local policies. The agent should not delay
>             sending candidates just because it assumes that the peer
>             will anyway wait for them.
>
>              
>
>             Regards,
>
>              
>
>             Christer
>
>              
>
>             *From: *Justin Uberti <[email-masked]>
>             <mailto:[email-masked]>
>             *To: *Nils Ohlmeier <[email-masked]>
>             <mailto:[email-masked]>
>             <mailto:[email-masked]>, Roman Shpount
>             <[email-masked]> <mailto:[email-masked]>,
>             "[email-masked]" <mailto:[email-masked]> <[email-masked]>
>             <mailto:[email-masked]>
>             *Subject: *Re: [Ice] ICE PAC: When to start the timer
>             waiting for possible peer reflexive candidates?
>
>              
>
>              
>
>              
>
>             On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                  
>
>
>
>
>                     On May 2, 2019, at 12:13, Justin Uberti
>                     <[email-masked] <mailto:[email-masked]>>
>                     wrote:
>
>                      
>
>                      
>
>                      
>
>                     On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>
>
>                         >> 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:
>                         >> b) a) + receipt of at least one remote
>                         candidate (or remote EOC). (This is Nils'
>                         suggestion).
>                         As we are mostly concerned about the remote
>                         side: 1) not providing us with candidates, or
>                         2) providing us with unusable candidates or 3)
>                         providing us with candidates really late I
>                         don’t see how option c) would help in any of
>                         these scenarios.
>                     c) is just a clarification of a), in that you
>                     can't expect to receive prflx candidates until
>                     you've at least provided the other side with a
>                     candidate, so that may be the right time for the
>                     timer to start. I don't feel super strongly about
>                     this though. 
>
>                  
>
>                 I guess my only concern is that in Firefox we stopped
>                 doing a) because it caused to many problems. With that
>                 in mind would it cause interop problems if we leave up
>                 to the implementor to choose to implement either b) or c)?
>
>              
>
>             I'd be fine with that, but I'd want to describe what to
>             watch out for. Can you explain a bit more? 
>
>
>
>
>
>                         >> b) has a problem if the remote side doesn't
>                         send any candidates, which we want to
>                         explicitly allow.
>                         >
>                         > True. 
>
>                         Just to make sure we are all on the same page:
>                         b) is only a problem in the scenario where the
>                         remote side doesn’t send any candidates but
>                         also does not send EOC. 
>
>
>                         The EOC should allow agents which explicitly
>                         don’t want to provide candidate to get the
>                         timer started soon.
>                         I think that leaves us with scenarios where
>                         the remote doesn’t provide host candidates,
>                         and it’s reflexive or relay candidates take
>                         for ever because of slow servers.
>
>                      
>
>                     Correct, but we can't control which endpoints will
>                     send us an EOC or not. So that will always be a
>                     possibility. 
>
>                  
>
>                 Fair enough.
>
>
>
>
>
>                         > Keep in mind that RFC 8445 is generic, so we
>                         need to to define what we mean by "answer". I
>                         guess it means some kind of indication that
>                         makes the agent assume that the remote peer
>                         has been contacted. In ice-sip-sdp we can then
>                         map that to an SDP answer.
>
>                         Good point. We basically treat the SDP answer
>                         here to be something like an beginning of ICE,
>                         because we don’t have an explicit signal for
>                         that. I think in SDP based worlds there is no
>                         need for an extra signal like that. Not sure
>                         if other use cases of ICE would benefit from
>                         an explicit begin signal.
>
>                      
>
>                     The answer in some ways is an explicit begin
>                     signal, because it contains the username/password
>                     information needed to start ICE checks. 
>
>                  
>
>                 Yeah I didn’t see your reply before hitting send on
>                 mine. Using the availability sounds like a good idea
>                 as the minimum gating function/signal.
>
>                  
>
>                 Best
>
>                   Nils
>
>                  
>
>              
>
>             [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 6 Jul 2019 12:10:20 +0000

Hi,

Unless I misunderstood, the original idea was to start the timer *once all pairs had been tried* – in order to wait for potential peer reflexive candidates to arrive before declaring ICE failure.

I am pretty sure such peer reflexive candidates would arrive within 39.5 seconds, so the chance for a premature failure would be very minor.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Sent: 03 July 2019 23:38
To: Christer Holmberg <[email-masked]>
Cc: Peter Thatcher <[email-masked]>; Harald Alvestrand <[email-masked]>; Justin Uberti <[email-masked]>; Nils Ohlmeier <[email-masked]>; [email-masked]
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

Christer,

All we are doing here is a solution which is better then existing situation but still not ideal. No matter how we set the timer or when we start it, there are going to be situations when ICE nomination fails when it should have succeeded if it waited longer. In practice it does not matter, if call setup does not complete in 39.5 seconds (default STUN BIND request timeout), caller would likely give up much earlier then that. So, to summarize, if ICE nomination does not fail for default STUN BIND request timeout from the time first candidate or EOC was received from the remote, solution will be good enough.

If you do want something that works correctly with large signaling delays, long TURN server allocation times, and arbitrary number of candidates or streams, then what is needed is an additional signaling exchange that negotiates that ICE nomination is complete and unused candidate can be released. Something where controlling agent sends a signaling message asking if ICE nomination is done and controlled agent responding true or false. When response is true, ICE nomination is complete and unused candidates can be removed. This message can be sent on timer and can be combined with trickle ICE. However, I think we have decided previously that this was out of scope.

Best Regards,
_____________
Roman Shpount

On Wed, Jul 3, 2019 at 4:02 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
So, what timer value do people want?

Regards,

Christer

From: Peter Thatcher <[email-masked]<mailto:[email-masked]>>
Sent: 02 July 2019 03:56
To: Harald Alvestrand <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Justin Uberti <[email-masked]<mailto:[email-masked]>>; Nils Ohlmeier <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

Go for what? 😊

Regards,

Christer

Regards,

Christer

Hi,

Regards,

Christer

Fair enough.

Best
  Nils

Ice mailing list

--

--

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 6 Jul 2019 12:16:57 +0000

Hi,

>Any number significantly larger than zero will improve the current situation. I think 30.5 seconds was mentioned - that's a fine number to me.
 
I am not sure I understand what you mean by "larger than zero". Nobody today declares ICE failure at the same time as the begin ICE, do they?

>> And, assuming the timer value is not going to be based on the number of streams, what do we do if the timer expires before 
>> we have tested all pairs for all streams? I think we need to specify that.
>
> If I interpret the situation correctly, the timer is to catch the state when we don't have remote candidates to try, so if the timer 
> expires while we have remote candidates to try, we will just go on trying them; if the timer expires when we have no remote candidates, 
> we go to "failed" state, exactly as we do today.

In that case, why can't we start the timer once we don't have any remote candidates left? 

Because, ff we DO have remote candidates, the timer is meaningless, because if the timer expires we will ignore it and go on testing them.

Regards,

Christer

From: Peter Thatcher mailto:[email-masked] 
Sent: 02 July 2019 03:56
To: Harald Alvestrand mailto:[email-masked]
Cc: Christer Holmberg mailto:[email-masked]; Justin Uberti mailto:[email-masked]; Nils Ohlmeier mailto:[email-masked]; Roman Shpount mailto:[email-masked]; mailto:[email-masked]
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

On Mon, Jun 24, 2019 at 6:20 AM Harald Alvestrand <mailto:[email-masked]> wrote:
On 6/24/19 12:06 PM, Christer Holmberg wrote:
Hi,
 
Go for what? 😊

 

Regards,
 
Christer
 
From: Harald Alvestrand mailto:[email-masked]
Date: Sunday, 23 June 2019 at 9.08
To: Christer Holmberg mailto:[email-masked], Justin Uberti mailto:[email-masked], Nils Ohlmeier mailto:[email-masked]
Cc: Roman Shpount mailto:[email-masked], mailto:[email-masked] mailto:[email-masked]
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

 

 

Regards,
 
Christer

 

From: Ice mailto:[email-masked] on behalf of Christer Holmberg mailto:[email-masked]
Date: Friday, 3 May 2019 at 15.02
To: Justin Uberti mailto:[email-masked], Nils Ohlmeier mailto:[email-masked]
Cc: Roman Shpount mailto:[email-masked], mailto:[email-masked] mailto:[email-masked]
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?
 
Hi,

 
Regards,
 
Christer
 
From: Justin Uberti mailto:[email-masked]
Date: Thursday, 2 May 2019 at 22.28
To: Nils Ohlmeier mailto:[email-masked]
Cc: Christer Holmberg mailto:[email-masked], Roman Shpount mailto:[email-masked], mailto:[email-masked] mailto:[email-masked]
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier <mailto:[email-masked]> wrote:

On May 2, 2019, at 12:13, Justin Uberti <mailto:[email-masked]> wrote:

 

 

 
 
Fair enough.

 

Best
  Nils

mailto:[email-masked]

mailto:[email-masked]

mailto:[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Sat, 6 Jul 2019 14:13:08 -0400

On Sat, Jul 6, 2019 at 8:17 AM Christer Holmberg <
[email-masked]> wrote:

> I am not sure I understand what you mean by "larger than zero". Nobody
> today declares ICE failure at the same time as the begin ICE, do they?
>

This is exactly what happens and this what we are trying to fix.

> streams, what do we do if the timer expires before
> when we don't have remote candidates to try, so if the timer
> > expires while we have remote candidates to try, we will just go on
> trying them; if the timer expires when we have no remote candidates,
> Because, ff we DO have remote candidates, the timer is meaningless,
> because if the timer expires we will ignore it and go on testing them.
>

If there are remote candidates to check, then ICE should continue checking
them. Part of the problem is that when ICE is starting, it is unclear if
remote candidate have not been received yet, no usable remote candidates
where received, or remote candidates are not going to be sent at all.
Also, checking remote candidates can end very quickly if remote candidates
are unreachable (fail immediately with ICMP remote address unreachable
message).

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 6 Jul 2019 21:50:59 +0000

Hi,

...

>If there are remote candidates to check, then ICE should continue checking them. Part of the problem is that when ICE is starting, it is unclear 
>if remote candidate have not been received yet, no usable remote candidates where received, or remote candidates are not going to be sent 
>at all.  Also, checking remote candidates can end very quickly if remote candidates are unreachable (fail immediately with ICMP remote address unreachable message). 

Ok, let's assume we DO have remote candidates, and the timer expires. We discard the fact that the timer expires, and go on checking the remote candidates, as you suggested.

Then, at some point we have checked all remote candidates, but we have NOT found successful pairs for all streams. So, since the timer already expired, we declare ICE failure.

I thought the whole idea was to still wait for some time after we have tried all remote candidates, in case we will receive peer reflexive candidates, before we declare ICE failure.

But, as I said earlier, I am fine doing as you and others suggest. All I am saying is that the draft needs to describe what to do if the timer expires while there are still untested remote candidates. If the solution is to discard the timer expiration, then it needs to be documented.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 7 Jul 2019 09:25:49 +0200

> I thought the whole idea was to still wait for some time after we have tried all remote candidates, in case we will receive peer reflexive candidates, before we declare ICE failure.

The scenario that I saw starting this debate was:

- Offer/answer happens

- Either some candidate pairs are formed, or no candidate pair are formed

- All the candidate pairs formed can be discarded very quickly (because
they are the wrong protocol, or non-routable addresses)

- Failure is declared

- ICE BIND requests from the other side arrive, giving peer-reflexive
candidates, but ICE connection is already closed

The arrival time of the ICE BIND requests from the other side is
independent of the length of the local candidate pair list, it depends
on the length of the remote candidate pair list, which is unknowable on
the local side. The most likely time is "really fast".

> But, as I said earlier, I am fine doing as you and others suggest. All I am saying is that the draft needs to describe what to do if the timer expires while there are still untested remote candidat…

Saying that the timer and pair testing proceeds in parallel is all that
needs to be said, I think.
Declaring failure requires BOTH the timer to have expired AND testing of
candidate pairs to complete.

The timer is a hack that can be applied by one side to fix the problem
for the 99% case.

A more architectural approach would be a way to pass (over the
signalling channel) a message saying "I have now sent all the BIND
requests I intend to send, if you haven't received any of them, please
give up now". But that requires both sides to update code and signalling
paths to be redesigned.

Let's deliver this document.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 7 Jul 2019 09:53:40 +0000

Hi,

>>> If there are remote candidates to check, then ICE should continue 
>>> checking them. Part of the problem is that when ICE is starting, it 
>>> is unclear if remote candidate have not been received yet, no usable remote
>>> candidates where received, or remote candidates are not going to be sent at all. 
>>> Also, checking remote candidates can end very quickly if remote candidates are 
>>> unreachable (fail immediately with ICMP remote address unreachable message).
> - All the candidate pairs formed can be discarded very quickly (because they are the wrong protocol, or non-routable addresses)
>
> - Failure is declared
>
> - ICE BIND requests from the other side arrive, giving peer-reflexive candidates, but ICE connection is already closed

I agree that is a valid use-case.

But, isn't that use-case just a version of the generic use-case: when we have no more remote candidates, we start a timer in order to wait for potential peer reflexive candidates? 

> The arrival time of the ICE BIND requests from the other side is independent of the length of the local candidate pair list, it depends on the length 
> of the remote candidate pair list, which is unknowable on the local side. The most likely time is "really fast".
>
>> But, as I said earlier, I am fine doing as you and others suggest. All I am saying is that the draft needs to describe what to do if the timer expires 
>> while there are still untested remote candidates. If the solution is to discard the timer expiration, then it needs to be documented.
>
> Saying that the timer and pair testing proceeds in parallel is all that needs to be said, I think.
> Declaring failure requires BOTH the timer to have expired AND testing of candidate pairs to complete.

No matter what solution we move forward with: we also need to define whether this applies to trickle.

For example, what if BOTH the timer has expired AND testing of currently available candidate pairs are complete, but trickle is still ongoing? Do we declare ICE failure, or do we discard the timer expiration?

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Sun, 7 Jul 2019 20:56:43 -0700

On Sun, Jul 7, 2019 at 2:53 AM Christer Holmberg <
[email-masked]> wrote:

> >> Ok, let's assume we DO have remote candidates, and the timer expires.
> We discard the fact that the timer expires, and go on checking the remote
> candidates, as you suggested.
> >>
> >> Then, at some point we have checked all remote candidates, but we have
> NOT found successful pairs for all streams. So, since the timer already
> expired, we declare ICE failure.
> >>
> >> I thought the whole idea was to still wait for some time after we have
> tried all remote candidates, in case we will receive peer reflexive
> candidates, before we declare ICE failure.
> >
> But, isn't that use-case just a version of the generic use-case: when we
> have no more remote candidates, we start a timer in order to wait for
> potential peer reflexive candidates?
>

Right, but that makes the waiting interval unnecessarily large. Really what
the timer is doing is setting a minimum amount of time for ICE to run, with
the idea that that minimum is as low as possible.

> independent of the length of the local candidate pair list, it depends on
> the length
> > of the remote candidate pair list, which is unknowable on the local
> side. The most likely time is "really fast".
> >
> >> But, as I said earlier, I am fine doing as you and others suggest. All
> I am saying is that the draft needs to describe what to do if the timer
> expires
> >> while there are still untested remote candidates. If the solution is to
> discard the timer expiration, then it needs to be documented.
> >
> For example, what if BOTH the timer has expired AND testing of currently
> available candidate pairs are complete, but trickle is still ongoing? Do we
> declare ICE failure, or do we discard the timer expiration?
>

As noted above, the timer is just a minimum amount of time to run. If we
wouldn't have declared ICE failure without the timer, nothing changes that
fact.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 10 Jul 2019 16:09:11 -0700

When writing up this text, I realized there are edge cases where you might
want to discover prflx candidates even if you didn't send any candidates
(e.g., you don't send any candidates, you get a single IP from the remote
side, and when you check it, you get a response back from a different IP).

Ergo, I think we should start the timer as soon as we have local and remote
ICE credentials, regardless of whether or not we send a candidate.

On Wed, Jul 3, 2019 at 9:22 PM Justin Uberti <[email-masked]> wrote:

>> [email-masked]>; Nils Ohlmeier <[email-masked]>; Roman
>> Shpount <[email-masked]>; [email-masked]
>> But my main concern is that we get this stuff done and get the basic
>> timer mechanism into interoperable code - having a spec to implement from
>> now is better than having a spec that has had slightly more discussion, but
>> no fundamental changes, 6 months from now.
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>> Regarding 2), it has been suggested that the duration would be the same
>> as the max duration of a connectivity check transaction. Do we think that
>> is enough, no matter how many media streams and components are used?
>>
>>
>>
>> I don’t think there will be any interoperability issues. At the end of
>> the day PAC is only about how long to wait for candidates, so the worse
>> thing that can happen is than an agent declares ICE failure too early.
>>
>>
>>
>> As we are mostly concerned about the remote side: 1) not providing us
>> with candidates, or 2) providing us with unusable candidates or 3)
>> providing us with candidates really late I don’t see how option c) would
>> help in any of these scenarios.
>> Just to make sure we are all on the same page: b) is only a problem in
>> the scenario where the remote side doesn’t send any candidates but also
>> does not send EOC.
>>
>>
>> Good point. We basically treat the SDP answer here to be something like
>> an beginning of ICE, because we don’t have an explicit signal for that. I

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Jul 2019 19:20:25 -0400

On Wed, Jul 10, 2019 at 7:09 PM Justin Uberti <[email-masked]> wrote:

> Ergo, I think we should start the timer as soon as we have local and
> remote ICE credentials, regardless of whether or not we send a candidate.
>

Agreed. This makes perfect sense to me.

_____________
Roman Shpount

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 10 Jul 2019 19:16:09 -0700

Yeah, I was thinking of that edge case as well, which is why one version of
my proposed text was "send a local candidate or EOC", but EOC depends on
trickle-ice.

I think just basing this on the candidate information exchange is
sufficient and more simple, so I like it.

On Wed, Jul 10, 2019 at 4:09 PM Justin Uberti <[email-masked]> wrote:

>>> *Cc:* Christer Holmberg <[email-masked]>; Justin Uberti
>>> <[email-masked]>; Nils Ohlmeier <[email-masked]>; Roman
>>> I was noting the month of silence, and thinking that I should encoruage
>>> a decision to be taken - "analysis paralysis" is not a good thing!
>>>
>>>
>>>
>>> It's a well defined time, and is observable by the entity that has to
>>> act when the timer expires, so I think it is much better than "undefined".
>>>
>>> I guess my only concern is that in Firefox we stopped doing a) because
>>> it caused to many problems. With that in mind would it cause interop
>>> problems if we leave up to the implementor to choose to implement either b)
>>> or c)?
>>>
>>>
>>>
>>> Correct, but we can't control which endpoints will send us an EOC or
>>> not. So that will always be a possibility.
>>>
>>>
>>>
>>> Fair enough.
>>>
>>>
>>>
>>>
>>>

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 10 Jul 2019 20:34:17 -0700

> On 10Jul, 2019, at 16:09, Justin Uberti <[email-masked]> wrote:
> 
> When writing up this text, I realized there are edge cases where you might want to discover prflx candidates even if you didn't send any candidates (e.g., you don't send any candidates, you get a single IP from the remote side, and when you check it, you get a response back from a different IP).
> 
> Ergo, I think we should start the timer as soon as we have local and remote ICE credentials, regardless of whether or not we send a candidate.

Technically there is another edge case (for trickle only I believe): if you hand out SDP, but then local gathering of host candidates fails for some bizarre reason (e.g. application ran out of file descriptors or something alike). In that scenario it would be pointless to start the PAC timer, or at least you should end it early when you know that the pairing table will stay empty forever.
Unfortunately the other side will have to wait for the PAC timer to expire before giving up, as we don’t have any means to indicate that we are neither going to send candidates nor are able to check peers candidates.

Or to state it differently: the PAC timer should be started when at least local host candidates exist and local and remote ICE credentials have been exchanged.

Best regards
  Nils Ohlmeier

---

From: Justin Uberti <[email-masked]>
Date: Wed, 10 Jul 2019 20:42:33 -0700

I see your point, but I tend to think you could always encounter some sort
of unrecoverable system error like this (even after seeing that local
candidates exist), and the ICE agent could always blow up ICE in such a
situation.

On Wed, Jul 10, 2019 at 8:34 PM Nils Ohlmeier <[email-masked]> wrote:

> > When writing up this text, I realized there are edge cases where you
> might want to discover prflx candidates even if you didn't send any
> candidates (e.g., you don't send any candidates, you get a single IP from
> the remote side, and when you check it, you get a response back from a
> different IP).
> >
> Technically there is another edge case (for trickle only I believe): if
> you hand out SDP, but then local gathering of host candidates fails for
> some bizarre reason (e.g. application ran out of file descriptors or
> something alike). In that scenario it would be pointless to start the PAC
> timer, or at least you should end it early when you know that the pairing
> table will stay empty forever.
> Unfortunately the other side will have to wait for the PAC timer to expire
> before giving up, as we don’t have any means to indicate that we are
> neither going to send candidates nor are able to check peers candidates.
>
> Or to state it differently: the PAC timer should be started when at least
> local host candidates exist and local and remote ICE credentials have been
> exchanged.
>
> Best regards
>   Nils Ohlmeier
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 06:19:41 +0000

Hi,

What do you mean by ”single IP from the remote side”? A candidate?

Regards,

Christer

From: Justin Uberti <[email-masked]>
Date: Thursday, 11 July 2019 at 2.09
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Harald Alvestrand <[email-masked]>, Nils Ohlmeier <[email-masked]>, Roman Shpount <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

On Wed, Jul 3, 2019 at 9:22 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
For #1, I don't think the proposed solution is correct. The "alternative c)" that I proposed is to "Start the timer as soon as we have received a remote offer or answer and have also sent a local candidate to the remote side", which is different than what is mentioned in the OP.

The rationale for this is:
A) we can't start ICE processing (checks) until we get a remote offer/answer with ICE credentials
B) we can't receive an incoming check that could create a prflx candidate unless we sent a candidate to the remote side

Tracking this issue in https://github.com/cdh4u/draft-ice-pac/issues/12<https://protect2.fireeye.com/url?k=fa812fa0-a60b0d76-fa816f3b-0cc47ad93dcc-14ecb4925c17821c&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-ice-pac%2Fissues%2F12>.

For #2, I agree we should use the "max duration of a connectivity check transaction". I think this value will work just fine in real world scenarios. And if the timer expires before we have tested all pairs (this can certainly happen, in the case of two hosts with no connectivity to each other), we just resume existing ICE processing, and fail when everything moves to the failed state (i.e., every pair has timed out). The timer is simply there to prevent premature failures.

Tracking in https://github.com/cdh4u/draft-ice-pac/issues/13<https://protect2.fireeye.com/url?k=560d1e46-0a873c90-560d5edd-0cc47ad93dcc-dad442e58bc4db30&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-ice-pac%2Fissues%2F13>

On Wed, Jul 3, 2019 at 1:02 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
So, what timer value do people want?

Regards,

Christer

Go for what? 😊

Regards,

Christer

Regards,

Christer

Hi,

Regards,

Christer

Fair enough.

Best
  Nils

Ice mailing list

--

--

---

From: Justin Uberti <[email-masked]>
Date: Wed, 10 Jul 2019 23:25:00 -0700

yes, a candidate

On Wed, Jul 10, 2019 at 11:19 PM Christer Holmberg <
[email-masked]> wrote:

> *Date: *Thursday, 11 July 2019 at 2.09
> *Cc: *"[email-masked]" <[email-masked]>, Harald Alvestrand <
> [email-masked]>, Nils Ohlmeier <[email-masked]>, Roman
> Shpount <[email-masked]>, "[email-masked]" <[email-masked]>
> Tracking this issue in https://github.com/cdh4u/draft-ice-pac/issues/12
> <https://protect2.fireeye.com/url?k=fa812fa0-a60b0d76-fa816f3b-0cc47ad93dcc-14ecb4925c17821c&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-ice-pac%2Fissues%2F12>
> .
>
>
>
> <https://protect2.fireeye.com/url?k=560d1e46-0a873c90-560d5edd-0cc47ad93dcc-dad442e58bc4db30&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-ice-pac%2Fissues%2F13>
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 06:34:20 +0000

Hi,

>yes, a candidate

But, I thought that the timer would be started even if an ICE agent has not received any remote candidates, as long as it had sent at least one candidate.

If we are saying that the timer starts once an ICE agent has sent and received ICE credentials – even if it has not sent or received any candidates – it means that the timer will be started before any connectivity checks are sent (as no candidates has been provided).

Regards,

Christer

On Wed, Jul 10, 2019 at 11:19 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 11 July 2019 at 2.09
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Harald Alvestrand <[email-masked]<mailto:[email-masked]>>, Nils Ohlmeier <[email-masked]<mailto:[email-masked]>>, Roman Shpount <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

Regards,

Christer

Go for what? 😊

Regards,

Christer

Regards,

Christer

Hi,

Regards,

Christer

Fair enough.

Best
  Nils

Ice mailing list

--

--