WebRTC servers explained

WebRTC is a peer-to-peer communication technology. However, you still need WebRTC servers to perform certain tasks involved with establishing the direct connection between devices.

The idea of getting two devices to communicate seems simple, in principle. But, once you get the internet involved, things get a lot more complex. And you need WebRTC servers to handle that complexity.

→ Telnyx provides everything you need to get started with WebRTC in 20 minutes, including servers. Try it out.

WebRTC Servers Explained:

WebRTC is a foundational technology, one that larger solutions and services can be built on. However, like any other communication technology, WebRTC requires some computing power, in a certain configuration, to accomplish all the tasks that enable people to have real-time conversations over the internet.

WebRTC servers are just like any other servers. They’re simply set up to accomplish the tasks which are specific to WebRTC communication.

What is a WebRTC Server?

A WebRTC server is a computer that handles some aspect of establishing peer-to-peer connections, transmitting data, and maintaining connection stability for real-time communication. There are four key WebRTC servers: WebRTC media servers, WebRTC signaling servers, WebRTC TURN servers, and WebRTC NAT traversal servers.

Generally speaking, WebRTC servers handle the process of negotiating a connection between the two devices in a real-time conversation and managing the connection once it’s established. Most of the time, the communicating devices do most of the data sending and receiving. But if you're building your own WebRTC services, you need WebRTC servers to deliver reliable, high quality real-time communication using WebRTC.

→ Talk to our experts about how our WebRTC infrastructure can eliminate the need for your own servers.

Does WebRTC Need a Server?

WebRTC can easily connect two browsers on a local area network. However, WebRTC and browsers alone aren’t capable of connecting through the internet. WebRTC needs a server to handle tasks like getting through firewalls and routing data outside of your local network.

In theory, a single physical computer could perform all the tasks that get handled by servers in a WebRTC call. However, network infrastructures are usually outsourced and distributed. So each WebRTC server ends up being a separate computer. But WebRTC servers can be categorized as tasks that must be performed by a computer during a WebRTC call. Here at Telnyx, we built our own global IP communications network for WebRTC, SIP trunking, messaging, and more.

WebRTC Server Types

There are three core WebRTC server types: NAT traversal servers, signaling servers, and media servers. NAT traversal servers establish a connection. Signaling servers maintain connection stability and manage calls. And media servers provide media processing for things like call recording and group calls.

That’s a very high level look at what the different types of WebRTC servers do. As you probably guessed, each of these functions involves several sub tasks.

WebRTC Media Server

A WebRTC media server processes audio and video data from WebRTC calls to provide certain WebRTC calling features. Most commonly, media servers are used to mix audio and video signals for group calls, since browsers are not capable of syncing multiple media streams.

WebRTC media servers are theoretically optional. If your WebRTC app only offers one-to-one calls, a media server may not be necessary. However, you’ll need a WebRTC media server to deliver functionality like:

• Conference and group calls.
• Call recording.
• Live WebRTC streaming and call broadcasting.

Most WebRTC media servers are outsourced and delivered by CPaaS providers. But it’s possible to develop your own media servers. But it’s time consuming and resource intensive.

→ Talk to our WebRTC experts and learn how we take care of media servers for you.

WebRTC Signaling Server

The devices on a WebRTC call are usually not capable of managing the call connection. That’s what the WebRTC signaling server does: it provides the signals that indicate when a WebRTC connection needs to be initiated, manage the connection while the call is in process, and close the connection when the call ends.

WebRTC signaling servers don’t transmit any of the call data. The signaling server just helps coordinate all the connections and computers that are involved with transmitting the call data. This ensures that the connection is reliable for the duration of a WebRTC call and that the connection does not remain open after the call has ended.

Unlike the media server, a WebRTC signaling server is mandatory. And most signaling servers are also outsourced from IaaS providers. Depending on the signaling protocol you use, you’ll either have a WebRTC SIP server, XMPP server, or an MQTT server. It’s also common for developers to choose a different protocol and develop their own WebRTC signaling server.

WebRTC TURN Server

A WebRTC TURN server is technically a NAT traversal server. However, the TURN (Traversal Using Relays around NAT) server also works as a failover in case the direct peer-to-peer connection cannot be established.

If the security layers cannot be navigated, each device on a WebRTC call can connect to the TURN server. Then the TURN server relays the audio and video data between the devices. This method works. However, it’s not ideal and should only be used when the peer-to-peer connection fails.

TURN server is a necessity for delivering reliability in WebRTC calls. You must have a WebRTC turn server. Also, a TURN server needs to be a powerful and robust server that’s physically located as near as possible to the devices on the WebRTC call. Otherwise your backup connection might fail, which would cause an unrepairable disconnection. As such, most TURN servers are typically sourced from IaaS providers.

→ Talk to our WebRTC experts and learn how we take care of TURN servers for you.

WebRTC NAT Traversal Server

There are technically two types of WebRTC NAT traversal servers: STUN (Session Traversal Utilities for NAT) and TURN servers. Both servers accomplish the same goal: navigating through firewalls and NAT devices to establish a peer-to-peer connection between devices behind those security layers. However, STUN servers and TURN servers use different methods.

On a normal WebRTC call, the STUN server requests the public IP address for each device on the call, then uses that IP address to route call data through the firewall and NAT device.

However, occasionally this doesn’t work. If that happens, the call data must be routed around the firewall and NAT device. If that’s the case, then the TURN server gets used to relay the data between the devices on the WebRTC call.

Having a STUN and TURN server ensures that WebRTC calls can connect, even if there’s a problem negotiating a connection through the security layers. It’s possible for a STUN and TURN server to be the same computer. However, these two servers will often be separate computers due to the performance and geolocation requirements involved with TURN servers.

It’s most common for STUN servers to be outsourced to IaaS providers. However, there are providers that offer free STUN servers. Free STUN servers should never be used, because they cause frequent failovers to your TURN servers.

→ Use our WebRTC SDKs and stop worrying about NAT Traversal

How to Set Up a WebRTC Server

Setting up a WebRTC server takes some work. But these are the (VERY) basic steps:

1. Procure the hardware.

No matter which type of WebRTC server you’re setting up, you’ll need a computer to do all the computing. Most of the time this will involve sourcing some hardware from an IaaS provider. But you can use your own equipment.

→ Find out how our network eliminates the need to procure your own WebRTC hardware.

2. Choose a signaling protocol and configure your server for your chosen protocol.

There are a lot of options. SIP works well for most things. However, certain applications may require XMPP, MQTT, or a proprietary signaling protocol.

→ Our Mission Control Portal gives you built-in SIP signalling. Try it out.

3. Configure NAT and firewall traversal using the ICE framework.

This only applies to setting up your STUN and TURN servers, since those are the servers that must negotiate the peer-to-peer connection through these security layers. The ICE framework essentially generates a list of potential protocol and routing configurations for the peer-to-peer connection, then selects the best one from the available options.

→ Talk to an expert about our STUN and TURN servers.

4. Connect your server to the WebRTC application server.

The application server is where your WebRTC application is hosted. The super simple explanation is that the application server stores the website where end users use your WebRTC app.

→ Learn how to use our pre-built WebRTC application to call your phone.

5. Find users for your WebRTC server.

The last step is to get people to use your WebRTC app. That can be deceptively difficult, though. So don’t take this step too lightly.

That’s the super distilled process for setting up a WebRTC server. Each of these steps involves writing some code, using APIs, and maybe even negotiating a service contract.

But the important thing is to understand which servers you need for a complete WebRTC infrastructure. That way you don’t get blindsided by development requirements and overhead when you start building your WebRTC solution.

At Telnyx, we're here to help you cut through all of the technical intricacies of WebRTC and get set up making calls between browsers and phone numbers in minutes. Follow our quickstart guide to get up and running in 20 minutes, or talk to a WebRTC expert to find out how we can help.