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

Adam Roach <adam@nostrum.com> Thu, 18 December 2014 20:40 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BA51A875B for <rtcweb@ietfa.amsl.com>; Thu, 18 Dec 2014 12:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A50tvUKf6bsA for <rtcweb@ietfa.amsl.com>; Thu, 18 Dec 2014 12:40:08 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147581A86EE for <rtcweb@ietf.org>; Thu, 18 Dec 2014 12:40:07 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (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 adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <54933BA3.9040209@nostrum.com>
Date: Thu, 18 Dec 2014 14:40:03 -0600
From: Adam Roach <adam@nostrum.com>
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)" <fluffy@cisco.com>, "Hutton, Andrew" <andrew.hutton@unify.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com>
In-Reply-To: <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/feMlseu4GTD55l0ITeWhDsK3Ig4
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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.

/a

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 <andrew.hutton@unify.com> wrote:
>>
>> I am thinking that https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4 should include a requirement that a WebRTC Browser MUST support the TURN server discovery as described in https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00.
>>   
>>   
>> Andy
>>   
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb