Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt

"Chenxin (Xin)" <hangzhou.chenxin@huawei.com> Sat, 14 September 2013 08:53 UTC

Return-Path: <hangzhou.chenxin@huawei.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9269321F9DDE; Sat, 14 Sep 2013 01:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 EVPLBMFQ8-Tj; Sat, 14 Sep 2013 01:53:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BF5DC21F9DDB; Sat, 14 Sep 2013 01:53:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXU05003; Sat, 14 Sep 2013 08:53:33 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 09:53:13 +0100
Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 09:53:29 +0100
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0146.000; Sat, 14 Sep 2013 16:53:22 +0800
From: "Chenxin (Xin)" <hangzhou.chenxin@huawei.com>
To: Simon Perreault <simon.perreault@viagenie.ca>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Thread-Topic: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt
Thread-Index: AQHOsL+XhyORzIvU1ESsGxOV4IuYl5nEOHMAgACbzYA=
Date: Sat, 14 Sep 2013 08:53:21 +0000
Message-ID: <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com>
References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca>
In-Reply-To: <5233FC04.7040509@viagenie.ca>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.166.41.115]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "behave@ietf.org" <behave@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2013 08:53:44 -0000

Hi Simon,

>> I agree with you that this has not been well covered in the draft. In
>> order to make the minimun changes possible, and align it with the
>> general view of changing just the turn client to turn server
>> encapsulation protocol, I would propose to extend websockets usage only
>> for the turn control connection in RFC 6062 but keep turn data
>> connections on TCP.
>
>So with an HTTP proxy the control would be over websockets and the data
>would be through the CONNECT method? Yuck...

Or using websocket multiplexing http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11 . 
>
>> That, or drop RFC 6062 extension altogether and just
>> focus on 5766. What do you feel it would be best?
>
>I say focus on 5766.
>
>I have a new question: what does the TURN server put in the
>XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's
>address? 

The proxy's address. I do not think this attribute will help ICE process. 

Can TURN over WebSockets be used to gather server-reflexive
>candidates?

Yes, It could do as UDP and TCP. But when there is a http proxy. I think the server reflexive candidates will be the address of proxy, which means nothing for the peer. But if there is only NAT, the server reflexive candidates is possible to work in the ICE.


Best Regard,
  Xin
>
>Simon
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb