WebRTC PaaS SDKs 101

What exactly do WebRTC PaaS have to offer when it comes to APIs?

Recently, I’ve been asked multiple times questions that fall into this category. A recent post on Respoke’s blog, which clarifies the Respoke libraries and SDKs led me to write this post.

When you go to a WebRTC API Platform today, trying to understand the types of interfaces you get as a developer, it seems like there’s a mix of technologies at play here. This isn’t your typical web service with its REST APIs. There’s a lot more to work with, which can be a bit confusing to begin with.

What should you expect from your WebRTC PaaS then? Here’s a breakdown of the SDKs they offer.

REST

All of these platforms offer RESTful APIs.

These are part of the backend management system, where either your server or your client side application interact with the server on housekeeping issues. From key management, to logs, to making decisions and connecting to PSTN.

This API is the easiest one to understand, as most of our modern web is built with these types of APIs.

Vendors will differ here in several ways:

• The richness of features and capabilities they offer. Some will enable doing whatever you can do in their admin UI via APIs as well (an advantage)
• The languages they offer libraries for that call their REST APIs, either as samples or as official “SDKs”. The more the merrier, but you can live without it. And if you can’t, then just make sure that the language you plan on writing your code with is in their list of samples

JS

The JavaScript APIs are those that operate inside the browser. This is where WebRTC gets to be used.

While there is a signaling/control protocol between the WebRTC PaaS server and its browser clients, this protocol will be “hidden” from the developers. You won’t need to know the intricacies of it, and instead, you will have access to a JavaScript library that abstracts that knowledge (and WebRTC) from you.

In most cases, this JavaScript library implements the signaling/control protocol on top of WebSocket – but not always.

iOS

Support for iOS comes in the form of a Native SDK. A library you load into your app and link with. The APIs themselves will be written in Objective-C, and will usually be similar to the ones in the JS library.

There may be differences between the capabilities and exact feature set provided for the browser and for iOS devices. These gaps tend to close with time and maturity of the platforms. Be sure to check for these differences before committing to a specific WebRTC PaaS vendor.

Recently, all WebRTC PaaS vendors started introducing 64-bit iOS SDKs, to meet with Apple’s new requirement of 64-bit support in iOS 8.

Android

Like iOS, Android support comes in the form of a Native SDK. In the case of Android, the APIs will be written in Java.

Others

PhoneGap? Xamarin? There are cross platform mobile frameworks out there that are quite popular. Some of the WebRTC PaaS vendors offer support for them. If this is what you are looking for, then check if they are supported out of the box, as a reference or will they be something you’ll need to provide interfaces for.

Why is this important?

• Selection of a WebRTC PaaS vendor isn’t easy. There are many parameters to check and work with
• The more understanding you have on the architecture of WebRTC PaaS and the devices you’ll be using, the better your decision will be