IETF Logo Mail Archive

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

Justin Uberti <juberti@google.com> Wed, 17 December 2014 00:56 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 330821A1A1D for <rtcweb@ietfa.amsl.com>; Tue, 16 Dec 2014 16:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.088
X-Spam-Level:
X-Spam-Status: No, score=-1.088 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, MIME_8BIT_HEADER=0.3, 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 1TeGln3ykjHg for <rtcweb@ietfa.amsl.com>; Tue, 16 Dec 2014 16:56:35 -0800 (PST)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBC61A1A1B for <rtcweb@ietf.org>; Tue, 16 Dec 2014 16:56:35 -0800 (PST)
Received: by mail-vc0-f171.google.com with SMTP id hy4so6844155vcb.16 for <rtcweb@ietf.org>; Tue, 16 Dec 2014 16:56:34 -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=yCaYOltv5IY6n4spceedRJlsFFpVlVxwHC+62LaMF7Y=; b=kaR6kun4BPUTcamJPBiuhJowHVzct2xbuNrIqLDGa9woZDUwZKZvzvlawm/ecxOdQo 8aGf0TZMWdo8gZOwlnE8v4vy3ukuPWt2NVkFUkSAULmGRyFRkpYvHNFzIpRNM05cE87x e16WX7VWwu98F3mBnr2UVEiB29Rd8++hsxjA3IfHlg/DhYvgC4SOgHFLtO1+o5UmgzsF jnYQpjPhp0USl83f7+SDbpAIvlNBkcYTvO2jAKQ9/QE7QIsD5guFP+AIAI6MWi7CvXUX rb0nuO2MW/S/hNRLwraaBToMO/W3YUTKAt33FxIywLgYW9//wx+zIGqY4wuSpEjQV3Oq CGfw==
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=yCaYOltv5IY6n4spceedRJlsFFpVlVxwHC+62LaMF7Y=; b=aYMqjMzXhuY/AlTudddXnqrZQra9m9Hv7a/Vn+C6cqyUjSPmE1FuAH7vWRZ3ktHAeE 7B8hZaUUwR6hquQToiwA9mtbXBUB95E27oW1ozoKSITbUodrFQYjwwKZKyEON/4vtmWq Mpj5CbB7BDhelykIuSj2COkwEufjRnkTZ5HXZrXgLQYnBMzF8DLFHpCNpMsa1YEUZa0E hX79J6k0vtHPOxXTp/5SPdTx8+AoHFfYNK6lxNztEqZZHxSXnXh5UJRc6cOInIeHgK9w 3Eey6OwSGPH71giDLAqZdAlVQqqwSmcktfaQZ1OkcsRwGqgs/ORw+u7UzHQsQYxpSW+w kykg==
X-Gm-Message-State: ALoCoQmkjODZy0I3rgCqdObBcSYKKRAXvYEmd0IurnpfFpfgMglV1y8LtfOjg2j2042nKmEFnJnY
X-Received: by 10.220.178.3 with SMTP id bk3mr16625503vcb.16.1418777794177; Tue, 16 Dec 2014 16:56:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.10.229 with HTTP; Tue, 16 Dec 2014 16:56:13 -0800 (PST)
In-Reply-To: <DA5613E8-DAAB-41DC-9A16-4C3D567A607B@cisco.com>
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> <FAA9B38F-1AB8-4E2C-AB02-2525402B4890@cisco.com> <CAOJ7v-3xxVa05kA0SYVYQO324AwLWGUo8f_u534fN_-De0AV4A@mail.gmail.com> <DA5613E8-DAAB-41DC-9A16-4C3D567A607B@cisco.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 16 Dec 2014 16:56:13 -0800
Message-ID: <CAOJ7v-0ZJt9ykV66A4dbttJ5HVhANW29cG+bbjvdmtvwEmS--g@mail.gmail.com>
To: 🔓Dan Wing <dwing@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c1d370700eb4050a5ef26d"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PFaSXvddNJXJ5jE87bnLxoxDun0
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: Wed, 17 Dec 2014 00:56:40 -0000

Seems like something that should go into -transports (i.e. that WebRTC
clients SHOULD obtain a srflx address from the TURN server, in addition to
any provided STUN servers).

On Tue, Dec 16, 2014 at 11:16 AM, 🔓Dan Wing <dwing@cisco.com> wrote:
>
>
> On Dec 16, 2014, at 9:40 AM, Justin Uberti <juberti@google.com> wrote:
>
> Given that TURN servers can be used for STUN, is there a need to
> autodiscover STUN-only servers?
>
>
> I am not aware of spec encouraging such implementations, and I don't know
> if everyone implementing WebRTC clients is going to be aware that TURN
> servers can provide useful information about the mapped IP address.
> Perhaps it just needs a few sentences in an appropriate spec?
>
> -d
>
>
>
> On Mon, Dec 15, 2014 at 5:23 PM, 🔓Dan Wing <dwing@cisco.com> wrote:
>>
>>
>> On Dec 15, 2014, at 7:56 AM, Hutton, Andrew <andrew.hutton@unify.com>
>> wrote:
>>
>> +1 Also wondering why it is not appropriate?
>>
>> F20 in the requirements draft states:
>>
>> F20     The browser must support the use of STUN and TURN
>>            servers that are supplied by entities other than
>>            the web application (i.e. the network provider).
>>
>> So I was thinking the need for specifying the discovery method would not
>> be controversial.
>>
>>
>> Note that draft-ietf-tram-turn-server-discovery only discovers TURN
>> servers.  If we need to discover STUN servers, too -- and I think we do --
>> we need that document to expand its scope or a second document.
>>
>> I recently attended a talk where Matt Peterson presented Burning Man's
>> network.  That network assigns RFC6598 addresses to each Burning Man
>> "camp", and their ISP provides CGN'd addresses to Burning Man.  Each camp
>> operates its own WiFi network, and we can all reasonably assume they are
>> using typical consumer or SMB NAPT devices for those networks (e.g.,
>> D-Link, Linksys, Ubiquity, etc.).  To avoid tromboning camp-to-camp WebRTC
>> traffic to their ISP's CGN, they would benefit from a STUN and a TURN
>> server within the Burning Man network.  His presentation can be found at
>> https://www.nanog.org/meetings/nanog62/agenda (PDF and video).
>>
>> -d
>>
>>
>>
>> Andy
>>
>>
>> *From:* Simon Perreault [mailto:sperreault@jive.com <sperreault@jive.com>
>> ]
>> *Sent:* 15 December 2014 15:49
>> *To:* Eric Rescorla
>> *Cc:* Hutton, Andrew; rtcweb@ietf.org
>> *Subject:* Re: [rtcweb] rtcweb-transports reference to TRAM discovery
>>
>>
>> On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> I do not believe that this is an appropriate requirement
>>
>> Care to say why?
>>
>> Thanks,
>> Simon
>> _______________________________________________
>> 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
>>
>>
>

v2.23.0 | Report a Bug | By Email