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

Suhas Nandakumar <suhasietf@gmail.com> Fri, 19 December 2014 16:58 UTC

Return-Path: <suhasietf@gmail.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 A94AB1A89A0 for <rtcweb@ietfa.amsl.com>; Fri, 19 Dec 2014 08:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 rxk6fX2UpZpm for <rtcweb@ietfa.amsl.com>; Fri, 19 Dec 2014 08:58:20 -0800 (PST)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2FD1A88EF for <rtcweb@ietf.org>; Fri, 19 Dec 2014 08:58:20 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id et14so1561564pad.3 for <rtcweb@ietf.org>; Fri, 19 Dec 2014 08:58:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wqvKCxouxkNoSLmnq3JpDGe8ozOkI/i9M5LsP4DczgY=; b=uclj5f3mHX0vEwvLgprkwci3aRX0iT/iVzrwV6suFGxIfJGYr1KzqMMXbq5+rxWlD0 yQpydWmtHk9ikDRwLRiXnFeSfkVk+CQ9xDo7dgydvS4nRfw26QTTmfHsUbe5bWJq0uoh eniLbhUC2tJdRYvRqHPhy2fEIeycejj5bIAjVEeivZ/EFlgfnvvrCIjfHRB4RfJo2gNK dUtFk5wW1BbbWH7BA/1Iku6HkCh5cT1CjLzkcTsXLAQqzrbUdbrcKLrhPqgbbGTQLE4x 5AyDRyLVPtmLtHiLsiikls0hjj/+uvWVLaWKwLV+GOlkkim+x3Hsifg9thDZHct0sp9E H2nA==
MIME-Version: 1.0
X-Received: by 10.68.167.36 with SMTP id zl4mr13806209pbb.83.1419008299349; Fri, 19 Dec 2014 08:58:19 -0800 (PST)
Received: by 10.70.60.201 with HTTP; Fri, 19 Dec 2014 08:58:19 -0800 (PST)
In-Reply-To: <CAHbrMsCG6PxfCZTeXv9guOvWmV=Miqg1O6p6LgXOdSyneoKqTw@mail.gmail.com>
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> <CAHbrMsCG6PxfCZTeXv9guOvWmV=Miqg1O6p6LgXOdSyneoKqTw@mail.gmail.com>
Date: Fri, 19 Dec 2014 22:28:19 +0530
Message-ID: <CAMRcRGSpzNLn-PW+i9PYwfznv6fW_CpS6Ubf3c9Xqwdzh6xrmg@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Benjamin Schwartz <bemasc@webrtc.org>
Content-Type: multipart/alternative; boundary=047d7bd6c74e9dbcc1050a949d39
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ekHt89v3ITovcdWMy5C7ZZHwTJc
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 16:58:24 -0000

Few cents ..

I tend to agree with Cullen's sentiment since as a end user I don't want to
end up with service provider lock-in when using a TURN server.

Such lock-ins might not be a bad option but It need not be enforced by
design.

OTOH  I am not sure how effective will be a typical not-so-technical
end-user's decision making in choosing one turn server over the other.

But having flexibility is not a bad idea , thus i feel the spec needs to
just say the plausible options but mandating with MUST might not be what we
need here.



Cheers
Suhas


On Fri, Dec 19, 2014 at 8:55 PM, Benjamin Schwartz <bemasc@webrtc.org>
wrote:

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