Why TURN matters
WebRTC calls and softphones first try to connect directly. STUN tells them their public address, but behind symmetric NAT or a corporate firewall a direct path fails and audio can only flow through a TURN relay. Without a working TURN those calls connect with no audio or not at all. Your NAT type: NAT test.
What the results mean
- relay: the server allocated a relay address, so TURN works over that transport.
- srflx: your public address as reported by STUN.
- 401: the server answered but rejected the login. 701 or nothing: no answer.
A minimal coturn
# /etc/turnserver.conf
listening-port=3478
tls-listening-port=5349
external-ip=203.0.113.10
realm=turn.example.com
use-auth-secret
static-auth-secret=long-random-secret
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
min-port=49160
max-port=49200
no-multicast-peers
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
Open 3478 UDP/TCP, 5349 TCP and 49160–49200 UDP. The denied-peer-ip lines stop your TURN from being used as a door into private networks. Server sizing: server sizing.