The 4 Different Approaches of Using WebRTC APIs

For those who want to develop with WebRTC, there’s more than one way to go.

In my talks with the vendors who either use or plan on using WebRTC, I can say that the way to get things done isn’t a one-size-fits-all approach. The good thing is – there are options available that fits practically anyone. The vendors who are adopting WebRTC for their services take one of four different approaches:

1. Go it alone

This seems like the most straight forward approach. WebRTC is out there already and while it has its challenges it can be used directly.

There’s also enough reference code out there to start from, with around 2,000 different WebRTC related projects only on github.

Those that take this approach tend to be outfits that have full stack developers with previous VoIP experience, and they usually have an NIH (Not Invented Here) mentality which revolves around wanting to have control on each and every aspect of their service.

The other reason to go it alone is usually because you already have a VoIP deployment, and the only thing you are looking for is adding another access point into your service from the web browser by adding WebRTC into it.

With self-development, most will still end up using open source components such as the popular rfc5766-turn-server, the relatively newer Janus gateway or an Asterisk / FreeSWITCH VoIP platform.

When necessary, commercial components and SDKs are also licensable. Most notable one today is Dialogic’s PowerMedia XMS, offering media processing capabilities for those who need it.

2. Adopt Frameworks

WebRTC on its own can be viewed as a media engine. The signaling on top of it – finding out who to connect to and negotiating that session – are out of the scope of WebRTC and is left for the developers to decide.

There are already several frameworks that take care of the signaling aspects of WebRTC, which utilize WebSockets or COMET technologies and provide proprietary means to communicate across browsers. These frameworks today are mostly open source and it is common to find them in many projects out there.

The most popular ones are:

• PeerJS, which I have already written about here. This one is used mainly to decentralize the web due to its P2P nature and focus.
• EasyRTC, focusing on video communications with mesh video conferencing capabilities. Due to its ease of installation and use, it has been deployed in labs or early production on over 5,000 servers already.
• SimpleWebRTC, which has been around for a long time, and is now getting a bit more focus from its original developers; making it a compelling framework as well.

People using these frameworks as starting points tend to be either those exploring what can be done with WebRTC for specific projects or small startups. With such frameworks, you get a bit of a head start, but still have full control and ownership of the solution.

3. Rely on SaaS Suppliers

To deploy a WebRTC project, you have to deal with NAT traversal issues at the very least. At the end of the day, this means deploying more than just web servers and deal with things like geolocation of your target users and other headaches involved with low latency real time communication. There’s also the need to maintain and monitor the deployment, which tends to be a hassle.

To that end, a new breed of SaaS suppliers exist that can offload that headache from developers and DevOps teams by providing SaaS offerings. The 4 notable areas are:

1. NAT traversal. Instead of deploying your own TURN servers out there, you can just consume that as a service by selecting XirSys or VideoRoaming for the job.
2. Signaling. There are those who offer low latency messaging service today, and they can be used for WebRTC signaling as well. Those that offer it, complementing it with reference code are PubNub and Firebase.
3. Multipoint conferencing. Multipoint video is a real challenge for WebRTC. To that end you can use MCU1.com service. I am sure others will follow.
4. Quality tracking. Instead of having to build up an operation that monitors the whole service for its quality to understand what users are experiencing, you can use CallStats.io‘s service and get online reporting on the user experience.

4. Choose a WebRTC API Platform

At times, what you are looking for isn’t really to touch the technology. WebRTC or not, what you are looking for is the ability to make voice or video calls to build a new services or embed them into your own service logic.

When this is the case, then a WebRTC API Platform is an approach that many end up adopting. By using such a SaaS platform, you get an abstraction on top of WebRTC, which takes care of signaling, media processing, fallback mechanisms to cases when WebRTC doesn’t exist and SDKs for embedding WebRTC into mobile apps.

There are over 10 such platforms out there already, including AddLive, TokBox, Tropo  and Twilio. They come in different shapes and sizes, focusing on different types of use cases and offer slightly different set of capabilities.

This approach may be the most popular of them all and is adopted by those that view voice and video communication as a means to an end – as a feature within a larger service and something that isn’t really core to their business – at least not in the sense that requires them to own and control it.

Why is it Important?

Some believe WebRTC brings nothing new, but reality looks quite different when you view the ecosystem building around it – the types of vendors who offer services and technologies that developers can use to overcome the challenges of WebRTC.

This wide variety of options means that virtually any person or company that wants to leverage WebRTC can do so in a way that makes sense to it – one that fits both from its business as well as its technology aspects.

–

If you want to learn more about these approaches, their advantages and disadvantages – and make an informed decision – you can always take a look at my Choosing a WebRTC API Platform report.