Re: [rtcweb] HTTP Fallback draft

Marc Petit-Huguenin <> Tue, 07 August 2012 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C528421F8668 for <>; Tue, 7 Aug 2012 14:36:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.557
X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zy46bflaQpag for <>; Tue, 7 Aug 2012 14:36:38 -0700 (PDT)
Received: from ( [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by (Postfix) with ESMTP id B51AC21F8667 for <>; Tue, 7 Aug 2012 14:36:38 -0700 (PDT)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] ( [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "" (verified OK)) by (Postfix) with ESMTPS id 4928820491; Tue, 7 Aug 2012 21:36:37 +0000 (UTC)
Message-ID: <>
Date: Tue, 07 Aug 2012 14:36:34 -0700
From: Marc Petit-Huguenin <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: Lorenzo Miniero <>
References: <20120807180156.286e74d2@rainpc> <> <20120807191226.5b8e7f32@rainpc> <> <20120807215415.00bebaa7@rainpc>
In-Reply-To: <20120807215415.00bebaa7@rainpc>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] HTTP Fallback draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Aug 2012 21:36:39 -0000

Hash: SHA256

On 08/07/2012 12:54 PM, Lorenzo Miniero wrote:
> Hi Iñaki,
> On Tue, 7 Aug 2012 21:34:09 +0200 Iñaki Baz Castillo <>
> wrote:
>> Hi Lorenzo, sorry for opening another thread about this (I didn't check
>> my unread emails before reading the draft). Please see comments inline:
> No harm done, don't worry!
>>> Hannes Tschofenig <> wrote:
>>>> Just to be clear, I don't have objections regarding your draft. I
>>>> just would like to understand what motives people to run everything
>>>> over HTTP (besides using HTTP features, which you don't really do).
>> Honestly I don't like the "all-over-http" vision. Admins filtering 
>> traffic other than HTTP or HTTPS will also do their best efforts for 
>> filtering specific traffic over HTTP, and IMHO making specifications to
>> run protocolos over HTTP legitimizes those hateful filtering techniques.
> I'm not a fan either, believe me :)
> That said, as I said in another post I still think that, if RTCWEB/WebRTC
> is going to be deployed in browsers, they'll expect it to work in all the
> places where all other web applications do. Many proprietary protocols that
> do real-time communication implement tunneling somehow, or pretend to do
> so, which means something in line with that is needed for RTCWEB as well.
>> 2012/8/7 Lorenzo Miniero <>om>:
>>> I agree with you and I'm not really dying to do RTP over HTTP either,
>>> but if some scenarios make it impossible for use cases to work (and
>>> some firewall/NAT deployers are to blame here, probably) then a
>>> fallback mechanism is something that can be nice to have, especially if
>>> we're interested in something that "just works".
>> That's the problem (IMHO): if we make all to work over HTTP then some day
>> telcos providers will just offer HTTP (as "Internet") and we'll need to
>> study a new OSI model in which the lowest layer is called "HTTP".
> Which is close enough to the hourglass draft Hannes mentioned in his post,
> I'm afraid. I can't but agree with you, but, again, if we have use cases
> and we want to have them working in as many topologies as possible,
> something must be done.
>> BTW: I sitll don't understand which is the advantage of using RTP over 
>> HTTPS in comparison to TURN over TLS:443. Does is exist?
> If we talk about a simple comparison, I'm sure TURN:TLS:443 performs much
> better than RTP over HTTPS, or at least, over the simple approach I
> documented in the draft at least (even though I tried to keep the overhead
> as little as possible). Comparing them is probably not fair, though, as
> they address two different scenarios: that's why HTTP would be just a
> fallback, and not something you'd use when you have alternatives.
> Referring to the steps I described in my previous answer to Hannes,
> TURN:TLS:443 is probably the most useful option for scenarios 1 and 2, that
> is, where you can just pipe what you want on port 443 and be sure it will
> be ignored by the proxy. If the proxy checks what's going on, though, that
> may not be as easy. The proxy may be acting as a MITM for HTTPS, as Roman
> described, or just doing some traffic monitoring with anomaly detection or
> something like that: faking to be HTTPS is not going to work in that case,
> since the proxy may just see it's not HTTP at all, or may just understand
> it's not what it claims to be because it doesn't behave as it should; HTTP
> connections have a usually quite simple pattern (e.g., much more traffic
> going in one direction than the other and never at the same time),
> something that would be very different in a TURN connection instead.

I think that this problem should be looked from another point of view.  One of
the basic assumption of ICE is that a TURN address is always added with the
lowest priority to the gathered candidate addresses, because it guarantees
that ICE will always works.  Now we all now that this assumption is not true
in 100% of the cases, and this is the reason why years ago I added a TURN over
HTTP(S) transport in the product I was developing at the time and worked on an
I-D (never published).  So instead of seeing TURN over Websocket as a way to
work in difficult environments, we can just see it as a way to fulfill the
promise of ICE, which is to find a path in 100% of the cases, by adding TURN
over UDP then TURN over TCP/TLS, then TURN over Websockets as the lowest
priority in the gathered candidate addresses (that will probably require a
modification in RFC 5245, as it already recommends a priority of 0 for TURN
over UDP).

After Taipei I restarted working on this idea, but using Websocket this time.
 I gave up when I discovered that there was no Websocket dissector in
Wireshark, but now that this issue seems to be fixed, perhaps it is a good
idea to finish this work.

- -- 
Marc Petit-Huguenin
Version: GnuPG v1.4.12 (GNU/Linux)