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

I agree

-Victor

On Aug 27, 2013, at 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.  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
> > To: rtcweb@ietf.org; 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