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

+1

Emil

On Tue, 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
>


-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31