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

["Avasarala, Ranjit (NSN - IN/Bangalore)" <[e-mail]>]

I too agree that this functionality is required for enterprises where devices could be behind NAT. But in IMS we may not need as UEs are globally reachable.

Regards
Ranjit
Sent from Nokia Lumia
________________________________
From: ext [e-mail]<mailto:[e-mail]>
Sent: ‎27-‎08-‎2013 18:23
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-rtcweb-transports-00.txt)

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: [e-mail] [mailto:[e-mail]] On Behalf Of ext Bernard Aboba
Sent: 21 August, 2013 00:44
To: Hutton, Andrew; [e-mail]; 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: [e-mail]<mailto:[e-mail]>
> To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> 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