Re: [pntaw] I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt
"Chenxin (Xin)" <hangzhou.chenxin@huawei.com> Wed, 22 January 2014 12:03 UTC
Return-Path: <hangzhou.chenxin@huawei.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DBD1A043E for <pntaw@ietfa.amsl.com>; Wed, 22 Jan 2014 04:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwKJNfcD6J2O for <pntaw@ietfa.amsl.com>; Wed, 22 Jan 2014 04:03:35 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 992931A043D for <pntaw@ietf.org>; Wed, 22 Jan 2014 04:03:34 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAH50356; Wed, 22 Jan 2014 12:03:33 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 12:03:20 +0000
Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 12:03:32 +0000
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.191]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 20:03:25 +0800
From: "Chenxin (Xin)" <hangzhou.chenxin@huawei.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>, "pntaw@ietf.org" <pntaw@ietf.org>
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: <9E34D50A21D1D1489134B4D770CE0397680AA8CE@SZXEMA504-MBX.china.huawei.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17CBE35E@MCHP04MSX.global-ad.net> <9E34D50A21D1D1489134B4D770CE0397680AA8A5@SZXEMA504-MBX.china.huawei.com>
In-Reply-To: <9E34D50A21D1D1489134B4D770CE0397680AA8A5@SZXEMA504-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.17.195]
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-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw/>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=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, Xin >-----Original Message----- >From: pntaw [mailto:pntaw-bounces@ietf.org] On Behalf Of Chenxin (Xin) >Sent: Wednesday, January 22, 2014 7:48 PM >To: Hutton, Andrew; pntaw@ietf.org >Subject: Re: [pntaw] I-D Action: >draft-hutton-rtcweb-nat-firewall-considerations-03.txt > >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:pntaw-bounces@ietf.org] On Behalf Of Hutton, Andrew >>Sent: Monday, January 20, 2014 8:10 PM >>To: pntaw@ietf.org >>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:i-d-announce-bounces@ietf.org] On Behalf Of >>internet-drafts@ietf.org >>Sent: 20 January 2014 11:35 >>To: i-d-announce@ietf.org >>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-consideratio >ns >>/ >> >>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-consideratio >ns >>-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 >>I-D-Announce@ietf.org >>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 >>pntaw@ietf.org >>https://www.ietf.org/mailman/listinfo/pntaw >_______________________________________________ >pntaw mailing list >pntaw@ietf.org >https://www.ietf.org/mailman/listinfo/pntaw
- [pntaw] FW: I-D Action: draft-hutton-rtcweb-nat-f… Hutton, Andrew
- Re: [pntaw] I-D Action: draft-hutton-rtcweb-nat-f… Hutton, Andrew
- Re: [pntaw] I-D Action: draft-hutton-rtcweb-nat-f… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-n… Oleg Moskalenko
- Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-n… Hutton, Andrew
- Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-n… Harald Alvestrand
- Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-n… Simon Perreault
- Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-n… Oleg Moskalenko
- Re: [pntaw] I-D Action: draft-hutton-rtcweb-nat-f… Chenxin (Xin)
- Re: [pntaw] I-D Action: draft-hutton-rtcweb-nat-f… Chenxin (Xin)