Coturn

Coturn is an open-source STUN/TURN server used to help devices discover their public network address and relay media when direct peer‑to‑peer connectivity is not possible. It is a core infrastructure component for WebRTC applications, VoIP systems, and any real‑time communication platform that relies on NAT traversal.

Reference: https://medium.com/av-transcode/what-is-webrtc-and-how-to-setup-stun-turn-server-for-webrtc-communication-63314728b9d0

Context

Real‑time communication over the internet is complicated by NAT devices, firewalls, and corporate network controls. Peer‑to‑peer protocols—such as WebRTC—must discover each device’s reachable address and negotiate a stable path for media.

Coturn enables this by implementing:

**STUN (Session Traversal Utilities for NAT)** — helps endpoints discover their public IP and port.
**TURN (Traversal Using Relays around NAT)** — relays traffic when a direct connection cannot be established.
**ICE (Interactive Connectivity Establishment)** — coordinates STUN/TURN usage to select the best available path.

Although many networks allow direct connectivity, real‑world deployments quickly reveal the opposite: symmetric NATs, carrier‑grade NAT, and strict firewalling often require a TURN relay for communication to succeed.

Core Concepts

STUN

STUN provides the bare minimum:

The client asks the STUN server “How do I appear from the outside?”
The server responds with the public IP and port.

This works only if the NAT behaviour is predictable and allows inbound return traffic.

STUN is extremely lightweight but unreliable on restrictive networks.

TURN

TURN is the “fallback” but often becomes the primary communication path in the real world.

TURN:

Allocates a relay address on the server.
Both peers send media to the relay.
The relay forwards traffic between them.

TURN ensures connectivity at the cost of server bandwidth and increased latency.

ICE

ICE coordinates multiple network candidate addresses from STUN and TURN and runs connectivity checks.

Coturn participates in ICE by providing both STUN and TURN candidates.

Practical Application

Coturn is widely used in:

WebRTC video/voice communication
Telehealth platforms
Remote desktop and screen‑sharing
IoT remote control
Video conferencing systems
Secure peer‑to‑peer file transfer

In typical deployments:

1. **STUN** is used first because it’s fast and free to operate. 2. **TURN** is used only when NAT traversal fails. 3. **ICE** automatically tests both and selects the best working route.

Well‑designed systems deploy Coturn in multiple availability zones or datacenters to minimise latency.

Common Pitfalls

**Relying on STUN alone**

 Many developers mistakenly assume STUN is enough. It rarely is. Without TURN, 15–30% of users (enterprise, hotel, mobile networks) may be unable to connect.

**TURN over TCP only**

 Some clients require TURN/UDP for full compatibility. TCP-only TURN increases latency and may cause choppy audio/video.

**Firewall misconfiguration**

 Coturn requires inbound access to:
 * STUN/TURN ports (default 3478/TCP+UDP)
 * TLS variants (5349)
 * Relay ports (configurable range)

**Lack of authentication**

 TURN must be authenticated. Open relays quickly become abused for UDP amplification attacks.

**Insufficient logging**

 Coturn logs are essential for diagnosing ICE failures.

Design & Architecture Considerations

Scalability

TURN relaying has a linear bandwidth cost: every active session consumes server bandwidth.

To scale Coturn:

Deploy multiple instances behind DNS load balancing.
Use geographically distributed servers.
Allocate large relay port ranges.
Monitor TURN allocation counts and throughput.

Security

Key measures include:

Use **long-term credentials** for TURN authentication.
Enable TLS for secure signalling.
Restrict allowed peers and interfaces.
Limit relay bandwidth if needed.
Harden firewall rules around the relay range.

Maintainability

Keep configuration in version control and use explicit, commented options in `turnserver.conf`.

Backwards Compatibility

Coturn supports a wide range of legacy NAT behaviours and older WebRTC stacks, making it suitable for long-lived enterprise deployments.

Troubleshooting & Diagnostics

What to Check If Calls Fail

ICE negotiation logs in the browser or client app.
TURN allocation attempts (Coturn logs show ACCEPT/REJECT).
Whether STUN candidates are reachable.
Firewall blocks on relay ports.
TLS negotiation for secure TURN endpoints.

Behavioural Indicators

No local candidates → client network misconfiguration.
Only relay candidates used → restrictive NAT or firewall.
Frequent allocation failures → port exhaustion or authentication problems.

Reference Configuration (Example)

# /etc/turnserver.conf
listening-port=3478
tls-listening-port=5349
listening-ip=0.0.0.0
relay-ip=0.0.0.0
min-port=49152
max-port=65535

realm=example.com
use-auth-secret
static-auth-secret=YOUR_SECRET

no-loopback-peers
no-multicast-peers

References

RFC 8489 – STUN
RFC 8656 – TURN
RFC 8445 – ICE
Coturn GitHub Documentation
WebRTC Working Group Notes

Coturn

Contents