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

🔓Dan Wing <dwing@cisco.com> Tue, 16 December 2014 01:23 UTC

Return-Path: <dwing@cisco.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 EEC801A016B for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 17:23:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.21
X-Spam-Level:
X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 gA3NSGK4sHVB for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 17:23:51 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB801A0140 for <rtcweb@ietf.org>; Mon, 15 Dec 2014 17:23:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11077; q=dns/txt; s=iport; t=1418693031; x=1419902631; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=pMjU8hwSrkbHcuP8lbVrYAbxmIQENY6oFPZN5XEW+oQ=; b=AUgdNC6V75RiThquCV6KXPYkD2Egm2/s5BpFGk1kBhz/PoSD/rIcjtPY ERmJQkIXt+8TtUxthVbxXV4ZNlsIG94dRhBaZp53GySjES4UcZbLVbQWo iVq1XIQaFRcGnkIrEhsWMxSYFsLzmTAyHEJTMXx7CWD94GbNilRRhyjAI U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoYFANiIj1StJA2E/2dsb2JhbABagkNDUljFYAEJhShKAoEiFgEBAQEBfYQMAQEBAwEBAQFrCxALEQQBAQEnBycfCQgGE4gkCA3UcgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj24EBgGDFoETBYk+jTOFeYs+IoQNHTCCQwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,583,1413244800"; d="scan'208,217";a="106015524"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 16 Dec 2014 01:23:50 +0000
Received: from [10.24.106.80] ([10.24.106.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sBG1Ni9T029555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Dec 2014 01:23:48 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_897224CE-BC1B-4802-89FD-FD167644F9C3"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= <dwing@cisco.com>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net>
Date: Mon, 15 Dec 2014 17:23:43 -0800
Message-Id: <FAA9B38F-1AB8-4E2C-AB02-2525402B4890@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>
To: "Hutton, Andrew" <andrew.hutton@unify.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ERAYWnTdj7iJBM33PFZHEyaG29Y
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: Tue, 16 Dec 2014 01:23:54 -0000

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] 
> 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