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

[Matthew Kaufman <[e-mail]>]

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:[e-mail]] 
Sent: Monday, August 27, 2012 1:15 PM
To: Matthew Kaufman; Martin Thomson; Cullen Jennings
Cc: [e-mail]
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:[e-mail]]
Sent: Monday, August 27, 2012 3:54 PM
To: Jim Barnett; Martin Thomson; Cullen Jennings
Cc: [e-mail]
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-----
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