Re: [rtcweb] HTTP Fallback draft

[Lorenzo Miniero <[e-mail]>]

Hi Iñaki,


On Tue, 7 Aug 2012 21:34:09 +0200
Iñaki Baz Castillo <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>:
> 
> > 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.

Lorenzo

> 
> Regards.
> 
> 
> -- 
> Iñaki Baz Castillo
> <[e-mail]>


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com