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

[Justin Uberti <[e-mail]>]

On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <[e-mail]> 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.

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

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