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

Another +1.

Mary.

On Tue, Aug 27, 2013 at 7:53 AM, <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
> > 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-01assuming we can get this adopted.
> >
> > Regards
> > Andy****
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>