Making WebRTC work

The IETF is meeting in London this week. It’s usually easy to spot an IETF’er, often eclectic, slightly out of phase with the rest of the world and usually speaking in 3 letter technology acronyms.  But make no mistake, these people are the ‘oilers’ of the Internet ensuring that all the little gears that make up this massive network work.  The hi-tech facade aside, good ole fashioned Southern politics are at work at this meetings as they attempt the impossible, convincing agreement from often polarized members.

Right now I hope they’re focused on making WebRTC work.

A tagline I often use is that WebRTC is “similar” to Skype in it’s ability to work in all sorts of network obstacles. I’m not telling the truth though, I’m telling what I hope. I hope the IETF is working on this.

The truth is that WebRTC stumbles in restricted networks. The irony, I most find this situation at telecom operators, who have some of the most secure and overly managed internal networks in the world, often with nothing more than TCP Port 80 and 443 (and UDP DNS Port 53) open to the rest of the world.

We’re in another battle. A battle with the corporate IT guy. The guy who didn’t want to implement SMTP, because it was unsecure, the guy who wanted to proxy all the Internet traffic, because it was unsecure and the same guy who didn’t want to support the iPhone because (you know). We must make WebRTC work despite him.

Network security attitudes aren’t going to change over night and what this means is that the IETF is going to have to figure out how to tunnel WebRTC media via TCP Port 80/443. To some extent this is a violation of the rules of how the Internet is supposed to work, something only a hacker would do, a kludge fix at best. It will be interesting to see how the IETF addresses this dilemma.