Re: [rtcweb] rtcweb-transports reference to TRAM discovery

Adam Roach <> Thu, 18 December 2014 20:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 12BA51A875B for <>; Thu, 18 Dec 2014 12:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A50tvUKf6bsA for <>; Thu, 18 Dec 2014 12:40:08 -0800 (PST)
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 147581A86EE for <>; Thu, 18 Dec 2014 12:40:07 -0800 (PST)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id sBIKe3eA045723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2014 14:40:04 -0600 (CST) (envelope-from
X-Authentication-Warning: Host [] claimed to be Orochi.local
Message-ID: <>
Date: Thu, 18 Dec 2014 14:40:03 -0600
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <>, "Hutton, Andrew" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery
X-Mailman-Version: 2.1.15
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: Thu, 18 Dec 2014 20:40:10 -0000

So, I think it's important that we have some way to encourage deployment 
of TURN servers both in the ISPs, and as part of firewalls (both 
residential and enterprise). By putting TURN in paths that are already 
going to bear the traffic in question, the overall cost associated with 
calls goes down, and call quality (latency, loss) improves.

I'm sympathetic to the position that we don't want to give these 
entities specific hooks to force specific servers to be inserted into 
the flow. We need to find a balance here: something that allows the 
relevant entities to deploy and advertise such servers; something that 
allows WebRTC applications to discover and use them; and something that 
puts the ultimate decision in the hands of the users. Off the top of my 
head, adding a browser API that allows applications to  to retrieve 
these servers and elect to use them if it wants to would serve part of 
the purpose; giving users a means by which they can instruct the browser 
not to return such a list would serve the remainder.

But that's all kind of orthogonal to the IETF issues: if we're going to 
do *anything* in this space, we need the discovery mechanisms.


On 12/18/14 11:23, Cullen Jennings (fluffy) wrote:
> It seems that in the mobile case and many residential cases, doing that draft would allow a service provider to force all the traffic through a TURN server of the service providers choosing. Am I reading this correctly because I am pretty sure I would not be in favor of that.
>> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew <> wrote:
>> I am thinking that should include a requirement that a WebRTC Browser MUST support the TURN server discovery as described in
>> Andy
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list