Re: [rtcweb] [art] [clue] ICE, ICE-bis, and Cluster 238

Cullen Jennings <> Fri, 07 September 2018 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E972C12F1A2 for <>; Fri, 7 Sep 2018 09:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.59
X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N2X-GY1ppYps for <>; Fri, 7 Sep 2018 09:36:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5676130DF7 for <>; Fri, 7 Sep 2018 09:36:37 -0700 (PDT)
Received: from (localhost []) by (SMTP Server) with ESMTP id D6594404ED; Fri, 7 Sep 2018 12:36:36 -0400 (EDT)
Received: by (Authenticated sender: with ESMTPSA id 54563403D1; Fri, 7 Sep 2018 12:36:36 -0400 (EDT)
Received: from [] ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.7.12); Fri, 07 Sep 2018 12:36:36 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_229D84CB-B9E6-4319-9E94-646186D4468C"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Cullen Jennings <>
In-Reply-To: <>
Date: Fri, 7 Sep 2018 10:36:35 -0600
Cc: Applications and Real-Time Area Discussion <>, "" <>, RTCWeb IETF <>, "" <>, "" <>
Message-Id: <>
References: <> <> <>
To: Christer Holmberg <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [rtcweb] [art] [clue] ICE, ICE-bis, and Cluster 238
X-Mailman-Version: 2.1.29
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: Fri, 07 Sep 2018 16:36:42 -0000

> On Sep 7, 2018, at 1:25 AM, Christer Holmberg <> wrote:
> > Cisco has implemented stuff that is WebRTC 1.0 compliant without this change. These gratuitous changes, years after the implementation were coded, with no real benefit will ensure that we are not
> > and will not become compliant with the RFC. It's unlikely we will upgrade to the new ICE until it has real befits. 
> The main reason we did 8445 was because people had identified issues with 5245. The work was driven mostly by the WebRTC community, including yourself and the Chrome people (or, at least the Google people), and one of the reason it took time to finalize 8445 was because you (among others) wanted to make sure we get things right (by making network measurements etc). Are you now saying all those changes bring no benefit? Did we all waste our time?

Our testing, which we do not share, dig not indicate an improvement of connectivity rates. I did not see results from others that did. Some of the early test results from others that drove this work were not reproducible in our testing. The one thing I think most people did find is that the more out of sync the pacing of the two agents was, the worse the connectivity was. But all of this is water under the bridge, we have old and new ice, people can use either. What we are talking about here is what is the minimum bar for WebRTC 1.0 

> > It is doubtful Justin will want to implement the 8445 mechanisms of supporting both new and old ICE. Instead, we will move to say "works with Browser X version Y or later." We have watched at W3C as it moved to be that unless chrome does it, it rare that it becomes a standard.  
> > Right here I am watching how the stuff IETF defines will be less relevant than the issue of what chrome implements. 
> What exactly would Justin have to change?

For us, the largest part is having to test for both old and new - it’s not easy to do good automated testing for ICE.