Riedel STAGE™ & Virtual SmartPanel® – How to Implement STUN and TURN
Introduction
With the introduction of Riedel’s new STAGE platform we add the capability to use the new Virtual SmartPanel for secure local area (LAN) and wide area (WAN) intercom environments.
A key component of this architecture is WebRTC technology combined with the ability to link to your User Directories and Identity Providers. In order to build a secure, effective connection across single or multiple firewalls and NAT boundaries, the use of STUN and/or TURN services need to be provisioned.
This section aims to cover the use cases for STUN and TURN services and how to implement these in the Riedel STAGE environment.
For devices such as a Smartphones, these may work in the local area network, for example, on a Wi-Fi network but if for any reason the network connection changes to that of the mobile service provider, it will be on a different network and therefore will stop working as its IP address will not be known by other devices in the system and stream establishment will have to be restarted. When a Smartphone has internet access through the mobile service provider, STUN or TURN may be required for the Virtual SmartPanel to establish a connection with STAGE.
What is STUN?
STUN stands for Session Traversal Utilities for NAT and is currently defined in RFC 8489 (previously RFC 3489 & RFC 5389) by the Internet Engineering Task Force (IETF). It's a protocol used to determine network address information about an endpoint behind a Network Address Translator (NAT) and/or a firewall.
In simpler terms, STUN helps devices discover their public IP address and port number, even when they're behind a firewall or NAT router. This information is crucial for establishing direct peer-to-peer connections.
When is STUN Required for Virtual SmartPanel Usage
The Riedel Virtual SmartPanel utilizes WebRTC for the real-time audio communication between the application and the WebRTC Gateway server.
STUN is essential for WebRTC when peers are behind different NATs, which is almost certainly the case unless both clients are within the same local area network (LAN).
NAT (Network Address Translation): Many home and small office networks use NAT to share a single public IP address among multiple devices. This can make it difficult for devices to directly communicate with each other.
WebRTC: A technology designed for real-time peer-to-peer communication, often used to transfer audio/video data between two endpoints. WebRTC primarily relies on devices directly connecting with each other in a 1:1 relationship, to do this, they need to know each other’s IP addresses.
STUN’s Role
Discover Public IP: STUN helps devices determine their public IP address and port number.
NAT Traversal: By knowing their public addresses, devices can attempt to establish a direct connection with each other.
ICE (Interactive Connectivity Establishment): STUN is a key component of ICE, which is a framework that tries different connection possibilities to find the best way for two peers to communicate.
In summary, STUN is not always strictly required for Virtual SmartPanel connections when all clients are internal to the same network and there is no NAT involved in the audio path, but it significantly improves the chances of establishing a direct peer-to-peer connection, especially in complex network environments.
Additional Considerations
For devices such as a Smartphones, these may work in the local area network e.g. a Wi-Fi network but if for any reason the network connection changes to that of the mobile service provider, it will be on a different network and therefore will stop working as it’s IP address will not be known by other devices in the system and stream establishment will have to be restarted.
While STUN is helpful, it might not always be sufficient. In cases where NAT traversal is impossible, a TURN server can be used as a relay for data.
Example System Drawing
What is TURN?
TURN: A Relay for WebRTC
TURN stands for Traversal Using Relays around NAT. It is a protocol used in WebRTC to establish a communication channel between two peers when a direct connection is not possible due to network restrictions, such as firewalls or NAT (Network Address Translation).
When is TURN Required for Virtual SmartPanel Usage?
While not always necessary, TURN becomes crucial in the following scenarios:
Strict Firewalls: If both peers are behind strict firewalls that block incoming connections, TURN can relay data between them.
Symmetric NAT: This type of NAT makes it difficult for peers to establish direct connections, so TURN is often required, this is common when both peers are behind a strict NAT and can’t map ports between Inside/Outside.
Mobile Networks: Mobile networks often have dynamic IP addresses and complex NAT configurations, making TURN a much more reliable option.
Unfavorable Network Conditions: In cases of network congestion or packet loss, TURN can provide a more stable connection.
How does TURN work?
TURN operates as a relay server. It receives data from one peer (end device), stores it temporarily, and then forwards it to the other peer. This indirect communication path ensures that data can be exchanged even when direct peer-to-peer connections are hindered.
Important note: While TURN is a valuable tool, it is generally less efficient than direct peer-to-peer connections due to the added latency introduced by the relay server. Therefore, it's recommended to prioritize direct connections using protocols like STUN before resorting to TURN.
In summary, TURN is a vital component in WebRTC for overcoming network challenges and ensuring reliable communication between peers. However, it is essential to consider the trade-offs between performance and reliability when deciding whether to implement TURN in your WebRTC application.
Setting Up and Configuring STUN within Riedel STAGE
Setting up a STUN service for use with Riedel STAGE and the Virtual SmartPanel is straightforward. All you need is the publicly available STUN URL which you then add into the associated part of the STAGE configuration User Interface.
Free STUN services
To simplify deployment, see below for a list of common, freely accessible STUN services that can be added to the Riedel STAGE configuration to fulfill system STUN requirements.
All ports are listed below as [FQDN]:[Port]. Please note DNS is required to be configured to resolve these addresses. For the WebRTC server, ensure that this is configured within System Commissioning > Configuration for the respective devices. Please refer to chapter Configuration for more information. The address is resolved through the device starting the communication to the service. In this case, the WebRTC Gateway and the device hosting the Virtual SmartPanel App itself.
The Riedel STAGE configuration will also accept standard [IPv4 Address]:[Port] for STUN configuration should you choose to use static addresses for STUN servers.
Free Google STUN Servers
stun.l.google.com:19302
stun1.l.google.com:19302
stun2.l.google.com:19302
stun3.l.google.com:19302
stun4.l.google.com:19302
Free Cloudflare STUN Servers
stun.cloudflare.com:3478
An additional list of freely available STUN Servers can be found here
There are many other public (or private) STUN services available that are not listed above that can be used with Riedel STAGE and the Virtual SmartPanel, if you have a particular service they prefer to use.
Adding the Selected STUN Service to Riedel STAGE
Login to Riedel STAGE as a User with access levels set to either System Administrator or Technical Administrator. See chapters Start & Login and Users.
Navigate to System Management from either the Dashboard or popout menu on the left of the screen. See chapter Menu.
Proceed to the Virtual SmartPanel Settings tab across the top of the window.
Select the STUN tab.
Click on the Add button to add a STUN entry to the list.
URL | Set the URL/IP for the STUN service in the following format |
Username | Optional: Set the required username and password for the TURN service. |
Password |
Click Save.
The STUN entry has now been added to the Riedel STAGE system and is available for use.
Additional Considerations
When adding STUN / TURN services to Riedel STAGE, you can add one or many STUN / TURN services to your system for added resiliency in the event of an outage of one or more configured services.
Setting Up and Configuring TURN within Riedel STAGE
Setting up a TURN service for use with Riedel STAGE and the Virtual SmartPanel is straightforward. All you need is a TURN service that is either created by you, or a private paid service. This service comes with a TURN URL which you then add into the associated part of the STAGE configuration User Interface.
Note: Riedel provides guidelines only on the recommended implementation of the Coturn service as described below. It is the user's responsibility to deploy, support, update and diagnose any issues with the implementation.
Installing a TURN Server
Though Riedel does not create or distribute a TURN service, we have provided an example installation process for a commonly used open-source TURN resource called Coturn.
It is available on GitHub here: GitHub - coturn/coturn: coturn TURN server project
The example configuration below provides basic guidance on how to install Coturn via Docker on an Ubuntu 22.04 machine.
Installing COTURN through Docker on Ubuntu Server 22.04 LTS (Jammy Jellyfish)
Prerequisites
A server with sufficient resources (CPU, RAM, network).
Root or sudo access to the server (once Ubuntu Server 22.04 Installed)
Basic understanding of Linux command line and Docker.
Step-by-Step Installation
Step 1: Install Ubuntu Server 22.04 Server Operating System
Obtain the Ubuntu 22.04 Server installation image from the official Ubuntu website.
More information can be found here: Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Create a bootable USB drive or DVD using a tool like Rufus or Etcher.
Rufus can be found here: Rufus - Create bootable USB drives the easy way
Etcher can be found here: balenaEtcher - Flash OS images to SD cards & USB drives
Boot your server from the installation media and follow the on-screen instructions to install Ubuntu.
More information can be found here: Basic installation - Ubuntu Server documentation
Step 2: Update and Upgrade the Operating System
Once the installation is complete, log in as root or a user with sudo privileges.
Update the package lists and upgrade the system:
sudo apt update && sudo apt upgrade -y
Step 3: Install Docker
Follow the official instructions from Docker here listed under “Install using the apt repository”
Follow the “linux postinstall” instructions to allow non-privileged users to run Docker commands and to start Docker on system start/restart
Step 4: Download (Pull) the Latest coturn Docker Image
docker pull coturn/coturn
Step 5: Follow the Official Guide to Configure and Run your coturn Docker Image
coturn/docker/coturn/README.md at master · coturn/coturn · GitHub
Additional Considerations
Performance: Adjust the container resources (CPU, Memory) based on your load.
Monitoring: Use Docker tools to monitor the container's resource usage and health.
Redundancy: Create additional COTURN instances on alternate servers and add these to Riedel STAGE for added COTURN redundancy.
Note: This guide provides a basic installation. For advanced configurations and troubleshooting, refer to the official COTURN and Docker documentation.
By following these steps, you should have a COTURN server running in a Docker container on your Ubuntu Server 22.04 LTS system.
Adding a TURN Service to Riedel STAGE
Login to Riedel STAGE as a User with access levels set to either System Administrator or Technical Administrator. See chapters Start & Login and Users.
Navigate to System Management from either the Dashboard or popout menu on the left of the screen. See chapter Menu.
Proceed to the Virtual SmartPanel Settings tab across the top of the window.
Select the TURN tab.
Click on the Add button to add a TURN entry to the list.
URL | Set the URL/IP for the TURN service in the following format |
Username | Optional: Set the required username and password for the TURN service. |
Password |
Click Save.
The TURN entry has now been added to the Riedel STAGE system and is available for use.
Additional Consideration
When adding these services to Riedel STAGE, you may add one or many TURN services to your system for added resiliency in the event of an outage of the services configured.
Appendix
NAT Variations (from RFC3489 Section 5)
In this section, it is assumed that you are familiar with NATs. The way a NAT handles UDP packets can vary according to the different possible technical implementations available listed below. As a result, the method to tunnel packets through a NAT has to be adjusted accordingly.
Full Cone
A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
Restricted Cone
A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.
Port Restricted Cone
A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.
Symmetric
A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.
Visual Overview of Possible Scenarios with the Applicable STUN / TURN Counter-Measure Option
NAT | FULL CONE | RESTRICTED CONE | PORT RESTRICTED CONE | SYMMETRIC |
FULL CONE | STUN | STUN | STUN | STUN |
RESTRICTED CONE | STUN | STUN | STUN | STUN |
PORT RESTRICTED CONE | STUN | STUN | STUN | TURN |
SYMMETRIC | STUN | STUN | TURN | TURN |
Additional Reading
RFC 3489 - STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (ietf.org) (Original RFC)
RFC 5389 - Session Traversal Utilities for NAT (STUN) (ietf.org) (Intermediate RFC)
RFC 8489 - Session Traversal Utilities for NAT (STUN) (ietf.org) (Latest RFC)