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

"Chenxin (Xin)" <> Wed, 22 January 2014 12:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E0DBD1A043E for <>; Wed, 22 Jan 2014 04:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FwKJNfcD6J2O for <>; Wed, 22 Jan 2014 04:03:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 992931A043D for <>; Wed, 22 Jan 2014 04:03:34 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BAH50356; Wed, 22 Jan 2014 12:03:33 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 22 Jan 2014 12:03:20 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 22 Jan 2014 12:03:32 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 20:03:25 +0800
From: "Chenxin (Xin)" <>
To: "Hutton, Andrew" <>, "" <>
Thread-Topic: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt
Thread-Index: AQHPFdOd2Vn6yFd4yUSx85JgARaXd5qNhEhAgAMSnnCAABDIoA==
Date: Wed, 22 Jan 2014 12:03:24 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [pntaw] I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jan 2014 12:03:37 -0000

Besides , I support that this draft should be considered to be accepted by rtcweb-transport documents too.

Best Regards,

>-----Original Message-----
>From: pntaw [] On Behalf Of Chenxin (Xin)
>Sent: Wednesday, January 22, 2014 7:48 PM
>To: Hutton, Andrew;
>Subject: Re: [pntaw] I-D Action:
>   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 [] On Behalf Of Hutton, Andrew
>>Sent: Monday, January 20, 2014 8:10 PM
>>Subject: [pntaw] FW: I-D Action:
>>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
>>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.
>>-----Original Message-----
>>From: I-D-Announce [] On Behalf Of
>>Sent: 20 January 2014 11:35
>>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
>>   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:
>>There's also a htmlized version available at:
>>A diff from the previous version is available at:
>>Please note that it may take a couple of minutes from the time of submission
>>until the htmlized version and diff are available at
>>Internet-Drafts are also available by anonymous FTP at:
>>I-D-Announce mailing list
>>Internet-Draft directories:
>>pntaw mailing list
>pntaw mailing list