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

Justin Uberti <juberti@google.com> Thu, 08 January 2015 04:15 UTC

Return-Path: <juberti@google.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 0016D1A8852 for <rtcweb@ietfa.amsl.com>; Wed, 7 Jan 2015 20:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 UzMtkzy7IOnH for <rtcweb@ietfa.amsl.com>; Wed, 7 Jan 2015 20:15:32 -0800 (PST)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461941A8843 for <rtcweb@ietf.org>; Wed, 7 Jan 2015 20:15:32 -0800 (PST)
Received: by mail-vc0-f180.google.com with SMTP id im6so406267vcb.11 for <rtcweb@ietf.org>; Wed, 07 Jan 2015 20:15:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H3nxo1JAwj2L+7Q74Qf10Zwc6dqkJOTgRla0UoNhbfE=; b=OQ84ePiLv2f5B5JvtD1fQW31FcX2tXj76HR7UTpYxtvgeoA/2uHaiHJK3xRima10+n ji6WGg0jCDlG/7IjKMSRNNqnJkIVNnmferHgGtyfNr56DbCRagINjoVzL25AEkXtYGcf ssyYViKYf8wclR6enLOZN71azwGFwE5bYVdpMhQJt3uUrwvJyNL38NnbX3UAEPOHk4t4 4AimKtIapbK+nsTrh6etSuzj0JeLmvnujE0etUHlIhhiKUqOFNwGjEdu64S/pkJLiaHG XDQOQ/1qrHiTfzmuWYHnDpfpZtYIqopEXt9r4KRXE8SbkW23ARRZuzoo/4ZiQWUbLPG3 Jiuw==
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:from:date :message-id:subject:to:cc:content-type; bh=H3nxo1JAwj2L+7Q74Qf10Zwc6dqkJOTgRla0UoNhbfE=; b=UXtZ0UxlXXNMNngipFUUwDG7RlrsaLvSHNR6odv+022TDP8D8v1gqtXAKNgX0zdWPr K/CSRHZKVwlJ6YhohviEcKEL+lMBtr4GEnLTaz8fpDDdCRrTdpzOmTmFI+ZHQnkvhFbi R/Q/lj0Jr/G6zIqtUqVhtXhwcQKSCMquTkv0d7NrxoF8Jj5tEnP1F3i6GG0IPu6IMwfT Eo4qajIeIQu2bwta8cTKSNItJxZqn9C/oi9ymEnNLgoDvYxQmwToprqjMtcWV4ICmV9G yOP8Nv7CPPRN3UvNKnRcr0z1jnwqzRzHv0hdixEkpwVOn58HOU4lnvgAVEWKEFkn5N0Q hQoQ==
X-Gm-Message-State: ALoCoQnmczfsh2E3/0NwE6XjcFC1j7yebfFUWY9fOyp5Blv3HRkwctvENSvHYzTHPB2Q84+mnWcO
X-Received: by 10.220.250.198 with SMTP id mp6mr5521982vcb.19.1420690531424; Wed, 07 Jan 2015 20:15:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.111.232 with HTTP; Wed, 7 Jan 2015 20:15:11 -0800 (PST)
In-Reply-To: <E1B969F2-318A-4514-8899-44D595F63F30@mnot.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <CABcZeBOpX0vM9NJeKY5e+S13oKrLW3Td53qcxRkCHa2=nv=EGg@mail.gmail.com> <CANO7kWBY1MTU1A2fWo0E5Y6TQ1o+vWSz22pnWz6+5s7SFQcP-g@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> <CAOJ7v-1NnS1QOF-Ujv7a=qCnXrQ0htd0b4TFUDaKgwik9Rd=-Q@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF1E643D2C@MCHP04MSX.global-ad.net> <5491B831.70704@alvestrand.no> <F1DDC0E1-8B87-45D9-ACDD-7A53F34A79E2@cisco.com> <E1B969F2-318A-4514-8899-44D595F63F30@mnot.net>
From: Justin Uberti <juberti@google.com>
Date: Wed, 7 Jan 2015 20:15:11 -0800
Message-ID: <CAOJ7v-0Tu_xc6fdETnnN7y87jho538c8O23aP6VfJbYq1kJAaw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/alternative; boundary=089e013cb9927640c9050c1c4ac0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yNl6RGtw4RYDZQLvV52WITnhqpc
Cc: RTCWEB <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, 08 Jan 2015 04:15:35 -0000

The actual requirement (as indicated in S 3.3.5.1 of
https://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-15#page-8)
is for an enterprise to be able to force the use of a enterprise-controlled
TURN server. Here, enterprise policy surely can allow for all traffic to be
forced through said TURN server, just as it can be done for HTTP/HTTPS
proxies today.

I agree that the ISP TURN server case is different, and merits additional
discussion. So while we can argue about exactly how autodiscovery should
work (e.g. .pac or
https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00), we
should be able to agree on how things should work once a local TURN server
is found (i.e. https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04
).

This would allow the above scenario to be satisfied when the TURN proxy
configuration is set through enterprise policy, and would be a substantial
improvement over the current state of affairs (e.g. where many enterprises
force all WebRTC traffic to TCP or through a HTTPS proxy)


On Wed, Dec 24, 2014 at 1:54 PM, Mark Nottingham <mnot@mnot.net> wrote:

> I’d say that there’s some level of implementer interest in standardising /
> documenting proxy.pac, but — so far — inadequate resources; I don’t see
> *any* interest in WPAD standardization, as it’s viewed as actively bad.
>
> Regards,
>
>
> > On 17 Dec 2014, at 4:58 pm, 🔓Dan Wing <dwing@cisco.com> wrote:
> >
> > On Dec 17, 2014, at 9:06 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
> >
> >> On 12/17/2014 05:19 PM, Hutton, Andrew wrote:
> >>> OP: 15 December 2014 22:44 Justin Uberti Wrote:
> >>>> I think making it a requirement is probably premature until we have a
> >>>> WG document that explains what should happen when you discover one of
> >>>> these network-provided TURN servers.
> >>>> Once https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 is
> >>>> accepted as a WG doc, we can add a requirement for support for RETURN
> >>>> and server discovery.
> >>>>
> >>>> Unclear whether it needs to be MUST-strength until we get some
> >>>> implementation feedback though.
> >>>>
> >>> -transports already states " WebRTC browsers MUST support
> configuration of STUN and TURN servers, both from browser configuration and
> from an application".
> >>>
> >>> So it looks like we already have a requirement but no explanation of
> what should happen when both are available.
> >>
> >> The last times we've talked about this, people have imagined
> configuring this via the same mechanism as configuring HTTP proxies
> (nonstandard script at a nonstandard URL).
> >>
> >> Autodiscovery may be preferable, but it's not clear that it removes the
> need for the script-like things.
> >
> > If there is, gathering that requirement seems important.  Mark
> Nottingham was beginning an effort around WPAD standardization (or
> something that resembled it).  CC'ing him in case there is useful status on
> that front.
> >
> > -d
> >
> >
> >>
> >>>
> >>> Looks like we need to adopt draft-schwartz-rtcweb-return and explain
> this stuff. I would certainly support that and put some effort into getting
> this done.
> >>>
> >>> 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
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>