Peer to Peer Reaching the Browser through WebRTC

Will WebRTC disrupt or be disrupted?

WebRTC promises to deliver computer to computer communications with minimal reliance on central servers to manage the conversation. Peer-to-peer systems promise smoother exchanges without the tremendous scale challenges of running video, for example, through central points.

The WebRTC Conference and Expo was unlike any other web conference I’ve attended. Though technologies in development are common at tech conferences, I can’t remember attending a show that was focused on a technology whose future had these levels of promise and uncertainty. Also, despite the name, WebRTC doesn’t resemble much of the Web despite being built into some browsers (more hopefully coming soon) and supporting HTTP(S) proxying.

 

WebRTC Conference, November 2013.
Video chat has long been a central part of the WebRTC story, a common feature of demos. Most of the conversations I’ve had with people enthusiastic about WebRTC center on adding live communications to the Web. Some of them just want to replace Skype, while others want to make the Web more immediate than pages of text and graphics.

The “video birds of a feather” session, the first I attended, was a great way to see many red flags raised at once, though. That conversation was dominated by questions about patents, primarily on video codecs. Cisco has bought an unlimited license for H.264 and is letting Mozilla work using it. That has at least made it possible for open source tools to use that approach (and hardware acceleration in particular), but it didn’t seem to be an appealing lowest common denominator for attendees, or at least for those speaking. Quality and latency issues seem to be pushing many developers toward other codecs. That then crashes into walls of patents controlled by people who insist they’re doing things for the best reasons but may squash WebRTC video from the beginning.

Later that day, a speaker on a panel wanted to dodge the whole conversation, saying “That’s a political discussion: who’s in charge. It’s a big mistake to go down that path.” Since the path is blocked, I guess he had a point, but vague appeals to progress and the market didn’t seem likely to clear the blockage.

At the very end of the show, Cisco Fellow Cullen Jennings addressed the politics. He talked about the “need to get to some common codec…on whatever browser… for fallback. IETF has known this a hard problem.” To deal with it, he talked about efforts to achieve consensus on using an alternative process: listing out ideas followed by a voting process to focus on one scheme for use as a fallback foundation. When the IETF is talking about voting, the problems are indeed hard, but maybe this will work.

I suspect that WebRTC could probably thrive even if video proved impossible because of legal reasons, thanks to the data side of the story. As enticing as it is to send video from point to point, sending data from point to point is also useful. Ideally, it can be streaming over UDP, for low latency, but WebRTC recognizes the existence of NAT and firewalls and supports more choices. Setting up a peer connection can be intricate, but WebRTC hides that complexity, using intermediaries if necessary. STUN, TURN, and ICE might sound odd, but WebRTC abstracts those details away for developers. (The intricate combination may be one of the best hacks I’ve seen in a long while, and I mean “hack” as high praise.)

WebRTC’s rearrangement of the network world creates opportunities to re-think development, but the shift away from servers raises questions. Are JavaScript developers and browser vendors ready to deal with large volumes of data from peer connections? How do we know when browsers are talking amongst themselves? WebRTC opens all kinds of possibilities for delivering content in ‘live’ contexts, distributed games, file sharing, second screens, and even remote controls – but how do we get there?

In some ways, though WebRTC looks very different from the traditional HTML+HTTP vision of the Web, it’s a return to the beginnings. A panelist pointed out that “if you listen to Tim Berners-Lee, the browser was supposed to be two way.” It took years for developers to establish workable two-way connections, and now WebRTC may make it easier to distribute those connections without crushing servers under insane scale.

I was impressed by the speakers’ and attendees’ devotion to getting WebRTC to work, in spite of the legal and technical challenges. One happy note from the final panel was that WebRTC is “becoming more teachable, because things are starting to stabilize”.

Maybe it will work – I did see a rare rainbow over Silicon Valley during the show.

Rainbow over Silicon Valley, 11/20/2013

(O’Reilly has been talking about peer to peer for a long time; it’s good to see the conversation taking off.)

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Web Platform