MOS e R-factor: come si misura la qualita' audio VoIP

"Si sente male" e' la segnalazione piu' frequente e piu' inutile che arriva su un centralino. Per trasformarla in un dato servono due metriche: MOS e R-factor. Entrambe sintetizzano in un numero la qualita' percepita di una conversazione, e quasi tutti i PBX e i probe le calcolano gia'.

MOS: il punteggio percepito

Il MOS (Mean Opinion Score) nasce come media dei voti dati da ascoltatori reali su una scala da 1 a 5. Nei sistemi moderni non lo vota nessuno: viene stimato a partire dai parametri di rete tramite un modello, in genere l'E-model, e prende il nome di MOS stimato o MOS-CQE.

Riferimenti pratici:

• 4,3 - 4,5: qualita' massima ottenibile con G.711. Nessun utente si lamenta.
• 4,0 - 4,3: buona. Qualche degrado percepibile solo su linee molto silenziose.
• 3,6 - 4,0: accettabile. Iniziano le richieste di ripetere le parole.
• 3,1 - 3,6: fastidiosa. Segnalazioni sicure.
• Sotto 3,1: inutilizzabile per uso business.

Il tetto dipende dal codec: G.711 puo' arrivare a 4,4 circa, G.729 parte gia' da un massimo teorico intorno a 4,0 per via della compressione, Opus a banda larga puo' superare il MOS di G.711 sulla stessa rete. Confrontare il MOS di due chiamate con codec diversi non ha senso se non si tiene conto di questo.

R-factor: il numero da cui deriva

L'R-factor e' l'output dell'E-model, su scala da 0 a 100, e il MOS stimato ne e' una conversione diretta. Si costruisce partendo da un valore ideale e sottraendo le penalita':

• Il degrado di base della codifica, cioe' quanto perde il codec anche in condizioni perfette.
• Il degrado da ritardo, che diventa significativo quando la latenza one-way supera i 150 ms e cresce rapidamente oltre i 200 ms.
• Il degrado da perdita di pacchetti, pesantissimo: con G.729 anche l'1% di loss taglia il punteggio in modo visibile.

Soglie di riferimento: sopra 80 la chiamata e' buona, tra 70 e 80 e' accettabile, sotto 70 gli utenti si lamentano, sotto 50 la conversazione non e' praticabile. Il vantaggio dell'R-factor e' che le penalita' sono separabili: guardando quale componente pesa di piu' capisci se il problema e' ritardo, perdita o codec.

I tre parametri che contano

Ogni degrado nasce sempre da questi tre valori, raccolti dai report RTCP e visibili nei CDR del centralino:

• Latenza one-way: obiettivo sotto 100 ms, limite pratico 150 ms. Su fibra nazionale sono valori facili; sono a rischio i collegamenti satellitari, i tunnel VPN con hop lunghi e le chiamate instradate verso provider esteri.
• Jitter: la variazione del ritardo tra pacchetti consecutivi. Obiettivo sotto 20 ms. Il jitter buffer del terminale assorbe la variabilita', ma per farlo aggiunge ritardo: un buffer adattivo che si allarga per compensare peggiora la latenza complessiva.
• Packet loss: obiettivo sotto lo 0,5%, tollerabile fino all'1% con G.711 e PLC attivo. La perdita a raffica, cioe' concentrata in burst, e' molto piu' dannosa della stessa percentuale distribuita in modo uniforme, perche' il PLC ricostruisce bene un pacchetto isolato ma non quattro consecutivi.

Come si legge un caso reale

Quando un cliente segnala audio scadente, la sequenza utile e' questa:

1. Estrai MOS, jitter e loss dai CDR delle chiamate segnalate, non da un test fatto dopo. Il dato deve riferirsi al momento del problema.
2. Verifica se il degrado e' su una direzione sola. Loss solo in ricezione indica un problema a monte o sul collegamento in downstream; solo in trasmissione indica saturazione dell'upload del cliente, il caso piu' comune negli uffici con backup cloud attivi in orario di lavoro.
3. Correla con la fascia oraria. Degrado ripetibile tra le 9 e le 11 significa quasi sempre congestione locale, non problema del trunk.
4. Controlla se le chiamate degradate condividono lo stesso terminale, la stessa VLAN o lo stesso codec: se si', il campo di indagine si chiude subito.

Interventi che spostano davvero il punteggio

• QoS in uscita sul router con priorita' assoluta al traffico RTP e limite di banda impostato leggermente sotto la capacita' reale del collegamento: e' l'intervento che risolve la maggior parte dei casi legati alla saturazione upload.
• Codec fissato a G.711 quando la banda lo consente, invece di lasciare la negoziazione libera che puo' scendere a G.729 senza motivo.
• Jitter buffer adattivo entro limiti ragionevoli, per evitare che compensi il jitter aggiungendo ritardo fino a superare la soglia dei 150 ms.
• Rete voce separata in VLAN dedicata, per togliere alla voce la concorrenza del traffico dati sullo stesso dominio di broadcast.
• Percorso di rete accorciato: SIP trunk sullo stesso provider della connettivita' elimina peering intermedi e rende il ritardo prevedibile.

Un MOS misurato costantemente sopra 4,2 su tutte le chiamate e' il modo piu' semplice per dimostrare che il problema, quando c'e', non e' nel trunk.