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

+1 a must have to be able doing any serious business with webrtc..

El 27/08/2013 16:34, Victor Pascual escribió:
> I agree
>
> -Victor
>
> On Aug 27, 2013, at 2:53 PM, <Markus.Isomaki@nokia.com 
> <mailto: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> 
>> [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *ext Bernard Aboba
>> *Sent:* 21 August, 2013 00:44
>> *To:* Hutton, Andrew; rtcweb@ietf.org <mailto: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 <mailto:rtcweb@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb