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

"Hutton, Andrew" <andrew.hutton@unify.com> Fri, 19 December 2014 10:15 UTC

Return-Path: <andrew.hutton@unify.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 DF4461A6F97 for <rtcweb@ietfa.amsl.com>; Fri, 19 Dec 2014 02:15:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4k2KgAYrThFd for <rtcweb@ietfa.amsl.com>; Fri, 19 Dec 2014 02:15:11 -0800 (PST)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CB1E71A6F59 for <rtcweb@ietf.org>; Fri, 19 Dec 2014 02:15:10 -0800 (PST)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id DEA911EB84F3 for <rtcweb@ietf.org>; Fri, 19 Dec 2014 11:15:09 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.192]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 11:15:09 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery
Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwCjXsFl///6QID//xuyUA==
Date: Fri, 19 Dec 2014 10:15:09 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E645DA3@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> <54933BA3.9040209@nostrum.com> <D0B8A9B6.40F29%mzanaty@cisco.com>
In-Reply-To: <D0B8A9B6.40F29%mzanaty@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q66ePc3Gh6FCZfAWIHDq1T07prg
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: Fri, 19 Dec 2014 10:15:17 -0000

+1 to Adam and Mo's comments which make a lot of sense to me.

I agree we need to enable the use of TURN servers which provide the best user experience so enabling the use of TURN servers close to the clients makes sense.  At the same time there are some security considerations which we can provide some guidance on so would it make sense to do the following?

1. Add a reference to draft-ietf-tram-turn-server-discovery in -transports- and make it a SHOULD/MAY/MUST implement (I prefer MUST but I know others probably don't). 

2. Add some text either inline or in the security considerations about the concerns and the need for user/app override. 

By the way I am not sure we need the app override if we consider draft-schwartz-rtcweb-return part of the solution.

Andy


> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: 18 December 2014 21:20
> To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery
> 
> The priority order that makes most sense to me is:
> 
> 1. user override
> 2. app override
> 3. auto discovery
> 4. app fallback
> 5. user fallback
> 
> If any override is configured by the user or app, do not perform auto
> discovery, stop here.
> 
> If auto discovery fails, use a fallback configured by the app or user.
> 
> There is a big difference between an override and a fallback, so both
> seem
> necessary.
> 
> Obviously, we need some mechanism for 3 as Adam said, in case it needs
> to
> be invoked.
> 
> Mo
> 
> On 12/18/14, 3:40 PM, Adam Roach <adam@nostrum.com> wrote:
> 
> 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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb