Session Traversal Utilities for NAT is a standard method of NAT traversal used in WebRTC. The definition is in IETF RFC 5389.

It is one of two NAT traversal servers that are used in WebRTC (the other one is TURN).

At its core, it’s purpose is to answer the question “what is my IP address?” It does that by using a STUN server.

What is a STUN server?

It is a client-server protocol.

A STUN server is a server that runs on the public network and replies to incoming requests. The responses sent out include the public IP address the request was sent to him from. This effectively answers the question “what is my IP address?”

In most cases, the STUN servers aren’t installed and managed as separate entities but are rather installed together with TURN servers.

While there are free public servers that can be used (such as the one Google operates), it isn’t advisable to use them in commercial services as your main NAT traversal mechanism.

Using a STUN server

A WebRTC client has to know its public IP address in order to get more sessions connected successfully. For that purpose, WebRTC sends a request to a STUN server asking for its public IP address. The server replies back to the WebRTC client with the public IP address the request came from. This way, the WebRTC client learns what its public IP address is.

The WebRTC client then shares the public IP address it received from the server with its peer.

It might not always work. With some network architecture and NAT device types, the public IP address obtained via STUN will not work. This is why we use it in conjunction with TURN and ICE.

As a protocol, it is lightweight and simple, making the availability of public, free and open servers possible.

Free and public Session Traversal Utilities for NAT server

There are various free STUN servers available out there.

It is lightweight and carry no real authentication mechanism to it. This makes it simple for developers to connect to freeservers without any technical hurdles. It is not advisable to do so.

• These free STUN servers might not be there for you tomorrow, and there is no one that offers support for them or even guarantees that they will be there
• You will usually also need TURN servers and these aren’t free. As a result TURN servers also double as STUN servers and you will need to deploy or pay for those, just use them for STUN as well
• Using too many STUN and TURN servers in the iceServers list is counterproductive, often causing delays in connectivity and increasing network congestion instead of improving your chances to connect

Best practices

• STUN doesn’t cost much to operate, which is why there are various free servers you can connect to. Accordingly if you are using a free or a public server (like the famous stun.l.google.com:19302 server), expect it to go down from time to time as you have no control or an SLA for it
• STUN is usually deployed with TURN servers. Focus on a TURN server solution and STUN “will follow”
• Basically configuring TURN/UDP implicitly also implements the STUN protocol. As a result if you use a TURN/UDP server, you can do away with explicitly stating the server in the iceServers configuration of a peer connection

See also the episode of “WebRTC Insights”:

The post STUN: Definition and explanation appeared first on BlogGeek.me.

ice-lite is easy to implement, requiring the media server to only answer incoming STUN binding requests and acting as a controlled entity in the ICE process itself. This simplicity makes it quite popular among implementations of SFUs and other media servers.

Support for ice-lite is announced in the SDP as a=ice-lite.

The post ice-lite appeared first on BlogGeek.me.

This saves a few bites over the wire and enables sending media directly to a peer or a server located on the public internet where the local firewall doesn’t allow UDP  transmission out of the boundary of the local network.

ICE-TCP is available in most browsers today (Edge pre-Chromium version doesn’t support ICE-TCP).

The post ICE-TCP appeared first on BlogGeek.me.

The main bottleneck in ICE is the time it takes to start initiating connectivity checks – it requires collecting all ICE candidates in advance, which in turn means interacting with external servers (STUN and TURN servers). This takes several round trips.

Trickle ICE makes the whole process parallel by having the ability to send single or multiple ICE candidates when they become available without waiting for the collection of all candidates.

In the realm of WebRTC, the process of ICE (Interactive Connectivity Establishment) negotiation has evolved significantly. Let’s rewind to the older days to better understand how things have changed.

Originally, ICE negotiations were conducted in a sequential manner. First, a user initiated a request to ascertain their IP address or to procure a relay. This was executed via STUN and TURN servers, which essentially served to collect the actual IP addresses required for the ICE negotiation process.

Upon receiving the results, the user transmitted an offer to the counterpart. The receiving user would then replicate the process: ascertain their public IP address via STUN, and get relay IP addresses from the TURN servers. With IP addresses from both sides now known, the receiving user would send their response, paving the way for connectivity checks.

The Challenge with the Traditional ICE Process

This traditional process, while functional, proved to be time-consuming. There was a considerable amount of latency because we were unable to preemptively conduct these operations. For instance, SIP softphones could perform these tasks ahead of time, but browsers lacked this advantage. Each time a new browser tab or context was opened, the entire process had to be repeated from scratch.

Introducing Trickle ICE

So, how can we trim this process to minimize time waste? The answer lies in an improved mechanism known as Trickle ICE. With Trickle ICE, we collect the candidates concurrently with the connectivity checks. We send the offer while simultaneously querying the STUN and TURN servers for our IP addresses.

The response from the other side is received promptly. That party then asks the same queries to their STUN and TURN servers. The beauty of Trickle ICE is that the connectivity checks commence immediately using local IP addresses. As new addresses are discovered, they’re reported via an “a=ice-candidate” message, enabling the addition of these ICE candidates along the way.

The Benefits of Trickle ICE

Trickle ICE effectively shortens the time required to conduct ICE connectivity checks. This mechanism gets its name from the fact that it ‘trickles’ the candidates from the commencement of the session until a connection is established, thereby streamlining the entire process.

If you are keen to dive deeper into this subject or learn more about WebRTC, I recommend checking out webrtcglossary.com or taking a look at my training courses on webrtccourse.com.

Thank you for reading, and I hope this gives you a clearer understanding of the benefits and functionality of Trickle ICE in WebRTC.

The post Trickle ICE appeared first on BlogGeek.me.

It is a standard method of NAT traversal used in WebRTC. It is defined in IETF RFC 5245.

ICE deals with the process of connecting media through NATs by conducting connectivity checks.

ICE collects all available candidates (local IP addresses, reflexive addresses – STUN ones and relayed addresses – TURN ones). All the collected addresses are then sent to the remote peer via SDP.

Once the WebRTC Client has all the collected ICE addresses of itself and its peer, it starts initiating connectivity checks. These checks essentially try sending media over the various addresses until success.

The downside of using ICE is the time it takes, which can be 10s of seconds. To run faster, a new mechanism was added in WebRTC called Trickle ICE.

Understanding Interactive Connectivity Establishment (ICE) in WebRTC

At the heart of ICE is a robust mechanism that gathers a plethora of IP address candidates from the participating entities in a communication session. These candidates encompass local IP addresses, reflexive addresses obtained via STUN, and relayed addresses acquired through TURN.

The aggregation of these addresses is a precursor to the connectivity checks, which are necessary for establishing a viable media path between the peers. This is because we don’t really know which of these addresses can be used in the specific situation to connect the peers properly.

Upon the collation of address candidates, ICE orchestrates the exchange of these candidates between the peers using SDP message blobs. This exchange is instrumental in ensuring that both peers have a comprehensive understanding of each other’s reachable network endpoints, thereby setting the stage for the ensuing connectivity checks.

Connectivity Checks

The connectivity checks are at the heart of the ICE algorithm. They offer a pragmatic approach to ascertain the most efficient path for media transmission. These checks are conducted by attempting to send media packets across the various address pairs, evaluating the success of each attempt.

The objective is to unearth a pair of addresses that allow for successful media transmission, thereby ensuring an uninterrupted communication session.

However, a notable caveat associated with ICE is the latency incurred during the gathering of address candidates and the connectivity checks. The process can span tens of seconds, which might not be conducive for real-time communications. To improve this, WebRTC introduced a mechanism known as Trickle ICE.

This enhancement expedites the ICE process by allowing the incremental sending and processing of ICE candidates, thereby significantly reducing the setup time required for establishing a connection.

The post ICE: Interactive Connectivity Establishment appeared first on BlogGeek.me.

It is a standard method of NAT traversal used in WebRTC. It is defined in IETF RFC 5766.

TURN Server

TURN is used to relay media via a TURN server when the use of STUN isn’t possible.

The decision whether to use STUN or TURN is orchestrated by a protocol called ICE.

Since it relays all media through it, this can be a rather expensive endeavor (costing in bandwidth and CPU at a data center). This is why public TURN servers aren’t usually available and every service needs to install and maintain its own server (or pay for a hosted service).

TURN can use different transport protocols to relay its media:

1. TURN/UDP – relaying media over UDP. This is the preferred method for handling real time media
2. TURN/TCP – relaying media over TCP. This method can be seen as a fallback to UDP when UDP isn’t reachable from the device to the TURN server
3. TURN/TLS – relaying media over TLS. This method is used for “worst case” scenario when nothing else can be used

Each of the mechanisms above is independent of the other. ICE is used to determine which of these transport protocols can be used for a given scenario.

WebRTC has revolutionized real-time communication, but it comes with its own set of challenges, especially when dealing with Network Address Translators (NATs) and firewalls.

Why WebRTC Needs to Deal with NATs and Firewalls

WebRTC is designed to facilitate peer-to-peer communication directly between browsers. However, this becomes a challenge when a firewall is involved. The firewall can block the direct flow of media from one browser to another, making it essential for WebRTC to find a way to traverse these firewalls.

The Challenge of Private and Public IPs

When a user is behind a firewall, their device is usually assigned a private IP address, like 10.0.0.1. This private IP is not directly accessible from the public network. The NAT device at the edge of the network assigns a public IP address to the user’s traffic as it moves into the public network. The challenge here is that WebRTC inside a browser only has access to the private IP address, making it impossible to establish a direct connection.

How STUN Servers Help

To overcome this, a STUN (Session Traversal Utilities for NAT) server can be used. The user can query the STUN server to find out their public IP address. Once the public IP is known, it can be shared with the other peer, allowing for a direct connection. This process also creates a “pinhole” in the NAT device, enabling incoming traffic from the other peer.

The Limitations of STUN

While STUN works well in many scenarios, it falls short when dealing with symmetric NATs. In such cases, the mapping of private and public IPs is such that it blocks incoming traffic from any other destination other than the one the original pinhole message was sent to, making STUN ineffective. This is where TURN servers come into play.

The Role of TURN Servers

TURN (Traversal Using Relays around NAT) servers act as a relay for all the traffic between the peers. If a direct connection can’t be established, the TURN server steps in to relay the media. However, this comes at a cost—increased bandwidth usage, higher server-side CPU load, and potential latency.

Comparing STUN and TURN

• Purpose: STUN is used to discover public IP, while TURN is used to relay media
• Frequency of Use: STUN is used almost always, and TURN is used as a fallback
• Cost: STUN is generally inexpensive, while TURN can be costly, especially at scale
• Quality Impact: STUN has no quality impact, but TURN might affect quality depending on deployment

Making the Choice: ICE Protocol

The ICE (Interactive Connectivity Establishment) protocol helps in deciding whether to use STUN or TURN. ICE collects different types of candidates (host, server-reflexive, and relay candidates) and performs connectivity checks to determine the best path for the media flow.

Conclusion

Understanding the roles of STUN and TURN servers is crucial for anyone working with WebRTC. While STUN servers help in most cases, TURN servers are the go-to solution for more complex scenarios involving symmetric NATs. By leveraging the ICE protocol, you can make an informed decision on which to use, ensuring a smooth and efficient real-time communication experience.

The post TURN appeared first on BlogGeek.me.

NAT is a technology that is embedded into network routing devices such as home DSL boxes, firewalls, switches and routers.

A NAT is usually placed between a private  network (LAN – Local Area Network) and the public network (The Internet).

Due to the lack of IP address space and the need to keep a private network’s architecture unknown to external users, NATs are used. These translate internal private IP addresses to external public IP addresses.

Incoming traffic into the private network is routed through a public address binding that occurs on the NAT device. This binding is created when an internal machine with a private IP address tries to access a public IP address (through the NAT).

Not all NAT devices are created equal – they behave differently to traffic coming to private addresses from different external addresses than the original one.

VoIP (and WebRTC) need to be able to pass media between two peers that might both be behind NAT devices. It also requires external packets to be able to pass to the internal network. This requires mechanisms known as NAT Traversal to be used.

In WebRTC, the selected mechanisms are STUN, TURN and ICE.

The post NAT (Network Address Translation) appeared first on BlogGeek.me.