August 4, 2022
Comments Off on Automatic Configuration for WebRTC (Part I)

Building repeatable and reliable deployments and configurations of the infrastructure that supports your WebRTC application can be really helpful to prevent errors and optimize available resources. It is also especially useful when you are ready to scale your application. What follows is technically DevOps content, but is also quite valuable for complex WebRTC processes like building Media and STUN/TURN servers.

Managing Complexity

The first thing we need to take into consideration is the fact that WebRTC is a technology, not a solution. In other words, you need to consider WebRTC as a building block. In conjunction with other building blocks, it is used to build the actual solution.

The process of putting the building blocks together is complex, with multiple tasks involved and often limited resources. The challenge here is to be able to know how to manage such resources optimally.

Here’s the part where automation can be helpful: being able to do something once and then apply it multiple times saves effort that can be spent on other tasks.

It’s also important to remember that automation it’s not a one-size-fits-all approach. There are things that cannot be automated, so there is still work that needs to be done manually.

What Automation Can (and Can’t) Do

Automation is a really helpful tool, but it’s by no means a solution for everything. Here are some scenarios where automation can be useful:

  • Reduce the amount of time and effort spent on repetitive tasks. Any task that consists of repetition of the same steps is an ideal candidate for automation, as this will allow us to focus resources on more creative and/or analytical tasks.
  • Provide a repeatable process. Automation allows you to build something once and then implement it multiple times. This reduces the possibility of unintentional errors that can appear when doing the same thing over and over manually.
  • Manage configuration through version control. The usual approach for automation is to write scripts. Such scripts can be managed through a version control system, such as Git, and have “versions” of the configuration which is useful when testing and/or reverting new settings.

Of course there are things automation can’t do, it’s not possible to automate the whole process. There is still work that needs to be done manually but you can leverage automation for those repetitive and tedious tasks so you can focus on actually building your product.

Automation Tools

Terraform and Ansible are two popular tools used for automating tasks. Terraform is used to automate infrastructure creation. Ansible is used for automating configuration.

Some advantages of both tools are the following:

Terraform

  • Automates provisioning infrastructure on any cloud vendor
  • Open source
  • Delivers infrastructure as code

Ansible

  • Automates configuration
  • Runs in an agentless fashion, no additional infrastructure is required
  • Runs on top of SSH

The automation approach using the aforementioned tools consists of provisioning the infrastructure using Terraform and once it’s up and running, apply the configuration using Ansible.

A depiction of an approach for automation using Terraform & Ansible on AWS with EC2 instances.

What to Automate?

So far we’ve discussed the benefits (and limitations) of automation, and also some tools that can be used. But what should be automated? This will ultimately depend on each project but in our day-to-day work on WebRTC projects, we have identified two main components that are ideal candidates for automation: Media and STUN/TURN servers.

A media server performing Selective Forwarding Unit for multiple peers.

A media server is a piece of infrastructure that sits in the middle of the WebRTC traffic. Media servers are capable of multiple things, from simply routing the traffic to other peers to transcode and join media streams and send a single stream to other peers.

Two representations of peers connecting. The one at the left is performing a STUN request for ICE candidate exchange, and the one on the right depicts communication using TURN.

STUN/TURN servers are what enable communication in the first place. During the exchange of ice candidates, a peer can make a STUN request to a STUN server in order to know how it can be reached from outside the local network, and when direct communication is not possible due to firewall restrictions, traffic can be relayed through a TURN server.

Both Media and STUN/TURN servers provisioning and configuration can be automated using Terraform and Ansible, this is specially important when building a WebRTC solution on scale as it’s highly likely that you’d end up needing multiple instances of such services.

You can even combine your automation scripts with the scalability features that most cloud vendors offer and set up an infrastructure that can adapt to the demand of your WebRTC solution.

Stay tuned for the next part of the series where we will look at an example of how to provision and configure a set of Media and STUN/TURN servers using two popular options: Janus WebRTC Server and CoTURN.

For more on the subject (and a demo!):

These types of innovative solutions are the reason people come to our expert team at WebRTC.ventures when they are interested in integrating (or optimizing!) live video or audio into their applications. Learn more about our WebRTC development services and tell us how we can help your business! 

Recent Blog Posts