Re: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-rtcweb-transports-00.txt)

+1


On 8/27/13 2:53 PM, Markus.Isomaki@nokia.com wrote:
>
> Hi,
>
> I would support the adoption of the NAT and Firewall considerations 
> (http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01) 
> as a WG document. Or to be more precise, I very much agree with the 
> requirements summarized in Section 5. Especially this one seems 
> important to me:
>
> o  connect to a TURN server via a HTTP proxy using the HTTP connect
>        method,
>
> If we want WebRTC to work from many corporate networks I'm aware of, 
> it would not be possible without this as a fallback capability.
>
> Markus
>
> *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On 
> Behalf Of *ext Bernard Aboba
> *Sent:* 21 August, 2013 00:44
> *To:* Hutton, Andrew; rtcweb@ietf.org; Harald Alvestrand
> *Subject:* Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
>
> The NAT/Firewall considerations document does go into detail on the 
> various traversal scenarios, which helps inform the discussion of what 
> should or should not be supported in terms of transport.  Section 5 
> summarizes the recommendations as follows:
>
>
>     5
>     <http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01#section-5>.
>     Requirements for RTCWEB-enabled browsers
>
>   
>   
>     For the purpose of relaying RTCWEB media streams or data channels a
>     browser needs to be able to
>   
>     o  connect to a TURN server via UDP, TCP and TLS,
>   
>     o  connect to a TURN server via a HTTP proxy using the HTTP connect
>        method,
>   
>     o  connect to a TURN server via the HTTP(s) ports 80/443 instead of
>        the default STUN ports 3478/5349,
>   
>     o  upgrade the HTTP proxy-relayed connection to the TURN server to
>        use TLS,
>   
>     o  use the same proxy selection procedure for TURN as currently done
>        for HTTP,
>   
>     o  switch the usage of the HTTP proxy-relayed connection with the
>        TURN server from HTTP to STUN/TURN,
>   
>     o  use a preconfigured or standardized port range for UDP-based media
>        streams or data channels,
>   
>     o  learn from the proxy configuration script about the presence of a
>        local TURN server and use it for sending UDP traffic to the
>        internet,
>   
>     o  support ICE-TCP for TCP-based direct media connection to the
>        RTCWEB peer.
>
> > From: andrew.hutton@siemens-enterprise.com 
> <mailto:andrew.hutton@siemens-enterprise.com>
> > To: rtcweb@ietf.org <mailto:rtcweb@ietf.org>; harald@alvestrand.no 
> <mailto:harald@alvestrand.no>
> > Date: Tue, 20 Aug 2013 16:31:28 +0000
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
> >
> > Section 2.2 "Middle Box Related Functions" should also I assume 
> cover the case of using a HTTP Proxy or an enterprise TURN server and 
> reference 
> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01 
> assuming we can get this adopted.
> >
> > Regards
> > Andy
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb