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

Matthew Kaufman <> Mon, 27 August 2012 19:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8658021F84B3 for <>; Mon, 27 Aug 2012 12:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S8MZfQ8rRnRd for <>; Mon, 27 Aug 2012 12:53:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 75FD921F8495 for <>; Mon, 27 Aug 2012 12:53:56 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Mon, 27 Aug 2012 19:53:55 +0000
Received: from mail226-va3 (localhost []) by (Postfix) with ESMTP id 5D6E89001D5; Mon, 27 Aug 2012 19:53:55 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -26
X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah)
Received-SPF: pass (mail226-va3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail226-va3 (localhost.localdomain []) by mail226-va3 (MessageSwitch) id 1346097233234450_27463; Mon, 27 Aug 2012 19:53:53 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 36A61780045; Mon, 27 Aug 2012 19:53:53 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 27 Aug 2012 19:53:53 +0000
Received: from ([]) by ([]) with mapi id 14.02.0318.003; Mon, 27 Aug 2012 19:53:51 +0000
From: Matthew Kaufman <>
To: Jim Barnett <>, Martin Thomson <>, Cullen Jennings <>
Thread-Topic: [rtcweb] Filling in details on "trickle ICE"
Date: Mon, 27 Aug 2012 19:53:50 +0000
Message-ID: <>
References: <><><><><><><> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] Filling in details on "trickle ICE"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Aug 2012 19:53:57 -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: [] On Behalf Of Jim Barnett
Sent: Friday, August 24, 2012 3:33 PM
To: Martin Thomson; Cullen Jennings
Subject: Re: [rtcweb] Filling in details on "trickle ICE"

  Just to make sure that I understand your position, I take you to be
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