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.
Other Articles
Gateway VoIP-ISDN: mantenere il centralino dopo lo switch off
Microsoft Teams Phone: il centralino dentro Teams, come funziona davvero
Integrazione tra centralino e CRM: come funziona davvero la CTI
Centralino NEC a fine supporto: cosa fare con SL2100 e SV9100
Wi-Fi in ospedale e nelle strutture sanitarie: progettazione e criticità
Wi-Fi nell’industria alimentare: reti a prova di lavaggi, vapore e celle

