Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

[Bernard Aboba <[e-mail]>]

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: [e-mail]
> To: [e-mail]; [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