Volume audio basso in chiamata VoIP, da dove iniziare

Chi installa e gestisce sistemi VoIP si trova spesso davanti a una scena ormai familiare: il cliente finale chiama, descrive una voce troppo bassa durante la conversazione e si aspetta una risposta rapida. Dal suo punto di vista il problema è semplice, durante la chiamata sente poco oppure viene sentito con un livello troppo basso. Dal punto di vista del tecnico, invece, quella segnalazione è solo il punto di partenza.

Il motivo è chiaro. Quando un utilizzatore parla di volume audio basso durante la chiamata, non sta quasi mai facendo una diagnosi tecnica, sta descrivendo una percezione. In quella percezione possono rientrare situazioni molto diverse: livello realmente basso in ricezione, microfono che trasmette con poca presenza, voce chiusa per effetto del codec, audio impoverito dalla transcodifica RTP, problemi di rete che rendono il parlato meno pieno o meno intellegibile.

Per questo, quando un cliente finale riporta questo difetto, la cosa più utile che l’installatore o il tecnico possa fare non è cercare subito il parametro da cambiare. Conviene prima ordinare il problema, fare le domande giuste e restringere il campo con metodo. Solo così si evita di attribuire al trunk un difetto che nasce tra interni, oppure di sospettare il PBX quando il problema è locale al terminale o al percorso RTP.

Dove nasce il livello audio

Prima ancora di distinguere tra rete pubblica e chiamate interne, conviene chiarire un punto tecnico spesso trascurato: il livello audio non nasce in un solo punto della chiamata. Si forma lungo una catena composta da più passaggi, e ogni passaggio può conservare il livello corretto oppure alterarlo.

Il primo passaggio è il terminale. La voce entra dal microfono come segnale analogico, attraversa il circuito audio locale e viene campionata, quantizzata e codificata dal codec. È qui che si definiscono i primi equilibri del segnale utile, del rumore di fondo, della dinamica e della presenza vocale. Per questo motivo un codec non va letto solo come compressione o risparmio di banda, ma come primo livello in cui la voce viene trasformata in informazione digitale trasportabile.

Il secondo passaggio è il trasporto tra endpoint, PBX, SBC e provider. In questa fase il flusso RTP può restare diretto oppure essere ancorato, rielaborato o transcodificato. Se il PBX o un media server entra nel media path, il segnale può essere decodificato e ricodificato, con effetti concreti sulla presenza della voce, sulla banda percepita e sul modo in cui l’utilizzatore descrive il volume.

Il terzo passaggio è l’interconnessione sulla rete pubblica. Anche quando il primo tratto interno è corretto, la voce può attraversare gateway, carrier e transcodifiche ulteriori prima di arrivare al destinatario finale. In questo tratto il problema non è solo la perdita di qualità assoluta, ma anche il cambiamento di percezione del livello audio, soprattutto quando la catena include conversioni tra codec diversi o passaggi tra ambienti wideband e narrowband.

Per questo motivo il volume audio basso durante la chiamata non va mai letto come un singolo parametro fuori posto. Va letto come il risultato finale di una catena audio composta da cattura, codifica, trasporto RTP, eventuale trattamento media e riproduzione lato ricevente.

Se vogliamo schematizzare questa catena in modo molto pratico, il percorso è questo:
voce analogica, circuito audio del telefono IP, codifica del codec, trasporto RTP interno, eventuale transcodifica su PBX o media server, trasporto verso il provider, eventuale interscambio tra operatori sulla rete pubblica, decodifica lato ricevente, riproduzione su microtelefono, vivavoce o cuffia.

Questa sequenza aiuta a capire perché una segnalazione apparentemente semplice, come audio basso, non andrebbe mai affrontata toccando subito i livelli del terminale. Prima bisogna capire in quale punto della catena il segnale sta perdendo presenza, dinamica o intelligibilità.

Rete pubblica o interni

La prima domanda tecnica non riguarda ancora microfoni, codec o PBX. Riguarda il perimetro del problema: l’audio è basso solo nelle chiamate che passano sulla rete pubblica, oppure è basso anche tra interni?

Se il difetto compare solo nelle chiamate verso la rete pubblica, il sospetto iniziale si concentra sulla parte esterna del percorso: trunk SIP, provider, media gateway, negoziazione codec con l’operatore, eventuale transcodifica RTP sul lato carrier o sul PBX se il centralino entra nel media path.

Se invece il difetto compare anche nelle chiamate tra interni, il quadro cambia subito. In quel caso il problema non può essere attribuito solo alla rete pubblica, perché una parte delle prove resta completamente dentro l’infrastruttura del cliente. Qui diventano centrali telefoni IP, PBX, SBC, rete locale, WAN tra sedi e percorso RTP reale.

Questa distinzione iniziale è fondamentale perché evita un errore comune: concentrarsi subito sul provider quando il problema è già presente nelle chiamate interne, oppure perdere tempo sugli endpoint quando il difetto esiste solo in uscita verso il trunk.

Ricezione o trasmissione

La domanda successiva è altrettanto semplice: chi percepisce il volume audio basso durante la chiamata?

Se l’utilizzatore sente basso l’altro interlocutore, bisogna guardare il livello di riproduzione, quindi microtelefono, altoparlante, cuffia, circuito audio del telefono IP, impostazioni locali e qualità del flusso RTP ricevuto.

Se invece è l’interlocutore remoto a sentire bassa la voce dell’utilizzatore, allora l’analisi si sposta sul livello di cattura, quindi microfono, guadagno, algoritmi di trattamento locale, accessori, profilo audio e, in alcuni casi, trattamento del media lungo il percorso.

Se il difetto è in entrambe le direzioni, la probabilità di una causa unica sul singolo terminale si riduce e salgono di peso codec, transcodifica RTP, percorso media e condizioni di rete.

Anche questa distinzione va fatta prima di toccare qualunque parametro. Nel troubleshooting VoIP serve sempre separare il piano di segnalazione SIP dal piano media RTP, e poi capire se il difetto riguarda il segnale in ingresso, quello in uscita o entrambi.

Solo sulla rete pubblica

Quando il volume audio è percepito come basso solo nelle chiamate verso l’esterno, conviene partire da ciò che cambia rispetto a una chiamata interna. Entrano in gioco il trunk SIP, il provider, eventuali media gateway, il set di codec negoziato con la rete pubblica e il comportamento del PBX se ancora il flusso RTP o fa transcodifica.

In questo scenario bisogna chiedersi se il PBX stia lavorando solo sulla segnalazione oppure se stia agendo anche come media server. Se il centralino entra nel percorso RTP, può fare bridging del flusso audio oppure vera e propria transcodifica RTP. In quel momento il media non è più lo stesso che parte dal telefono IP e arriva all’operatore, ma un flusso che viene trattato, ricostruito e talvolta ricodificato lungo il percorso.

Se il problema appare solo sulla rete pubblica, i sospetti principali sono quattro: codec incompatibili o poco favorevoli tra PBX e carrier, transcodifica RTP con resa audio poco naturale, livello audio diverso introdotto da gateway o carrier, e qualità del trasporto sulla tratta esterna.

Anche tra interni

Quando il volume audio basso compare anche nelle chiamate tra interni, il provider non basta più a spiegare il difetto. In questo caso l’analisi deve restare dentro l’impianto: telefoni IP, PBX, SBC, rete locale, collegamenti tra sedi, QoS, provisioning, firmware e percorso RTP effettivo.

Una chiamata interna è molto utile proprio perché elimina la variabile della rete pubblica. Se il difetto resta, bisogna capire se il media passa direttamente tra gli endpoint oppure se il PBX o l’SBC lo stanno ancorando. Questa informazione cambia il peso delle ipotesi. Se il media è diretto, il PBX conta meno. Se il media passa dal PBX e quel sistema lavora come media server, il ruolo della transcodifica RTP e del trattamento media sale molto.

Analisi per gradi

Dopo aver distinto rete pubblica e chiamate interne, e dopo aver chiarito chi percepisce il volume audio basso durante la chiamata, si può iniziare ad analizzare le cause più frequenti. L’ordine conta, perché aiuta a non mescolare un problema locale del terminale con un effetto del media path.

Cause più frequenti

1. Microtelefono, vivavoce, cuffia

Può sembrare banale, ma va verificato con metodo. Alcuni utenti rispondono in vivavoce, altri usando il microtelefono, altri ancora con cuffie cablate o wireless. Il problema può esistere solo in una modalità. Un telefono che sul microtelefono si sente basso ma in vivavoce no, o viceversa, non sta indicando un problema di trunk ma una differenza nel percorso audio locale.

Qui vale la pena fermarsi un momento anche sul lessico. Nel linguaggio comune si usa spesso la parola cornetta, ma in ambito tecnico è più corretto parlare di microtelefono. Il motivo è semplice: non stiamo indicando solo la forma dell’oggetto, ma un sottosistema audio preciso, composto da capsula microfonica, capsula ricevente, circuito interno e relativo accoppiamento acustico con l’orecchio e con la bocca dell’utilizzatore. La parola cornetta è intuitiva e resta comprensibile a tutti, ma microtelefono è più utile quando si vuole distinguere la modalità di uso dal vivavoce, dalla cuffia o dall’altoparlante.

Usare il termine microtelefono aiuta anche a ragionare meglio sul problema. Se il volume è basso in ricezione sul microtelefono ma corretto in vivavoce, l’attenzione va sulla capsula ricevente, sul percorso audio locale e sulla parte terminale della catena. Se invece il problema riguarda la trasmissione mentre si usa il microtelefono, allora bisogna osservare la capsula microfonica, l’eventuale trattamento locale del segnale e il livello con cui il parlato entra nel codec.

Su molti telefoni IP moderni non sempre è disponibile una regolazione fine e separata del guadagno microfonico o della capsula ricevente del microtelefono. In diversi casi il controllo è automatico oppure esposto in modo molto limitato. Questo significa che inseguire parametri di gain senza sapere come il terminale gestisca davvero il segnale può portare fuori strada.

In linea generale questi guadagni non andrebbero spostati dai valori di default senza una misura chiara del problema. I valori di fabbrica sono in genere scelti dal costruttore per mantenere un equilibrio tra intelligibilità, rumore, distorsione, sensibilità della capsula microfonica e livello di ascolto sul microtelefono. Un aumento arbitrario del livello microfonico può introdurre distorsione, pompaggi dell’AGC, saturazione locale o una voce apparentemente più forte ma meno intellegibile. Allo stesso modo, alzare il livello della capsula ricevente senza criterio può mascherare il problema reale e confondere la diagnosi.

2. Codec diversi

Quando due dispositivi o due tratte lavorano con codec diversi, il sistema deve adattare il media. Qui entra in gioco un aspetto che merita di essere chiarito bene: il codec è il primo punto in cui il segnale analogico diventa segnale digitale utilizzabile in una chiamata IP, e non tutti i PBX trattano il flusso RTP nello stesso modo.

Dal punto di vista tecnico, nel terminale la voce viene acquisita dal microfono, campionata, quantizzata e trasformata in frame audio. Questo è il primo punto in cui si definiscono livello utile, rumore di fondo, risposta in frequenza percepita e dinamica del parlato. Per questo si può dire che il codec rappresenta il primo step della catena in cui viene fissato il modo in cui il livello audio verrà poi trasportato e percepito.

Se il PBX si limita a gestire la segnalazione SIP e lascia passare il media direttamente tra gli endpoint, il suo peso sul livello audio è minore. Se invece il PBX ancora il flusso RTP o lavora come media server, allora può intervenire direttamente sul media. In questo secondo scenario possono comparire conversioni di codec, cambio di packetization time, normalizzazioni non omogenee, gestione diversa dei frame audio e, soprattutto, transcodifica RTP.

La transcodifica RTP non significa solo passare, per esempio, da G.722 a G.711 o da un codec compresso a uno lineare. Significa anche ricostruire il flusso voce, decodificarlo e ricodificarlo in un altro formato o con altri vincoli. Ogni volta che questo accade, la voce può cambiare presenza, banda utile e percezione soggettiva del volume. L’utente spesso lo descrive come audio basso, anche se in realtà il livello non è semplicemente attenuato ma reso meno pieno, meno aperto o meno intellegibile.

Questo passaggio è importante perché molti descrivono come volume basso un fenomeno che in realtà è audio compresso, chiuso o povero di banda. Se un lato usa un codec wideband e l’altro scende a un codec narrowband, oppure se il PBX deve fare transcodifica tra due mondi diversi, il risultato percepito può essere una voce meno presente, più distante o meno corposa.

Per questo il brand del PBX diventa davvero rilevante solo quando quel sistema entra nel percorso media e svolge funzioni da media server. Se il PBX non tocca il flusso RTP, il marchio conta molto meno di topologia, endpoint e rete. Se invece il PBX transcodifica, allora la sua architettura audio, i codec supportati e il modo in cui gestisce il media diventano elementi centrali dell’analisi.

3. Profili non coerenti

Se i telefoni sono stati riutilizzati da un impianto precedente, una parte dell’eredità può essere rimasta nei profili. Un provisioning coerente non riguarda solo account SIP e BLF, ma anche codec abilitati, priorità, modalità cuffia, settaggi regionali, volume iniziale, firmware e parametri specifici del vendor.

In questi casi cambiare modello o produttore non sempre basta. Se un nuovo telefono IP viene inserito in una rete che mantiene lo stesso schema di provisioning, la stessa priorità codec o lo stesso percorso media, il sintomo può restare visibile anche con apparati diversi.

4. Firmware

I problemi audio non nascono solo da configurazioni errate. Possono dipendere anche dal firmware, soprattutto quando un terminale è stato tenuto a lungo in produzione e ha attraversato più cicli di aggiornamento, magari con reset incompleti o template ereditati.

Qui non serve partire con una teoria. Serve verificare tre cose: versione firmware, data del provisioning ricevuto dal centralino, e comportamento del problema su un terminale nuovo o ripristinato alle impostazioni di fabbrica e registrato da zero. Se il difetto scompare, il sospetto si sposta sul profilo o sul firmware. Se resta, conviene guardare media path e rete.

5. Jitter e perdita pacchetti

Molti utenti chiamano volume basso ciò che in realtà è voce scavata, intermittente o smorzata. Quando il jitter buffer è sotto stress o arrivano pacchetti RTP fuori ordine, il telefono può riprodurre una voce meno piena, con sillabe mangiate o con una sensazione di livello ridotto.

Questo spiega bene anche la componente casuale descritta spesso dagli utilizzatori. Un problema davvero casuale, che non segue sempre lo stesso telefono o lo stesso utente, spesso dipende da condizioni di rete variabili: congestione locale, switch non ottimali, coda QoS assente, uplink saturi, WiFi usato dove non dovrebbe, power saving sulle porte, cablaggi borderline, oppure SBC che lavorano correttamente ma sopra un trasporto non costante.

6. SBC e percorso media

Un audio basso percepito può essere collegato a una tratta RTP non stabile, a riscritture non coerenti dell’indirizzo media, a frammentazione o a buffering anomalo. In questi casi il SIP spesso appare perfetto, mentre il problema reale è solo nel media path.

7. Accessori

Quando si riutilizzano telefoni già precedentemente configurati o riadattati per un nuovo PBX, bisogna verificare anche ciò che sta intorno al telefono. Una cuffia non perfettamente compatibile, un adattatore EHS, una prolunga, una base DECT o un accessorio USB possono abbassare drasticamente il livello microfonico o quello della capsula ricevente. Questo controllo va eseguito anche se l’utilizzatore dichiara di usare sempre la cornetta. In molti ambienti il terminale resta impostato su un profilo headset o speakerphone senza che chi lo usa ne sia consapevole.

8. AGC e trattamento locale

Un altro punto poco intuitivo è che i meccanismi pensati per migliorare l’audio, come AGC, cancellazione dell’eco e soppressione del rumore, in alcuni scenari possono produrre l’effetto opposto. Se il microfono lavora in un ambiente rumoroso o con una cuffia non ideale, l’algoritmo può abbassare la voce utile insieme al rumore di fondo. Il risultato, per chi ascolta, è una voce distante e debole. Questo aspetto va verificato con la massima attenzione.

Questo aspetto, più di altri, spiega perché in certe segnalazioni il difettopotrebbe non essere sistematico e costante. Cambia la stanza, cambia la postura dell’utente, cambia il modo in cui il telefono aggancia il microfono o il vivavoce, e cambia anche il risultato percepito.

Transcodifica RTP

Dal punto di vista tecnico, la transcodifica RTP è il punto in cui una parte della catena audio torna a essere lavorata. Il flusso in ingresso viene decodificato, ricostruito in forma PCM o equivalente interna, e poi ricodificato nel codec richiesto dal lato opposto. In mezzo possono intervenire packetization time differente, gestione del jitter buffer, voice activity detection, packet loss concealment e altri meccanismi che non cambiano solo la compatibilità, ma anche la percezione finale della voce.

La transcodifica RTP merita un capitolo a parte perché spesso è sottovalutata. Non abbassa automaticamente il volume in senso stretto, ma può cambiare in modo evidente la percezione della voce.

Per leggere bene il problema conviene separare i tre step della catena. Il primo step è la codifica locale nel terminale, dove il segnale analogico viene trasformato in digitale. Il secondo step è il trasporto tra terminale, PBX, SBC e provider, dove il flusso RTP può restare intatto oppure essere trattato. Il terzo step è l’intercambio sulla rete pubblica, dove possono comparire ulteriori conversioni di codec o passaggi tra ambienti diversi. Un volume percepito come basso può nascere in uno solo di questi tre step, oppure dalla loro combinazione.

Quando un PBX o un media server transcodifica, il flusso voce viene decodificato dal codec di origine e ricodificato verso un altro codec. In questo passaggio possono cambiare banda utile, dinamica, presenza della voce, packetization time e resa complessiva. L’utente non descrive quasi mai questi aspetti in termini tecnici. Dice semplicemente che l’audio è basso, chiuso o poco chiaro.

Per questo la transcodifica RTP va verificata ogni volta che il PBX entra nel media path, soprattutto quando il problema compare solo in certe direttrici di chiamata o solo con certi interlocutori. In molti casi la differenza non è casuale. Cambia il codec, cambia il percorso RTP, cambia il punto in cui il media viene trattato, e cambia anche la percezione finale del volume.

Quando sembra casuale

Quando l’utilizzatore dice che non c’è una logica, spesso una logica esiste ma non è stata ancora isolata. Succede soprattutto in quattro casi: il difetto dipende dalla modalità di risposta, compare solo con certi codec, è legato alla fascia oraria di congestione, oppure è influenzato da una specifica combinazione tra telefono IP, switch, SBC e percorso di rete.

In questi casi il valore del troubleshooting sta proprio nella riduzione delle variabili. Quando il problema compare anche tra interni, oppure solo in alcune direttrici, bisogna costruire test controllati e ripetibili. Senza questo passaggio, il difetto resta percepito come random anche quando ha una causa tecnica precisa.

Un metodo pratico per procedere

Ecco come mi sento di consigliare di procedere in questi casi. Sono osservazioni che derivano dalla teoria ma, ancora più spesso dalla pratica. Vanno attuate in maniera sistematica

Identifica la direzione del difetto

Crea una tabella di test molto semplice: chiamata interna, chiamata esterna, stessa sede, sedi diverse, microtelefono, vivavoce, cuffia, telefono IP A, telefono IP B, softphone. Per ogni prova va annotato se il volume basso è in ricezione, in trasmissione o in entrambe le direzioni.

Telefono e softphone

Questo passaggio è decisivo. Se il problema si presenta solo sui telefoni fisici, il baricentro si sposta su terminali, provisioning, firmware, accessori e rete locale del desk phone. Se invece si presenta anche sul softphone, il sospetto sale verso PBX, codec, media path e rete generale.

Leggi l’SDP nel messaggio SIP

Nel tracciato SIP bisogna controllare i codec proposti e accettati, il payload type, il ptime, l’indirizzo IP e la porta RTP. Qui si capisce se la chiamata sta lavorando come atteso oppure no. In molti casi la risposta è già nell’INVITE e nel 200 OK, non nelle impressioni dell’utente.

Analizzare l’RTP

Con Wireshark o strumenti equivalenti bisogna osservare perdita pacchetti, jitter, sequenza RTP, eventuali burst di ritardo e andamento temporale. Se disponibile, conviene anche ascoltare il flusso RTP esportato. Una voce percepita come bassa può risultare in realtà impoverita o intermittente per problemi di trasporto. Ascolta sempre la traccia audio catturata con wireshark nella fase iniziale. Ti dice molto sul difetto: puoi valutare immediatamente il volume oggettivo della chiamata ed escludere almeno metà della catena audio.

Firmware e reset

Un test serio richiede almeno un telefono riportato a default, aggiornato, provisionato da zero e usato senza cuffie o accessori. È il modo più rapido per capire se si sta inseguendo un parametro ereditato da vecchie configurazioni.

Limitare i codec

In fase di prova può essere utile ridurre i codec consentiti e osservare se il problema cambia frequenza o scompare. Non è la cura definitiva, ma è un test diagnostico molto efficace. Se con una sola combinazione codec l’audio torna stabile e pieno, si è già individuata una pista concreta.

Controlli sul PBX

Quando si arriva al PBX, la domanda corretta non è solo quali codec siano abilitati, ma dove il centralino stia entrando davvero nel percorso audio. Un PBX che lavora solo sulla segnalazione SIP non definisce da solo il livello audio finale. Un PBX che ancora il media, fa bridging RTP o transcodifica diventa invece parte attiva della catena audio.

Sul PBX conviene verificare almeno questi punti: codec disponibili sui lati della chiamata, codec effettivamente negoziati dagli endpoint, eventuale ancoraggio del media, presenza di transcodifica RTP, topologia delle chiamate interne, provisioning dei terminali, versione firmware supportata ed eventuali differenze tra template o profili.

Va poi chiarito un aspetto decisivo: se il PBX entra nel percorso RTP e fa da media server, allora ogni scelta sui codec può avere un impatto diretto sulla resa audio. Se invece il PBX non interviene sul media, allora bisogna concentrare l’analisi soprattutto su endpoint, SBC e rete. In altre parole, il marchio del centralino conta davvero quando il centralino sta toccando il flusso voce e, in particolare, quando esegue transcodifica RTP.

Cosa appuntarsi

Quando il volume audio viene percepito come basso durante la chiamata, la cosa più utile non è partire da una teoria, ma da una sequenza ordinata di domande. Il difetto compare solo sulla rete pubblica o anche tra interni? È un problema di ricezione, di trasmissione o di entrambe le direzioni? Il media passa direttamente tra gli endpoint oppure attraversa PBX e SBC? C’è transcodifica RTP oppure no?

Ogni risposta restringe il campo e rende l’analisi più concreta. Solo a quel punto ha senso entrare nel merito di telefoni IP, codec, firmware, accessori, QoS, trunk o PBX. Senza questo ordine si rischia di cambiare parametri a caso e di perdere tempo su elementi che non stanno davvero influenzando il difetto.

Il brand del PBX va considerato quando quel sistema entra nel percorso media e diventa parte attiva della resa audio, soprattutto se svolge funzioni da media server ed esegue transcodifica RTP. In tutti gli altri casi conviene partire dai fatti osservabili, dal percorso RTP reale e da prove semplici ma ripetibili. È così che un audio percepito come basso smette di essere una sensazione generica e diventa un problema tecnico che si può misurare e risolvere.