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

["Jim Barnett" <[e-mail]>]

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