IETF Logo Mail Archive

Re: [rtcweb] some thoguhts on draft draft-hutton-rtcweb-nat-firewall-considerations-00

"Stach, Thomas" <thomas.stach@siemens-enterprise.com> Tue, 19 March 2013 16:24 UTC

Return-Path: <thomas.stach@siemens-enterprise.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 B8E2421F86E3 for <rtcweb@ietfa.amsl.com>; Tue, 19 Mar 2013 09:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.37
X-Spam-Level:
X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=1.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJECT_FUZZY_TION=0.156]
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 NaihA02f2FfR for <rtcweb@ietfa.amsl.com>; Tue, 19 Mar 2013 09:24:06 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75721F87C5 for <rtcweb@ietf.org>; Tue, 19 Mar 2013 09:24:05 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 471571EB856B; Tue, 19 Mar 2013 17:24:04 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Tue, 19 Mar 2013 17:24:04 +0100
From: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
To: "Chenxin (Xin)" <hangzhou.chenxin@huawei.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
Thread-Topic: [rtcweb] some thoguhts on draft draft-hutton-rtcweb-nat-firewall-considerations-00
Thread-Index: Ac4kdG4t/VbBlcdVS2qFsvPBgtNscwASQsrA
Date: Tue, 19 Mar 2013 16:24:03 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE120679A4E6@MCHP04MSX.global-ad.net>
References: <9E34D50A21D1D1489134B4D770CE0397390EDEE2@szxeml538-mbx.china.huawei.com>
In-Reply-To: <9E34D50A21D1D1489134B4D770CE0397390EDEE2@szxeml538-mbx.china.huawei.com>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE120679A4E6MCHP04MSXglobal_"
MIME-Version: 1.0
Subject: Re: [rtcweb] some thoguhts on draft draft-hutton-rtcweb-nat-firewall-considerations-00
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: Tue, 19 Mar 2013 16:24:06 -0000

Hi Xin,

with the HTTP Connect we already have a TCP connection to the TURN server and could a TURN channel for media transport.
With your proposal the TURN server would have to additional protocols.
What would be the benefit of using websockets to transport media?
I rather prefer to have less options than more.

Regards
Thomas



________________________________
Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im Auftrag von Chenxin (Xin)
Gesendet: Dienstag, 19. März 2013 08:36
An: rtcweb@ietf.org; Hutton, Andrew
Betreff: [rtcweb] some thoguhts on draft draft-hutton-rtcweb-nat-firewall-considerations-00

Hi Andrew,

   I have read the draft-hutton-rtcweb-nat-firewall-considerations-00, and have some more considerations about nat-fw-traversal: Is it possible to consider to allow the webrtc client connect to the turn server using websocket connection. The websocket is upgraded from http and supports subprotocol field and multiplexing extension, which will be convenient to deal with the multiplexing usecase.

2.3 Firewall open only for TCP-based HTTP(s) traffic

   If upgrade the http to websocket and send the Turn data directly on the websocket connection, it works too.
   The Turn server should be configured to accept the websocket connection and listen to the HTTP(S) ports as well.
   The webrtc client need to be configured to contact the TURN server over the HTTP(s) ports.

3.3.1 TURN server connection via TCP
   Websocket works fine in the scenario of explicit proxy traversal using Http Connect method. If there are intermediate transparent proxy server, ecncrypted websocket connection will be successful.

  In this scenario, The Turn server should be configured to accept the websocket connection and listen to the HTTP(S) ports as well.
  In addition, the proxy server may need to be upgraded to support Websocket if the uncrypted websocket need be supported.

Best Regards,
     Xin

v2.23.0 | Report a Bug | By Email