As smart video surveillance has grown, so has reliance on real-time video streaming protocols in IoT like the Web Real-Time Communication (WebRTC) protocol. In the world of WebRTC, the terms ICE, STUN, and TURN often come up. These are protocols that ensure seamless and secure connections between devices to share data and transmit video.

If you’re unfamiliar, WebRTC is an open-source technology that enables communication between various browsers and devices. The devices involved are known as peers, and the goal is to establish peer-to-peer (P2P) connections. WebRTC allows web applications to capture and transmit audio or video media, whether it’s video calls between friends or livestreams from cameras to personal IoT devices. More recent updates to WebRTC include new data channels that allow the transmission of other types of data as well.

However, establishing P2P connections with WebRTC can be challenging due to network configurations and restrictions. That’s where ICE, STUN, and TURN come into play. While these protocols have different methods, their overall goal is to enable low latency communication between peers, even when they are behind restrictive firewall rules or have scrambled IP addresses. Understanding how these protocols work helps ensure continuous and reliable video transmission in critical applications.

But first, NAT

Before diving into the protocols, it’s essential to familiarize ourselves with the concept of Network Address Translation (NAT), a key component of internet-based communication. NAT is a technique used to transform the private IP address of a device (IP addresses that can only be used inside your local network, i.e. cannot be routed on the “real” internet) – be it a computer or a smart security camera – into a public IP address. This translation makes the device discoverable to external servers, such as WebRTC signaling servers. Additionally, NAT enhances security by masking private devices’ IP addresses from being directly visible to external servers.

However, using NAT introduces a challenge. While it makes the public IP address discoverable, which is necessary for establishing connections between peers, it also prevents Peer Two from seeing the actual private IP address of Peer One. This complication can hinder direct communication between peers, as the private IP address remains hidden behind the NAT.

So, what does NAT have to do with our three protocols? Well, to overcome the complications that NAT gives rise to, we use what’s known as Session Traversal Utilities for NAT, or STUN. This is a protocol used to discover the public IP address and port of a device situated behind a NAT.

In more complicated contexts with stricter security, there is also Traversal Using Relays around NAT (TURN), a protocol used when direct peer-to-peer communication is not possible, often due to restrictive NATs or firewalls. In such cases, a TURN server acts as a relay between the communicating peers.

TURN versus STUN

In the context of WebRTC, TURN and STUN are protocols that facilitate peer-to-peer connections by helping developers navigate the complexities of NAT. Despite their shared goal of enabling effective communication between peers, TURN and STUN serve distinct functions and operate in different scenarios.

STUN is suitable for scenarios in which NAT traversal is relatively straightforward, and direct connections are feasible. Meanwhile, TURN is essential in environments with highly restrictive NATs or firewalls in which direct connections fail.

STUN has a minimal impact on performance, as it aims to establish direct connections and is less resource intensive, as it only relays the initial session setup data through a server. Conversely, TURN introduces additional latency and bandwidth usage due to relaying all traffic through the server.

Overall, STUN is used to discover public IP addresses and facilitate direct peer-to-peer connections in less restrictive network environments. TURN, on the other hand, provides a reliable fallback by relaying traffic when direct connections are not possible, ensuring connectivity even in the most challenging network conditions.

What about ICE?

Now that we’ve discussed STUN and TURN, what about ICE? ICE, or Interactive Connectivity Establishment, helps STUN and TURN work together efficiently. Imagine ICE as a skilled air traffic controller that manages the flow of multiple planes (STUN and TURN) to ensure they can take off and land smoothly at their destinations.

ICE performs connectivity checks to determine the best possible path between the peers. This involves sending connectivity check messages using the STUN protocol to verify if a candidate pair can communicate successfully.

Once the connectivity checks are complete, ICE selects the best candidate pair that provides the most efficient and reliable path for communication. This selection process prioritizes direct peer-to-peer connections discovered via STUN, due to their lower latency and reduced server load. However, if such a direct path is not feasible, ICE opts for the relay path through TURN servers.

Practical examples of STUN and TURN in action

To better understand how STUN and TURN work, let’s explore some practical scenarios involving real-time communication, particularly within the context of a video call application. For instance, imagine Alice and Bob wish to establish a video call using a WebRTC application. Both are on networks with moderate NATs that support direct peer-to-peer connections.

Alice and Bob both launch their WebRTC applications and start the process of setting up a video call. Each application collects local IP addresses and ports. Alice and Bob then send requests to STUN servers to discover their public IP addresses and ports. The STUN server responds with the public IP address and port for each device. Alice and Bob exchange their gathered candidates, the local and public IP addresses and ports through the signaling server.

Using the ICE framework, Alice and Bob perform connectivity checks to determine the best path for communication. Alice and Bob send STUN binding requests to each other’s public IP addresses. The checks succeed, and a direct peer-to-peer connection is established using their public IP addresses. The video call proceeds with minimal latency.

Using TURN when direct peer-to-peer fails

Now imagine a similar scenario in which Carol and Dave want to establish a video call using a WebRTC application. However, Carol is behind a very restrictive NAT that prevents direct peer-to-peer connections. This is how the process would work with TURN.

Initiation

Carol and Dave launch their WebRTC applications and initiate the call setup.

Candidate Gathering:

Similar to what happened in the first example, both applications gather local IP addresses and attempt to get public IP addresses via STUN servers.

STUN Response

The STUN server responds, but Carol’s NAT type is too restrictive for a direct connection.

Candidate Exchange

They exchange candidates via the signaling server, including any gathered TURN server candidates.

Connectivity Checks

ICE attempts direct connectivity checks, but they fail due to Carol’s restrictive NAT.

TURN Allocation

Carol’s application requests a relay allocation from a TURN server. The TURN server provides a relay IP and port.

Relayed Communication

The signaling process includes TURN candidates. Dave’s application now tries to connect to the TURN server’s relay address.

Successful Connection via TURN

The connection succeeds via the TURN server. Data packets from Carol are sent to the TURN server, which then forwards them to Dave, and vice versa. This allows the video call to proceed, albeit with some additional latency due to the relaying.

How are ICE, STUN, and TURN relevant to IoT?

For IoT devices, especially those requiring real-time data transmission like security cameras or medical monitors, uninterrupted connectivity is crucial. STUN and TURN ensure this by addressing the challenges of NAT and providing reliable communication pathways between devices. It’s important to understand that WebRTC is not completely limited to video streaming data either; since its development, it has also become capable of transmitting other types of data from devices through specific data channels. This means the use of WebRTC in IoT has expanded significantly.

For instance, in a smart security scenario, surveillance cameras deployed across a building need to send live video feeds to a central monitoring station. Smart alarms will add another layer of safety to the system, and with WebRTC to enable an immediate exchange of information, alarms will trigger in real-time and quickly respond to human commands and alerts to secure the premises or notify emergency services. Using STUN, these cameras and alarms can discover their public IP addresses and establish direct connections with the monitoring station, ensuring high-quality video transmission and communication with minimal latency.

Alternatively, consider a senior care facility using IoT devices with motion sensors to monitor patient falls. If the network environment includes restrictive NATs that prevent direct connections between the devices and the central monitoring system, TURN servers can relay the critical data. This ensures that the staff receives continuous updates on patients’ conditions, allowing for timely interventions.

Final thoughts

Understanding the roles of ICE, STUN, and TURN is crucial for developing reliable and continuous video transmission in health and safety IoT applications. These protocols ensure that real-time communication between devices is efficient and robust, even in challenging network environments. By leveraging the strengths of each protocol, developers can maintain the dependable connectivity essential for critical video applications.

Read our other resources

We’ve also published a range of resources for our community, including:

• What does RTC mean?, which provides an explainer for RTC and P2P connections
• Understanding WebRTC IoT in 2024, which explains the use of WebRTC in the IoT landscape
• What is TCP tunneling in IoT, which offers a guide on how to connect to and send data via a TCP tunnel