Re: [pntaw] I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt

["Chenxin (Xin)" <[e-mail]>]

Hi,

   I have a question on the this draft:

  1. Section 2.3. NAT/Firewall open only for TCP on restricted ports

       In this case the firewall blocks all outgoing traffic except for TCP
   traffic to specific ports, for example port 80 (HTTP) for HTTP or 443
   for HTTPS(HTTPS).  A TURN server listening to its default ports (3478
   for TCP/UDP, 5349 for TLS) would not be reachable in this case.
   However, the TURN server can still be reached when it is configured
   to listen to e.g. the HTTP(S) ports.

   If It is possible that, NAT/Firewall forbid none-http data on 80/443, which will make the client failed to connect to turn server.

   I want there could be a discussion on that scenario --
      ' NAT/Firewall open only for http packet on restricted ports without the presence of http proxy'
   Is such kind of scene common and valuable to webrtc application?  Need we consider such nat/fw case and requirement? should we handle this now or consider it as a future research.
　 I think this mailing list is the right place to discuss it.


  2. Section 3.3
     All scenarios besides this have a solution to make webrtc application successful. I still think recommend solution should be added. In my opinion, http connection, alpn, turn over websocket are candidates. 

  3. Requirements for RTCWEB-enabled browsers

    " support a mechanism for connecting to a TURN server in the
      presence of a firewall that only permits connections that orginate
      from a HTTP Proxy.  The mechanism is for further study."

     Why a future study mechanism becomes a requirement?  for section 3.3?

    "use the same proxy selection procedure for TURN as currently done
      for HTTP (e.g. Web Proxy Autodiscovery Protocol (WPAD) and .pac-
      files for Proxy-Auto-Config)"

      I do not understand  why you put this requirement in the draft. Which scenario is it relared to?

   4. confusion about the discussion on pntaw?

     I think the pntaw is established for rtcweb transport areas. However, Because of no chairs, there were many discussion but no decision. I do not know if rtcweb agenda have considered the discussion in pntaw, at least I did not see it in IETF88. I still think there should be a way to conclude and make decision on related topics on pntaw. I suggest chairs could leave some time slot for pntaw topics in IETF89, or other ways. After all, pntaw is a sub-list of rtcweb. 


Best Regards,
     Xin 


>-----Original Message-----
>From: pntaw [mailto:[e-mail]] On Behalf Of Hutton, Andrew
>Sent: Monday, January 20, 2014 8:10 PM
>To: [e-mail]
>Subject: [pntaw] FW: I-D Action:
>draft-hutton-rtcweb-nat-firewall-considerations-03.txt
>
>I updated draft-hutton-rtcweb-nat-firewall-consideration.
>
>The main change is that the draft now explores the different options that are
>available for handling such things as HTTP Proxies in a WebRTC environment and
>no longer recommends a specific solution.
>
>Would be good to restart the discussion on these options and determining the
>best way forward to ensuring we get some defined standardized behavior for
>WebRTC for these scenarios.
>
>So please go ahead and make comments.
>
>Regards
>Andy
>
>
>
>-----Original Message-----
>From: I-D-Announce [mailto:[e-mail]] On Behalf Of
>[e-mail]
>Sent: 20 January 2014 11:35
>To: [e-mail]
>Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>        Title           : RTCWEB Considerations for NATs, Firewalls and
>HTTP proxies
>        Authors         : Thomas Stach
>                          Andrew Hutton
>                          Justin Uberti
>	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-03.txt
>	Pages           : 14
>	Date            : 2014-01-20
>
>Abstract:
>   This document describes mechanism to enable media stream
>   establishment for Real-Time Communication in WEB-browsers (WebRTC) in
>   the presence of network address translators, firewalls and HTTP
>   proxies.  HTTP proxy and firewall deployed in many private network
>   domains introduce obstacles to the successful establishment of media
>   stream via WebRTC.  This document examines some of these deployment
>   scenarios and specifies requirements on WebRTC enabled web browsers
>   designed to provide the best possible chance of media connectivity
>   between WebRTC peers.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-considerations
>/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-hutton-rtcweb-nat-firewall-considerations
>-03
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>I-D-Announce mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>_______________________________________________
>pntaw mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pntaw