Solving the WebRTC signaling challenge

Even if you think you don’t know what WebRTC is, chances are you are pretty well-acquainted with it. Why? Because everyday web operations rely on it. The article below describes a common challenge developers encounter when employing WebRTC under the hood and how to solve it, with links to further information.

WebRTC is a realtime communication standard that is baked right into the web browser. It enables developers to build applications that allow things like voice or video calling as well as sending arbitrary data (which Google Stadia uses to control cloud games for example). If you ever did a voice or video call using Facebook Messenger or Google Duo/Meet/Hangouts - then you’ve experienced WebRTC already.

Interestingly though, I am not here to discuss what WebRTC is or has (you can find more information about that on my blog, BlogGeek.me), but rather what it lacks and how to solve it. WebRTC lacks signaling. By signaling I mean the ability to find the person you want to communicate with and negotiate the communication terms (is this a video session? Voice only? What codecs will be used? etc). WebRTC will do a fabulous job connecting a session and making sure audio and video are crisp to the level available by your network. But for that to happen your application first needs to have a signaling channel and protocol in use.

So if WebRTC lacks signaling, this is a part developers need to figure out on their own. The messages that WebRTC wants you to send on its behalf are a set of SDP blobs. WebRTC handles the creation and parsing of these SDPs but not the sending and receiving part.

You as a developer, need to decide how to send them. Some use XMPP as their protocol of choice for such messages. Or resort to MQTT. Others use SIP (which is quite common in VoIP). For the most part, though, I’d say that developers tend to invent and use their own proprietary protocol here and just use WebSocket or Comet type solution like XHR.

Many of the developers who implement WebRTC in their apps make two good friends along the road:

1. Node.js - seems like the winner in many signaling projects these days
2. GitHub - where code can be found

The challenge is that there’s no popular and proven GitHub project for WebRTC signaling. All of them require a lot of care and love to get them to production readiness.

Which is why there are developers who end up opting to not run their own signaling service, but rather “rent” one - from services like Ably Realtime.

Why would someone prefer using a third-party managed service for WebRTC signaling and not take the route of self development? For the same reasons you host machines on AWS and not open your own data center:

1. Someone else needs to take care of uptime, monitoring, security, updating and dealing with the nuances of supporting multiple browsers, operating systems and SDKs
2. That vendor is also responsible for scaling the service to meet your growing demands. This is double try in WebRTC where all of these messages are “stateful” - something that makes scaling even harder
3. You get to focus on what’s important to you - the messages and state machines that drive your application, and nothing more

Ably has put together a series of tutorials on how to implement WebRTC apps with Ably Realtime as the underlying signaling service - You can try it out yourself by following their simple steps.

The way I see it, there are 3 main ways to develop a communication with WebRTC these days:

1. DIY - by using GitHub and open source
2. Semi-managed - using a vendor to manage your signaling and another vendor to manage your NAT traversal
3. Fully managed - going and using a CPaaS vendor that has it all

Why the middle ground of semi-managed? Because it has less vendor lock-in characteristics to it and gives better flexibility in mixing and matching components that you may need. I’d especially suggest it for those who are considering the DIY route - because it will make their lives easier by reducing the non-functional aspects of development needed, while still letting them maintain a large bulk of their IP.

What’s your preferred signaling method for WebRTC? More information about WebRTC signaling servers is available on BlogGeek.me. Jump in to Ably WebRTC signaling solutions by browsing Ably docs or experimenting with a free account. If you have any particularly good solutions to this issue that you feel would benefit this article, get in touch with Data in Motion editors.

Blog by Tsahi Levent-Levi, Author of BlogGeek.me as well as CEO & Co-founder at testRTC. He also has online courses (free and paid) at webrtccourse.com