A thorough explanation and practice of STUN/TURN/TURNS/SFU in WebRTC

What is WebRTC?

WebRTC (Web Real-Time Communication) is an open technology that enables real-time audio, video, and data communication between browsers. It is being standardized by companies including Google as a mechanism that enables P2P communication using only a JavaScript API, without the need for additional plug-ins or software.

WebRTC consists of three main components:

• getUserMedia: An API for acquiring audio and video from devices such as cameras and microphones.
• RTCPeerConnection: The core API for establishing communication between peers and exchanging media and data.
• RTCDataChannel: A data channel that can be used for sending files, chatting, etc.

These APIs enable the development of many real-time applications such as video calls, audio conferencing, file sharing, etc. However, in actual communications, there are issues with NAT traversal and firewalls, so it is essential to understand and implement NAT traversal technologies such as STUN/TURN/TURNS.

Differences and roles of STUN, TURN, and TURNS

A NAT traversal mechanism is essential to achieving stable peer-to-peer connections with WebRTC. This article provides a detailed explanation of the three major technologies, STUN, TURN, and TURNS, including their technical differences, usage scenarios, and advantages and disadvantages.

STUN is a protocol used primarily to find one's own external address in a NAT environment, while TURN is a protocol that functions as a relay server when a direct connection is not possible. On the other hand, TURNS encrypts TURN communications with TLS and uses port 443, the same as HTTPS, making it possible to communicate behind strict firewalls such as corporate networks.

By understanding the characteristics of each and using them appropriately, you can increase the success rate and quality of WebRTC communications.

Role and characteristics of STUN (UDP)

STUN (Session Traversal Utilities for NAT) is a protocol that allows clients toExternal IP address and portFor example, if your PC is behind a NAT, it does not know its own global IP address, but it can obtain its "IP:port as seen from the outside world" by querying a STUN server.

The STUN server acts like a mirror, returning the source information of the received request exactly as it is. As a result, the client can find out its own global IP address and the port number assigned by the NAT (Server Reflexive candidate).

STUN communication is usually performed over UDP, with the default port being 3478 (UDP/3478). Because it requires only a lightweight, single-shot communication over UDP, it has low overhead, low latency, and places almost no load on the server. Therefore, in environments where UDP communication is permitted, NAT traversal using STUN is attempted first.

STUN usage scenarios

It is effective in environments where NAT traversal is required but UDP communication itself is not blocked, such as home networks or mobile networks. If STUN can obtain each other's external IP and port, clients can establish direct (peer-to-peer) communication. Because the communication path is direct, latency is low and quality is maintained at a high level. Furthermore, since the server only facilitates the exchange of IP information, costs are kept extremely low. For example, in online games or video calls, if both devices are behind a relatively open NAT, STUN is sufficient to enable a peer-to-peer connection.

Limitations and Disadvantages of STUN

STUN is merely a means to "find your own external address," and depending on the NAT type and firewall restrictions, it may not be possible to connect using this alone. In particular, in symmetric NAT or strict firewall environments, packets from the other party may not reach the address obtained by STUN, making communication impossible.

Additionally, UDP communication itself may be blocked on corporate networks, in which case STUN requests themselves may not be received. In short, STUN is a mechanism for determining whether direct communication is possible, and it will not function in environments where direct communication is physically impossible. For this reason, STUN is used in ICE (described below) to obtain first-stage candidates, and if STUN is not sufficient, it is designed to fall back to TURN, described below.

Role and characteristics of TURN (UDP)

TURN (Traversal Using Relays around NAT) is a protocol that acts as an intermediary relay when direct communication is not possible using STUN. The TURN server acts as a globally accessible relay point, acting as an intermediary between the communication partner and the other party to forward packets. The client connects to the TURN server and obtains a relay IP address and port, known as a relay candidate. Thereafter, media and data exchange with the other party takes place via that TURN server.

TURN also normally communicates over UDP, so as long as UDP is used, it can relay media packets in a manner similar to direct communication. By default, the TURN protocol is accepted on port 3478 (UDP), the same as STUN. Even if your firewall policy restricts UDP port numbers, you can also run TURN on an allowed port such as UDP/443. As long as UDP is available, relaying with higher real-time performance than TCP is possible.

TURN usage scenarios

TURN is essential when a direct connection cannot be established. For example,This is the case when one or both parties are behind a strict corporate firewall, or when both parties have symmetric NATs, which can cause UDP hole punching to fail.In such an environment, communication is impossible without relaying via a TURN server, so TURN acts as a sort of last resort.

WebRTC aims for all peers to be able to communicate directly, but even if this is not possible, communication can continue by falling back to TURN. In actual operation, the general strategy is to first attempt a direct connection using STUN, and only switch to TURN relay if that fails. For example, in a video conference over an internal network, if two peers cannot communicate directly with each other, the system automatically switches to communication via the TURN server, allowing the conversation to continue without the user even noticing.

Benefits of TURN

Its greatest advantage is reliability. Even in any NAT or firewall environment, peer-to-peer communication can ultimately be achieved as long as communication can be established from the client to the TURN server. TURN is also an extension of the STUN protocol, so a single server implementation (such as coturn, described below) can process both STUN and TURN requests. Once a connection is established, subsequent media is relayed as a stream, making communication seamless from the user's perspective, with the exception of a slight delay.

Disadvantages of TURN

Its biggest drawbacks are resource consumption and latency. With TURN, all audio and video data passes through the server, requiring a huge amount of bandwidth and processing power on the server side. For example, if we assume that a one-to-one video call consumes 1Mbps of bandwidth in one direction, then by simple calculation, 1,000 simultaneous users would require a relay bandwidth of 1Gbps. This makes the operating costs of a TURN server high, and large-scale services require the provision of multiple TURN relay servers to scale.

Additionally, the longer communication path increases latency, resulting in video and audio time lags and reduced quality. Furthermore, compared to peer-to-peer communication via STUN, TURN is not strictly peer-to-peer, so it is slightly less secure in terms of confidentiality (although TURN servers typically only relay unencrypted RTP/datagrams and do not interpret the content).

Overall, TURN should only be used when necessary. In fact, most WebRTC communications can be connected directly using STUN, and Google statistics show that approximately 861 TP3T of all calls are established without a relay (peer-to-peer). Only the remaining approximately 141 TP3T require TURN, but it is important to have a TURN infrastructure in place for those 141 TP3T.

Role and features of TURNS (TLS over TCP/443)

TURNS is an abbreviation for "TURN over TLS," which means that relay communication via the TURN protocol is further encrypted with TLS (Transport Layer Security).TURN communication secured by TLS (HTTPS)It is often served on TCP port 443.Port 443 is the same port number as HTTPS, so it can easily pass through corporate firewalls and bypass proxies and censorship.The following is a list of the most common problems with the

For example, an internal company network may only allow external communications via ports 80 and 443, but even in this case, if the TURN server uses TLS communications via port 443, there is a high chance that communications will be able to go through. In addition, because the communications are TLS encrypted, they are secure and difficult for third parties to intercept.

In WebRTC, the settings"urls": "turns:turnsserver:443"In the URI scheme,turns:You can use this TLS-encrypted TURN server by specifying

TURNS usage scenarios

TURNS is useful for WebRTC communications in strict restricted environments, such as corporate networks, where all other means are blocked. Even in environments where all UDP and general TCP ports are blocked, many policies allow communication as long as it is treated the same as HTTPS communication, so TURN over TLS port 443 is effectively a last resort.

It is also used in situations where certain ports are closed on public wireless LANs, or when only TLS communication is possible on the client side.First UDP, if that doesn't work then TCP, if that doesn't work then TLS to 443It is positioned as the final stage of a gradual fallback.

Benefits of TURNS

Its greatest advantage is its high firewall resistance. TLS encrypted communication is difficult to distinguish from standard HTTPS, so it is more likely to pass through even strict filters. In particular, when introducing a web conferencing system to a company, external connections from the internal network must be permitted, and TLS communication over TCP/443 is more likely to be accepted under security policies. In addition, because it is encrypted, the confidentiality of the communication to the relay server itself can be ensured (note that the content itself, such as video, is often already encrypted at the WebRTC layer).

Disadvantages of TURNS

The biggest drawback is the performance penalty. In addition to the latency and load of TURN itself, there is the added overhead of TLS and TCP. TCP provides reliable transport and has a retransmission mechanism in place in the event of packet loss, but it is not suitable for real-time media, and loss can cause video and audio to not play smoothly.

Also, TCP is prone to head-of-line blocking due to packet ordering,Jitter (fluctuation) also increases compared to UDPFurthermore, TLS encryption and decryption processing places additional load on the CPU. As a result, it has been reported that an additional delay of 50 ms or more occurs, causing a lag that can be felt by users. In particular, in video conferencing, this increased delay can slow down the tempo of conversations and cause noticeable timing discrepancies.

In this way, TURNS can be considered a "last resort" in terms of quality, but it is also a reliable lifeline in situations where there is no other option but to ensure communication.

In recent years, a new approach (TURN over QUIC) that operates on UDP port 443 and uses DTLS/QUIC instead of TLS has been considered, but it is still in the process of being standardized and is not widely used.

Communication flow when UDP STUN is not available

We will explain step by step how WebRTC ICE processing proceeds when STUN over UDP is not available. Let's assume a situation where UDP is completely blocked, such as on a corporate network, and follow how ICE negotiation falls back.

1. Client sends external IP query (UDP/3478) to STUN server:
   WebRTC client (browser)iceServersA Binding Request (request to verify external address) is sent to the STUN server specified in via UDP port 3478. This is the first step in collecting ICE candidates, and if successful, the server will return its own global IP address and port number, and add it to the candidate list as a Server Reflexive Candidate (srflx candidate).
2. UDP packets blocked by firewall and no response:
   In this case, the network firewall settings prevent UDP communication from reaching the outside. Therefore, requests to the STUN server do not reach the server, or the response does not reach the client. As a result, the clientNo STUN response received, the external IP address cannot be known. The ICE agent waits for a response for a certain period of time, but a timeout occurs. From the user's perspective, the connection is still in progress and no error message is displayed, but in reality,Failed to collect candidatesThis is currently happening.
3. ICE direct connection check fails because no Server Reflexive candidates are available:
   Normally, if STUN is successful, the client will have a Host candidate (its local IP) as well as a Server Reflexive candidate (its global IP), and will check the connection by combining them with the same candidate of the far-end peer. However, if STUN fails and there is no global IP candidate,Extremely limited candidates for direct peer connectionsFor example, if both parties only have private IP addresses, they will not be able to reach each other even if they try to connect. As a result, ICE will determine that "direct communication is not possible." If the ICE server (TURN) is not configured, the entire ICE will be treated as a failure at this stage, and the WebRTC connection will not be established (the developer console will showICE failedand ... andICE connection state: failedor other error will be displayed).
4. Attempt to get TURN relay candidates (over TCP/TLS/443):
   Even if direct candidate acquisition via STUN fails,iceServersIf a TURN server is specified inNext StepsIn this scenario, UDP is not supported, so the client attempts to connect to the TURN server using TCP or TLS (for example,turns:turn.example.com:443(If configured, the TLS handshake will begin.) Fortunately, the firewall allows HTTPS communication on TCP 443, so the TURN connection via TLS is successful. The client secures a relay address on the TURN server,Relay CandidateThe other side will obtain relay candidates (candidates). These are "virtual candidates for communication via the TURN server." Meanwhile, the other side (remote side) will also obtain relay candidates, or if the network is problem-free, it will have direct candidates or STUN candidates. In any case, if at least one side has relay candidates, the other side can attempt to connect to that TURN server.
5. ICE connection establishment (or eventual failure) via relay:
   Once both peers have obtained available candidates (one or both relay candidates in this example), ICE uses them to check the connection. Communication via the TURN server can be relayed once it is established with the server, so a media channel is opened even if UDP does not pass directly between the peers. This allows video and audio communication between users to begin. Once the connection is established, there is the overhead of TCP over TLS, but conversation itself is possible. Conversely, if there is a failure here too (for example, a corporate proxy detects and blocks non-HTTP TLS communication, or TURN server authentication fails), unfortunately, ICE will fail and the connection will be abandoned. The application must detect this situation and notify the user, such as "Connection failed."

This is the flow of ICE negotiation in a harsh environment where UDP cannot be used. In summary, candidates are tried in the order "host → STUN → TURN", and if that doesn't work, the connection will fail. It is important for developers to understand this behavior and to at least include a TURN/TURNS server in the ICE server list, so that communication can still be established even in the worst case. Furthermore, when receiving inquiries from users, troubleshooting is required, such as inferring a problem with the network environment (such as UDP blocking) from information such as "ICE failed" and checking to see if the TURN server has been configured properly.

Building and configuring a STUN/TURN/TURNS server using coturn

If you want to set up your own STUN/TURN server, use the open source implementation. coturnIt is common to use coturn. coturn is a server implementation that supports both STUN and TURN, and depending on the configuration, it can also support TURNS (TLS). This article explains how to install coturn on a Linux server and how to build a server that provides STUN/TURN/TURNS, as well as the configuration points. In addition, we will explain the typical configuration file (turnserver.conf) is also shown.

Installation and Basic Configuration

install

For Ubuntu or Debian,aptYou can install the coturn package from the command line. For example, use the following command to install it and set it to start automatically.

# Ubuntu/Debianの場合
sudo apt-get install coturn
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
sudo systemctl enable --now coturn

This will start the coturn server as a daemon. By default, it will use the configuration file /etc/turnserver.conf This will load the file, and you can then edit it (make a backup before editing just to be safe).

Basic settings

turnserver.confNow, set the following items:

• realm and server-name: This is the domain name or identifier of the TURN server. It may be used when authenticating a WebRTC client, but basically it can be any string. Example: realm=example.com,server-name=example.comThe following is a list of the most common problems with the
• listening-port: The UDP port number to listen on for TURN and STUN. The default is 3478.listening-ipYou can also bind to a specific NIC with0.0.0.0We accept all of them.
• tls-listening-port: This is the TCP port number to listen on for TLS (TURNS). Generally, you would specify 443 or 5349. Example: tls-listening-port=443The following is a list of the most common problems with the
• external-ip: If the server itself is behind a NAT, specify its own global IP (this allows the server to recognize the mapping between the internal IP and the external IP). This is not necessary if the server has a direct global IP.
• Authentication method: WebRTC TURN uses long-term credentials,lt-cred-mech(Long Term Credential Mechanism) is enabled.user=username:passwordSet the username and password in the formatuse-auth-secret(The latter is token-based authentication, which is effective for improving security, but here we will show simple static user authentication as an example.)
• Log Settings: For troubleshootinglog-fileSpecify the log file path inverboseYou may want to enable verbose logging.

Firewall settings

On the server side, for STUN/TURNUDP port 3478, and for TURN/TLSTCP port 443(or 5349) must be open. Additionally, TURN relay uses the UDP 10000-20000 range by default, so open this port range on the server as well (if necessary).min-portandmax-port(The range can be changed with

Below is a list of the settings that reflect the above basic settings./etc/turnserver.confHere is an example:

# TURNサーバの名称とレルム（ドメイン）
realm=example.com
server-name=example.com

# ネットワーク設定
listening-ip=0.0.0.0           # すべてのIPアドレスで待受
external-ip=203.0.113.10       # サーバのグローバルIP（必要な場合）

# ポート設定
listening-port=3478            # STUN/TURN用 UDPポート
tls-listening-port=443         # TLS用 TCPポート (443番)
min-port=10000                 # 中継に使用するポート範囲（下限）
max-port=20000                 # 中継に使用するポート範囲（上限）

# ログ設定
log-file=/var/log/turnserver.log
verbose                        # 詳細ログを有効化
fingerprint                    # パケットにfingerprint属性を付与

# 認証設定（長期認証方式）
lt-cred-mech                   # 長期認証を有効化
user=webrtcuser:secretpass123  # ユーザ名:パスワード を設定

# TLS/SSL証明書の指定
cert=/etc/letsencrypt/live/example.com/fullchain.pem   # サーバ証明書
pkey=/etc/letsencrypt/live/example.com/privkey.pem     # 秘密鍵

In the above, the domainexample.comWe obtain a Let's Encrypt certificate and use it for TLS configuration.lt-cred-mechEnable long term authentication withuserSimple username and password authentication is configured usinguse-auth-secretandstatic-auth-secretThe recommended method is to use a token-based method to issue temporary credentials, but we will not go into that here.

Precautions when using TLS

When running Coturn on port 443, you need to be careful about port permissions in a Linux environment. Ports under 1024 are called privileged ports and usually cannot be opened without root privileges. The Ubuntu coturn package defaults toturnserverBecause it is executed by a user, port 443 cannot be bound as is./etc/default/coturnChange the running user to root, orsetcapWith the commandturnserverto the executable filecap_net_bind_serviceThere are ways to grant permissions. For example, in the latter case,sudo setcap cap_net_bind_service=+ep /usr/bin/turnserverBy executing this command, you will be able to bind low-numbered ports even if you are not root. Also, please specify the correct path to the certificate file (cert/pkey) and set the file permissions so that the coturn user can read it. After changing the settings,sudo systemctl restart coturnRestart the service and check the logs for any errors.

Operation check

After starting the Coturn server, we will test it using a STUN client to check its operation, and then try connecting to ICE from the WebRTC app in the browser.stunclientcommand(apt-get install stun-client(Can be installed instunclient <server IP> 3478You can try to get your external IP by running the following. Also, in your browser, ICE candidates will be listed in the developer tools log, sosrflx(Server Reflexive) candidates andrelayPlease check if you get a candidate. If not, try the following troubleshooting steps:

• Are the necessary ports open in the server's firewall settings (iptables and cloud security groups)?
• Are the correct URI, port, and authentication information set in the client-side ICE server settings (described below)?
• turnserver.conf(at sentence-end, falling tone) indicates a confident conclusionrealmCheck whether the settings match the client authentication (this is usually not an issue in the browser version of WebRTC, as it automatically assigns the realm, but be careful if you have a custom implementation).
• coturn log (/var/log/turnserver.log) and check if there is an authentication error (WRONG USERIf there is an error such as the above, the username/password does not match.

With the above settings in place, you will have your own STUN/TURN/TURNS server running and will be able to support WebRTC connections in a variety of network environments.

ICE server configuration example for WebRTC client (JavaScript)

To actually use the STUN/TURN server we just built on the WebRTC application (browser),ICE Servers SettingsIn JavaScript's WebRTC API,RTCPeerConnectionYou can specify a list of STUN/TURN servers when generating a . Below we will show a concrete code example that specifies all STUN/TURN/TURNS and explain what it means.

First, create a configuration object for the ICE server.turn.example.com(Replace as appropriate) STUN does not require authentication, so just specify the URI, but TURN/TURNS requires authentication, so specify the username and password as well.

const iceConfig = {
  iceServers: [
    // 1. STUNサーバ（UDP/3478）
    { urls: 'stun:turn.example.com:3478' },
    // 2. TURNサーバ（UDP/443経由）
    { urls: 'turn:turn.example.com:443?transport=udp', username: 'webrtcuser', credential: 'secretpass123' },
    // 3. TURNサーバ（TCP/443 + TLS = TURNS）
    { urls: 'turns:turn.example.com:443', username: 'webrtcuser', credential: 'secretpass123' }
  ]
};
const pc = new RTCPeerConnection(iceConfig);

The aboveiceServersThe array has three entries.

1. STUN: stun:turn.example.com:3478
   Specifies the address of your own STUN server (if the port number is omitted, 3478 will be used). STUN is used to determine NAT traversal and obtain candidates. The browser will first query this server via UDP to obtain Server Reflexive candidates.
2. TURN (UDP): turn:turn.example.com:443?transport=udp
   Your own TURN serverUDP port 443This is the setting to be used. The username set in coturn earlier as authentication informationwebrtcuserand passwordsecretpass123The query parameter is specified.?transport=udpBy adding this, a TURN connection will be attempted over UDP (if not specified, the browser will first try UDP, and if that fails, will try TCP). With this setting, even if a direct connection via normal STUN fails, you will have a candidate for TURN relay on UDP port 443.
3. TURN (TLS/TCP): turns:turn.example.com:443
   TURN with TLS, that is, the TURNS server settings. A username and password are also specified here. The browser will make a TLS connection to this entry on TCP port 443 to obtain a TURN relay candidate. This is the relay candidate of last resort, and even if communication via UDP is not possible at all, there is a chance of establishing communication if this candidate is available.

RTCPeerConnectionOnce the ICE agent generates the srflx, it attempts to connect to the specified ICE servers in order to collect candidates. The ICE agent first obtains STUN candidates (srflx), then obtains TURN candidates (relay) in parallel. The ICE algorithm then combines these candidates, performs a connection check, and selects the optimal route. Developers do not need to be particularly aware of any further procedures.

point: As mentioned abovePrepare multiple candidatesis important. For example,stun:If you specify only TURN (UDP), no candidates will be found in an environment where UDP is blocked, and the connection will fail. Similarly, if you specify only TURN (UDP), it will fail in an environment where only TCP is allowed. Therefore, if possible,turn:andturns:By including both in the ICE server, redundancy is achieved so that at least one valid candidate can be found in any environment (of course, the TURN server must also support both UDP and TCP/TLS). The client (browser) will automatically select an available path, so the order of the list is not a big issue. If I had to say,iceTransportPolicyindicates object of desire, like, hate, etc.relayUnless you specify this, the browser will prioritize a direct connection, so if you enter a STUN entry, you will avoid using the TURN server unnecessarily. Also, if you enter irrelevant servers (such as non-existent addresses) in the ICE server list, there is a possibility of delays due to waiting for a timeout, so it is best to only enter servers that you are sure are available.

Finally, run the WebRTC application with this setting applied and verify the connection status.peerConnection.getStats()orchrome://webrtc-internalsYou can check the ICE Candidate and connection status in Chrome. If it works as expected, it should automatically fall back to a direct (P2P) connection in environments where UDP is available, and to a connection via TURN/TLS in environments where this is difficult.

Difference between SFU and TURN

WebRTC relays can be broadly divided into "TURN" and "SFU," but their roles, configurations, and uses are significantly different. Here we will clarify the technical differences.

TURN: Relay as an alternative to peer-to-peer

TURN (Traversal Using Relays around NAT) is an auxiliary relay server used in environments where WebRTC P2P communication is not possible. The TURN server acts as a relay between peers, relaying packets primarily when STUN does not function due to NAT or firewalls. Because each peer sends a stream individually to its respective communication partner, the configuration is essentially a mesh, and TURN is positioned as a "pinch hitter."

• composition: Each user sends to each other via a relay (effectively a mesh)
• Scalability: Low (the more people there are, the greater the load)
• Broadcast content: Simple packet transfer only, no media analysis or optimization

SFU: Efficient relay for multi-party calls

SFU (Selective Forwarding Unit) is an intelligent relay server used in multi-participant web conferences.Each client sends a single stream to the SFU, which selectively forwards it to other participants.It also performs speaker detection, image quality adjustment, and latency optimization, enabling scalable, high-performance broadcasting.

• composition: Star type where each client is connected to one SFU
• Scalability: Expensive (only one transmission even if the number of people increases)
• Broadcast content: Control of transfer destination and media optimization are possible

TURN vs SFU comparison chart

TURN is merely a "last resort when P2P communication is not possible," and is a relay that complements the P2P mesh.SFU is a relay architecture that is designed to be efficient from the start for multi-party calls.Because the roles of the two are fundamentally different, it is important to design them without confusing them.

summary

This article provides a detailed explanation for intermediate to advanced WebRTC users about the technical differences between STUN, TURN, and TURNS, as well as examples of how to build a server using coturn, and how ICE behaves in harsh network environments.

STUNis lightweight and enables direct communication in NAT environments,TURNprovides a lifeline for communication in difficult situations, andTURNSBy combining these, it opens the way for WebRTC to be used in special environments such as within a company.

Each has its own advantages and disadvantages, so ideally you should connect directly with STUN whenever possible, and only use TURN relay when absolutely necessary.In actual WebRTC application development, by setting up multiple routes in the ICE server configuration as introduced here, and by properly configuring and operating coturn on the server side, you can provide stable real-time communications in a variety of network environments.

WebRTC is a complex field that combines browser APIs and network technologies, but understanding how STUN/TURN and ICE work is essential to creating reliable applications.

We hope you will take the information in this article into consideration and try tackling the NAT traversal challenge in your own product. By doing so, users will be able to enjoy seamless communication thanks to intelligent connection processing that is carried out behind the scenes without them even realizing it.