Re: [Dart] ICE might send your traffic over TCP

Ben Campbell <> Thu, 24 July 2014 19:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E03171B287D for <>; Thu, 24 Jul 2014 12:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mPkbILGvpDAu for <>; Thu, 24 Jul 2014 12:44:52 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F75A1B27F0 for <>; Thu, 24 Jul 2014 12:44:52 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id s6OJimLe009436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 14:44:50 -0500 (CDT) (envelope-from
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Thu, 24 Jul 2014 15:44:43 -0400
X-Mao-Original-Outgoing-Id: 427923883.560901-299b818bbf9bc9607312e7fe082db681
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <CA7A7C64CC4ADB458B74477EA99DF6F502D8EA763B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <>
To: Jonathan Lennox <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "" <>, "" <>
Subject: Re: [Dart] ICE might send your traffic over TCP
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Jul 2014 19:44:54 -0000

(as individual)

On Jul 24, 2014, at 9:00 AM, Jonathan Lennox <> wrote:

> I don’t think different drop precedences would be useful in respect to TCP.
> The problem is that the way the WebRTC APIs are structured, it’s not necessarily clear to an application that its media traffic is indeed going over TCP, so it might make precedence requests that the browser implementing the APIs can’t (and shouldn’t try to) satisfy.
> The question is how the browser should behave when that happens.  I spoke to Cullen about this, offline, after the DART session, and I believe he had a simple proposal.

What would we expect DART to say about this? It seems to me that we should point out that we think different drop precedences for a single TCP connections doesn't make sense. But it is RTCWEB's issue to think things through if they have a use case that might make this happen, isn't it?