What’s Your SaaS for WebRTC Signaling?

Looking for a signaling solution for WebRTC? Why not ditch the whole protocol discussion and head straight towards a SaaS based approach?

The true meaning of cloud-based signaling

I’ve written last week on how to select a signaling protocol for WebRTC. This lead to a lively discussion both on my blog and on Facebook’s WebRTC group. I learned a new thing that day:

VoIP signaling is a religion. People believe in a specific protocol and worship it. And they tend to fight with the atheists.

I was part of the religious in VoIP, but I now have doubts of its need. Call me a signaling protocol atheist.

I was corrected on that post that signaling protocol and network protocol are two separate things that need to be discussed and selected separately. It is true that they are different, but I think that most developers who approach WebRTC today don’t make that distinction any more – they simply don’t care – they are just trying to get their service to work.

On Facebook, Olle E Johansson commented:

Yes, the API is the key. Finding an abstraction level that the web developer understands, not that just exposes protocol operations. The signalling matters when things start growing and you need scalability or interoperability with other systems, but only then.

I guess you care about signaling protocol for interoperability, I just don’t see how it can help with scalability – the web is scalable enough – a lot more than VoIP today – just ask Whatsapp. Why bog it down with SIP? My recommendation still stands: If you don’t need to connect to other networks (or if you do, but only for a small part of your use case) – go for a proprietary signaling protocol.

What I did ignore/miss though, is what happens when you decide to go for a proprietary protocol, but don’t really want to deploy a server at all. What if what you want is to get “signaling as a service” – SaaS.

First question is why would you?

The easy answer here is because you can, and because it has its advantages over building your own. As with any other SaaS or cloud related service, these things come to mind:

• Scalability – someone else who does that for a living takes care of it for you
• Maintenance – do you really want a DevOps guy to sit all day playing with scripts and monitoring your signaling infrastructure?
• Availability – same as above. Just too much work to deal with

The main thing though, is probably deciding what’s core to your business and what is just details. Signaling has migrated in to the “details” part, so outsourcing it to a SaaS vendor makes sense.

Here are 4 viable options to use for WebRTC signaling in a SaaS model.

PubNub

If you’ve been around long enough with WebRTC, you should already be aware of PubNub. As an example, Rebtel are already using them.

PubNub offers a publish/subscribe infrastructure that can be used to develop messaging applications. WebRTC services being one of their targets, they are heavy on marketing their solution in WebRTC events and have gone as far as offering a reference implementation for developing a video calling service with WebRTC and PubNub.

If you are looking for a vendor that cares about show casing customers that use WebRTC and offers the kind of scaling you will need today for other use cases – PubNub is a good choice.

Firebase

Firebase is one of the BaaS vendors out there (Backend as a Service). Their intent is to enable developers to build frontend apps without having to care at all about the backend.

The main difference from PubNub here is that it synchronizes data and acts as distributed storage/memory for your apps. If you need more than just messaging, I’d suggest you check it out.

I know of a few in the WebRTC community that are using Firebase, so it is a valid option. Firebase might not make a lot of noise about WebRTC, but they have built their own reference sample for it by forking a project called gupshup.

UPDATE: Firebase got acquired by Google, and now have a codelab of using WebRTC with Firebase.

PeerJS

PeerJS isn’t really a SaaS provider, but it is contemplating to be one – at least from how it looks like in their website.

PeerJS is a framework that provides signaling for WebRTC. It operates with a Node.js based server called PeerServer that has a service called PeerServer Cloud. This cloud service offers only free accounts for hacking, but nothing in the form of production support.

It is here because of three reasons:

1. Many are using it already to build their services, so it made sense to me
2. They have the potential (and general intent) of offering it in a SaaS model
3. The source is freely available, which means that you have the ability to start with SaaS and migrate to your own data center

A word of caution – from the looks of it – this might not be able to scale easily to the millions. It just seem too… lightweight.

Pusher

If PubNub and Firebase are here, then Pusher should be as well. It is a messaging SaaS provider. Not much in the WebRTC domain about it, but I guess that it can be used just as well.

Use it if you already know it and like it.

–

I am sure there are others as well that I missed, like XSockets.NET – and those that are still too small like GrimWire.