Re: [rtcweb] HTTP Fallback draft

[Bernard Aboba <[e-mail]>]

> We indeed met such network elements in our experience, even though most of the times it was just blind UDP filtering rather than RTP filtering per se. It sometimes was just blind port filtering but the effect was the same. This mostly happened within enterprises networks where we tried, no matter how small or large.


[BA] this fits with my experience as well.

> You're right. A couple of years ago we wrote a paper addressing the potential approaches for tunneling attempts (if you're interested, I can send you the link offline). In this paper we basically described, as a diagram, which incremental steps could be carried out in order to attempt a successful tunneling: 1) the first attempt is to just try port 443, without encapulating anything (e.g., ssh using 443 instead of 22);

[BA] There are DPI boxes that will compare traffic against TLS and catch this. So if it doesn't work you can't assume that 443 is blocked by the firewall. Same with non-HTTP on port 80.

> 2) in case that doesn't work, the second attempt is to use HTTP CONNECT and then fall back to 1. for the connection that is established;

[BA] Trying HTTP on port 443 isn't likely to work if the original non-TLS test on 443 failed. 

> 3) the third attempt (e.g., 443 is not available or the proxy acts as a MITM) is to actually encapsulate in HTTP messages, whether you do HTTP or HTTPS. In every case, the peer (either endpoint or server) must be configured accordingly of course.

[BA] If HTTP failed earlier, HTTP encapsulation also will probably fail. It makes more sense to me to try TLS on 443.

> What I describe in the draft is step 3, even though I guess some words to suggest steps 1 and 2 (where you'd still need to encapsulate RTP packets on top of a TCP-based protocol anyway) could be considered. As long as it looks like valid HTTP and it behaves accordingly, I think there's no reason why traversing should be impeded:

[BA] DPI boxes aren't always up to date. For example don't expect them to understand websockets.

> 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".

[BA] If all the other avenues are tried first, then this would really be a last resort. Any idea how frequently it should be expected to be used?