We techies love our acronyms, but ICE, STUN, TURN, TURNS ... it can be a bit much. What are these things really? Why do they exist, and how are they used by LiveSwitch? The goal of this article is to demystify these technologies and their usage.
Ultimately, the goal of a real-time application is high throughput, low latency communication between various clients that may (or may not) be behind restrictive firewall rules. This implies the following preferred precedence of network communication protocols:
- UDP - Direct between source and target of media flow.
- UDP - Indirect (relayed) between source and target of media flow.
- TCP - Indirect (relayed) between source and target of media flow, via TCP.
- TCP/TLS - Indirect (relayed) between source and target of media flow, via TCP, with an extra layer of encryption.
Now that we know what we want, how does this relate to STUN, TURN, and ICE?
For us to establish a UDP connection between two clients we need to be able to negotiate through a firewall. To do so, a given client must be able to target the other client's public IP address and negotiated port. However, most clients do not know their own public IP address. This is where STUN comes in. STUN is a protocol for the self-discovery of a client's public IP address from behind a NAT. A STUN server allows a computer on the internet to determine its own public-facing IP address. STUN uses UDP, and STUN servers typically listen for UDP requests on port 3478. For a client to use STUN, their network must allow UDP traffic.
STUN tells a client its public IP so that client can in turn communicate its IP to the other participating client. Assuming both clients can route to the other's discovered IP address and port directly, communication is established with direct UDP sockets. This routing capability is a big assumption because some firewall rules and/or network devices block direct connections. When this direct connection fails, we fall back to indirect (relayed) UDP.
UDP - Indirect (relayed) Between Source and Target of Media Flow
In the direct connection process (STUN), many firewall rules do not allow incoming traffic on the negotiated port. In that situation we have to introduce an IP and port that we know ahead of time is available. This is a TURN server. TURN is an extension of STUN, and as such, TURN servers also typically listen on port 3478. However, TURN provides STUN capability and more. TURN is a protocol for relaying media traffic through a service when a direct connection between two endpoints is not possible. TURN typically authorizes access to the server via username/password.
TURN's preferred mode of operation is to use UDP sockets. However, this assumes the target network is not actively blocking UDP sockets completely. This is another big assumption. When UDP TURN fails we fall back to TCP.
At this point, UDP has failed. In this case, we're stuck using TCP, and to make our connection most likely to succeed, we need to pretend our data is standard web traffic. Therefore, we'll wrap it up in a standard TCP packet and relay this using our TCP TURN server. This is typically done on port 80 since this is the standard port for web traffic.
TURN over TCP works in many restrictive environments, but we are making one more assumption. We are assuming that the firewall itself does not inspect packets to ensure that the data is actually web traffic. Our third big assumption. When this fails we fall back to TCP/TLS.
TCP/TLS - Indirect (relayed) Between Source and Target of Media Flow
If we have reached this point the network is very restrictive. This is typical only for large corporate networks, banks, or hospitals. In this scenario we wrap the TCP data in a secure TCP socket, initiating the connection with an HTTPS handshake, so the firewall is unable to distinguish this traffic from any other web traffic other than by using heuristics (such as data volume) or man-in-the-middle via proxy. We have never seen this fail in practice.
The STUN, TURN, and TURNS Protocols
The protocols used to realize connections over the network communication protocols we have outlined above are STUN, TURN, and TURNS. We have already hinted at this, but let's define these explicitly:
- Session Traversal Utilities for NAT (STUN) - Used to establish a direct UDP connection between two clients.
- Traversal Using Relay around NAT (TURN) - Used to establish a relayed UDP or TCP connection between two clients. Here, the traffic must be relayed through the TURN server to bypass restrictive firewall rules, and the preference is UDP over TCP because TCP's guaranteed ordered delivery of packets implies overhead that is undesirable for real-time communications.
- Secure Traversal Using Relay around NAT (TURNS) - Used to establish a relayed TCP/TLS connection between two clients. Here, the traffic must be relayed through the TURN server and through a TLS socket to bypass extremely restrictive firewall rules.
At this point, you understand the preferred methods and technologies for routing media traffic between clients.
So how does all this apply to my app? Inside LiveSwitch, we utilize the ICE protocol to manage STUN, TURN, and TURNS. Read on to learn how ICE accomplishes this.
ICE in a Nutshell
Interactive Connectivity Establishment (ICE) is a standard for using STUN and TURN to establish connectivity between two endpoints. ICE takes all of the complexity implied in the discussion above, and coordinates the management of STUN, TURN, and TURNS to a) optimize the likelihood of connection establishment, and b) ensure that precedence is given to preferred network communication protocols.
To understand ICE you must understand "candidates," how they are gathered, and how they are used to establish connectivity between two peers. A candidate is an IP address and a port. These candidates are "gathered" by an implementation of the ICE protocol, and iterated over to find candidates that are "routable" - that is, candidates between which clients can route media packets.
There are four types of candidates:
- "host" candidates - Gathered directly from the local network adapter, host candidates are the internal IP address and port of a computer on a LAN. They can only route between peers on the same subnet.
- "srflx" candidates - Gathered via STUN, srflx, or server reflexive candidates, consisting of the public IP address and negotiated port of the local peer. When signaled to a remote peer they can be used to route traffic over the internet providing that traffic is not blocked by firewall rules.
- "prflx" candidates - Peer reflexive candidates are simply a variation on server reflexive candidates. In this case, these candidates are gathered directly by peers after they have established a connection. A peer reflexive candidate could be used after connectivity has been established if ongoing connectivity checks determine the candidate is routable, and connectivity on the currently active candidate is failing.
- "relay" candidates - Gathered via TURN, relay candidates consist of the public IP address and a negotiated port for the relay server. This is useful when a firewall does not allow direct routing via srflx candidates. In this case, the remote peer has signaled a candidate it can use to route traffic to the relay server, which can then in turn relay that traffic to the peer behind the restrictive firewall. The firewall allows the TURN server to route traffic to the peer because the peer made the initial request to the server. In this way, the TURN server acts as a "man-in-the-middle" that the initiating peer uses to circumvent its firewall. From the discussion above, you know that communication over relay candidates is the least desirable option.
Now that we know what candidates are, and understand the different types, it's obvious that for real-time communication candidate preference is host > srflx/prflx > relay. Let's look at how ICE uses candidates to ensure the best possible routes for media flow while maximizing the chances that connectivity is possible at all. Here is a simplified version of how it works:
- The ICE layer of the LiveSwitch Client SDK gathers all types of candidates that it can. If STUN, TURN, and TURNS services are available, all candidate types are gathered for both UDP and TCP, if at all possible, at all times.
- Candidates are ranked with host > srflx/prflx > relay and UDP > TCP.
- Candidates are tested in order of rank. The first to establish connectivity is the winner and becomes the "active" candidate.
- Ongoing connectivity checks are performed on candidates. If the active candidate fails connectivity checks then a different candidate is used. Likewise, if a higher ranking candidate has connectivity checks succeed, then it becomes the active candidate.
Understanding how clients use ICE to establish and maintain connectivity is pretty cool, and the best part is that by offering embedded STUN/TURN capability directly in the Media Server, LiveSwitch manages all of this for you.
Provide Credentials for Embedded TURN
As discussed above TURN allows for authenticated access to the server. But, you don't want just anyone relaying traffic through your relay service. LiveSwitch's embedded TURN uses username/password authentication, but again, LiveSwitch manages this for you using usernames and passwords that are encrypted and temporary. You do not need to configure anything, and you do not need to worry about vending out TURN credentials to authorized clients.
FAQs
What is STUN TURN and ICE? ›
What are STUN, TURN, and ICE? STUN, TURN, and ICE are a set of IETF standard protocols for negotiating traversing NATs when establishing peer-to-peer communication sessions. WebRTC and other VoIP stacks implement support for ICE to improve the reliability of IP communications.
What are STUN and TURN servers? ›STUN stands for Session Traversal Utilities for NAT. It is a standard method of NAT traversal used in WebRTC. It is defined in IETF RFC 5389. It is one of two NAT traversal servers that are used in WebRTC (the other one is TURN).
How does STUN and TURN work? ›STUN tells a client its public IP so that client can in turn communicate its IP to the other participating client. Assuming both clients can route to the other's discovered IP address and port directly, communication is established with direct UDP sockets.
What is a STUN server used for? ›The STUN server allows clients to find out their public address, the type of NAT they are behind and the Internet side port associated by the NAT with a particular local port. This information is used to set up UDP communication between the client and the VoIP provider to establish a call.
How do I make a STUN and TURN server? ›- Update the apt-get libraries. sudo apt-get update.
- install coturn. sudo apt-get install coturn.
- Configure the server. Make a backup of the original configuration file ( sudo cp /etc/turnserver. conf /etc/turnserver. conf. ...
- Start the server.
For one, it will introduce some latency to the call. But the only alternative if you can't get that unique IP address from the STUN server is simply not to connect. So, TURN is better than nothing. And, the vast majority of the time you can connect once you are using the TURN server.
What are ICE candidates? ›An ICE candidate describes the protocols and routing needed for WebRTC to be able to communicate with a remote device.
How do I know if my server is STUN and TURN? ›- A STUN server works if you can gather a candidate with type "srflx" .
- A TURN server works if you can gather a candidate with type "relay" .
(Session Traversal Utilities for NAT) An IETF protocol for real-time voice, video and messaging in an IP network. STUN provides the mechanism to communicate with users behind a network address translation (NAT) firewall, which keeps their IP addresses private within the local network (LAN).
How do I connect to a STUN server? ›- Step 1: Firewall rules to Open ports: ...
- Step 2: Coturn installation. ...
- Step 3: Start the Coturn Daemon at Startup. ...
- Step 4: Create a TURN user to Next, edit the main configuration file. ...
- Step 5: Restart the Coturn Service. ...
- Step 6: Testing Time.
Why is STUN more preferred than TURN? ›
TURN is preferred because it is capable to traverse symmetric NATs too. However, STUN is useful to speedup the connection out of getting immediate candidates when users are sitting behind same NAT e.g. LAN.
How do TURN servers work? ›The TURN server receives the peer UDP datagram, checks the permissions and if they are valid, forwards it to the client. This process gets around even symmetric NATs because both the client and peer can at least talk to the TURN server, which has allocated a relay IP address for communication.
How do I connect to turn server? ›- Prerequisites.
- Step 1 - Installing Coturn.
- Step 2 - Configuring Coturn.
- Step 3 - Testing TURN server.
- Step 4 (Optional) - Adding a Domain to the Coturn server. Adding DNS records to your Domain. ...
- Step 5 (Optional) - Running TURN server using Docker.
- Resources.
On a typical webRTC app, about 20% of connections require a TURN server. It may work fine for you, but try accessing your webRTC service from a cell phone connection (which will usually require TURN), and you'll see that not all connections are equal when it comes to p2p.
Why turn server is needed? ›For most WebRTC applications to function a server is required for relaying the traffic between peers, since a direct socket is often not possible between the clients (unless they reside on the same local network). The common way to solve this is by using a TURN server.
What protocol does turn server use? ›TURN Server
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).
ICE candidates. As well as exchanging information about the media (discussed above in Offer/Answer and SDP), peers must exchange information about the network connection. This is known as an ICE candidate and details the available methods the peer is able to communicate (directly or through a TURN server).
What is ICE negotiation? ›STUN and TURN play a role in the ICE negotiation process. ICE, Interactive Connectivity Establishment, is a protocol that allows the dynamic discovery of the best way to establish a connection for entities that may be behind NAT. All WebRTC clients use ICE before media can flow.
What does ICE mean in communication? ›ICE: Introduce, Cite, and Explain Your Evidence.
How do I know if my turn server is working? ›on the TURN server, you can check whether a persistent TURN session has been connected. In the telnet CLI monitor, type command "ps <username>" and you will see the TURN sessions of the user, if any.
Is STUN server secure? ›
STUN servers do not implement any reliability mechanism for their responses. When reliability is mandatory, the Transmission Control Protocol (TCP) may be used, but induces extra networking overhead. In security-sensitive applications, STUN may be transported and encrypted by Transport Layer Security (TLS).
How does STUN damage work? ›■How stunning works
Each monster has a threshold for stun damage (head). Once you cross that line, it KOs them. Every 10 seconds (or in the rare case of Khezu, 15 seconds), the accumulated stun damage you have done to a monster will decrease by a set amount. For most monsters it's 5 damage.
: to make senseless, groggy, or dizzy by or as if by a blow : daze. : to shock with noise. 3. : to overcome especially with paralyzing astonishment or disbelief.
How do I TURN off STUN? ›open Settings -> Preferences -> Advanced -> Network sub-tab -> STUN options and use the drop-down menu to disable STUN.
What are STUN ports? ›STUN is a standardized protocol for traversing network firewall/gateways for applications of real-time voice, video, messaging, and other interactive communications.
What is a STUN extension? ›STUN (Session Traversal Utilities for NAT) is an auxiliary protocol for transmitting data around a NAT (Network Address Translator). STUN returns the IP address, port, and connectivity status of a networked computer behind a NAT.
How to setup STUN server in Windows? ›- To Configure the STUN Server Settings:
- On the Management Portal menu window, click System Configuration > Host. The Configuration page opens.
- Click the STUN Server tab.
- Enter your Host and Port settings.
- Click Update and Commit Changes buttons to enact your changes.
What is the TURN service? Communication between participants in Live Guided Tours is normally sent through peer-to-peer connections, where audio and video streams are sent directly between participants.
What port does TURN use? ›Port 3478 is the default port for the TURN Server. If your network has other requirements, see Enabling HTTP Connect Tunneling for audio and video calls. These port numbers must not be subject to third-party load balancing, packet rewriting (NAT/PAT), or other network-layer manipulation.
Is TURN server is a signaling server? ›TURN servers are used to stream audio, video, and other real-time data between peers. It does not share signal information as it enables real-time data exchange between peers. TURN servers have public addresses, so peers can connect to them even if they are behind NATs and firewalls.
Are TURN servers secure? ›
The benefits of a turn server include Increased security when actively used (less chance of IP leaking) and better network compatibility. Without a TURN server, about 10% of remote guests will not be able to connect with each other.
What is the STUN technique? ›The Stun Technique (夢中の術, "Muchū no Jutsu") is a jutsu that mentally restrains an opponent as if the opponent had become "brain-dead" for the duration of the technique. It debilitates the victim for a short period of time, which allows the user to either strike again, or take the target into custody.
What is STUN on Iphone? ›Details. In simple terms, STUN is a protocol used to enable a device running behind a NAT device to discover its public IP and port. This protocol is widely used in VOIP communications to mitigate issues arising due to NAT implemented by firewalls and routers. The standard and widely used port for STUN is 3478/UDP.
What is ICE in SIP? ›ICE use SIP, which means that the NAT traversal of SIP must be provided by another mechanism. ICE allows UAs, who are initially ignorant of their topologies, to discover enough topology information to find communications paths. The two UAs are each behind a NAT with unknown properties.
What is the STUN effect? ›Stun effects are a form of crowd control that cause the victim to be unable to move or perform most actions for a period of time.
What is STUN setting? ›STUN (Simple Traversal of UDP through NATs) is a network protocol allowing a client behind a NAT (or multiple NATs) to find out its public address, the type of NAT it is behind and the internet side port associated by the NAT with a particular local port.
What is STUN Internet traffic? ›(Session Traversal Utilities for NAT) An IETF protocol for real-time voice, video and messaging in an IP network. STUN provides the mechanism to communicate with users behind a network address translation (NAT) firewall, which keeps their IP addresses private within the local network (LAN).
How does a TURN server work? ›The TURN server receives the peer UDP datagram, checks the permissions and if they are valid, forwards it to the client. This process gets around even symmetric NATs because both the client and peer can at least talk to the TURN server, which has allocated a relay IP address for communication.
How do I TURN off STUN on my Iphone? ›Configuring, Enabling or Disabling STUN:
STUN is located in "Settings"->"Accounts"->your account->"Network Settings".
STUN stands for Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NAT's). The protocol is used in several different network implementations, one of which is VoIP.
What is ICE protocol? ›
This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP).
What does ICE mean in networking? ›ICE (Interactive Connectivity Establishment) is a framework used by WebRTC (among other technologies) for connecting two peers, regardless of network topology (usually for audio and video chat).
What is ICE configuration? ›The Integrated Configuration Environment (ICE) application is a centralized tool that provides easy access to most of the configuration options available within the Unified CCMP platform. Individual configuration tools are components within ICE.