Subject: [rtcweb] Filling in details on "trickle ICE"

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Aug 2012 08:14:39 -0700

I've been working on doing Firefox's trickle ICE implementation and
have had to make a bunch of decisions that suggest to me that perhaps
we need an update to RFC 5245 to specify exactly how trickle ICE
behaves. Here are some of the things we need to resolve.

WHEN CHECKS START
RFC 5245 currently specifies that connectivity checks start upon
receiving the offer/answer (See Section 5):

   When an agent receives an initial offer, it will check if the offerer
   supports ICE, determine its own role, gather candidates, prioritize
   them, choose default candidates, encode and send an answer, and for
   full implementations, form the check lists and begin connectivity
   checks.

However, if you are trickling all your candidates, then this algorithm
is no longer appropriate, since the check list will be empty, so we
need a new algorithm here. There seem to be a number of natural algorithms
here, including:

(a) as soon as any check list is non-empty, start that media stream.
(b) as soon as the first media stream has a non-empty check list
start that media stream
(c) as soon as all check lists are non-empty start the first
media stream.

Note that S 5.7.4 specifies that you are supposed to start with the
first media stream, which is what makes (b) and (c) compelling.

WHEN ICE ENDS
7.1.3.3 describes the conditions required to update the check list
based on transaction completion:

   Regardless of whether the check was successful or failed, the
   completion of the transaction may require updating of check list and
   timer states.

   If all of the pairs in the check list are now either in the Failed or
   Succeeded state:

   o  If there is not a pair in the valid list for each component of the
      media stream, the state of the check list is set to Failed.

Consider the following case:

- Alice and Bob are on different addresses which both use RFC 1918
  space.
- Alice sends Bob the candidate 10.0.0.10 as her first candidate at
  This just happens to correspond to an existing host on Bob's network.
- Bob creates a check list consisting solely of 10.0.0.10 and starts
  checks.
- Because 10.0.0.10 is a real host on Bob's network, it generates an ICMP
  error and per S 7.1.3.1 Bob marks the transaction as Failed:

Unless I have missed something, Given the algorithm above, the check
list now consists solely of Failed candidates and the valid list is
now empty, so this causes the media stream to be Failed. If this is
the only media stream, according to 8.1.2. the entire ICE process is
now marked as Failed.

What's letting this happen is a race condition between candidates
arriving and checks failing. I suspect that there are others, so we
probably need some way to handle these cases.

WHEN NEW TRICKLE CANDIDATES CAN BE PROCESSED
A related question is when new trickle candidates can be processed.
Say that a new candidate is received when a stream has a nominated
candidate on the valid list? Do we add a new candidate to the
list? Note that S 8.1.2 would ordinarily have us stopping checks
on all other extant candidates pairs.

HOW DO OTHER MEDIA STREAMS GET UNFROZEN
Say I finish checks on one stream but another stream successfully.
Ordinarily, I would start to unfreeze other check lists, but what
if those are empty? How do they get unfrozen when candidates come
in?

INTERACTION WITH NON-TRICKLE ICE
I'm concerned about the potential interactions between trickle ICE
and non trickle ICE. Obviously, an extant ICE implementation can
only handle getting all the candidates at once, so in order to
have interop we need to hold all the candidates until we get the
"null" finished candidate indication. But this means that in the
case where the non-trickle version is the offerer, then checks
aren't performed simultaneously. Consider the following case:

- Alice is a non-trickle endpoint
- Bob is a trickle endpoint
- Alice and Bob are behind standard address-dependent filtering NATs
- Bob has two STUN servers but one is down.
- The JS holds off on sending Bob's offer to Alice until all the
  candidates are in. (Which, as I say above, is I think mandatory).

I believe we get the following behavior.

Alice          Alice NAT                Bob NAT           Bob
 Bob STUN 1           Bob STUN 2

OFFER ------------------------------------------------------>
						            BINDING REQUEST ->
 						            BINDING REQUEST -------------------------->
							    <- BINDING RESPONSE
					            onicecandidate(...)
                X <----------------------- CONNECTIVITY CHECK
 						            BINDING REQUEST (RT) --------------------->
                X <------------------ CONNECTIVITY CHECK (RT)
		  		                          ...
						     [Give up on STUN 2]
					            onicecandidate(null)
                                 /----------------------  ANSWER
                                /              [Give up on
CONNECTIVITY CHECK; ICE fails]
<------------------------------/				

The key thing here is that if the STUN timers for connectivity checks
and for initial binding requests are similar, then Bob's checks can
fail before Alice has time to open up a pinhole. This doesn't happen
in regular ICE because the checks are synched in each direction.

I suspect that this list is incomplete, but I think it's enough to
suggest that there may be some details in trickle ICE that need to
at least be documented and perhaps investigated/resolved.

To the chairs: can you provide some guidance as to how to proceed with
this discussion, what forum it should be discussed in, etc.?

Thanks,
-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Aug 2012 08:26:07 -0700

> this discussion, what forum it should be discussed in, etc.?

With my chair hat on here…. this work clearly needs to change some stuff in RFC 5245 (the ICE spec) which was done in mmusic WG. So I think the default location for updating it is probably the mmusic WG. I'll ping the AD's and chairs but I think unless we here something different, mmusic is the place for this.

Cullen <rtcweb co-chair>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Aug 2012 08:55:01 -0700

> behaves. Here are some of the things we need to resolve.

These are not necessarily interoperability issues.  You can solve all
of these problems without creating another RFC.

You make the decision to start and stop, succeed or fail, nominate or
leave.  That decision might be guided by an RFC, but you are
responsible for what your code does.

...unless you consider it impossible to take actions unless those
actions have the blessing of RFC5245.

--Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Aug 2012 08:59:33 -0700

> responsible for what your code does.

I suppose it depends on whether you think it's important for
independently developed Web applications and/or softphones
to be able to talk to each other.

> actions have the blessing of RFC5245.

Not at all. We could take actions blessed by other RFCs.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Aug 2012 09:12:25 -0700

>> of these problems without creating another RFC.

I'd be interested in hearing the interoperability reason for, for
example, giving up on a particular component instead of waiting for
additional candidates.  What effect does that have on
interoperability.

It's fairly clear that if you are trickling candidates out, then an
strictly conforming implementation of RFC 5245 on the other end could
fail.  That's just a reason to not trickle at all.

--Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Aug 2012 09:42:40 -0700

> additional candidates.  What effect does that have on

I'm not following what you are saying here. Ignoring the question of
non-trickle (i.e., strict RFC 5245) endpoints, if you are a trickle endpoint
that gives up under conditions when RFC 5245 says you should give
up, you are likely to have problems. You don't think it's worth writing
that down somewhere more permanent/definitive than an email
to the mailing list?

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Aug 2012 09:56:09 -0700

On 24 August 2012 09:42, Eric Rescorla <[email-masked]> wrote:
> up, you are likely to have problems.

If you are a trickle endpoint, then you are not implementing RFC 5245.
 RFC 5245 might not explicitly exclude the possibility, but it is
certainly implicit, as the problems you cite in your email attest.

What I think we want to with trickle is to create a new method.  That
method is only like RFC 5245 to the extent that it shares some
properties: the good parts.

> You don't think it's worth writing

Only if it addresses a specific interoperability need does it need to
be in an RFC.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Aug 2012 11:16:36 -0700

I'm confused on what you are trying to say. Are you saying 

1) we don't need trickle ICE

2) we can do trickily ICE but no standards need to be written for two different devices to do trickle ICE

On Aug 24, 2012, at 9:56 , Martin Thomson wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Aug 2012 14:22:41 -0700

> 2) we can do trickily ICE but no standards need to be written for two different devices to do trickle ICE

It's just 2)

Trickle candidates is a *new thing*, a new problem that needs to be
solved.  It's fairly clear that trickling is an optimization that was
never considered in the design of ICE.

We can solve the problem by writing an RFC, but you can also write
fewer standards and enable the same outcome.

An RFC would specify how this differs from ICE and what new behaviours
are expected from endpoints.  That RFC would also describe how
implementations would discover if peers support the new behaviour so
that they don't do things that would surprise or break implementations
that did not.

The alternative is to recognize that ICE specifies a number of
features that are really, really important, both from an
interoperability and a security standpoint:
  The use of STUN Binding requests to gather server reflexive addresses.
  The use of TURN to allocate TURN relays.
  The use of STUN Binding requests to establish connectivity and consent.
  Constraints over how checks can be sent (which are actually not all
suitable in this context for other reasons).
  A way to resolve the problem of who performs candidate pair selection.

Then ICE has a bunch of really useful advice on what implementations
might do: gather candidates, prioritize them, check them, retry
checks, track those that succeed, etc...  None of that is really
necessary, just super handy.

The signalling stuff in ICE is not relevant to the rtcweb
architecture.  So we can ignore that part.  WebRTC decided to use it,
but that's their problem.

The most invasive thing that ICE does is describe a specific algorithm
in some detail.  Implicit in this algorithm is the fact that all
candidates have to be signaled together.  This is also stuff that we
don't *need* in rtcweb.

This might have been useful when you use RFCs to describe every facet
of your application, but it is in fact unnecessary for applications of
the sort that exist in rtcweb.  Many of these applications want things
like trickle candidates, which can give better session initialization
performance.  Many of these will have code on both endpoints.

Obviously, applications that want to interoperate with ICE
implementations will have to play nice with ICE.  But this is usually
known a priori.  Building signaling for this is presumptuous.

I understand how someone might conclude that you need to standardize
this behaviour.  It depends on what preconceptions you have.  If you
wanted to port trickle candidates to your SIP PBX, then I can see how
the standardization option might seem attractive.

The Microsoft API proposal makes all of this possible by only taking
the really important stuff from RFC 5245.

--Martin

---

From: "Jim Barnett" <[email-masked]>
Date: Fri, 24 Aug 2012 15:33:16 -0700

Martin,  
  Just to make sure that I understand your position, I take you to be
saying:  
1) in the case where both endpoints have downloaded their apps from the
same server, they can do trickle ICE any way that they want.
2) in the case where an application is  talking to an unknown or legacy
peer, trickle  ICE is a bad idea because there is no standard way to do
it. (i.e. try it at your own risk)

Is this correct?

- Jim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Martin Thomson
Sent: Friday, August 24, 2012 5:23 PM
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [rtcweb] Filling in details on "trickle ICE"

It's just 2)

We can solve the problem by writing an RFC, but you can also write fewer
standards and enable the same outcome.

The alternative is to recognize that ICE specifies a number of features
that are really, really important, both from an interoperability and a
security standpoint:
  The use of STUN Binding requests to gather server reflexive addresses.
  The use of TURN to allocate TURN relays.
  The use of STUN Binding requests to establish connectivity and
consent.
  Constraints over how checks can be sent (which are actually not all
suitable in this context for other reasons).
  A way to resolve the problem of who performs candidate pair selection.

Then ICE has a bunch of really useful advice on what implementations
might do: gather candidates, prioritize them, check them, retry checks,
track those that succeed, etc...  None of that is really necessary, just
super handy.

The signalling stuff in ICE is not relevant to the rtcweb architecture.
So we can ignore that part.  WebRTC decided to use it, but that's their
problem.

This might have been useful when you use RFCs to describe every facet of
your application, but it is in fact unnecessary for applications of the
sort that exist in rtcweb.  Many of these applications want things like
trickle candidates, which can give better session initialization
performance.  Many of these will have code on both endpoints.

The Microsoft API proposal makes all of this possible by only taking the
really important stuff from RFC 5245.

--Martin

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Aug 2012 17:08:39 -0700

> it. (i.e. try it at your own risk)

A fair summation.  In 1) they can do whatever they want within the
necessary security constraints.

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 27 Aug 2012 19:53:50 +0000

If both ends want to do a full, standards compliant (which also implies *not* trickle) ICE, then we can bake that into the browser following the existing RFC as specification.

If both ends want to do something that isn't that, then we either need to write down *exactly* how they do that "something else" (which would imply an RFC or three for things like how trickle ICE works, how it is discovered, what SDP implications it has, etc.) *or* we need to provide knobs that allow the developer, through Javascript, to ensure that both ends do the same (or compatible) "something elses".

Note that the only reason ICE-like STUN connectivity tests are a MUST is that it is required for consent verification. There are any number of reasons why an endpoint might wish to do something other than what a full standards-compliant ICE implementation would require... this thread has been about the issues around trickle candidates, but there's also the case where you're on a webpage of mine and I know I'm going to send your call via a gateway that has a public IP address. There is no reason to run any of what ICE requires *except* the security-considerations-mandated consent verification, and only in the browser-to-gateway test direction.

Again, we could write another RFC covering that case... or we could just do what our (Microsoft's) proposal suggests and provide the developer with the controls necessary to implement *any* of these use cases, including the mode that matches the current ICE RFC.

As a side effect, the developer then *also* has the flexibility to improve interoperation with things like pre-final ICE implementations, as long as they meet the requirements around STUN connectivity tests.

So to recap, if you want something fancy like ICE with trickle candidates you have two options:

X) Give the developer the flexibility to build variations upon ICE within the security constraints, or
Y) Start writing Internet Drafts describing all the variations upon ICE you might wish to use and then get every browser vendor to add them

Matthew Kaufman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Barnett
Sent: Friday, August 24, 2012 3:33 PM
To: Martin Thomson; Cullen Jennings
Cc: [email-masked]
Subject: Re: [rtcweb] Filling in details on "trickle ICE"

Martin,
  Just to make sure that I understand your position, I take you to be
saying:  
1) in the case where both endpoints have downloaded their apps from the same server, they can do trickle ICE any way that they want.
2) in the case where an application is  talking to an unknown or legacy peer, trickle  ICE is a bad idea because there is no standard way to do it. (i.e. try it at your own risk)

Is this correct?

- Jim

---

From: "Jim Barnett" <[email-masked]>
Date: Mon, 27 Aug 2012 13:15:06 -0700

One question I have is whether we consider the "Browser RTC Trapezoid"
to be in scope.  In this use case, the two UAs download their
applications from different web servers.  In such a case, I don't see
how we can enable trickle ICE without specifying _exactly_ how  it is
supposed to work (or, alternatively, specifying a protocol that the two
web servers will use to negotiate how to do it).  

Handling the trapezoid is a _lot_ more work than the case where both UAs
download their applications from the same server (or from the case where
a single WebRTC UA is talking to a legacy device).  Have we made a
decision on whether it is in scope?  In any case, it would certainly
clarify the discussion for me if I knew whether we were considering this
use case or not.  A number of claims have been and are being made on the
list that strike me as obviously false if this use case is in scope -
and perfectly sensible if it's not.  

- Jim
P.S.  My personal opinion is that it would make sense to defer the
trapezoid until a hypothetical version 2.  That way it would not inform
any immediate decisions about the APIs, but we would have to consider
what it would take to extend them to handle it. (I would think that
would involve mostly adding more detail, so forward compatibility might
not be hard to achieve.)

-----Original Message-----
From: Matthew Kaufman [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 3:54 PM
To: Jim Barnett; Martin Thomson; Cullen Jennings
Cc: [email-masked]
Subject: RE: [rtcweb] Filling in details on "trickle ICE"

If both ends want to do a full, standards compliant (which also implies
*not* trickle) ICE, then we can bake that into the browser following the
existing RFC as specification.

If both ends want to do something that isn't that, then we either need
to write down *exactly* how they do that "something else" (which would
imply an RFC or three for things like how trickle ICE works, how it is
discovered, what SDP implications it has, etc.) *or* we need to provide
knobs that allow the developer, through Javascript, to ensure that both
ends do the same (or compatible) "something elses".

Note that the only reason ICE-like STUN connectivity tests are a MUST is
that it is required for consent verification. There are any number of
reasons why an endpoint might wish to do something other than what a
full standards-compliant ICE implementation would require... this thread
has been about the issues around trickle candidates, but there's also
the case where you're on a webpage of mine and I know I'm going to send
your call via a gateway that has a public IP address. There is no reason
to run any of what ICE requires *except* the
security-considerations-mandated consent verification, and only in the
browser-to-gateway test direction.

Again, we could write another RFC covering that case... or we could just
do what our (Microsoft's) proposal suggests and provide the developer
with the controls necessary to implement *any* of these use cases,
including the mode that matches the current ICE RFC.

As a side effect, the developer then *also* has the flexibility to
improve interoperation with things like pre-final ICE implementations,
as long as they meet the requirements around STUN connectivity tests.

So to recap, if you want something fancy like ICE with trickle
candidates you have two options:

X) Give the developer the flexibility to build variations upon ICE
within the security constraints, or
Y) Start writing Internet Drafts describing all the variations upon ICE
you might wish to use and then get every browser vendor to add them

Matthew Kaufman

-----Original Message-----
Of Jim Barnett

Martin,

Is this correct?

- Jim

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 27 Aug 2012 20:42:03 +0000

The "two different web servers" "trapezoid" case would require a trunking protocol between these servers, such as SIP or Jingle, which can describe "trickle ICE" such that the browsers could be instructed properly by their respective web servers.

I believe that with Jingle, there is a written spec for that, and for SIP, there is not (at present).

Matthew Kaufman

-----Original Message-----
From: Jim Barnett [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 1:15 PM
To: Matthew Kaufman; Martin Thomson; Cullen Jennings
Cc: [email-masked]
Subject: RE: [rtcweb] Filling in details on "trickle ICE"

One question I have is whether we consider the "Browser RTC Trapezoid"
to be in scope.  In this use case, the two UAs download their applications from different web servers.  In such a case, I don't see how we can enable trickle ICE without specifying _exactly_ how  it is supposed to work (or, alternatively, specifying a protocol that the two web servers will use to negotiate how to do it).  

Handling the trapezoid is a _lot_ more work than the case where both UAs download their applications from the same server (or from the case where a single WebRTC UA is talking to a legacy device).  Have we made a decision on whether it is in scope?  In any case, it would certainly clarify the discussion for me if I knew whether we were considering this use case or not.  A number of claims have been and are being made on the list that strike me as obviously false if this use case is in scope - and perfectly sensible if it's not.  

- Jim
P.S.  My personal opinion is that it would make sense to defer the trapezoid until a hypothetical version 2.  That way it would not inform any immediate decisions about the APIs, but we would have to consider what it would take to extend them to handle it. (I would think that would involve mostly adding more detail, so forward compatibility might not be hard to achieve.)

-----Original Message-----
From: Matthew Kaufman [mailto:[email-masked]]
Sent: Monday, August 27, 2012 3:54 PM
To: Jim Barnett; Martin Thomson; Cullen Jennings
Cc: [email-masked]
Subject: RE: [rtcweb] Filling in details on "trickle ICE"

If both ends want to do a full, standards compliant (which also implies
*not* trickle) ICE, then we can bake that into the browser following the existing RFC as specification.

Matthew Kaufman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Barnett
Sent: Friday, August 24, 2012 3:33 PM
To: Martin Thomson; Cullen Jennings
Cc: [email-masked]
Subject: Re: [rtcweb] Filling in details on "trickle ICE"

Martin,

Is this correct?

- Jim

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 27 Aug 2012 14:45:41 -0600

On 8/27/12 2:42 PM, Matthew Kaufman wrote:
> The "two different web servers" "trapezoid" case would require a 
> trunking protocol between these servers, such as SIP or Jingle,
> which can describe "trickle ICE" such that the browsers could be
> instructed properly by their respective web servers.
> 

Correct: http://xmpp.org/extensions/xep-0176.html

/psa

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Aug 2012 14:51:53 -0700

Right.  

 XEP-0176 Sections 5.5-5.9 does describe how various aspects of "Trickle ICE" are handled in XMPP/Jingle, answering a number of the questions asked in Eric's original post (see http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html).  These sections are consistent with RFC 5245 with respect to STUN/TURN behavior, so that it isn't clear to me that a revision of RFC 5245 is needed.  Or am I missing something?

> Correct: http://xmpp.org/extensions/xep-0176.html

Eric Rescorla said:

I've been working on doing Firefox's trickle ICE implementation and
have had to make a bunch of decisions that suggest to me that perhaps
we need an update to RFC 5245 to specify exactly how trickle ICE
behaves. Here are some of the things we need to resolve.....

---

From: Emil Ivov <[email-masked]>
Date: Tue, 28 Aug 2012 00:04:45 +0200

On 27.08.12, 23:51, Bernard Aboba wrote:
> Right. 
> 
>  XEP-0176 Sections 5.5-5.9 does describe how various aspects of "Trickle
> ICE" are handled in XMPP/Jingle, answering a number of the questions
> asked in Eric's original post (see
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05121.html). 
> These sections are consistent with RFC 5245 with respect to STUN/TURN
> behavior, so that it isn't clear to me that a revision of RFC 5245 is
> needed.  Or am I missing something?

Well an ICE stack that implements trickle as per XEP-0176 would
currently not interoperate with a 5245 implementation or, at best, would
lead to unpredictable results.

The description in XEP-0176 is actually quite perfunctory and can't
really be considered a proper specification.

A document that describes a proper way of implementing this would hence
be quite helpful.

Emil

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Aug 2012 15:29:19 -0700

Emil Ivov said: 

Well an ICE stack that implements trickle as per XEP-0176 would currently
not interoperate with a 5245 implementation or, at best, would lead to
unpredictable results.

The description in XEP-0176 is actually quite perfunctory and can't really
be considered a proper specification.

A document that describes a proper way of implementing this would hence be
quite helpful.

[BA]  You are correct that XMPP/Jingle signaling will not be understood by a
SIP UA.  However,   I don't see anything inherent in the use of STUN/TURN 
within XEP-0176 that violates RFC 5245.  If the issue is lack of clarity in
XEP-0176, shouldn't that be brought up in the XSF, which owns the
specification?

---

From: Francois Audet <[email-masked]>
Date: Tue, 28 Aug 2012 00:23:08 +0000

Wouldn't the same mechanism as XEP-0176 work with SIP too, by sending new offer/answers with new candidates?

In either cases, it is true that the "trapezoid" model makes this process more difficult than with the "triangle" model.

But you don't *have* to do trickle ICE don't you, in the trapezoid scenario (especially when involving protocol mapping).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Monday, August 27, 2012 3:29 PM
To: 'Emil Ivov'
Cc: [email-masked]
Subject: Re: [rtcweb] Filling in details on "trickle ICE"

Emil Ivov said: 

Well an ICE stack that implements trickle as per XEP-0176 would currently not interoperate with a 5245 implementation or, at best, would lead to unpredictable results.

The description in XEP-0176 is actually quite perfunctory and can't really be considered a proper specification.

A document that describes a proper way of implementing this would hence be quite helpful.

[BA]  You are correct that XMPP/Jingle signaling will not be understood by a
SIP UA.  However,   I don't see anything inherent in the use of STUN/TURN 
within XEP-0176 that violates RFC 5245.  If the issue is lack of clarity in XEP-0176, shouldn't that be brought up in the XSF, which owns the specification?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Aug 2012 20:12:54 -0700

> But you don't *have* to do trickle ICE don't you, in the trapezoid scenario (especially when involving protocol mapping).

[BA]  Looking at XEP-0176 Section 5.8, it does seem possible to use new offer/answers with new candidates to similar effect.  Here is what Section 5.8 says: 

Section 5.8 Negotiating a new candidate

Even after media has begun to flow, either party MAY continue to send 
additional candidates to the other party (e.g., because the user agent 
has become aware of a new media proxy or network interface card). Such 
candidates are shared by sending a transport-info message....  The 
receiving party MUST acknowledge receipt of the candidate. The parties 
would check the newly-offered candidate for 
connectivity, as described previously. If the parties determine that 
media can flow over the candidate, they MAY then use the new candidate 
in subsequent communications.  

[BA]  If ICE completed and media was already flowing, the controlling agent can generate a RE-INVITE with a candidate from the in-use pair as the default as well as additional candidates.  There is no need to do an ICE restart.  As described in RFC 5245 Section 8.1.2, if the additional candidate ends up in a highest-priority nominated candidate-pair, then an updated offer is sent: 

      *  If an agent is controlling, it examines the highest-priority
         nominated candidate pair for each component of each media
         stream.  If any of those candidate pairs differ from the
         default candidate pairs in the most recent offer/answer
         exchange, the controlling agent MUST generate an updated offer
         as described in Section 9.  If the controlling agent is using
         an aggressive nomination algorithm, this may result in several
         updated offers as the pairs selected for media change.  An
         agent MAY delay sending the offer for a brief interval (one
         second is RECOMMENDED) in order to allow the selected pairs to
         stabilize.

Details of the updated offer are described in RFC 5245 Section 9.1.2.2:

   If an agent generates an updated offer including a media stream that
   was previously established, and for which ICE checks are in the
   Completed state, the agent follows the procedures defined here.

   The default destination for media (i.e., the values of the IP
   addresses and ports in the m and c lines used for that media stream)
   MUST be the local candidate from the highest-priority nominated pair
   in the valid list for each component.  This "fixes" the default
   destination for media to equal the destination ICE has selected for
   media.

   The agent MUST include candidate attributes for candidates matching
   the default destination for each component of the media stream, and
   MUST NOT include any other candidates.

   In addition, if the agent is controlling, it MUST include the
   a=remote-candidates attribute for each media stream whose check list
   is in the Completed state.  The attribute contains the remote
   candidates from the highest-priority nominated pair in the valid list
   for each component of that media stream.  It is needed to avoid a
   race condition whereby the controlling agent chooses its pairs, but
   the updated offer beats the connectivity checks to the controlled
   agent, which doesn't even know these pairs are valid, let alone
   selected.  See Appendix B.6 for elaboration on this race condition.

---

From: Francois Audet <[email-masked]>
Date: Tue, 28 Aug 2012 04:40:47 +0000

Yes, this is exactly the section of 5245 I was referring to. Seems to be effectively trickling.

On Aug 27, 2012, at 20:12, "Bernard Aboba" <[email-masked]<mailto:[email-masked]>> wrote:

Even after media has begun to flow, either party MAY continue to send additional candidates to the other party (e.g., because the user agent has become aware of a new media proxy or network interface card). Such candidates are shared by sending a transport-info message....  The receiving party MUST acknowledge receipt of the candidate. The parties would check the newly-offered candidate for connectivity, as described previously. If the parties determine that media can flow over the candidate, they MAY then use the new candidate in subsequent communications.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 28 Aug 2012 08:04:04 +0200

On 28.08.12, 00:29, Bernard Aboba wrote:
> SIP UA. 

Right. And of course, I was not referring to signalling.

> However,   I don't see anything inherent in the use of STUN/TURN 
> within XEP-0176 that violates RFC 5245. 

It's more about ICE processing rather than STUN and TURN and the fact
that, if an ICE implementation is not prepared to handle trickling it
would not work well with one that does. (more below)

>From your other mail:

> Details of the updated offer are described in RFC 5245 Section 9.1.2.2:

I am not sure how 9.1.2.2 would apply here given that it's about sending
updated offers once ICE has completed. It even says that:

Did you instead mean to quote section 9.1.2.1 which contains the following:

   The agent
   MAY include additional candidates it did not offer previously, but
   which it has gathered since the last offer/answer exchange, including
   peer reflexive candidates.

9.1.2.1 does indeed refer to updating ICE for "Existing Media Streams
with ICE Running".

While I agree that this does look like trickling I am not sure it was
intended to be used in exactly the same way that we are discussing here
and the text is not enough to cover a proper trickling implementation.

The main issue is that there's currently nothing in 5245 that would
allow an agent to determine if more candidates are to be expected. If
trickling is in use there's no way for a controlled agent to know that
(or if) more candidates are to be expected. This creates a race
condition which may result in the controlled agent moving into the "ICE
Failed" state before it has received all candidates from the controlling
agent.

Such premature failures can happen very easily if the first offer only
contains addresses that can be determined as unusable without even
running any checks. This would be the case for an IPv4-only host
receiving an offer with IPv6 candidates only (and vice versa). One can
probably come up with a few more cases like this one.

> If the issue is lack of clarity in

Nope, XEP-0176 would be crystal clear if the IETF comes up with a
document that explains how ICE agents should behave in situations where
addresses continue to arrive after the original offer.

Emil

--
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 28 Aug 2012 08:11:25 +0200

> Failed" state before it has received all candidates from the controlling

I just noticed that this is also what Eric's original mail was about, so
I suppose I just second his concern. We had the issue in ice4j and we
basically just had to implement and tune it in a way that would work
against other common ICE impls.

Text that specifies exactly how this is to be done would have been most
helpful.

Emil

--
https://jitsi.org

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 28 Aug 2012 13:04:53 +0000

> XEP-0176, shouldn't that be brought up in the XSF, which owns the

XEP-0176 mostly tells you how to transport the trickle candidates. It does not answer the questions of ICE works with trickle candidates and there are a bunch of them as raised in EKR's email and others. Note these are not new concerns - many of these were discussed with Rohan back when he was writing the Jingle stuff. We just never sorted them out.

---

From: Lishitao <[email-masked]>
Date: Wed, 29 Aug 2012 06:34:48 +0000

> Failed" state before it has received all candidates from the controlling

Agree, and AFAIK, what described in RFC 5245 is not the exact mechanism as ICE trickling. 

Moreover, using SDP for ICE trickling is not a good idea, because, the reason by using ICE trickling is to shorten 
the negotiation time, but the offerer can not send another update SDP offer which including the new candidates 
to the answerer unless the offerer has received the first SDP answer, this cannot increase the negotiation procedure.