Subject: [MMUSIC] Trickle ICE

From: Emil Ivov <[email-masked]>
Date: Wed, 10 Oct 2012 16:29:35 +0200

Hey all,

Eric, Justin and I have just submitted a first version of the
specification of a mechanism for incremental provisioning of ICE
candidates, also known as "Trickle ICE".

The spec is in an early state and will undoubtedly see a lot of changes
as implementations progress. It does however describe the main idea so
comments and questions are most welcome!

Cheers,
Emil

-------- Original Message --------
Subject: New Version Notification for
draft-rescorla-mmusic-ice-trickle-00.txt
Date: Wed, 10 Oct 2012 07:16:00 -0700
From: [email-masked]
To: [email-masked]
CC: [email-masked], [email-masked]

A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Filename:	 draft-rescorla-mmusic-ice-trickle
Revision:	 00
Title:		 Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol
Creation date:	 2012-10-10
WG ID:		 Individual Submission
Number of pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.txt
Status:
http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle
Htmlized:
http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00

Abstract:
   This document describes an extension to the Interactive Connectivity
   Establishment (ICE) protocol that allows ICE agents to send and
   receive candidates incrementally rather than exchanging complete
   lists.  With such incremental provisioning, ICE agents can begin
   connectivity checks while they are still gathering candidates and
   considerably shorten the time necessary for ICE processing to
   complete.

   The above mechanism is also referred to as "trickle ICE".

The IETF Secretariat

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Oct 2012 09:03:02 -0700

I haven't had a lot of time to think about this, but here are some
early comments:

It seems to me that the guidance in Section 6.2 regarding the
unfreezing of check lists needs a little more thought (and
specification).  The goals are clear: "so that checks for the same
media stream [component] would be performed simultaneously by both
agents".  The process by which each peer arrives at this point is less
so.

A naive implementation would use the set of known candidates on each
component to make this determination.  However, that set is
potentially different to the set of candidates known to their peer.
That could cause a mismatch if both peers "unfreeze the first
non-empty checklist."

Several points in the draft presume that this will be made "MUST
implement" for WebRTC.  That assumption is not stated, though it
should be.  In particular, this relates to the decision to require
signaling of support for trickle ICE outside of SDP (a decision that I
need to think about a little more).

--Martin

On 10 October 2012 07:29, Emil Ivov <[email-masked]> wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Oct 2012 20:18:49 +0200

Hi,

Thanks for submitting the document!

A couple of initial comments.

Q1: Remote endpoint support (SIP):
--------------------------------------------

You say that, before the first offer is sent, one SHOULD determine whether the remote endpoint supports trickle ICE. 

For SIP, you give RFC 3840 as an example. I am not sure how that will work. Yes, you can use 3840 to request that the offer is sent to an entity which supports trickle ICE (for that, btw, you will also need to define an option tag, or something similar), but you cannot use it to determine whether the remote endpoint supports trickle ICE. In addition, you typically use 3840 at the same time when you send the initial offer.

Of course, you could use SIP OPTIONS. But, there are a number of issues related to that, and I don't think we want to define a mechanism which relies on the usage of OPTIONS.

And, if we simply say that it's "outside the scope of the document", we could do the same for BUNDLE, and we wouldn't have issues with re-using the same ports in multiple m- lines etc :)

Q2: Offer/Answer Alignment:
------------------------------------

I assume the offers and answer are sent according to the rules in RFC 3264.

If so, when you talk about offers and/or answers "being sent at any point", I think it needs to be clear that it's within the rules of 3264.

Q3: Enough is enough:
----------------------------

I think it could be useful for the answerer to tell the offerer that it doesn't want/need any more candidates.

Thanks!

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Emil Ivov [[email-masked]]
Sent: Wednesday, October 10, 2012 5:29 PM
To: MMUSIC IETF WG
Subject: [MMUSIC] Trickle ICE

Hey all,

Cheers,
Emil

-------- Original Message --------

Abstract:

The IETF Secretariat

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Oct 2012 00:46:27 +0200

Hey Martin,

On 10.10.12, 18:03, Martin Thomson wrote:
> unfreezing of check lists needs a little more thought 

Quite likely, yes.

> (and

Yes, the above sentence may indeed be misleadingly read as "respecting
the order of the streams is all there is to it". What was really meant
was something along the lines of: "respecting the order of streams
improves the chances of the connectivity checks being run simultaneously
for a particular stream/component"

> That could cause a mismatch if both peers "unfreeze the first

Correct, but this is not going to be a problem. When the corresponding
candidates eventually find their way to the agent, it would unfreeze
their local counter-parts and, if necessary, rerun any in-progress or
failed checks. This is explained in Section 9:

   [snip] the agent examines the check
   list looking for another pair that would be redundant with the new
   one.  If such a pair exists and its state is:

   Failed:   the agent chooses the pair with the higher priority local
      candidate, places it in the Waiting state and removes the other
      one as redundant.
   In-Progress:   The agent cancels the in-progress transaction (where
      cancellation happens as explained in Section 7.2.1.4 of
      [RFC5245]), then it chooses the pair with the higher priority
      local candidate, places it in the Waiting state and removes the
      other one as redundant.

Does this sound reasonable or were you referring to something else?

> implement" for WebRTC. That assumption is not stated, though
> it should be. 

Mmm ... it might be my lack of IETF experience, but aren't references
supposed to happen the other way around? That is, if RTCWEB decides to
use Trickle ICE, then shouldn't RTCWEB documents be referring to this
spec and making whatever normative declarations they find appropriate?

Besides, trickle ICE is already in use by XMPP apps and SIP will
probably follow. Why would the RTCWEB usage be referred to and not the
others?

> In particular, this relates to the decision to require

Well the idea is that it doesn't really need to be signalling. The
example that we give is about a WebRTC app with no cross domain support.
In this case the WebRTC app can just enable trickle ICE without checking
anything since the remote agent is bound to have it too. Again, it's
just an example. We are not saying this is how it's going to be done for
RTCWEB.

Does this make sense?

Emil

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Oct 2012 00:48:00 +0200

Hey Christer,

Thanks for your comments!

Replies inline.

On 10.10.12, 20:18, Christer Holmberg wrote:
> You say that, before the first offer is sent, one SHOULD determine
> whether the remote endpoint supports trickle ICE.
> 
> For SIP, you give RFC 3840 as an example. I am not sure how that will
> work. Yes, you can use 3840 to request that the offer is sent to an
> entity which supports trickle ICE (for that, btw, you will also need
> to define an option tag, or something similar),

Right, but we were hoping this would happen in a separate spec that
details use of trickle ICE with SIP.

> but you cannot use it
> to determine whether the remote endpoint supports trickle ICE. In
> addition, you typically use 3840 at the same time when you send the
> initial offer.
> 
> Of course, you could use SIP OPTIONS.

Yes, that was the idea. The way 3840 describes it in Section 8.

> But, there are a number of issues related to that, 
> and I don't think we want to define a
> mechanism which relies on the usage of OPTIONS.
> 
> And, if we simply say that it's "outside the scope of the document",

I was just about to say that ;).

But, seriously, determining and negotiating caps happens very
differently in different signalling protocols, so it doesn't seem
reasonable to try and find answers for all of them in the generic
trickle ICE spec.

XMPP for example, has this part covered pretty well. If we determine
that 3840 does not provide a way of doing the same then we can find
another way for SIP.

Eric had this idea, where a trickle ICE agent would simply fire a first
offer that only other trickle ICE agents would accept and that any other
SIP endpoint would answer with an error. This would be enough of a check
and if it fails the caller can fall back to vanilla ICE.

Another option would be for trickle ICE agents to send empty INVITEs
that somehow indicate they will be trickling but contain no actual
offer. The offer that the remote side then adds in an OK response (or a
provisional one) would clearly indicate whether they support vanilla,
trickle, or no ICE at all, so the trickle agent would be able to answer
accordingly with the ACK.

> we could do the same for BUNDLE, and we wouldn't have issues with
> re-using the same ports in multiple m- lines etc :)

Well, we are not saying that they should not be addressed at all, or
even now. Just that maybe they shouldn't be addressed by this specific
document.

> Q2: Offer/Answer Alignment: ------------------------------------
> 
> If so, when you talk about offers and/or answers "being sent at any
> point", I think it needs to be clear that it's within the rules of
> 3264.

Good point! I think the text is indeed a bit unclear in that regard and
we might be making some non-stated assumptions about the relation
between 3264 Offer/Answer, the actual call answering, and the
connectivity checks phase. We'll fix this.
> 
> 
> Q3: Enough is enough: ----------------------------
> 
> I think it could be useful for the answerer to tell the offerer that
> it doesn't want/need any more candidates.

Yes, sounds useful. Do you have any specific use cases in mind?

I am also wondering what would happen if the answerer says "enough" too
early in the process and causes negotiation to fail. Is there a reason
why an agent would be willing to risk that? Or are we going to say that
it would only do that after finding at least one valid pair for every
component?

Cheers,
Emil

> Thanks!
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> ________________________________________ From:
> [email-masked] [[email-masked]] On Behalf Of Emil
> Ivov [[email-masked]] Sent: Wednesday, October 10, 2012 5:29 PM To:
> MMUSIC IETF WG Subject: [MMUSIC] Trickle ICE
> 
> Hey all,
> 
> The spec is in an early state and will undoubtedly see a lot of
> changes as implementations progress. It does however describe the
> main idea so comments and questions are most welcome!
> 
> Cheers, Emil
> 
> 
> -------- Original Message -------- Subject: New Version Notification
> for draft-rescorla-mmusic-ice-trickle-00.txt Date: Wed, 10 Oct 2012
> 07:16:00 -0700 From: [email-masked] To: [email-masked] CC:
> [email-masked], [email-masked]
> 
> 
> A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt has
> been successfully submitted by Emil Ivov and posted to the IETF
> repository.
> 
> Filename:        draft-rescorla-mmusic-ice-trickle Revision:
> 00 Title:           Trickle ICE: Incremental Provisioning of
> Candidates for the Interactive Connectivity Establishment (ICE)
> Protocol Creation date:   2012-10-10 WG ID:           Individual
> Submission Number of pages: 14 URL: 
Status:
> Abstract: This document describes an extension to the Interactive
> Connectivity Establishment (ICE) protocol that allows ICE agents to
> send and receive candidates incrementally rather than exchanging
> complete lists.  With such incremental provisioning, ICE agents can
> begin connectivity checks while they are still gathering candidates
> and considerably shorten the time necessary for ICE processing to 
> complete.
> 
> _______________________________________________ mmusic mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Oct 2012 11:53:12 +0200

Hi,

> and if it fails the caller can fall back to vanilla ICE.

Sure, but that is not checking for trickle support before sending the trickle offer :)

Also, I guess I still haven't completely understood the backward compatibility issue, but I guess I need to do some more reading.

> accordingly with the ACK.

I don't think we want to rely on empty INVITEs either, because there are a number of issues related to that.

> even now. Just that maybe they shouldn't be addressed by this specific

Perhaps we shouldn't say anything about finding out in advance, then. At least not use SHOULD. 

We CAN describe what may happen if the remote peer does not support trickle ICE, but leave it to that.

> connectivity checks phase. We'll fix this.

Thanx! :)

Q3: Enough is enough: 

> Yes, sounds useful. Do you have any specific use cases in mind?

Well, I guess any case where the remote peer knows it has a public IP address (it will most likely be an ICE lite entity).

> it would only do that after finding at least one valid pair for every

Well, the indication could mean please-try-whether-the-candidate-works-before-you-send-me-additional-ones :)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Oct 2012 14:17:40 +0200

Hey Christer,

> Q1: Remote endpoint support (SIP):

Yes, the wording may need to be reviewed if we go for this.

> Also, I guess I still haven't completely understood the backward compatibility issue, but I guess I need to do some more reading.

We describe these in Section 3 but the main problem is that a vanilla
ICE agent that gets a first subset of candidates (that may also be
empty) would declare failure prematurely.

> I don't think we want to rely on empty INVITEs either, because there are a number of issues related to that.

Well, it might be worth investigating exactly what they are. The same
applies to using OPTIONS and 3840.

> We CAN describe what may happen if the remote peer does not support trickle ICE, but leave it to that.

What we'd like to avoid is having trickle ICE offers to vanilla ICE
agents and then having them fail in a user-perceptible way.

Maybe we could modify the "SHOULD verify support" to "SHOULD verify
support or provide a mechanism for transparent fallback to vanilla ICE"

> Q2: Offer/Answer Alignment: 

Right, but in such cases the offerer would also know that a certain pair
has succeeded so if they continue it might be with the purpose of
finding a better RTT or a higher priority local candidate.

I guess what I am trying to say is that a Binding Response is enough of
an indication that trickling can stop. If it doesn't then maybe it's for
a reason.

Cheers,
Emil

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Oct 2012 10:13:16 -0700

> Does this sound reasonable or were you referring to something else?

Actually, this part in Section 9 wasn't very clear.  I think that the
terms aren't quite right.  "Redundant" and "priority" have specific
meanings in ICE that I think aren't quite right for using here.

This wasn't immediately clear, though I get where you are going with
this.  Though I do think that you need to ensure that this
cancellation doesn't occur to the highest priority"

You aren't talking about priority or redundancy, I think.  You want to
ensure that you are making checks on the first component (of the first
media stream).  What you want is probably more like:

The agent examines the check list and looks for a pair with the same
foundation.  Where multiple such pairs exist, the one from the
component that is first in order is selected.  If an existing pair is
selected, based on its state, the following actions are taken:

 Failed:  The agent marks the new pair as Failed.  [[?: not sure that
this is entirely safe, might need to re-open this one to prevent a
race condition...]]
 In-Progress: If the new pair is for a component [[i.e. media stream +
component]] after the existing pair, the new pair is Frozen.  If the
new pair is for a component that comes before the existing pair's
component the existing pair becomes Frozen, the outstanding
transaction on the existing pair is cancelled, and the new pair is
placed in the Waiting state.
  Waiting: If the new pair is for a component [[i.e. media stream +
component]] after the existing pair, the new pair is Frozen.  If the
new pair is for a component that comes before the existing pair's
component the existing pair becomes Frozen and the new pair is placed
in the Waiting state.
 etc...

Does *that* make sense?

> spec and making whatever normative declarations they find appropriate?

Yes, but the draft makes the claim about a WebRTC app that is
contacting peers in the same domain.  This makes a big assumption:
namely, that ALL the other entities in that domain implement trickle
ICE.  I infer from this that you are assuming that rtcweb is going to
make this MUST implement, so that you can at least expect all browsers
to implement trickle ICE.  That is if you are assuming that the same
domain is only using browsers.

> probably follow. Why would the RTCWEB usage be referred to and not the

SIP may well follow, but that doesn't mean that you can make any
assumptions about support.

> just an example. We are not saying this is how it's going to be done for

You can't send an offer sans candidates and expect it to work.  That's
part of the reason you are writing this draft, as I understand.
Unless you know for certain that the other side implements it.  I
don't think that this is realistic.  Therefore, signaling.

> Does this make sense?

Not entirely ;)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Oct 2012 10:16:37 -0700

Forgot something, inline below...

> component the existing pair becomes Frozen and the new pair is placed

Note: we probably also need to note that a transaction can succeed for
a Frozen candidate pair (due to the fact that you can't take a STUN
packet back, so "cancelling" a transaction might still result in a
successful Binding response.  I don't know what you would do with
this, but I'd just move the pair to Succeeded.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Oct 2012 21:23:18 +0200

Hi, 

Q1: Remote endpoint support (SIP):
----------------------------------

>>>> For SIP, you give RFC 3840 as an example. I am not sure how that 
>>>> will work. Yes, you can use 3840 to request that the offer is sent 
>>>> to an entity which supports trickle ICE (for that, btw, you will 
>>>> also need to define an option tag, or something similar),
>>>
>>>> But, there are a number of issues related to that, and I don't think 
>>>> we want to define a mechanism which relies on the usage of OPTIONS.
>>>>
>>> Eric had this idea, where a trickle ICE agent would simply fire a 
>>> first offer that only other trickle ICE agents would accept and that 
>>> any other SIP endpoint would answer with an error. This would be 
>>> enough of a check and if it fails the caller can fall back to vanilla ICE.
>> 
> We describe these in Section 3 but the main problem is that a vanilla ICE agent that gets a first subset of candidates (that may also be

The text gives an example where the receiver (Bob) receives a host-candidate-only offer, and start checks which fail.

I think it's quite strange if Bob would reject the call at that point. Because, no matter how many candidates the offer contains, there might still be peer reflexive candidates created later, once the offerer (Alice) starts sending the STUN binding requests. So, one would think that Bob at least would wait for those.

>>> offer. The offer that the remote side then adds in an OK response (or 
>>> a provisional one) would clearly indicate whether they support 
>>> vanilla, trickle, or no ICE at all, so the trickle agent would be 
>>> able to answer accordingly with the ACK.
>> 
> Well, it might be worth investigating exactly what they are. The same applies to using OPTIONS and 3840.

Well, to start with, empty INVITEs will work very badly with legacy.

In addition, there migth be other functions which do not work with empty INVITEs.

And, I am not sure how it would work with JSEP.

>>>> even now. Just that maybe they shouldn't be addressed by this 
>>>> specific document.
>>> 
>> What we'd like to avoid is having trickle ICE offers to vanilla ICE agents and then having them fail in a user-perceptible way.
>>
> Maybe we could modify the "SHOULD verify support" to "SHOULD verify support or provide a mechanism for transparent fallback to vanilla ICE"

In my opinion, if one has to do something extra (e.g. send OPTIONS), the whole idea of trickle-ICE goes away, because at the end of the day you won't save any time in call establishment.

Now, if the browser is communicating with a ICE terminating gateway, and if the browser performs SIP registration, then the gateway can indicate trickle-ICE during registration.

But, in the peer-to-peer case I don't know how it would work. It's not even sure OPTIONS would reach the same remote peer as the INVITE...

Q2: Offer/Answer Alignment: 
---------------------------
 
>>> Good point! I think the text is indeed a bit unclear in that regard 
>>> and we might be making some non-stated assumptions about the relation 

Q3: Enough is enough: 
---------------------

> Right, but in such cases the offerer would also know that a certain pair has succeeded so if they continue it might be with the purpose of finding a better RTT or a higher priority local candidate.
>
> I guess what I am trying to say is that a Binding Response is enough of an indication that trickling can stop. If it doesn't then maybe it's for a reason.

Maybe it is enough... In any case I think it would be good to document :)

Also, at least in cases where the remote peer only provide a host candidate (because it has a public IP address), one should be smart enough to figure out that there most likely will be no better alternative.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Oct 2012 22:00:21 +0200

> Q1: Remote endpoint support (SIP):

I think that we should start that work in parallell. Doing trickle ICE with SIP O/A
can be trick(l)y and the solution for that may affect the Trickly ICE core.

I do think trickle ICE will help SIP quite a lot, especially in a b2bua situation.

/O

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Oct 2012 23:34:32 +0200

Hey Martin,

On 11.10.12, 19:13, Martin Thomson wrote:
> Actually, this part in Section 9 wasn't very clear. 

Sorry about that. We'll try to add clarifications before the 01 deadline.

> I think that the

Yes they do, and those same meanings apply here.

> cancellation doesn't occur to the highest priority"

Why not?

> You aren't talking about priority or redundancy, I think. 

I believe we are.

> You want to
> media stream). 

No, not really. What we want to ensure is that if a number of checks
fail because pairs are in an asymmetric state, those checks will be
retried later.

Imagine the following case (described by Eric in his original mail to
RTCWEB):

* Alice calls Bob with a list containing server reflexive candidates.
* Bob responds with host candidates only.
* Bob then starts checks but the pairs containing Alice's server
reflexive address won't be succeeding because Alice is not doing checks
to open up the filtering on the NAT.
* Bob then gets SR addresses and sends them to Alice so she also starts
conn checks.
* With the rules in Secion 9, Bob also places the pairs that failed just
above into the Waiting state, so this time checks are simultaneous and
they succeed.

> What you want is probably more like:
> 
> The agent examines the check list 

When is this happening? When learning new local candidates? Remote? In
the beginning of ICE processing? At some other point?

> and looks for a pair with the same

Not entirely ;)

Could you please describe a scenario that you think would file with the
text currently in the draft, and that would succeed with the above?

> domain is only using browsers.

Oh right. We'll make sure the assumption is stated.

> You can't send an offer sans candidates and expect it to work. 

Indeed not. I would expect it to fail for non-trickle agents (without
alerting the remote user) which would then be my cue to fallback to
vanilla ICE.

> this, but I'd just move the pair to Succeeded.

The case where a cancelled transaction ends up succeeding is indeed
worth covering, but given how the concept is defined in 5245 then maybe
at least part of the coverage should go in 5245bis?

Cheers,
Emil

> That's

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Oct 2012 23:34:43 +0200

Hey Christer,

On 11.10.12, 21:23, Christer Holmberg wrote:
>>>>> You say that, before the first offer is sent, one SHOULD
>>>>> determine whether the remote endpoint supports trickle ICE.
>>>>> 
>>>>> For SIP, you give RFC 3840 as an example. I am not sure how
>>>>> that will work. Yes, you can use 3840 to request that the
>>>>> offer is sent to an entity which supports trickle ICE (for
>>>>> that, btw, you will also need to define an option tag, or
>>>>> something similar),
>>>> 
>>>> Right, but we were hoping this would happen in a separate spec
>>>> that details use of trickle ICE with SIP.
>>>> 
>>>>> but you cannot use it to determine whether the remote
>>>>> endpoint supports trickle ICE. In addition, you typically use
>>>>> 3840 at the same time when you send the initial offer.
>>>>> 
>>>>> But, there are a number of issues related to that, and I
>>>>> don't think we want to define a mechanism which relies on the
>>>>> usage of OPTIONS.
>>>>> 
>>>> differently in different signalling protocols, so it doesn't
>>>> seem reasonable to try and find answers for all of them in the
>>>> generic trickle ICE spec.
>>>> 
>>>> XMPP for example, has this part covered pretty well. If we
>>>> determine that 3840 does not provide a way of doing the same
>>>> then we can find another way for SIP.
>>>> 
>>>> Eric had this idea, where a trickle ICE agent would simply fire
>>>> a first offer that only other trickle ICE agents would accept
>>>> and that any other SIP endpoint would answer with an error.
>>>> This would be enough of a check and if it fails the caller can
>>>> fall back to vanilla ICE.
>>> 
>>> Also, I guess I still haven't completely understood the backward
>>> compatibility issue, but I guess I need to do some more reading.
>> 
>> We describe these in Section 3 but the main problem is that a
>> vanilla ICE agent that gets a first subset of candidates (that may
>> also be empty) would declare failure prematurely.
> 
> The text gives an example where the receiver (Bob) receives a
> host-candidate-only offer, and start checks which fail.
> 
> I think it's quite strange if Bob would reject the call at that
> point. Because, no matter how many candidates the offer contains,
> there might still be peer reflexive candidates created later,

How does Bob know that there's going to be a "later" ? It's just a
vanilla ICE agent that assumed it received a full set of candidates, it
checked them all, all checks failed.

Now, we could rely on Bob not doing anything rash and waiting patiently
for reINVITEs from Alice in order to get more candidates ... but that
might be about as risky as relying on empty INVITEs to be handled
properly by everyone or on OPTIONS to be transmitted end-to-end.

Besides there are other possible failures, like for example the case
where I get your server reflexive candidates long before you get mine so
we perform checks out of sync (the case that I also described in my
other mail to Martin).

> once
> the offerer (Alice) starts sending the STUN binding requests. So, one
> would think that Bob at least would wait for those.
> 
>>>> Another option would be for trickle ICE agents to send empty
>>>> INVITEs that somehow indicate they will be trickling but
>>>> contain no actual offer. The offer that the remote side then
>>>> adds in an OK response (or a provisional one) would clearly
>>>> indicate whether they support vanilla, trickle, or no ICE at
>>>> all, so the trickle agent would be able to answer accordingly
>>>> with the ACK.
>>> 
>>> I don't think we want to rely on empty INVITEs either, because
>>> there are a number of issues related to that.
>> 

You mean, because legacy devices don't properly implement 3261 in that
regard?

That might actually be a good thing. An error response at this point
would be a good indication that there's no trickle ICE support at the
remote side.

> In addition, there migth be other functions which do not work with

OK, I agree. It's a clumsy solution at best. It would be impossible for
SIP user agents to translate a user request to start an audio,
audio/video or some other media session (which is the typical rant you
get for handling empty INVITEs). It was just a thought :)

> And, I am not sure how it would work with JSEP.

You mean, in cases of gatewaying SIP to WebRTC? I suppose it could just
be translated to some custom signalling that actually does capability
negotiation and then triggers a remote INVITE ... OK I know, it's a stretch.
> 
> 
>>>>>> we could do the same for BUNDLE, and we wouldn't have
>>>>>> issues with re-using the same ports in multiple m- lines
>>>>>> etc :)
>>>>> 
>>>>> Well, we are not saying that they should not be addressed at
>>>>> all, or even now. Just that maybe they shouldn't be addressed
>>>>> by this specific document.
>>>> 
>>>> We CAN describe what may happen if the remote peer does not
>>>> support trickle ICE, but leave it to that.
>>> 
>>> What we'd like to avoid is having trickle ICE offers to vanilla
>>> ICE agents and then having them fail in a user-perceptible way.
>>> 
> In my opinion, if one has to do something extra (e.g. send OPTIONS),
> the whole idea of trickle-ICE goes away, because at the end of the
> day you won't save any time in call establishment.

The OPTIONS request does not need to be sent right before the call. It
can be done once, upon bootstrap.

> Now, if the browser is communicating with a ICE terminating gateway,
> and if the browser performs SIP registration, then the gateway can
> indicate trickle-ICE during registration.
> 
> But, in the peer-to-peer case I don't know how it would work. It's
> not even sure OPTIONS would reach the same remote peer as the
> INVITE...

I agree. Not sure what to say other than, I agree that SIP does not have
good mechanisms for XMPP like negotiation of entity caps but,
personally, I do believe that finding one would be helpful here.

Maybe we can work on making sure that 3840 (or some other mechanism)
would better allow for caps to be discovered in advance.

At the very least, if we can't find a way to do this gracefully with
SIP, we can RECOMMEND it whenever the protocol allows it and try to
devise a fall back strategy when it does not (e.g. with SIP).

> Q2: Offer/Answer Alignment: ---------------------------
> 
>>>>> If so, when you talk about offers and/or answers "being sent
>>>>> at any point", I think it needs to be clear that it's within
>>>>> the rules of 3264.
>>>> 
>>>> Good point! I think the text is indeed a bit unclear in that
>>>> regard and we might be making some non-stated assumptions about
>>>> the relation between 3264 Offer/Answer, the actual call
>>>> answering, and the connectivity checks phase. We'll fix this.
>>> 
>>> Thanx! :)
> 
> 
> Q3: Enough is enough: ---------------------
> 
>>>>> I think it could be useful for the answerer to tell the
>>>>> offerer that it doesn't want/need any more candidates.
>>>> 
>>> Well, I guess any case where the remote peer knows it has a
>>> public IP address (it will most likely be an ICE lite entity).
>> 
>> Right, but in such cases the offerer would also know that a certain
>> pair has succeeded so if they continue it might be with the purpose
>> of finding a better RTT or a higher priority local candidate.
>> 
>> I guess what I am trying to say is that a Binding Response is
>> enough of an indication that trickling can stop. If it doesn't then
>> maybe it's for a reason.
> 

OK. Agreed.

> Also, at least in cases where the remote peer only provide a host
> candidate (because it has a public IP address), one should be smart
> enough to figure out that there most likely will be no better
> alternative.

I am not sure I got this.

Cheers,
Emil

---

From: Emil Ivov <[email-masked]>
Date: Thu, 11 Oct 2012 23:35:51 +0200

Hey Olle,

> can be trick(l)y and the solution for that may affect the Trickly ICE core.

Agreed.

Emil

---

From: Lishitao <[email-masked]>
Date: Fri, 12 Oct 2012 02:43:15 +0000

Hi Emil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Emil Ivov
> Sent: Friday, October 12, 2012 5:35 AM
> To: Christer Holmberg
> Cc: MMUSIC IETF WG
> Subject: Re: [MMUSIC] Trickle ICE
> 
> Hey Christer,
> 

In this way , as christer described, it won't save any time in call establishment. 

> can be done once, upon bootstrap.

If the callee has already in your contact list, of course you can do that, but if you 
call a strange number at the first time, the OPTION request should be sent right 
before the call.

/Shitao

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Oct 2012 10:08:15 +0200

Hi,

>> I think it's quite strange if Bob would reject the call at that point. 
>> Because, no matter how many candidates the offer contains, there might 
>> still be peer reflexive candidates created later,
>
> How does Bob know that there's going to be a "later" ? It's just a vanilla ICE agent that assumed it received a full set of candidates, it checked them all, all checks failed.

Bob knows that there will be STUN requests coming, and based on those additional candidates (peer reflexive) might be created.

> Now, we could rely on Bob not doing anything rash and waiting patiently for reINVITEs from Alice in order to get more candidates ...

The peer reflexive candidates will not come in a re-INVITE, they will be created based on the STUN requests.

Having said that, I agree that legacy ICE endpoints might not behave that way, and reject the call, but then we would simply do a fallback to legacy ICE. 

> Besides there are other possible failures, like for example the case where I get your server reflexive candidates long before you get mine so we perform checks out of sync (the case that I also described in my other mail to Martin).

I'll need to re-read that.

>>>>>> Well, we are not saying that they should not be addressed at all, 
>>>>>> or even now. Just that maybe they shouldn't be addressed by this 
>>>>>> specific document.
>>>>> 
>> the whole idea of trickle-ICE goes away, because at the end of the day 
>> you won't save any time in call establishment.
>
> The OPTIONS request does not need to be sent right before the call. It can be done once, upon bootstrap.

Yes, but in that case there is an even less chance that the OPTIONS and INVITE requests will reach the same remote peer (in case of forking).

>> But, in the peer-to-peer case I don't know how it would work. It's not 
>> even sure OPTIONS would reach the same remote peer as the INVITE...
>
> I agree. Not sure what to say other than, I agree that SIP does not have good mechanisms for XMPP like negotiation of entity caps but, personally, I do believe that finding one would be helpful here.
>
> Maybe we can work on making sure that 3840 (or some other mechanism) would better allow for caps to be discovered in advance.
>
>At the very least, if we can't find a way to do this gracefully with SIP, we can RECOMMEND it whenever the protocol allows it and try to devise a fall back strategy when it does not (e.g. with SIP).

There ARE ways to do it, but they all suck :)

Q3: Enough is enough: 

>>>>>> I think it could be useful for the answerer to tell the offerer 
>>>>>> that it doesn't want/need any more candidates.
>>>>> 
>>>> Well, I guess any case where the remote peer knows it has a public 
>>> IP address (it will most likely be an ICE lite entity).
>>> 
>>> I guess what I am trying to say is that a Binding Response is enough 
>>> of an indication that trickling can stop. If it doesn't then maybe 
>>> it's for a reason.
>> 

If the remote peer only provides a host candidate, and it works, I think there won't be any better alternatives.

Anyway, it's not that important, just some brainstorming from my side :)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Oct 2012 13:25:11 +0200

Hey Christer,

On 12.10.12, 10:08, Christer Holmberg wrote:
>>>>> Also, I guess I still haven't completely understood the
>>>>> backward compatibility issue, but I guess I need to do some
>>>>> more reading.
>>>> 
>>>> vanilla ICE agent that gets a first subset of candidates (that
>>>> may also be empty) would declare failure prematurely.
>>> 
>> vanilla ICE agent that assumed it received a full set of
>> candidates, it checked them all, all checks failed.
> 
> Bob knows that there will be STUN requests coming, and based on those
> additional candidates (peer reflexive) might be created.

Chances are that no STUN requests will be arriving unless Bob is also
making simultaneous checks toward Alice's SR candidates, which he isn't
because he doesn't have them.

>> Now, we could rely on Bob not doing anything rash and waiting
>> patiently for reINVITEs from Alice in order to get more candidates
>> ...
> 

That's kind of a corner case. Learning peer-reflexive candidates
implies that Bob can get Alice's conn checks which would only happen if
Bob's addresses are directly reachable from Alice (e.g. Bob has a public
address or a NAT with no endpoint dependent filtering). All in all, not
the most likely scenario.

> Having said that, I agree that legacy ICE endpoints might not behave
> that way, and reject the call, but then we would simply do a fallback
> to legacy ICE.

The problem is that in this case Bob might have been alerted of the call
and witnessed the failure, so a fallback to vanilla ICE would not be
particularly smooth.

>> Besides there are other possible failures, like for example the
>> case where I get your server reflexive candidates long before you
>> get mine so we perform checks out of sync (the case that I also
>> described in my other mail to Martin).
> 
>>>>>>>> issues with re-using the same ports in multiple m-
>>>>>>>> lines etc :)
>>>>>>> 
>>>>>>> Well, we are not saying that they should not be addressed
>>>>>>> at all, or even now. Just that maybe they shouldn't be
>>>>>>> addressed by this specific document.
>>>>>> 
>>>>> What we'd like to avoid is having trickle ICE offers to
>>>>> vanilla ICE agents and then having them fail in a
>>>>> user-perceptible way.
>>>>> 
>>>> Maybe we could modify the "SHOULD verify support" to "SHOULD
>>>> verify support or provide a mechanism for transparent fallback
>>>> to vanilla ICE"
>>> 
>>> In my opinion, if one has to do something extra (e.g. send
>>> OPTIONS), the whole idea of trickle-ICE goes away, because at the
>>> end of the day you won't save any time in call establishment.
>> 
> Yes, but in that case there is an even less chance that the OPTIONS
> and INVITE requests will reach the same remote peer (in case of
> forking).

True. Maybe adding gruu-s into the mix could help ... This would indeed
imply that the caller needs prior knowledge of the callee (e.g. adding
them to a contact list) but maybe we can have this and then another
solution for the first call/unknown callee case.

I am pretty much out of ideas for the time being anyway, so if you, or
anyone else, can think of something that would miraculously solve the
issue, I'd be very happy to hear it.

>>> Now, if the browser is communicating with a ICE terminating
>>> gateway, and if the browser performs SIP registration, then the
>>> gateway can indicate trickle-ICE during registration.
>>> 
>>> But, in the peer-to-peer case I don't know how it would work.
>>> It's not even sure OPTIONS would reach the same remote peer as
>>> the INVITE...
>> 
>> I agree. Not sure what to say other than, I agree that SIP does not
>> have good mechanisms for XMPP like negotiation of entity caps but,
>> Maybe we can work on making sure that 3840 (or some other
>> mechanism) would better allow for caps to be discovered in
>> advance.
>> 
>> At the very least, if we can't find a way to do this gracefully
>> with SIP, we can RECOMMEND it whenever the protocol allows it and
>> try to devise a fall back strategy when it does not (e.g. with
>> SIP).
> 

Is it realistic to expect that we can improve any of them to do the job?
Or add a new one?

> Q3: Enough is enough: ---------------------------
> 
>>>>> public
>>>> Right, but in such cases the offerer would also know that a
>>>> certain pair has succeeded so if they continue it might be with
>>>> the purpose of finding a better RTT or a higher priority local
>>>> candidate.
>>>> 
>>>> enough of an indication that trickling can stop. If it doesn't
>>>> then maybe it's for a reason.
>>> 
>>>  candidate (because it has a public IP address), one should be
>>> smart enough to figure out that there most likely will be no
>>> better alternative.
>> 
> If the remote peer only provides a host candidate, and it works, I
> think there won't be any better alternatives.

I don't know about that. Well, what if the host candidate is actually an
IPv6 (or VPN) tunnel with poor latency and bandwidth and the SR
candidate works better? Or what if it's the address of an 802.11g/b
interface and the same machine has a NATed Ethernet connection with,
again, better bandwidth and latency?

All in all, making assumptions on the receiving end is always a risk. If
the host sending the candidates knows that they are its best/only
candidates, then it could indicated so by sending the end-of-candidates
message we describe in the draft.

Cheers,
Emil

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Oct 2012 14:55:39 +0200

Hi,

>>> vanilla ICE agent that assumed it received a full set of candidates, 
>>> it checked them all, all checks failed.
>> 
> Chances are that no STUN requests will be arriving unless Bob is also making simultaneous checks toward Alice's SR candidates, which he isn't because he doesn't have them.

Since Alice supports trickle, we can specify that Alice shall not wait for Bob's checks :)

> That's kind of a corner case. Learning peer-reflexive candidates implies that Bob can get Alice's conn checks which would only happen
> if Bob's addresses are directly reachable from Alice (e.g. Bob has a public address or a NAT with no endpoint dependent filtering).

I assume that Bob (since he doesn't support trickle) has provided ALL his available candidates (server reflexive, relay etc) in the SDP answer.

(Just because Bob only got a host candidate in the offer, it doesn't mean he will only return a host candidate in the answer.)

> The problem is that in this case Bob might have been alerted of the call and witnessed the failure, so a fallback to vanilla ICE would not be particularly smooth.

I think that's an implementation issue, whether Bob is alerted before a working ICE pair has been found.

> True. Maybe adding gruu-s into the mix could help ... This would indeed imply that the caller needs prior knowledge of the 
> callee (e.g. adding them to a contact list) but maybe we can have this and then another solution for the first call/unknown callee case.
>
> I am pretty much out of ideas for the time being anyway, so if you, or anyone else, can think of something that would miraculously solve the issue, I'd be very happy to hear it.

I think we simply need to accept the fact that the offer may be rejected.

Based on the discussion above, I believe there are cases where things will work even if Bob doesn't support trickle, and in other case we'll just have to send a new non-trickle offer.

Of course, people CAN use OPTIONS, or whatever mechanisms they want to figure out before sending the offer, but I don't think we should have that as a SHOULD.

>>>> It's not even sure OPTIONS would reach the same remote peer as the 
>>>> INVITE...
>>> 
>>> mechanism) would better allow for caps to be discovered in advance.
>>> 

This is not the first time we realize that it would be good to know what the remote peer supports :)

Q3: Enough is enough: 
 
> message we describe in the draft.

In case Bob has a public IP address, why does Alice need to send an offer with the additional candidates in the first place? Why not simply start using them, and Bob will process them as peer reflexive candidates?

(I can understand that signaling is needed in case per-candidate ufag/pwd values are used, but let's assume a case where the same values are used for all candidates.)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Oct 2012 16:13:25 +0200

Hey Christer,

On 12.10.12, 14:55, Christer Holmberg wrote:
>>>>>>> backward compatibility issue, but I guess I need to do
>>>>>>> some more reading.
>>>>>> 
>>>>>> We describe these in Section 3 but the main problem is that
>>>>>> a vanilla ICE agent that gets a first subset of candidates
>>>>>> (that may also be empty) would declare failure
>>>>>> prematurely.
>>>>> 
>>>>> I think it's quite strange if Bob would reject the call at
>>>>> that point. Because, no matter how many candidates the offer
>>>>> contains, there might still be peer reflexive candidates
>>>>> created later,
>>>> 
>>>> How does Bob know that there's going to be a "later" ? It's
>>>> just a vanilla ICE agent that assumed it received a full set of
>>> Bob knows that there will be STUN requests coming, and based on
>>> those additional candidates (peer reflexive) might be created.
>> 
>> Chances are that no STUN requests will be arriving unless Bob is
>> also making simultaneous checks toward Alice's SR candidates, which
>> he isn't because he doesn't have them.
> 

It's Bob that I was worrying about. As soon as all his checks fail
(which can happen quite quickly if a similar host address also exists in
Bob's network and returns ICMP unreachable), all his check lists will be
in the failed state, and then its entire ICE processing will hence also
move to failed.

The whole thing may even fail before that. Bob would probably reject the
offer outright if it didn't contain any candidates. He may also do the
same if it only has IPv6 candidates while Bob is an IPv4 only host.

I am sure that one can also find other cases where lack of connectivity
can be precluded before actually running the checks and in all of them
it is entirely possible that Bob won't even send his candidates.

>>>> patiently for reINVITEs from Alice in order to get more
>>>> candidates ...
>>> 
>>> The peer reflexive candidates will not come in a re-INVITE, they
>>> will be created based on the STUN requests.
>> 
>> implies that Bob can get Alice's conn checks which would only
>> happen if Bob's addresses are directly reachable from Alice (e.g.
>> Bob has a public address or a NAT with no endpoint dependent
>> filtering).
> 
> I assume that Bob (since he doesn't support trickle) has provided ALL
> his available candidates (server reflexive, relay etc) in the SDP
> answer.
> 
> (Just because Bob only got a host candidate in the offer, it doesn't
> mean he will only return a host candidate in the answer.)

Yes of course, however I don't think this would help in the cases I
describe above. In all of them Bob can still prematurely fail the session.

And yes, 5245 does say that the controlling agent should terminate the
session when ICE processing fails, which may partially alleviate the
first case above although I am not sure all ICE implementations would
behave properly and accept new candidates once all their check lists
have moved into failed.

Even if they did, it still wouldn't help with the other two cases (i.e.
no candidates, or different address families) where lack of connectivity
can be determined without any checks at all.

>>> Having said that, I agree that legacy ICE endpoints might not
>>> behave that way, and reject the call, but then we would simply do
>>> a fallback to legacy ICE.
>> 
>> The problem is that in this case Bob might have been alerted of the
>> call and witnessed the failure, so a fallback to vanilla ICE would
>> not be particularly smooth.
> 

True. Still, 5245 allows for it and people have argued it has sometimes
been presented as a protection of privacy: I won't advertise any of my
user's addresses before I am sure my user actually wants to talk to the
caller. I believe one of the Jingle XEPs have a similar statement.

>>>>> OPTIONS), the whole idea of trickle-ICE goes away, because at
>>>>> the end of the day you won't save any time in call
>>>>> establishment.
>>>> 
>>>> The OPTIONS request does not need to be sent right before the
>>>> call. It can be done once, upon bootstrap.
>>> 
>>> Yes, but in that case there is an even less chance that the
>>> OPTIONS and INVITE requests will reach the same remote peer (in
>>> case of forking).
>> 
>> True. Maybe adding gruu-s into the mix could help ... This would
>> indeed imply that the caller needs prior knowledge of the callee
>> (e.g. adding them to a contact list) but maybe we can have this and
>> then another solution for the first call/unknown callee case.
>> 
>> I am pretty much out of ideas for the time being anyway, so if you,
>> or anyone else, can think of something that would miraculously
>> solve the issue, I'd be very happy to hear it.
> 

Personally, I am OK with this, especially as far as SIP is concerned
(given the deficiencies in the caps neg support). However if we go for
this it may be best to agree exactly how things should fail so that:

1 - time is not wasted
2 - reasons for the failure are easily related to non-support of trickle ICE
3 - failures happen in a predictable way
4 - users are not bothered with them

> Based on the discussion above, I believe there are cases where things
> will work even if Bob doesn't support trickle, and in other case
> we'll just have to send a new non-trickle offer.

Supporting non-trickle is definitely a MUST for whoever cares for
interop. I agree with this.

> Of course, people CAN use OPTIONS, or whatever mechanisms they want
> to figure out before sending the offer, but I don't think we should
> have that as a SHOULD.

OK, I can agree with making the "check support in advance" a MAY.
However defining a try and fallback procedure for usages (including SIP)
seems quite important to me.

>>>>> gateway, and if the browser performs SIP registration, then
>>>>> the gateway can indicate trickle-ICE during registration.
>>>>> 
>>>>> But, in the peer-to-peer case I don't know how it would
>>>>> work. It's not even sure OPTIONS would reach the same remote
>>>>> peer as the INVITE...
>>>> 
>>>> I agree. Not sure what to say other than, I agree that SIP does
>>>> not have good mechanisms for XMPP like negotiation of entity
>>>> caps but, personally, I do believe that finding one would be
>>>> helpful here.
>>>> 
>>>> with SIP, we can RECOMMEND it whenever the protocol allows it
>>>> and try to devise a fall back strategy when it does not (e.g.
>>>> with SIP).
>>> 
>> Is it realistic to expect that we can improve any of them to do the
>> job? Or add a new one?
> 
>>>>>>>>> I think it could be useful for the answerer to tell
>>>>>>>>> the offerer that it doesn't want/need any more
>>>>>>>>> candidates.
>>>>>>>> 
>>>>>> Right, but in such cases the offerer would also know that
>>>>>> a certain pair has succeeded so if they continue it might
>>>>>> be with the purpose of finding a better RTT or a higher
>>>>>> priority local candidate.
>>>>>> 
>>>>>> I guess what I am trying to say is that a Binding Response
>>>>>> is enough of an indication that trickling can stop. If it
>>>>>> doesn't then maybe it's for a reason.
>>>>> 
>>>>> Also, at least in cases where the remote peer only provide a
>>>>> host candidate (because it has a public IP address), one
>>>>> should be smart enough to figure out that there most likely
>>>>> will be no better alternative.
>>>> 
>>> If the remote peer only provides a host candidate, and it works,
>>> I think there won't be any better alternatives.
>> 
>> I don't know about that. Well, what if the host candidate is
>> actually an IPv6 (or VPN) tunnel with poor latency and bandwidth
>> and the SR candidate works better? Or what if it's the address of
>> an 802.11g/b interface and the same machine has a NATed Ethernet
>> connection with, again, better bandwidth and latency?
>> 
>> All in all, making assumptions on the receiving end is always a
>> risk. If the host sending the candidates knows that they are its
>> best/only candidates, then it could indicated so by sending the
>> end-of-candidates message we describe in the draft.
> 
> In case Bob has a public IP address, why does Alice need to send an
> offer with the additional candidates in the first place? Why not
> simply start using them, and Bob will process them as peer reflexive
> candidates?
> 
> (I can understand that signaling is needed in case per-candidate
> ufag/pwd values are used, but let's assume a case where the same
> values are used for all candidates.)

My point was that Bobs IP address being public:

* does not mean it is the best option: VPN, tunnelling, and multiple
interfaces can all generate public host IP addresses that are a lot less
preferable to server reflexive ones.
* does not even guarantee that it's reachable. Connectivity may be
administratively prohibited, routes can be down.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Oct 2012 09:55:08 -0700

Emil,

> Sorry about that. We'll try to add clarifications before the 01 deadline.

Actually, I think that we've just uncovered a case of talking past
each other.  I was talking about the inter-component interactions and
you were talking about the interactions intra-component.

It's seems obvious to me now that there needs to be more certainty
about the interactions on both axes.

There are clearly interactions on the one component, but I'm not sure
that the conclusions that you have drawn are necessarily optimal.
When you make the choice to cancel an outstanding transaction, you
don't do anything other than increase the probability of success.  The
Binding requests from the lower priority pair have gone out and may
still succeed, assuming of course that both peers are opening
pinholes.

Cancelling the transaction at this point seems counterproductive.
Instead, adding the new pair to the check list such that a transaction
is created in response to the next ordinary check timer pop ensures
that checks proceed on the new pair as soon as is reasonable, while
allowing the lower priority pair to move to the Failed or Succeeded
state normally.

This may result in a lower priority pair reaching Succeeded before the
higher priority one, but that was an inevitable consequence of the
sequencing anyhow.

> alerting the remote user) which would then be my cue to fallback to

That's an interesting choice.  I tend to prefer don't-even-try
solutions to try-fail-and-fallback ones if at all possible.  They tend
to be more robust because your legacy peer doesn't get in a messed up
state due to the failure.

> at least part of the coverage should go in 5245bis?

5245 doesn't really have the concept of re-freezing a pair, does it?
(Again, this was related to my comments on inter-component checking,
it might not be relevant ultimately.)

Cheers,
Martin

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Oct 2012 09:57:50 -0700

> describe above. In all of them Bob can still prematurely fail the session.

Well, spending the time to gather some server reflexive candidates
will at least turn it into a race between Alice's server reflexive
candidates and Bob's arriving.  I'd put that race down as a dead heat,
probability-wise.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Oct 2012 20:04:01 +0200

Hi,

Q1: Remote endpoint support (SIP):
-------------------------------------

> in the failed state, and then its entire ICE processing will hence also

Correct.

But, my point is that Bob might get additional candidates (peer reflexive ones) once he gets the STUN checks from Alice, so if he is smart he will wait for those before he declares failure :)

But, again, I agree that Bob may not do that, and will declare failure as soon as the host candidate present in the offer fails.

> it is entirely possible that Bob won't even send his candidates.

I don't disagree. Without doubt there will be cases where Bob will reject the offer "too early" :)

> behave properly and accept new candidates once all their check lists

My dream and vision is that they don't move to fail until they have received a STUN check, in case it will create additional candidates :)

> can be determined without any checks at all.

Sure.

(Of course, if Alice is dual stack, she can provide both IPv4 and v6 host candidates in the offer)

> caller. I believe one of the Jingle XEPs have a similar statement.

It may happen, yes. But, even if the user is alerted, keep in mind that Alice may
also terminate the call establishment.

> 4 - users are not bothered with them

I agree we should have text about it.

And, I have no problem to give examples on how all this can be avoided. It's the "SHOULD use them" that is my main issue :)

> seems quite important to me.

I agree.

Q3: Enough is enough: 
----------------------

> administratively prohibited, routes can be down.

Alice CAN continue to gather candidates, in case there are better ones. My question was why she needs to signal them to Bob in a new offer, instead of simply start sending STUN checks associated with the candidates? Bob will then process them as peer reflexive candidates.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Oct 2012 20:16:42 +0200

Hey Christer,

(one minor comment)

On 12.10.12, 20:04, Christer Holmberg wrote:
> Alice CAN continue to gather candidates, in case there are better
> ones. My question was why she needs to signal them to Bob in a new
> offer, instead of simply start sending STUN checks associated with the
> candidates? Bob will then process them as peer reflexive candidates.

She can do that of course. And she should. That's what trickling is
about after all. But those checks may fail for the reasons above (second
bullet) or simply because Bob has a firewall with endpoint-dependent
filtering so it won't let Alice's packets come in unless Bob also starts
sending packets to her.

Does this make sense?

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Oct 2012 20:20:41 +0200

Hi,

> filtering so it won't let Alice's packets come in unless Bob also starts

Note that in my use-case Bob has a public IP address, and is an ICE lite entity, so Bob won't send any STUN requests to Alice - only reply to those received from Alice.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Oct 2012 20:55:39 +0200

Hey Christer,

On 12.10.12, 20:20, Christer Holmberg wrote:
> Hi,
> 
>>>>>> All in all, making assumptions on the receiving end is
>>>>>> always a risk. If the host sending the candidates knows
>>>>>> that they are its best/only candidates, then it could
>>>>>> indicated so by sending the end-of-candidates message we
>>>>>> describe in the draft.
>>>>> 
>>>>> In case Bob has a public IP address, why does Alice need to
>>>>> send an offer with the additional candidates in the first
>>>>> place? Why not simply start using them, and Bob will process
>>>>> them as peer reflexive candidates?
>>>>> 
>>>>> (I can understand that signaling is needed in case
>>>>> per-candidate ufag/pwd values are used, but let's assume a
>>>>> case where the same values are used for all candidates.)
>>>> 
>>>> * does not mean it is the best option: VPN, tunnelling, and
>>>> multiple interfaces can all generate public host IP addresses
>>>> that are a lot less preferable to server reflexive ones. * does
>>>> not even guarantee that it's reachable. Connectivity may be 
>>> Alice CAN continue to gather candidates, in case there are
>>> better ones. My question was why she needs to signal them to Bob
>>> in a new offer, instead of simply start sending STUN checks
>>> associated with the candidates? Bob will then process them as
>>> peer reflexive candidates.
>> 
>> She can do that of course. And she should. That's what trickling
>> is about after all. But those checks may fail for the reasons above
>> (second bullet) or simply because Bob has a firewall with
>> endpoint-dependent filtering so it won't let Alice's packets come
>> in unless Bob also starts sending packets to her.
>> 
>> Does this make sense?
> 
> Note that in my use-case Bob has a public IP address, and is an ICE
> lite entity, so Bob won't send any STUN requests to Alice - only
> reply to those received from Alice.

Oh, I had missed the "Lite" part. Sorry about that.

So, yes, right now I can't think of a good reason why Alice would
continue trickling after a successful check in this case.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Oct 2012 21:00:32 +0200

Hey Shitao,

> In this way , as christer described, it won't save any time in call establishment. 

I believe Christer was referring to the case where an extra RTT right
before trickle ICE negotiation.

In this case however we are talking about an extra RTT that happens
before a vanilla ICE session and that is not in anyway blocking
candidate harvesting, so I don't see how it would be a problem.

That said, I already agreed that relying on empty INVITEs has other
disadvantages (same as empty INVITEs outside the context of ICE).

> call a strange number at the first time, the OPTION request should be sent right 

Yes, good point!

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Sat, 13 Oct 2012 00:16:16 +0200

Hey Martin,

> you were talking about the interactions intra-component.

Do you mean inter/intra-checklist?

> about the interactions on both axes.

I do believe we mention both of those but there are probably a number of
things still missing. We'll be reviewing the text in the following days
but if you can describe specific scenarios that you believe are not
currently covered, this would be very helpful.

> that the conclusions that you have drawn are necessarily optimal.

Completely possible.

> still succeed, assuming of course that both peers are opening

Well, the reason we cancel and then restart transactions is exactly
because both peers have most probably not opened pinholes.

I do however agree that in certain situations transactions may be
cancelled when they were just about to succeed, but I also think this
would be fairly easy to cover: as you suggested yourself - we just need
to declare the check successful.

> that checks proceed on the new pair as soon as is reasonable

I agree and I also believe that this is exactly what the text says right
now.

>, while

I agree and I think that if a check succeeds while it is being
cancelled, we don't necessarily need to insist on the higher priority,
redundant pair succeeding. I suppose in we can maybe keep them this way
(that is, the lower prio as successful and the higher prio as failed).

However if it doesn't and the transaction is properly cancelled then we
may just as well reschedule it for the higher prio pair.
> state due to the failure.

It's funny how I find my self on exactly the opposite sides of the same
argument in two concurrent threads :).

Yes, check-before-trying is definitely better, which is why we currently
have it as a SHOULD in the draft. The sentence that you are commenting
on was just an example of an alternative way of doing the same thing for
protocols that don't have decent Caps negotiation, like SIP.

My conversation with Christer was about me desperately insisting that
there might be a way to do this with SIP, and him persuading me that
there isn't and that we should keep this in mind when designing base
trickle.

I still think that using things like XMPP disco info and entity
capabilities is best when available.

> 5245 doesn't really have the concept of re-freezing a pair, does it?

No, and neither do we. 5245 defines the concept of cancelling a
transaction however and it doesn't cover the case where it succeeds
while being cancelled. It might be worth doing it.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Oct 2012 16:23:55 -0700

Hey,

Only really one thing to say.  The rest can await the meeting (where
I'm going to be in another room), or a revised draft.

> protocols that don't have decent Caps negotiation, like SIP.

If you say SHOULD for any particular thing, then it MUST be possible.
In order for something to be possible, you have to define a mechanism.
 My current preference is for this draft to not declare the mechanism
out of scope.  Obviously, we have a little way to go on that front, at
least with SIP.

--Martin

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Oct 2012 18:50:44 -0700

On Oct 10, 2012, at 11:18, "Christer Holmberg" <[email-masked]> wrote:

I think the idea originated from the RFC 5768 use of sip.ice, such as in a Require header in an INVITE request, Contact header in a REGISTER request or OPTIONS response. Some of the scenarios mentioned there include gateway scenarios in Section 3.1.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Oct 2012 10:35:06 +0200

Hi,

> Oh, I had missed the "Lite" part. Sorry about that.

I may not have made it very clear that I was talking about a "lite" entity, which only provides a host candidate (no matter whether it supports trickle or not)

> So, yes, right now I can't think of a good reason why Alice would continue trickling after a successful check in this case.

Well, Alice can continue to collect local candidates. But, when she has them, she doesn't need to send them to Bob in a new offer - she can simply start using them.

The advantage is that it reduces the need for additional O/A transactions on the wire, which is good, so I think it would be good to document it :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Oct 2012 10:48:40 +0200

Hi,

>> For SIP, you give RFC 3840 as an example. I am not sure how that will work. Yes, you can use 3840 to request that the
>> offer is sent to an entity which supports trickle ICE (for that, btw, you will also need to define an option tag, or something 
>> similar), but you cannot use it to determine whether the remote endpoint supports trickle ICE. In addition, you typically 
>> use 3840 at the same time when you send the initial offer.
>> Of course, you could use SIP OPTIONS. But, there are a number of issues related to that, and I don't think we want to 
>> define a mechanism which relies on the usage of OPTIONS.
>
> I think the idea originated from the RFC 5768 use of sip.ice, such as in a Require header in an INVITE request, Contact header 
> in a REGISTER request or OPTIONS response. Some of the scenarios mentioned there include gateway scenarios in Section 3.1.

Sure. SIP allows you to indicate support of features during registration, it allows you to require support of features from the remote 
peer when you send the INVITE, and it allows you to request that the INVITE is routed towards a remote peer entity that supports
certain features.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 13 Oct 2012 11:05:06 +0200

> Q1: Remote endpoint support (SIP):
Using that would require a failure, then a backoff to something that interoperates.

Using some sort of multipart/alternative attachment would be faster - but I am afraid that a lot of applications doesn't support it, 
even though it's been a requirement in SIP since day one.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Oct 2012 11:51:24 +0200

Hi,

> Using that would require a failure, then a backoff to something that interoperates.

Exactly.

> even though it's been a requirement in SIP since day one.

Not sure how multipart would help. The idea of trickle is that, when you send the offer, you only have the host candidates, so you can't send one "trickle" offer, and an alternative "non-trickle" offer, because you don't have any additional candidates to put into the non-trickle offer :)

Of course, the alternative could be without candidates all together, but then we would have to assume that the remote legacy peer still includes candidates in the answer, and start listening for STUN checks from the offerer. I think that would be a very unlikely scenario :)

Regards,

Christer