Re: [pntaw] TURN over websockets

Marc Blanchet <marc.blanchet@viagenie.ca> Fri, 30 August 2013 14:28 UTC

Return-Path: <marc.blanchet@viagenie.ca>
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 B38D011E81A1 for <pntaw@ietfa.amsl.com>; Fri, 30 Aug 2013 07:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.742
X-Spam-Level:
X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 NkKLdmLaTDCv for <pntaw@ietfa.amsl.com>; Fri, 30 Aug 2013 07:28:25 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB71011E810A for <pntaw@ietf.org>; Fri, 30 Aug 2013 07:28:24 -0700 (PDT)
Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1F81F403EE; Fri, 30 Aug 2013 10:28:24 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <913383AAA69FF945B8F946018B75898A19034557@xmb-rcd-x10.cisco.com>
Date: Fri, 30 Aug 2013 10:28:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F058FF6A-35F2-4372-AAB7-345F0024E845@viagenie.ca>
References: <52205AE1.9010807@gmail.com> <913383AAA69FF945B8F946018B75898A19034557@xmb-rcd-x10.cisco.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
X-Mailer: Apple Mail (2.1508)
Cc: "pntaw@ietf.org" <pntaw@ietf.org>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Subject: Re: [pntaw] TURN over websockets
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, 30 Aug 2013 14:28:26 -0000

Le 2013-08-30 à 09:53, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> a écrit :

> The other way to solve the Firewall problem is use PCP.

don't agree.  it would be great, much better design, but all the install base of gateways in public wifi, coffee shop wifi, hotel networks, etc... are not going to do any PCP. 

Marc.

> For more details refer to sections 3.1, 3.2 of draft http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00 which addresses the problem of Enterprise Firewalls permitting P2P media streams. 
> 
> -Tiru.
> 
>> -----Original Message-----
>> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf Of
>> Sergio Garcia Murillo
>> Sent: Friday, August 30, 2013 2:12 PM
>> To: pntaw@ietf.org
>> Subject: [pntaw] TURN over websockets
>> 
>> Hi all,
>> 
>> I will shoot first.
>> 
>> It is great to finally see some real interest in what I consider to be
>> the blocking point for webrtc in order to run business on top of it,
>> which is the ability to be able to connect through corporate firewalls.
>> 
>> I have seen some people arguing that with just TURN over TCP on port 443
>> the problem will be solved, but I seriously doubt it. Neither TURN over
>> SSL would do, as most web filters do DPI and will not enable the
>> connection. Also, I have heard lots of voices that says we are trying to
>> override network admin policies with dirty tricks. With whom, I could agree.
>> 
>> So, the only way I see to move forward and overcome this issues is by
>> playing according to the WEB rules, and use HTTP standards to enable
>> media connectivity in WebRTC that would play nicely with current
>> corporate HTTP proxies and web filters.
>> 
>> And,  for me the most viable solution would be to enable TURN over
>> websockets. As most WebRTC services relay on websockets in one way or
>> another for signaling, we could assume that media would work on 100% of
>> the cases where signaling is working today.
>> Also, as it is an http based solution, network administrators could
>> apply corporate policies and block connections to not-trusted TURN servers.
>> 
>> Best regards
>> Sergio
>> _______________________________________________
>> 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