Re: [pntaw] TURN over websockets

Simon Pietro Romano <spromano@unina.it> Fri, 30 August 2013 11:59 UTC

Return-Path: <spromano@unina.it>
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 F20A721E80C0 for <pntaw@ietfa.amsl.com>; Fri, 30 Aug 2013 04:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.718
X-Spam-Level:
X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, 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 CWxMtrIWox3u for <pntaw@ietfa.amsl.com>; Fri, 30 Aug 2013 04:59:01 -0700 (PDT)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 286BA21E80BC for <pntaw@ietf.org>; Fri, 30 Aug 2013 04:59:00 -0700 (PDT)
Received: from u665211.xgsnuf61.imtp.tachikawa.mopera.net ([91.255.122.61]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r7UBwrUT023511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 30 Aug 2013 13:58:55 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <20130830134531.787fda3c@rainpc>
References: <52205AE1.9010807@gmail.com> <20130830134531.787fda3c@rainpc>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----1TKWKUFRJRG39M91A2H0KLWXT9VEIR"
From: Simon Pietro Romano <spromano@unina.it>
Date: Fri, 30 Aug 2013 13:58:50 +0200
To: Lorenzo Miniero <lorenzo@meetecho.com>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Message-ID: <73abe274-acc2-4e37-847c-a660bbd2859c@email.android.com>
Cc: pntaw@ietf.org
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 11:59:06 -0000

+1 to the plain HTTP fallback solution proposed by Lorenzo a while ago.

Simon

Lorenzo Miniero <lorenzo@meetecho.com> ha scritto:
>On Fri, 30 Aug 2013 10:42:09 +0200
>Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
>
>> 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.
>> 
>
>
>That's the main objection I got when I published the (now expired)
>draft I published a year ago to throw the proverbial "stone in the
>lake" about an HTTP fallback solution. As I said at the time, I agree
>with you that the solution doesn't have to be sneaky, and that it could
>very well be conceived to be network admin-friendly/controllable.
>
>
>> 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
>
>
>I'm not an expert in websockets, which is why in my rough proposal I
>described a way to do this using plain HTTP, but I guess they'd be good
>for the purpose as well. The only doubt I have is that, as far as I
>know, not always websockets are able to traverse some more restrictive
>components: the popular BitDefender firewall, for instance, apparently
>doesn't let it through.
>
>Anyway, I'd personally support a work in that direction, and would be
>willing to help working on it too if needed.
>
>Lorenzo
>
>> _______________________________________________
>> pntaw mailing list
>> pntaw@ietf.org
>> https://www.ietf.org/mailman/listinfo/pntaw
>
>
>-- 
>Lorenzo Miniero, COB
>
>Meetecho s.r.l.
>Web Conferencing and Collaboration Tools
>http://www.meetecho.com
>_______________________________________________
>pntaw mailing list
>pntaw@ietf.org
>https://www.ietf.org/mailman/listinfo/pntaw