STUN, TURN e ICE: come il VoIP attraversa il NAT

Chiunque abbia configurato un centralino VoIP o un softphone dietro NAT conosce bene il problema: l'audio va in una direzione sola, la chiamata si connette ma rimane silenziosa, oppure non si connette affatto. La causa quasi sempre è il NAT traversal. STUN, TURN e ICE sono i tre protocolli che risolvono questo problema.

Il problema: SIP e NAT non vanno d'accordo

SIP è un protocollo applicativo che incorpora gli indirizzi IP direttamente nel corpo dei messaggi (header Contact, Via, corpo SDP con c= e m=). Quando un client è dietro NAT, l'IP inserito nel pacchetto SIP è quello privato (es. 192.168.1.10), che dall'esterno è irraggiungibile.

Il server SIP riceve la richiesta dal NAT pubblico, ma le informazioni nel pacchetto puntano a un IP privato inutilizzabile. Risultato: signaling OK, media (RTP/RTCP) che non arriva a destinazione.

STUN: scoprire il proprio IP pubblico

Session Traversal Utilities for NAT (RFC 5389) è il protocollo più semplice della triade. Il client invia una binding request a un server STUN raggiungibile su Internet; il server risponde con l'IP:porta pubblici visti dalla rete esterna.

Il client usa queste informazioni per popolare correttamente le intestazioni SIP e l'SDP, permettendo al remote end di inviare RTP all'indirizzo corretto.

Limiti di STUN:

• Funziona con NAT di tipo Full Cone, Restricted Cone e Port Restricted Cone
• Non funziona con NAT Symmetric (frequente su router aziendali e CGNAT)
• Non attraversa firewall che bloccano il traffico UDP in ingresso

Il server STUN di Google (stun.l.google.com:19302) è pubblico e spesso usato in test, ma per produzione conviene usarne uno proprio o del proprio provider VoIP.

TURN: relay quando STUN non basta

Traversal Using Relays around NAT (RFC 5766) è il fallback quando STUN fallisce. Invece di tentare una connessione diretta peer-to-peer, tutto il traffico RTP viene instradato attraverso un server TURN che fa da relay.

Il flusso è:

1. Client si autentica sul server TURN (username/password o long-term credentials)
2. Il server alloca una porta pubblica per il client
3. Il remote end invia RTP al server TURN, che lo consegna al client
4. Il client invia RTP al server TURN, che lo inoltra al remote end

Vantaggi: funziona in qualsiasi scenario NAT, incluso Symmetric NAT e CGNAT.

Svantaggi: il relay introduce latenza aggiuntiva e carico sul server. Per un ISP o un provider VoIP che gestisce migliaia di chiamate, i server TURN rappresentano un costo infrastrutturale significativo.

La porta standard è 3478/UDP (e TCP per fallback), con 5349 per la variante TLS (TURNS).

ICE: orchestrare STUN e TURN

Interactive Connectivity Establishment (RFC 8445) non è un sostituto di STUN/TURN ma un framework che li coordina. ICE raccoglie tutti i possibili "candidati" per la comunicazione:

• Host candidates: indirizzi IP locali del dispositivo
• Server Reflexive candidates: IP:porta ottenuti tramite STUN
• Relay candidates: IP:porta allocati su un server TURN

Poi esegue un processo di connectivity check usando STUN Binding Requests tra tutti i candidati, seleziona la coppia funzionante con priorità più alta e avvia la comunicazione.

La priorità tipica è: direct > server reflexive > relay. ICE usa sempre il percorso più diretto disponibile, ricorrendo al TURN solo se tutto il resto fallisce.

Configurazione pratica su FreePBX / Asterisk

In asterisk/pjsip.conf (o tramite GUI FreePBX → PJSIP Settings):

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=1.2.3.4      ; IP pubblico del server
external_signaling_address=1.2.3.4
local_net=192.168.1.0/24            ; rete locale da escludere dal NAT

Per endpoint che si connettono da remoto con ICE:

[endpoint-remoto]
type=endpoint
ice_support=yes
media_use_received_transport=yes
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

Su Yeastar (S-Series / P-Series) la configurazione è in Settings → VoIP → SIP → NAT dove si inserisce IP pubblico, STUN server e si abilita ICE per endpoint.

Diagnosi problemi audio

Se una chiamata connette ma non c'è audio:

• Verifica con tcpdump o Wireshark che i pacchetti RTP arrivino all'interfaccia corretta
• Controlla che le porte RTP (default 10000-20000/UDP su Asterisk) siano aperte nel firewall
• Verifica i log ICE nel client: cerca ICE failed o candidate pair failed
• Prova a forzare TURN disabilitando temporaneamente i candidati host e server reflexive

Un sintomo tipico di Symmetric NAT è che STUN restituisce un IP corretto ma le porte cambiano ad ogni connessione, rendendo inutilizzabili i candidati server reflexive.

Considerazioni per ISP con CGNAT

Se la tua rete usa CGNAT (RFC 6598, range 100.64.0.0/10), i clienti hanno NAT doppio. In questo scenario:

• STUN funziona raramente
• TURN è praticamente obbligatorio per RTP
• L'alternativa è fornire IP pubblici dedicati agli utenti VoIP business
• Alcuni ISP usano ALG SIP sul router per manipolare i pacchetti, ma questa soluzione crea spesso problemi con TLS

La scelta migliore per un ISP che vuole offrire VoIP di qualità è evitare CGNAT per i clienti che usano SIP, o in alternativa fornire un server TURN gestito internamente.