VoIP SIP e NAT: perché tipo di NAT e porte contano davvero per audio e stabilità

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.

Perché il NAT è un problema per il VoIP SIP

NAT, IP privati e IP pubblici in breve

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.

Segnalazione SIP vs flussi RTP/RTCP

In una chiamata VoIP, la segnalazione SIP (INVITE, 200 OK, BYE, ecc.) e i flussi RTP/RTCP (audio/video) seguono percorsi diversi:

• SIP viaggia verso il server/proxy del provider sulla porta SIP (di solito 5060 UDP/TCP o 5061 TLS);
• nel corpo SIP, l’SDP annuncia quali porte RTP l’endpoint userà per l’audio e il video;
• i flussi RTP/RTCP viaggiano direttamente tra gli endpoint (o via media relay) sulle porte indicate.

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.

Tipologie classiche di NAT: Full Cone, Restricted, Port‑Restricted, Simmetrico

Cone NAT vs NAT simmetrico: le due grandi famiglie

La letteratura tecnica distingue due macro famiglie di NAT:

• Cone NAT (Full Cone, Restricted, Port‑Restricted), dove una mappatura IP:porta esterna può essere riutilizzata verso più destinazioni;
• NAT simmetrico (Symmetric NAT), dove ogni destinazione esterna genera una nuova mappatura distinta.

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.

Full Cone NAT

Nel Full Cone NAT:

• la prima uscita (es. 192.168.1.10:5060 → IP_pubblico:40000) crea una mappatura riutilizzabile;
• qualsiasi host esterno può inviare traffico a IP_pubblico:40000 e verrà inoltrato a 192.168.1.10:5060;
• la porta esterna spesso è preservata o è comunque stabile.

È 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.

Restricted Cone NAT e Port‑Restricted Cone NAT

Nei Restricted Cone NAT:

• la mappatura interna→esterna è indipendente dal destinatario, ma il traffico in ingresso è accettato solo da IP già contattati dall’interno;
• nel Port‑Restricted Cone NAT il filtro è ancora più restrittivo: devono combaciare IP e porta remota.

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.

NAT simmetrico (Symmetric NAT)

Nel NAT simmetrico:

• ogni flusso verso un diverso IP:porta esterno ottiene una mappatura esterna diversa;
• il traffico in ingresso è accettato solo se proviene da quell’esatto IP:porta di destinazione;
• la porta esterna è spesso randomizzata (no port preservation).

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.

Terminologia moderna (RFC 4787) spiegata semplice

Endpoint‑Independent vs Address/Port‑Dependent Mapping

La RFC 4787 introduce una terminologia più precisa per i NAT:

• Endpoint‑Independent Mapping (EIM): la stessa mappatura esterna viene usata verso qualsiasi destinazione;
• Address‑Dependent Mapping: mappatura dipende dall’IP di destinazione;
• Address‑and‑Port‑Dependent Mapping: mappatura dipende da IP e porta di destinazione.

I NAT “amici del VoIP” tendono ad avere mapping endpoint‑independent; quelli più critici (simmetrici) usano mapping address‑and‑port‑dependent.

Endpoint‑Independent / Address‑Dependent Filtering

La stessa RFC definisce il comportamento di filtraggio:

• Endpoint‑Independent Filtering: qualsiasi host può rispondere sulla mappatura esterna;
• Address‑Dependent Filtering: solo host con IP già contattato;
• Address‑and‑Port‑Dependent Filtering: solo host con IP e porta già contattati.

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.

Port preservation, port randomization e port overloading

Un altro aspetto chiave è se il NAT preserva o meno il numero di porta:

• port preservation: la porta esterna coincide (se possibile) con quella interna;
• port randomization: la porta esterna viene scelta casualmente;
• port overloading: stessa porta esterna riutilizzata per più interni, distinguendo solo tramite destinazione.

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.

Effetti dei tipi di NAT su SIP e RTP

Full Cone NAT: alta compatibilità, alto rischio

Con Full Cone NAT:

• registrazioni SIP dietro NAT funzionano spesso “al primo colpo”;
• le risposte dal server SIP e i flussi RTP trovano facilmente la strada di ritorno;
• ma esporre la porta 5060 o un range RTP verso Internet apre a brute force, scanning e tentativi di frode VoIP.

Restricted / Port‑Restricted Cone NAT

In scenari tipici di small office, router con Restricted/Port‑Restricted Cone NAT permettono di far funzionare telefoni IP e softphone con:

• registrazioni periodiche (keepalive) che mantengono aperte le mappature;
• uso di STUN per scoprire l’IP/porta pubblici;
• configurazioni corrette di “rport” e “received” lato proxy SIP.

Di solito sono gestibili senza grosse complicazioni, ma possono dare problemi quando si usano più provider SIP contemporaneamente dietro lo stesso NAT.

NAT simmetrico: il caso più critico

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.

Tabella: Tipo NAT e compatibilità VoIP

Strumenti di NAT traversal per SIP: STUN, TURN, ICE, proxy

STUN: utile ma non sempre sufficiente

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 e media relay

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: orchestrare STUN e TURN

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.

rport, “received”, keepalive e SIP Outbound

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.

SIP, SDP e NAT: dove compaiono IP e porte

Dove viaggiano IP e porte in SIP/SDP

Per capire i problemi NAT nel VoIP è importante ricordare che:

• gli header SIP (Via, Contact) contengono IP/porta di segnalazione;
• il body SDP (campi c= e m=) contiene IP e porte per i media;
• RTP/RTCP usa le porte realmente mappate dal NAT, che possono differire da quelle dichiarate.

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.

SIP ALG: cosa fa e perché spesso conviene disattivarlo

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.

Doppi NAT e CGNAT

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.

Sicurezza: quando il NAT “troppo aperto” è un rischio per il VoIP

Full Cone + port forwarding: comodo ma pericoloso

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).

Mitigazioni: firewall, ACL, limiti, SBC

Per bilanciare compatibilità VoIP e sicurezza è opportuno:

• limitare le origini ammesse (ACL per IP e paesi);
• impostare limiti su chiamate simultanee, credito, destinazioni a rischio;
• usare strumenti tipo fail2ban/IDS/IPS per bloccare tentativi ripetuti;
• in contesti complessi, introdurre un SBC / proxy SIP davanti al PBX.

Esempi pratici di NAT in scenari VoIP

Small office dietro router con Cone NAT

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.

PBX on‑prem dietro NAT con port forwarding

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.

Softphone e telefoni IP dietro NAT simmetrico o CGNAT

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.

Diagnostica e best practice operative

Come capire che NAT hai

Per identificare il tipo di NAT puoi usare:

• test STUN (molti softphone e tool diagnostici indicano il tipo di NAT rilevato);
• log del router/firewall e strumenti di analisi traffico;
• supporto del tuo provider VoIP, che può spesso riconoscere pattern tipici dai log di registrazione/chiamata.

Cosa guardare nei log SIP e nell’SDP

In caso di problemi audio:

• verifica gli IP/porte nei campi Via, Contact e nei campi c=/m= dell’SDP;
• controlla se il server SIP vede l’IP/porta reale del client (parametri rport/received);
• usa strumenti come Wireshark per vedere se i pacchetti RTP arrivano e da dove.

Quando cambiare router/NAT e quando usare un SBC

Se il NAT è particolarmente ostile (simmetrico, con ALG non disattivabile, doppi NAT), spesso è più semplice:

• adottare un router/firewall più adatto al VoIP;
• oppure introdurre un SBC / proxy SIP che faccia da punto fisso sulla rete pubblica;
• in parallelo, scegliere soluzioni VoIP professionali come quelle presentate nella sezione VoIP per aziende, che tengono conto di questi aspetti progettuali.

Conclusione: NAT, SIP e RTP non sono dettagli di contorno

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.