In a previous post, we explored whether a CPaaS was right for your WebRTC application. We talked about the things to consider when deciding whether to use a Communication-Platform-a-Service (CPaaS) provider in a WebRTC application. Building a WebRTC application is a complex process. (We can help!) A CPaaS makes it simpler through a set of Application Programming Interfaces (API) and Software Development Kits (SDK).
In this first part of a series on How to Build WebRTC Applications Using CPaaS, we will elaborate on the role that a CPaaS plays and give an overview of the process. In later posts, we will take a look at the steps to implement it correctly and apply these best practices to some popular CPaaS providers.
WebRTC Complexity
As mentioned before, building a WebRTC application is a complex process. It involves providing the mechanism for peers (users) to connect, routing and processing media, and dealing with NAT traversal. For this, you not only need to write the application code, but also build and maintain the services that support such features.
Signaling
The first of these services is the Signaling channel. A Signaling channel is an intermediary service that allows participants in a WebRTC connection to exchange information with each other in order to establish such a connection. It’s only needed prior to the WebRTC connection.
WebRTC doesn’t enforce or define a Signaling mechanism. It’s your responsibility to build it. Most of the time, you’ll end up defining a media server or a separate application to manage this.
Media Server
WebRTC is all about peer-to-peer communication. This means that you’re able to establish connections directly between users with no intermediary servers involved. However, when you want to add processing to the media in any way, as is the case for implementing recordings or optimizing processes, you’ll need a media server to do so.
As before, it’s your responsibility to set up such a server and maintain it. Thankfully there are some open source options, such as Janus or Kurento, that you can use to make this simpler.
More on media servers in my post, Networking Basics for WebRTC: Signaling and Media Exchange.
NAT Traversal
Network Address Translation (NAT) is what allows devices to connect to the internet. In the context of peer-to-peer connections, it can be a headache. WebRTC uses the Interactive Connection Establishment (ICE) framework to perform the connection and STUN/TURN servers to manage NAT traversal.
STUN stands for Session Traversal Utilities for NAT. It provides peers the ability to know how they can be reached by other peers.
TURN stands for Traversal Using Relays around NAT. It provides an alternative method to connect when a direct connection is not possible.
Both require setting up and maintaining additional servers, and … you guessed it right! It’s your responsibility to do so.
More on all the networking that happens in order to establish a call using WebRTC can be found in my post, Networking Basics for WebRTC: Networking in Action.
The “-ity” Trinity: Availability, Scalability and Security
In addition to setting up the above services, you also need to make sure they are available for your application. As your user base grows, they need to scale and remain secure.
To ensure availability, you need to make sure your infrastructure spans across multiple geographical locations. This also helps users from far away to reach a server that’s closest to them. This is easier than it was before thanks to cloud computing. Many cloud vendors offer multiple geographical locations where you can provision your servers.
For scalability, you need to make sure your infrastructure is able to grow with your user base. A popular approach is to spin up additional servers as traffic grows and shutdown them when it shrinks. Again, this approach is possible thanks to the elasticity of cloud computing. For on-premise infrastructures, things are more complicated as you need to deal with actual hardware.
Security is also a crucial factor. When there is sensible data involved, you will need to comply with regulatory requirements such as HIPAA or PCI DSS. This requires, among other things, encryption at-rest and in-transit of sensible information, and also the implementation of controls that allow to know who accessed what and when. Once again, you can take advantage of what some cloud providers like AWS offer to comply with these kinds of security requirements.
Solving Complexity
All this translates into having lots of moving parts to manage! Building a WebRTC application is more than just writing the application code. It’s about building a complete communication platform. Despite how hard it sounds, it’s a doable task! Here at WebRTC.ventures, we’ve been doing it since 2015.
Done correctly, you’ll have a powerful product that for sure will make a difference in your business and with your clients. CPaaS providers are aware of this and that’s why they provide a simple alternative for these challenges.
A CPaaS provider abstracts the complexity of managing a signaling channel, and STUN/TURN and media servers, while also making sure that they are always available, scale as your user base grows, and comply with regulatory requirements. All this is in a cost effective way!
Up Next
Stay tuned for two more posts in this series:
- How to Build WebRTC Applications Using CPaaS, Part Two: The Implementation
- How to Build WebRTC Applications Using CPaaS, Part Three: The Options
