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

Agree that enterprises need this plus a few other TURN extensions. 

I support adoption as WG draft. 

- Alan -

On Aug 27, 2013, at 9:52 AM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:

> +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.  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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb