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

Benjamin Schwartz <bemasc@webrtc.org> Fri, 19 December 2014 15:25 UTC

Return-Path: <bemasc@webrtc.org>
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 BC0441A89B9 for <rtcweb@ietfa.amsl.com>; Fri, 19 Dec 2014 07:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 UYFLCMnbW3hi for <rtcweb@ietfa.amsl.com>; Fri, 19 Dec 2014 07:25:35 -0800 (PST)
Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC251A89F0 for <rtcweb@ietf.org>; Fri, 19 Dec 2014 07:25:35 -0800 (PST)
Received: by mail-vc0-f173.google.com with SMTP id kv19so393817vcb.18 for <rtcweb@ietf.org>; Fri, 19 Dec 2014 07:25:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gNtfFcFYq8s0GRC3gLqV9OpZumdNn5z1OHQkrcBzd7o=; b=Hv6epePgP4JE5+tBOFFeHjPOBA4w//995zCMwhQmK6uvMawKOQmtwAwl1VT4CydU78 YdSbsBKu4o1pSU7Pjx5hIJB7rrcKCivcWiRgfD5YxANEMV1I9dij1OCB14ixSWel6wYw otyFgJ7sh9nffxsVkbX/0aPmbt4EEIvXrKIcUocoO6hiRSxSdLszlXP7aToST9M59KeD AN4jifTxKiPBWaUHyAjR/vgKieIelNkFUcBckdLyNP+iIgpaVyr3704f7f726m/1pXwP YyXC58q5XwtQeBgC96xFwRfXrVhXFJ4R+ihC+WmNrrng2DfXs+fRDprFYkENaq5ooISD QKlA==
X-Gm-Message-State: ALoCoQle7TP43mKFzum/jT5ceq3ZcfV1D5LcZgQeuMKV0OzV7YXPC2y5hwRz0WzzCt/GfZzvrIC7
X-Received: by 10.220.102.20 with SMTP id e20mr2795076vco.12.1419002734606; Fri, 19 Dec 2014 07:25:34 -0800 (PST)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com. [209.85.220.175]) by mx.google.com with ESMTPSA id oh11sm1731279vdb.9.2014.12.19.07.25.33 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 07:25:33 -0800 (PST)
Received: by mail-vc0-f175.google.com with SMTP id hy10so393576vcb.34 for <rtcweb@ietf.org>; Fri, 19 Dec 2014 07:25:33 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.220.205.2 with SMTP id fo2mr2785319vcb.8.1419002733481; Fri, 19 Dec 2014 07:25:33 -0800 (PST)
Received: by 10.52.54.194 with HTTP; Fri, 19 Dec 2014 07:25:33 -0800 (PST)
In-Reply-To: <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> <9F33F40F6F2CD847824537F3C4E37DDF1E645DA3@MCHP04MSX.global-ad.net>
Date: Fri, 19 Dec 2014 10:25:33 -0500
Message-ID: <CAHbrMsCG6PxfCZTeXv9guOvWmV=Miqg1O6p6LgXOdSyneoKqTw@mail.gmail.com>
From: Benjamin Schwartz <bemasc@webrtc.org>
To: "Hutton, Andrew" <andrew.hutton@unify.com>
Content-Type: multipart/alternative; boundary=001a11c3dfd0dd6930050a9351aa
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/B9h2vvNeQ0dFPWeYO9fY7f-8BP4
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: Fri, 19 Dec 2014 15:25:39 -0000

To reiterate, the TRAM draft doesn't specify what WebRTC should actually do
with the discovered TURN server(s).  RETURN (
https://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/) attempts to
fill in the details, and also resolve questions about priority of different
settings, etc.

Comments on the RETURN draft are appreciated, of couse.

On Fri, Dec 19, 2014 at 5:15 AM, Hutton, Andrew <andrew.hutton@unify.com>
wrote:

> +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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>