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

[Matthew Kaufman <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Jim Barnett
Sent: Friday, August 24, 2012 3:33 PM
To: Martin Thomson; Cullen Jennings
Cc: [e-mail]
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