A WebRTC API can mean different things to different people. At its heart, the WebRTC library is just a voice over...
IP (VoIP) media engine embedded in a Web browser or ported and embedded elsewhere by developers.
- GetUserMedia gives developers access to the camera and microphone of a device, whether it's a laptop, tablet or smartphone.
- Peer Connection offers the meaty part of the VoIP stack. It implements media coding and sending and network address translation (NAT) traversal.
- Data Channel provides arbitrary data transmission directly between browsers.
That's all there is to it. And yet, these APIs aren't nearly enough to connect a single call through an IP network. For that, you need several additional servers and components, including a signaling server, TURN and STUN servers, and maybe media servers to handle back-end processing. This setup is needed for any VoIP protocol, not just WebRTC.
Since WebRTC is embedded in browsers, developers need to implement these additional servers. That's where WebRTC API platforms come in.
Dissecting WebRTC API platforms
WebRTC API platforms aim to ease the development of communication services and decrease their time to market for enterprises that need to use WebRTC in their use case. WebRTC API platforms usually consist of three main parts.
First, client software development kits (SDKs) act as wrappers on top of WebRTC, communicating with the vendor's back-end infrastructure. They usually abstract and simplify the use of WebRTC and flesh out the different WebRTC browser interoperability issues.
Second, NAT traversal servers handle the infrastructure side of getting media to flow through the network. These servers include STUN and TURN servers, located in different data centers around the globe. The client SDKs communicate and connect with these servers automatically, which eases the burden on developers.
Third, server side media processing usually includes the ability to conduct large conferences of multiple participants and recording capabilities. Some of these features may not be available, depending on the vendor, but most vendors will have these implemented or in their immediate roadmap.
Develop WebRTC in-house or outsource to a vendor?
While the components above cover the basics, some vendors provide a fuller set of features. Twilio, for instance, offers a wide array of communication APIs, where WebRTC is a small piece to its larger puzzle. Twilio also has its own WebRTC SDK, but the portfolio extends to SMS, voice calling, IP messaging, two-factor authentication and more.
Another vendor, TokBox, focuses on IP-based real-time video, where its platform extends toward live video broadcasting.
While WebRTC levels the communications playing field, it still leaves much to be desired. WebRTC API vendors fill that gap with offerings that support the rapid development and launch of new services. WebRTC API vendors fill a real need in the market.
Developers are left with two big questions: Should they use a WebRTC API vendor or develop the WebRTC infrastructure in-house? And, if they opt for a vendor, which vendor should they trust?
Different developers will have different answers to these questions. They need to look internally at their company to understand what core competencies they have and what their DNA dictates. They will also need to look at their use case to understand its requirements -- not only features, but also legal, support and geographical requirements, among other things. All these considerations will boil down to a decision -- one that makes sense to the unique needs of the developers.
In-house development or outsourcing your infrastructure to a WebRTC API vendor are both valid options -- each with its own advantages and challenges. While WebRTC reduces barriers, it increases available alternatives, making the decisions themselves somewhat harder to make.
Predicting WebRTC technology trends for 2016
Consider the security risks of a WebRTC deployment
Determine your WebRTC use case