Choosing a WebRTC API
Tsahi Levent-Levi's latest report offers a guide through the options for building a WebRTC-based service.
WebRTC may still be classified as an emerging technology, but it's emerging pretty quickly, and interest continues to run high. We saw that at Enterprise Connect last month, when our WebRTC conference-within-a-conference once again drew strong crowds, and post-show surveys likewise showed rising interest in the topic from our attendees.
But when it comes to building real-world WebRTC applications and services, we're still talking about the bleeding edge, at least within the enterprise. I've talked to consultants and vendors who know of real-world cases, but few of these early adopters have gone public, and most enterprises are still in exploration mode.
Still, things are moving fast in the world of next-gen communications, where the new buzzwords tend to be phrases like "customer contact," and "user experience"--notions that inherently suggest something more than traditional communications, something more integrated with the Web and other interfaces that people tend to prefer these days. Something, in short, like WebRTC.
So it's actually an opportune time for a new report that's just been released by Tsahi Levent-Levi, who's emerged as one of the leading voices on WebRTC. Tsahi's report is entitled, Choosing a WebRTC API Platform, and in it, Tsahi offers his usual encyclopedic review of a significant aspect of WebRTC's emergence--in this case, he deconstructs the technology and use cases for WebRTC API platforms, and then offers a comprehensive summary of the players in this space.
Here's how Tsahi explains the report's purpose:
"You decided to use WebRTC for your next service. You have a validated business
case, some money to spend, a roadmap of sorts and a few developers.
Do you throw them at the task of building it all or will you be looking for shortcuts along
Are WebRTC and the real-time communication component in your service core to what
you plan on introducing, or is it just means to an end?
Do you throw them at the task of building it all or will you be looking for shortcuts along the way?....
Are WebRTC and the real-time communication component in your service core to what you plan on introducing, or is it just means to an end?"
That's a critical question, because as Tsahi is constantly reminding people, "WebRTC is a technology and not a service." The question isn't, Do I need WebRTC, it's, Do I need to integrate real-time communications into my Web-based (or other) applications? If you do have that need, WebRTC might be the right technology to use. And then, once you've made that call, you need to figure out the best way to deliver the functionality that WebRTC provides.
API platforms are becoming more accepted as ways for enterprises to build out service capabilities for either inward- or outward-facing communications. Twilio is probably the pioneer and the best known of the providers and advocates of this general approach. As Tsahi shows, there is a range of companies taking a WebRTC-focused approach to making a business out of this new model of creating real-time multimedia services.
As I reported yesterday, the enterprise communications industry is ready to move away from the monolithic-platform vision of communications that was represented for so many years by the PBX. The new model hasn't yet solidified, and it may never, in any coherent, across-the-board way--different enterprises may move forward with different models, based on demands of their vertical industry, or their particular legacy environment, or a host of other factors.
WebRTC is just one of many components of a communications ecosystem that will foster a variety of new models for implementing features, delivering services, and creating new businesses for those providing these new capabilities. Watch this space.