Re: [pntaw] New version of TURN over websockets draft

"Yanqiang (Michael)" <michael.yan@huawei.com> Fri, 13 September 2013 09:29 UTC

Return-Path: <michael.yan@huawei.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2030611E817A for <pntaw@ietfa.amsl.com>; Fri, 13 Sep 2013 02:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t10PmHiQbMu5 for <pntaw@ietfa.amsl.com>; Fri, 13 Sep 2013 02:29:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D999611E8187 for <pntaw@ietf.org>; Fri, 13 Sep 2013 02:29:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ21674; Fri, 13 Sep 2013 09:29:34 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 10:29:11 +0100
Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 10:29:10 +0100
Received: from szxeml561-mbx.china.huawei.com ([169.254.5.162]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.007; Fri, 13 Sep 2013 17:29:01 +0800
From: "Yanqiang (Michael)" <michael.yan@huawei.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "pntaw@ietf.org" <pntaw@ietf.org>
Thread-Topic: [pntaw] New version of TURN over websockets draft
Thread-Index: AQHOsFSWr3i0fcJEpkONnJOMzf1ehZnDTijQ
Date: Fri, 13 Sep 2013 09:29:00 +0000
Message-ID: <21794EB0EE82B0458A524942A141542B313B6150@szxeml561-mbx.china.huawei.com>
References: <5232C18C.1030102@gmail.com>
In-Reply-To: <5232C18C.1030102@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.166.98.146]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Oleg Moskalenko <mom040267@gmail.com>, Victor Pascual Avila <victor.pascual.avila@gmail.com>, Lorenzo Miniero <lorenzo@meetecho.com>, "Chenxin \(Xin\)" <hangzhou.chenxin@huawei.com>
Subject: Re: [pntaw] New version of TURN over websockets draft
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 13 Sep 2013 09:29:43 -0000

Hi All,

	I read the revised draft again. For I'm not so familiar with RFC 6455. So just share some of my comments:

1. has an explicit requirement to allow such peers to use some kind of fallback communication in HTTP-only networks, as specified in [I-D.ietf-rtcweb-use-cases-and-requirements](F37).
  Is it better to use 'HTTP(s)-only networks'?

2. the involved WebSocket server have to relay the application data to each other by either UDP, TCP or other existing ways
  Since 3.2 has mentioned the connection between TURN/WebSocket servers could by UDP, TCP or other ways, should the Figure 2 change to 'UDP/TCP/Others' or 'UDP/TCP/...'?

3. The WebSocket messages transmitted over this connection MUST conform to the negotiated WebSocket sub-protocol.
  Should we restrict the 80/443 port only run websocket once the handshake or negotiation finish? Or there are other better ways? I thought other people in NAT network can still use 80 port to explore internet. (maybe I made some mistake here.)

	The 1st time I started to work with Xin about this idea was original from Lorenzo's HTTP fallback proposal and rtcweb requirement F37. We thought HTPP fallback proposal *still* need to work on many new parameters for mechanism suggested (chunked or non-chunked mode). At that time someone had propose several documents about 'over websocket'. So we tried to assume the media stream of webrtc application can traverse the restricted networking via websocket as well. There were several points we thought:

1. What's the usage or motivation of this mechanism? Except the networking restricting area(prisons, hotels, airports) is there any better case?
2. Will it be better or easier to use TURN over WS/WSS than TURN over TCP/TLS? Or it is an alternative choice?
3. Will the combo 'TURN+HTTP(s) Port+WebSocket' works well and easily deploying?

	Are they handled well now?

Thanks,
Michael

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf Of
> Sergio Garcia Murillo
> Sent: Friday, September 13, 2013 3:41 PM
> To: pntaw@ietf.org
> Cc: Oleg Moskalenko; Victor Pascual Avila; Lorenzo Miniero; Chenxin (Xin)
> Subject: [pntaw] New version of TURN over websockets draft
> 
> Hi all
> 
> We have been working on a new version of the TURN over Websocket draft
> originally proposed by Xin, which is now available at:
> 
> http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-01.txt
> 
> We believe that it is very well aligned with the spirit of
> draft-hutton-rtcweb-nat-firewall-considerations and should be considered
> to be endorsed by WebRTC.
> 
> Also, in order to address the concerns about the impact on TURN servers
> we will be working in providing a working prototype over the following
> weeks by adding a preliminary support of TURN over websockets into the
> rfc5766-turn-server.
> 
> Any kind of feedback would be very welcome.
> 
> Best regards
> Sergio
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw