Problemi audio VoIP: diagnosi e soluzioni, sintomo per sintomo

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 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: un audio brutto con perdita zero e jitter basso sposta la diagnosi verso codec e acustica, non verso la rete.

La tabella sintomo, causa e rimedio

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

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
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
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, una classe dedicata alla 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.

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; meno della metà con G.729. 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 nostro pane quotidiano: scopri le soluzioni VoIP aziendali di Netframe o contattaci per una diagnosi.

By Published On: Agosto 4, 2026Categories: Guide tecniche, Telefonia AziendaleTags: , , , ,

Other Articles