Last week on No Jitter, we were treated to two examples of WebRTC emerging in real-world services, offering opposite visions of what you can do with this evolving standard.
In "Amazon and WebRTC," Chris Vitek wrote about a couple of different service models that Amazon seems to be deploying with WebRTC under the covers. To me, the most intriguing aspect of Chris's post was his discussion of something called "PeerCDN." Chris describes PeerCDN's use of WebRTC's data channel as a kind of "legal BitTorrent." Basically, the idea is to change the architectural model of a Content Delivery Network, from one based on big, geographically optimized media servers, to a massively decentralized peer-to-peer model, kind of like the original Skype "supernode" architecture (which was largely abandoned by Skype before Microsoft even entered the picture).
It's an interesting model, especially in light of the ongoing angst over Net Neutrality. With the FCC ready to side with the big ISPs, against the content distributors, might there be an opportunity to use PeerCDN to get around the new regime of paying for preferred treatment? I honestly don't know the answer to that one, and I'm not sure that a company trying to build a sustainable business on content provision, such as Netflix, would want to take the risk. But could we see the rise of Napster- or BitTorrent-style competitors to Netflix, providing almost-as-good streaming without the higher prices that the Netflixes of the world will have to start charging once they have to pony up to the big ISPs?
At the other end of the spectrum, Sheila McGee-Smith writes about Voxbone, a little-known service provider that has come up with a WebRTC-based service that explicitly seeks to leverage the introduction of servers into what was originally conceived as a peer-to-peer interchange. And indeed, Voxbone's new service seems premised on the belief that Internet best-effort performance will never be good enough, so the thing to do is to get WebRTC traffic off the "open Internet" and onto a private, managed IP network as soon as possible. So its service does just that--it introduces an SBC-type element that talks WebRTC to the client, then transmits the sessions as SIP or PSTN traffic to the destination. Sheila says this could be a useful service for a contact center that wants to offer WebRTC-based video without having to WebRTC-enable its own infrastructure.
So we're seeing some of the old tensions return: Server hierarchies versus peer-to-peer for scalability; and Internet best-effort service versus paying for better QOS. These issues have been around as long as the Internet has, and they've driven the strategies of carriers and content providers since the early days of Skype and YouTube. They're going to become more relevant for enterprises as business communications start to run over the open Web, whether in B2C or B2B scenarios.
These developments also highlight the fact that WebRTC is, as our friend Tsahi Levent-Levi constantly says, "a technology, not a service." That means, among other things, that enterprises will need flexible approaches to enabling WebRTC-based endpoints that want to use the networks, applications, and services that the enterprise offers--again, whether these are being offered internally or externally.
It's not about which technology will "win"--it's about which technologies you can enable cost-effectively.
Follow Eric Krapf and No Jitter on Twitter and Google+!
@nojitter@EricHKrapf
Eric Krapf on Google+
