Problemi audio VoIP: diagnosi e soluzioni, sintomo per sintomo

Le chiamate VoIP che si sentono male hanno una caratteristica che manda in confusione: il centralino risulta perfettamente funzionante, la linea è registrata, eppure l’audio è a scatti, arriva da una parte sola o sparisce dopo mezzo minuto. Il motivo è che nel VoIP la voce non passa dal centralino inteso come scatola: passa dalla rete, e quasi tutti i problemi audio nascono lì, tra NAT, SIP ALG, QoS assente e codec. Questa guida è costruita come la usiamo noi in assistenza: prima le regole di diagnosi, poi la tabella sintomo, causa e rimedio, infine l’approfondimento dei colpevoli ricorrenti.

Le tre regole prima di toccare qualsiasi cosa

Prima regola: circoscrivere il problema

Il problema c’è tra interno e interno o solo verso l’esterno? In una direzione o in entrambe? Sempre, o solo in certi orari? Su tutti i telefoni o solo su softphone e dispositivi Wi-Fi? Ogni risposta dimezza il campo delle cause.

Seconda regola: separare segnalazione e voce

Nel VoIP viaggiano due flussi distinti: il SIP, che negozia la chiamata, e l’RTP, che trasporta l’audio. Una chiamata che squilla e si connette ma non si sente ha il SIP a posto e l’RTP bloccato: sono problemi diversi con rimedi diversi.

Terza regola: misurare, non giudicare a orecchio

Jitter, perdita di pacchetti e MOS si leggono nelle statistiche del centralino, dei telefoni o dell’SBC, e servono i valori di riferimento per interpretarli: il jitter va tenuto sotto i 30 millisecondi, meglio sotto i 20 dove la qualità deve essere ottima; la perdita di pacchetti sotto l’1%; il MOS a 4,0 o più per una chiamata giudicata buona, mentre sotto 3,0 la conversazione diventa faticosa.

Va guardata anche la latenza in una direzione, che la raccomandazione ITU-T G.114 vuole sotto i 150 millisecondi: quando sfora non produce audio a scatti, produce sovrapposizioni, cioè due persone che parlano insieme senza accorgersene. Un audio brutto con perdita nulla, jitter dentro soglia e latenza bassa sposta la diagnosi verso codec e acustica, non verso la rete.

La tabella sintomo, causa e rimedio

Sono i nove sintomi che coprono la quasi totalità delle segnalazioni reali. La colonna centrale indica la causa più probabile, da verificare per prima.

Sintomi che si presentano subito

Sintomo	Causa più probabile	Rimedio
Si sente solo da una parte (audio unidirezionale)	NAT che blocca l’RTP in una direzione, spesso per colpa del SIP ALG che riscrive male gli indirizzi	Disattivare il SIP ALG, verificare il forwarding del range RTP, valutare un SBC
Chiamata connessa ma muta nei due sensi	Range di porte RTP (UDP) chiuso sul firewall, o codec non compatibili tra le parti	Aprire il range RTP indicato dal centralino, allineare la lista dei codec
Voce a scatti o robotica	Jitter e perdita di pacchetti: uplink saturo, QoS assente	QoS con priorità alla voce (DSCP EF), verifica della banda in upload
Eco	Accoppiamento acustico di vivavoce e cuffie, o ibrido delle linee analogiche su gateway FXO	Abbassare i livelli, attivare la cancellazione d’eco, tarare l’impedenza sulle porte FXO
Voce metallica o ovattata	Doppie transcodifiche lungo il percorso, codec a banda stretta come G.729	Uniformare i codec end-to-end, preferire G.711 o codec wideband dove la banda lo consente
La chiamata cade dopo circa 30 secondi	ACK o messaggi successivi persi per colpa di NAT e SIP ALG: la segnalazione non si completa	Disattivare il SIP ALG, ridurre i tempi di registrazione, keepalive, SBC

Sintomi che compaiono dopo l’inizio della chiamata

Sintomo	Causa più probabile	Rimedio
L’audio sparisce dopo qualche minuto	Binding NAT scaduto sul router: il flusso RTP perde la strada	Keepalive RTP, timeout NAT più lunghi per l’UDP, SBC come punto fisso
Ci si sovrappone parlando, l’interlocutore risponde in ritardo	Latenza in una direzione oltre i 150 ms: percorsi di rete tortuosi, trunk con molti salti, jitter buffer troppo generosi	Misurare la latenza end-to-end, accorciare il percorso dei trunk, tarare il jitter buffer, che assorbe il jitter ma aggiunge latenza: i due si leggono insieme
Problemi solo su smartphone e cordless Wi-Fi	Roaming lento e copertura marginale: la rete wireless non è progettata per la voce	Verifica radio sul campo, celle a segnale forte e roaming veloce

Una nota sull’ultima riga: se i problemi compaiono solo sui dispositivi wireless, la diagnosi si sposta dalla telefonia alla rete radio, e lì la risposta è la misura sul campo con un site survey Wi-Fi, non un altro giro di parametri sul centralino.

SIP e RTP: perché una chiamata “funziona” ma si sente male

Il SIP è la segnalazione: fa squillare, risponde, chiude. L’RTP è la voce vera, un flusso di pacchetti UDP che parte solo dopo che il SIP ha negoziato indirizzi, porte e codec nel corpo SDP dei messaggi. Il NAT del router aziendale complica entrambe le cose, perché dentro l’SDP viaggiano indirizzi IP privati che dall’esterno non significano nulla. È qui che nascono l’audio unidirezionale, le chiamate mute e quelle che cadono al trentesimo secondo: la segnalazione riesce, la voce no.

SIP ALG: il primo indiziato, quasi sempre colpevole

Il SIP ALG (Application Layer Gateway) è una funzione dei router che ispeziona e riscrive i pacchetti SIP per aiutarli ad attraversare il NAT. L’intenzione è buona, il risultato quasi mai: le implementazioni dei router di fascia consumer e business entry riscrivono male gli header, corrompono l’SDP e producono esattamente i sintomi che vorrebbero evitare, audio a senso unico e chiamate che cadono. La regola pratica dell’assistenza VoIP è disattivarlo, sul router dell’operatore o sul firewall, e lasciare che siano il centralino o l’SBC a gestire il NAT come si deve. L’eccezione esiste, alcuni firewall enterprise hanno ALG implementati bene, ma va dimostrata sul campo, non presunta.

QoS che funziona davvero

Una chiamata in G.711 pesa circa 100 kbps: la banda non è quasi mai il problema, il problema è la coda. Quando l’uplink si satura, anche solo per i secondi di un backup verso il cloud o di un upload video, i pacchetti voce aspettano o si perdono, e la voce si spezza. La QoS corretta marca il traffico voce (DSCP EF per l’RTP, CS3 per la segnalazione) e soprattutto lo prioritizza dove serve: sull’uplink verso Internet, che è il collo di bottiglia reale, e sugli switch di accesso. Alla VLAN dedicata alla voce e alla configurazione della QoS sugli apparati dedicheremo una guida specifica: qui basti la regola, prima si misura la saturazione, poi si prioritizza, e solo alla fine si compra banda. Requisiti di banda, latenza e perdita dei collegamenti sono trattati anche nella pagina sull’integrazione della telefonia aziendale.

Quando serve un SBC

Quando i sintomi da NAT si ripresentano a ogni cambio di router, quando convivono operatori diversi, centralino e Microsoft Teams, o quando serve un punto unico di controllo e sicurezza sul SIP, la risposta strutturale è il Session Border Controller: gestisce il NAT in modo corretto, fa da punto fisso per i flussi RTP, transcodifica dove serve e nasconde la topologia interna. È lo stesso apparato al centro di Microsoft Teams Direct Routing, e come ogni apparato esposto va indurito: ne abbiamo scritto nella guida alla configurazione sicura dell’SBC.

Domande frequenti sui problemi audio VoIP

Perché nella chiamata VoIP si sente solo da una parte?

È il sintomo classico del NAT che blocca il flusso audio RTP in una direzione, quasi sempre aggravato dal SIP ALG del router che riscrive male gli indirizzi nella segnalazione. La sequenza di verifica: disattivare il SIP ALG, controllare che il range di porte RTP del centralino sia raggiungibile, e se il problema si ripresenta valutare un SBC come punto fisso per i flussi.

Cos’è il SIP ALG e perché conviene disattivarlo?

È una funzione dei router che ispeziona e riscrive il traffico SIP per farlo passare attraverso il NAT. Nella pratica le implementazioni sono spesso difettose e producono audio a senso unico, chiamate mute e cadute dopo pochi secondi. Nella maggior parte delle installazioni VoIP la scelta corretta è disattivarlo e lasciare la gestione del NAT al centralino o all’SBC.

Perché la chiamata VoIP cade dopo circa 30 secondi?

Perché la segnalazione SIP non si completa: l’ACK o i messaggi successivi si perdono nel NAT, spesso per colpa del SIP ALG, e il sistema chiude la chiamata allo scadere del timer. È un sintomo così ricorrente da essere una firma: la diagnosi parte dal SIP ALG e dal NAT, non dal centralino.

Come si elimina l’eco nelle chiamate VoIP?

Dipende da dove nasce. Se compare con vivavoce e cuffie è accoppiamento acustico: si riducono i livelli e si attiva la cancellazione d’eco del dispositivo. Se compare sulle chiamate che attraversano linee analogiche o gateway FXO è l’ibrido a due fili: si tarano impedenza e cancellazione d’eco sul gateway. L’eco non è quasi mai un problema di banda o di operatore.

Quanta banda serve per una chiamata VoIP?

Circa 100 kbps per direzione con il codec G.711, overhead compreso; circa un terzo con G.729, che scende intorno ai 30 kbps. Per questo la banda non è quasi mai la causa dei problemi: dieci chiamate simultanee stanno in circa 1 Mbps. A rovinare l’audio sono jitter e perdita di pacchetti quando l’uplink si satura senza una QoS che dia priorità alla voce.

Perché il VoIP va a scatti solo in certi orari?

Perché in quegli orari qualcosa satura la connessione, tipicamente in upload: backup verso il cloud, sincronizzazioni, videoconferenze. I pacchetti voce finiscono in coda dietro al resto e la voce si spezza. La soluzione non è comprare banda alla cieca ma misurare la saturazione e configurare una QoS che riservi priorità al traffico voce.

Hai chiamate che cadono, eco o audio a scatti e nessuno trova la causa? È il pane quotidiano di Netframe, system integrator IT dell’Emilia-Romagna con sede a Modena: scopri le soluzioni VoIP aziendali o contattaci per una diagnosi.

Netframe è un system integrator indipendente. Microsoft, citata in questa guida, è technology partner di Netframe.

Fonti

• RFC 3261 (SIP), RFC 3550 (RTP) e RFC 4566 (SDP): i protocolli di segnalazione, trasporto e negoziazione
• RFC 4028, Session Timers in the Session Initiation Protocol
• ITU-T G.711 e G.729, i codec audio
• ITU-T G.114, tempo di trasmissione in una direzione: la soglia dei 150 ms
• ITU-T P.800, metodi di valutazione soggettiva della qualità: la scala MOS
• RFC 2474 e RFC 3246, DiffServ ed Expedited Forwarding: le marcature DSCP
• Cisco, Quality of Service for Voice over IP: requisiti di perdita, ritardo e jitter della voce (cisco.com)

Fonti verificate l’11 agosto 2026.