WebRTC NAT Traversal Methods: A Case for Embedded TURN

The way we communicate through the internet has changed dramatically. In order to avoid issues with interoperability in peer-to-peer video conferences, developers need to have tools in their arsenal to deal with firewalls and routers used in both home and business environments. All routers, even the most basic home-based router, have a feature called Network Address Translation (NAT). NAT essentially hides a home or office's internal network from the public internet, so a direct peer-to-peer connection is generally not possible without punching a hole through the NAT.

There are a number of mechanisms for NAT hole punching - including ICE, STUN and TURN - and all must be in place to ensure that a connection can always be established regardless of the security protocols in use.

That is why we are excited to announce that LiveSwitch now features embedded TURN -- an industry first for on-premise and self-hosted video solutions! This advancement brings with it many exciting implications, that we will discuss in detail below, but before we dig in, let’s look at the various methods of NAT traversal.

Who are you? Network Address Translation (NAT)

Network Address Translation (NAT) is the process where a network device - a router or firewall - assigns a public IP address to a computer (or group of computers) inside a private network to allow those computers to access the internet by masquerading them as the firewall. While this is beneficial for security, it makes it difficult, and sometimes impossible, for peers (computers, smart phones, etc) to be able to establish connections without the assistance of a third party.

That is why there are several specifications used in WebRTC to help overcome these hurdles. The first is Interactive Connectivity Establishment (ICE). ICE is used to find all the ways for two peers to talk to each other by essentially removing the firewall's mask. It has two main roles, gathering candidates and checking connectivity. It guarantees that if there is a path for two clients to communicate, it will find that path and ensure it is the most efficient. ICE makes use of two protocols - STUN and TURN - which we will delve into in more detail in this post.

Who am I? An Intro to STUN

STUN stands for Session Traversal Utilities for NAT and is a lightweight and simple method for NAT traversal. At its essence, STUN simply asks the question “What is my IP address?” When a client in a private network that is behind a NAT needs to find its public facing IP address (the firewall's mask), it can make a request to a STUN server. The STUN server will then reply with the public IP address for the requesting party which can then be used to set up a peer-to-peer connection.

This method of NAT traversal has the benefit of being simple but it is not sufficient for overcoming all firewalls and all forms of NATs.

Symmetric NATs – A case for TURN

Not all NATs are the same. There are four main categories of NATs, but for simplicity in describing when TURN is required, we'll roll it up into two - Cone and Symmetric. To explain the difference, it’s simplest to think of each NAT device like a doorman to an apartment building. The main difference between Cone and Symmetric NATs is that the Cone NAT doorman will allow visitors to use a single door to visit a tenant. A Symmetric NAT’s doorman will make each visitor use a different door to the tenant’s apartment, even if it is the same tenant each time.

To bring this back to networking terms, a Symmetric NAT changes both the source IP address and the source port. Symmetric NATs make it difficult to establish a direct connection with a STUN server because if you were to ask two different STUN servers for your public IP address a Symmetric NAT (the doorman) will give you the same IP address but two different ports (doors).

When a STUN server is no longer sufficient, you must use a TURN server to relay media. It is important to note that not all symmetric NATs require a TURN server. TURN is only necessary if one side of the connection is symmetric and the other side is either symmetric or port restricted cone.

Turning to TURN

When it is determined by ICE that a direct connection using the IP addresses provided by STUN cannot be made, a request is made to a TURN (Traversal Using Relays around NAT) server to ask it if it can be used as a relay point. TURN servers are used to relay traffic if a peer-to-peer connection fails. It is important to note that a TURN server is a STUN server with the built in relaying functionality.

TURN is often used as a last resort when no other connection type is possible. Since TURN relays all media for communication through the server, it has higher operating costs than STUN due to the additional bandwidth and CPU usage placed on the TURN host. It is estimated by our one of our partners callstats.io, that as many as 30% of WebRTC enabled video conferences require the use of a TURN server. As such, all WebRTC-enabled video conferencing solutions need to have a solution for TURN.

Embedded TURN – A better solution

For anyone who needs end-to-end control of their WebRTC infrastructure and therefore needs an on-premise or self-hosted solution, installing and maintaining TURN servers in addition to media servers and other infrastructure adds a level of complexity to deployment for operation teams.

That is why LiveSwitch features embedded TURN – an industry first for on-premise WebRTC solutions! This means that using LiveSwitch as the server stack for your self-hosted solution, you can automatically spin up a STUN/TURN server with no additional set-up on the server side or on the client side.

Embedded TURN has a lot of advantages:

• Seamless Integration: From a software point of view the integration is seamless and NAT traversal happens automatically regardless of connection type.
• Easy Maintenance: Rather than installing, maintaining and configuring multiple TURN servers, LiveSwitch does the heavy lifting for you. Integrating TURN server functionality into your media servers is simple and requires very little configuration.
• Streamlined: LiveSwitch’s embedded TURN means your application only needs connect to a single server for all server-side functionality. This make it far easier for your DevOps team to manage, allowing them to focus their attention on more important things.