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

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