Nel mondo VoIP e SIP la qualità delle chiamate non dipende solo da banda e codec: il comportamento del NAT (Network Address Translation) del tuo router può determinare se l’audio passa correttamente o se ottieni i classici problemi di “telefono che squilla ma non si sente nulla”. Guide tecniche sui concetti di IP pubblico e IP privato spiegano proprio come il NAT nasconda gli indirizzi interni dietro un IP pubblico, creando sfide specifiche per la segnalazione SIP e per i flussi RTP.
In questo articolo vediamo quali sono i principali tipi di NAT (Full Cone, Restricted, Port‑Restricted, NAT simmetrico), come influiscono su porte SIP e flussi RTP/RTCP, quali meccanismi esistono per il NAT traversal (STUN, TURN, ICE, SIP Outbound) e quali best practice adottare per avere un VoIP stabile e sicuro. Se vuoi un quadro più ampio sul lessico VoIP, puoi partire dalle basi su cos’è il VoIP aziendale e sull’elenco di termini VoIP per aziende.
Il NAT è la funzione del router che permette a più dispositivi con indirizzi IP privati (es. 192.168.x.x) di condividere un unico IP pubblico verso Internet, riscrivendo indirizzi e porte dei pacchetti in transito. La documentazione IETF sul NAT descrive come il router mantenga una tabella di mappature tra coppie IP:porta interne ed esterne.
Questo meccanismo è trasparente per la maggior parte delle applicazioni, ma crea complicazioni per i protocolli come SIP e RTP, che usano spesso UDP e porte dinamiche e che inseriscono indirizzi e porte anche dentro il payload (SDP), non solo nell’header IP. Per approfondire la differenza pratica tra IP pubblico e privato in un contesto VoIP puoi vedere anche l’articolo su IP pubblico vs IP privato.
In una chiamata VoIP, la segnalazione SIP (INVITE, 200 OK, BYE, ecc.) e i flussi RTP/RTCP (audio/video) seguono percorsi diversi:
Se il NAT altera o blocca queste porte in modo non compatibile, ottieni sintomi tipici: telefono che squilla ma nessun audio, audio monodirezionale, sessioni che cadono dopo pochi minuti.
La letteratura tecnica distingue due macro famiglie di NAT:
Per il VoIP, i NAT di tipo Cone sono generalmente più “amichevoli”, mentre il NAT simmetrico è notoriamente il più problematico per SIP e RTP, come evidenziato anche nei documenti IETF sul NAT traversal e in articoli tecnici su STUN/TURN/ICE.
Nel Full Cone NAT:
È il tipo di NAT più compatibile con VoIP SIP, ma anche il più rischioso dal punto di vista sicurezza se abbini un port forwarding sulla 5060: la tua infrastruttura diventa facilmente bersaglio di attacchi e tentativi di brute force sui registri SIP.
Nei Restricted Cone NAT:
Per VoIP questo significa che STUN e tecniche di “hole punching” funzionano ancora abbastanza bene, ma possono esserci problemi con provider multipli o scenari complessi.
Nel NAT simmetrico:
Per il VoIP è il caso peggiore: STUN da solo non basta, le porte RTP annunciate nell’SDP spesso non corrispondono alle mappature reali e si verificano frequentemente audio assente o monodirezionale, specialmente quando telefoni IP o softphone sono dietro router “chiusi” o CGNAT di operatori mobile.
La RFC 4787 introduce una terminologia più precisa per i NAT:
I NAT “amici del VoIP” tendono ad avere mapping endpoint‑independent; quelli più critici (simmetrici) usano mapping address‑and‑port‑dependent.
La stessa RFC definisce il comportamento di filtraggio:
Più il filtro è restrittivo, più è difficile far funzionare VoIP SIP con semplici tecniche STUN, e più diventa importante avere un proxy/SBC o un media relay.
Un altro aspetto chiave è se il NAT preserva o meno il numero di porta:
Dal punto di vista VoIP, la preservazione di porta rende tutto più prevedibile; la randomizzazione estrema complica il debug di porte SIP e RTP e richiede strumenti di traversal più robusti.
Con Full Cone NAT:
In scenari tipici di small office, router con Restricted/Port‑Restricted Cone NAT permettono di far funzionare telefoni IP e softphone con:
Di solito sono gestibili senza grosse complicazioni, ma possono dare problemi quando si usano più provider SIP contemporaneamente dietro lo stesso NAT.
Nel NAT simmetrico, STUN non è sufficiente perché la mappatura esterna dipende da ogni singola destinazione; i flussi RTP provenienti da IP o porte diversi da quelli usati in uscita vengono scartati. I documenti IETF su ICE e NAT traversal raccomandano in questi casi l’uso di TURN o di un media relay/SBC che faccia da punto fisso per i media.
| Tipo NAT | Mappatura | Filtraggio | Compatibilità SIP/RTP | Note |
|---|---|---|---|---|
| Full Cone | Endpoint‑Independent | Endpoint‑Independent | Alta | Facile per VoIP, ma rischioso per sicurezza |
| Restricted Cone | Endpoint‑Independent | Address‑Dependent | Buona | Funziona bene con STUN, qualche attenzione ai provider multipli |
| Port‑Restricted Cone | Endpoint‑Independent | Address‑and‑Port‑Dependent | Media | Richiede STUN e keepalive ben configurati |
| NAT simmetrico | Address‑and‑Port‑Dependent | Address‑and‑Port‑Dependent | Bassa | Spesso necessario TURN/SBC, STUN da solo non basta |
STUN (Session Traversal Utilities for NAT) permette a un client di scoprire il proprio IP e porta pubblici contattando un server STUN. Funziona bene con NAT di tipo Cone ed è spesso integrato in telefoni IP e softphone per VoIP, ma è inefficace con NAT simmetrici, come spiegano le specifiche IETF e molti tutorial su STUN/TURN.
TURN (Traversal Using Relays around NAT) fornisce un relay per i media: audio/video vengono inviati a un server TURN che poi li inoltra all’altro endpoint. È più costoso in termini di banda server, ma è spesso l’unico modo per attraversare NAT simmetrici o doppi NAT complessi.
ICE (Interactive Connectivity Establishment), descritto in vari RFC tra cui la RFC 8839, combina STUN e TURN per trovare il percorso migliore tra due endpoint. Attraverso attributi SDP come a=ice-ufrag, a=ice-pwd e a=candidate, gli endpoint scambiano possibili “candidati” (IP/porte) e testano quale combinazione funziona meglio dietro i rispettivi NAT.
Lato SIP, RFC come la RFC 3581 introducono parametri come rport e il parametro received che permettono al server SIP di rispondere all’IP:porta effettivo da cui arriva la richiesta, non solo a quello dichiarato negli header. Alcune estensioni come SIP Outbound e l’uso di keepalive (OPTIONS, CRLF, REGISTER frequenti) aiutano a mantenere stabili le mappature NAT.
Per capire i problemi NAT nel VoIP è importante ricordare che:
c= e m=) contiene IP e porte per i media;Se un router o un SIP ALG riscrive in modo incoerente questi valori, è facile che il traffico audio non trovi strada, anche se la parte SIP sembra funzionare.
Molti router includono un SIP ALG (Application Layer Gateway) che tenta di “aiutare” il VoIP riscrivendo header SIP e SDP, ma implementazioni incomplete possono corrompere i pacchetti e peggiorare la situazione. Diverse best practice suggeriscono di disattivare l’ALG e affidarsi a configurazioni esplicite di NAT, STUN/TURN/ICE o a un SBC/proxy SIP dedicato.
In scenari con doppio NAT (router dell’ISP + router locale) o con CGNAT (Carrier‑Grade NAT, tipico di molte connessioni mobile), la complessità aumenta: i client VoIP vedono solo il NAT locale, ma i pacchetti devono attraversare un ulteriore livello di traduzione. In questi casi spesso è necessario un media relay o un SBC raggiungibile su IP pubblico per garantire la stabilità delle chiamate.
Esporre direttamente la porta 5060 e un ampio range di porte VoIP (RTP) tramite port forwarding su un NAT Full Cone rende la vita facile ai telefoni IP e ai PBX, ma anche agli attaccanti. È una configurazione che può portare a scanning massicci, brute force su account SIP e frodi telefoniche (chiamate internazionali abusive).
Per bilanciare compatibilità VoIP e sicurezza è opportuno:
Caso tipico: telefoni IP e softphone dietro un router SOHO con NAT di tipo Restricted/Port‑Restricted Cone. Con STUN ben configurato, keepalive delle registrazioni e SIP ALG disattivato, il VoIP funziona bene con uno o più provider SIP, specialmente se la rete è dimensionata correttamente e si usano router ottimizzati per voce come quelli descritti nelle guide su come scegliere un router VoIP e sui migliori router VoIP.
Molte aziende espongono il proprio centralino IP on‑prem via port forwarding su 5060 e range RTP. È una soluzione semplice che funziona bene con SIP trunk, come spiegato nelle guide su SIP trunk vs VoIP, ma richiede un’attenta configurazione di firewall, ACL e monitoraggio per evitare abusi.
In contesti enterprise o su reti mobile con NAT simmetrico/CGNAT, i client VoIP spesso si affidano a ICE con STUN+TURN, o a un proxy/SBC gestito dal provider per garantire la raggiungibilità. In alternativa, valutare soluzioni di telefonia IP più strutturate o numerazioni gestite via cloud PBX può semplificare molto la vita.
Per identificare il tipo di NAT puoi usare:
In caso di problemi audio:
Via, Contact e nei campi c=/m= dell’SDP;Se il NAT è particolarmente ostile (simmetrico, con ALG non disattivabile, doppi NAT), spesso è più semplice:
Capire come funziona il tipo di NAT che hai in rete (Full Cone, Restricted, Port‑Restricted, NAT simmetrico) e come interagisce con SIP, porte VoIP e flussi RTP è essenziale per progettare una telefonia IP stabile, sicura e pronta per scenari avanzati come softphone, DECT IP e lavoro ibrido. Una buona progettazione del NAT e delle relative eccezioni è tanto importante quanto la scelta del provider e dell’hardware VoIP.
Per approfondire architetture di telefonia IP, differenze tra VoIP e altre tecnologie e il ruolo di router e software nel mondo VoIP, puoi consultare i contenuti su VoIP aziendale e sugli altri articoli dedicati a VoIP vs VoLTE, SIP trunk, router VoIP e softphone per PC e smartphone.
Affidati a Epiclink, 3CX Partner esperto. Integriamo VoIP, Data Center e connettività per la tua…
Cerchi un Data Center a Milano? Scopri le soluzioni Epiclink: connettività carrier-neutral, sicurezza ISO e…
Quando si parla di VoIP (Voice over IP), molti pensano subito al protocollo SIP come…
Linea ISDN vs VoIP: differenze, vantaggi, costi e come gestire il passaggio Per anni la…
Negli ultimi anni il catalogo Microsoft si è popolato di nomi molto simili: Office 365,…
Smartphone, tablet e laptop sono diventati endpoint aziendali a tutti gli effetti: contengono email, documenti,…