Che jitter è accettabile in VoIP?

Una regola comune: jitter sotto i 30 ms, con meno dell'1% di perdita di pacchetti e meno di 150 ms di latenza di sola andata. Tra 30 e 50 ms la maggior parte degli ascoltatori inizia a notare vuoti o audio robotico, e oltre quella soglia nemmeno un jitter buffer ben dimensionato riesce a nascondere il problema.

Che differenza c'è tra jitter e latenza?

La latenza è quanto i pacchetti arrivano in ritardo; il jitter è quanto arrivano in modo irregolare. Una chiamata può avere bassa latenza e jitter pessimo allo stesso tempo. La latenza fa parlare le persone una sopra l'altra, il jitter rende le voci spezzate o robotiche, e la perdita di pacchetti toglie audio del tutto.

Cosa fa un jitter buffer?

Un jitter buffer è una piccola coda sul lato ricevente che trattiene i pacchetti vocali in arrivo e li rilascia a ritmo regolare, così i pacchetti in ritardo fanno ancora in tempo a essere riprodotti. Scambia ritardo con fluidità: troppo piccolo e i pacchetti in ritardo vengono scartati, troppo grande e il ritardo aggiunto trasforma la chiamata in una conversazione da walkie-talkie.

Come controllo il jitter di una chiamata?

Leggi il campo jitter dei receiver report RTCP che gli estremi della chiamata si scambiano, oppure passa la chiamata nell'analisi dei flussi RTP di Wireshark. In un browser, chrome://webrtc-internals mostra il jitter in diretta delle chiamate WebRTC. Anche un ping veloce aiuta: una grande differenza tra il tempo medio e quello massimo di andata e ritorno suggerisce jitter.

Il jitter può far suonare robotico un agente vocale?

Sì. Se un agente vocale IA suona metallico o spezzato al telefono ma bene nel browser, la rete telefonica è la prima sospettata. Controlla jitter e perdita di pacchetti della chiamata prima di cambiare modello o prompt, perché nessun modello vocale può riparare un audio che la rete ha già perso.

Cos'è il jitter in VoIP? Come misurarlo e correggerlo

Q: Cos'è il jitter in VoIP?

Il jitter è la variazione del tempo di arrivo tra i pacchetti che trasportano una chiamata vocale. La voce viaggia come un flusso costante di piccoli pacchetti, di solito uno ogni 20 millisecondi, e il jitter misura quanto irregolarmente arrivano. Si esprime in millisecondi, e i ricevitori lo assorbono con un jitter buffer.

Il jitter è la variazione nel momento in cui arrivano i pacchetti vocali. Una chiamata VoIP taglia la tua voce in piccoli pacchetti, ne invia uno ogni 20 millisecondi e si aspetta che arrivino sullo stesso ritmo costante. Quando arrivano in ritardo, in anticipo o in disordine, quell’irregolarità è il jitter, e chi è dall’altra parte la sente come parole spezzate, audio robotico o vuoti.

Se gestisci un agente vocale, il jitter conta due volte. Degrada l’audio di chi chiama in ingresso, quindi il tuo modello di riconoscimento vocale riceve un segnale peggiore, e degrada l’audio dell’agente in uscita, quindi chi chiama conclude che il tuo prodotto è rotto. Quando un agente suona robotico al telefono ma bene nel browser, controlla la rete prima di toccare il modello.

Questa guida copre cos’è il jitter, cosa lo causa, come misurarlo in una chiamata reale e come correggerlo, comprese le parti del percorso che chi costruisce agenti vocali controlla davvero.

Il jitter in sintesi

Metrica	Confortevole	Percettibile	Inutilizzabile
Jitter	Sotto 30 ms	30–50 ms	Oltre 50 ms
Perdita di pacchetti	Sotto l’1%	1–3%	Oltre il 3%
Latenza di sola andata	Sotto 150 ms	150–400 ms	Oltre 400 ms

Sono regole pratiche, non garanzie. Le cifre di latenza di 150 ms e 400 ms vengono dalla Raccomandazione G.114 dell’ITU sul ritardo di sola andata accettabile, e la soglia dei 30 ms di jitter è l’indicazione che trovi nella documentazione dei vendor, come la nota di Cisco sul jitter. Un buon jitter buffer adattivo può mascherare più di 30 ms di jitter, al prezzo di un ritardo aggiunto. L’esperienza d’ascolto complessiva di queste metriche è ciò che un mean opinion score prova a comprimere in un solo numero.

Cos’è davvero il jitter

La voce su IP viaggia su RTP, il Real-time Transport Protocol. Il mittente marca ogni pacchetto con un numero di sequenza e un timestamp (RFC 3550), quindi il ricevitore conosce sia l’ordine in cui i pacchetti sono stati inviati sia l’istante esatto in cui ogni porzione da 20 ms di audio deve suonare.

Il jitter è lo scarto tra quel programma e la realtà. Se il pacchetto 41 arriva 20 ms dopo il 40, ma il 42 arriva 60 ms dopo il 41, il flusso ha jitter. La stessa RFC definisce anche come gli estremi lo riportano: ogni flusso RTP è accompagnato da messaggi di controllo RTCP, e il ricevitore rimanda periodicamente un receiver report i cui campi includono il jitter di interarrivo misurato. Ecco perché ogni sistema telefonico serio sa dirti il suo jitter senza strumentazione extra: il protocollo tiene il punteggio fin dall’inizio.

Vale la pena distinguere due vicini, perché si somigliano e si risolvono in modo diverso:

Latenza. È quanto i pacchetti arrivano in ritardo nel complesso. Fa sì che le persone si parlino addosso senza volerlo, ma non distorce l’audio in sé.
Perdita di pacchetti. Sono i pacchetti che non arrivano mai (o arrivano troppo tardi per essere usati, cosa che il ricevitore conta come persi). La perdita rimuove porzioni di audio; il jitter le consegna solo in modo irregolare. Una raffica di pacchetti fuori ordine sembra perdita per il ricevitore, perché il decodificatore non può aspettare i ritardatari.

Come si sente il jitter

In una chiamata con jitter crescente, tutti descrivono la stessa progressione. Le parole iniziano a tagliarsi ai bordi. Le voci diventano metalliche o robotiche quando il decodificatore interpola sui frame mancanti. Poi arrivano i vuoti: silenzi di mezzo secondo mentre il ricevitore aspetta pacchetti che spuntano in gruppo un istante dopo. All’estremo, la chiamata cade.

Ognuno di questi sintomi è il jitter buffer che fa il suo lavoro e finisce il margine. Il che solleva la domanda ovvia.

Il jitter buffer e il suo prezzo

Un jitter buffer è una piccola coda sul lato ricevente. Invece di riprodurre ogni pacchetto appena arriva, il ricevitore trattiene i pacchetti per un istante e li rilascia a cadenza regolare, così un pacchetto che arriva con 30 ms di ritardo raggiunge ancora il suo slot. I buffer tipici trattengono da 30 a 50 ms di audio; quelli adattivi crescono e si restringono con le condizioni, a volte fino a 100 o 200 ms.

Lo scambio è ritardo in cambio di fluidità. Ogni millisecondo di buffer è un millisecondo aggiunto all’andata e ritorno, e oltre circa 150 ms di ritardo aggiunto una conversazione inizia a sembrare uno scambio via walkie-talkie: ognuno aspetta, parla, poi aspetta di nuovo. Un buffer troppo piccolo scarta i pacchetti in ritardo e senti dei tagli. Uno troppo grande nasconde il jitter e ti lascia invece la latenza. Non esiste un’impostazione che dia entrambe le cose, ed è per questo che sistemare la rete batte la regolazione del buffer.

Dove vive il buffer dipende dalla chiamata:

Le chiamate da browser e app (WebRTC) includono di default un jitter buffer adattivo e il mascheramento delle perdite, come spiega la guida WebRTC vs WebSocket. Raramente lo regoli tu.
Telefoni SIP, PBX e session border controller hanno buffer configurabili, e il valore predefinito non è sempre quello giusto per la tua rete.
Le integrazioni RTP grezze ti rendono l’autore del buffer. Se porti l’audio da un trunk SIP nel tuo stack, dimensionare quel buffer è compito tuo.

Da dove viene il jitter

Il jitter è quasi sempre un problema di code: pacchetti che aspettano tempi diversi da qualche parte lungo il percorso.

Congestione. Una porta di router o switch che si riempie e si svuota trattiene i pacchetti per tempi imprevedibili. È la causa classica, e compare nelle ore di punta.
Wi-Fi e rete cellulare. I collegamenti wireless schedulano il tempo di antenna e ritrasmettono in silenzio, quindi i tempi di arrivo variano molto più che su Ethernet. Chi chiama dal Wi-Fi di un hotel non se lo sta immaginando.
Mancanza di QoS. Senza marcatura di qualità del servizio, i pacchetti vocali fanno la coda dietro i download di massa. Marcare il traffico vocale (tipicamente DSCP EF) permette ai tuoi router e alle backbone di molti operatori di dargli priorità, anche se la marcatura spesso non sopravvive alla rete internet pubblica.
Cambi di rotta. Quando il traffico passa a un altro percorso a metà chiamata, il nuovo percorso ha tempi diversi, e il flusso balbetta finché il buffer non si adatta.
Buffer sovradimensionati. Il bufferbloat è il cugino discreto del jitter: una coda enorme da qualche parte aggiunge un ritardo permanente che varia con il carico, e non risulta come perdita di pacchetti da nessuna parte.

Come misurare il jitter

Non serve attrezzatura speciale; la chiamata si sta già misurando da sola.

Leggi i receiver report RTCP. Il campo jitter è il numero autorevole di ciò che ha vissuto l’altro estremo, espresso nelle unità di timestamp del flusso: su una chiamata G.711 dividi per 8 per ottenere i millisecondi (la maggior parte delle dashboard fa la conversione per te). PBX, SBC e dashboard CPaaS lo mostrano per chiamata.
Cattura il flusso in Wireshark. Telephony → RTP → Stream Analysis riporta jitter e perdite per direzione e ti fa ascoltare esattamente con cosa ha dovuto lavorare il ricevitore.
Per WebRTC, apri chrome://webrtc-internals durante la chiamata e osserva jitter, packetsLost e jitterBufferDelay in diretta.
Come sonda rapida, fai ping all’altro estremo. Una grande differenza tra i tempi medi e massimi di andata e ritorno suggerisce jitter sul percorso. È una stima, non la metrica, perché il jitter RTP si misura nelle unità di timestamp del flusso audio stesso.

Misura durante chiamate reali nella tua ora più trafficata. Misurare di domenica tranquilla un problema da martedì congestionato ti dirà che va tutto bene.

Come correggerlo

Lavora dal segmento che controlli verso l’esterno:

Dai priorità alla voce sulla tua rete. Marca l’RTP con DSCP EF e assicurati che i tuoi router la rispettino. Sposta il traffico delle chiamate su connessioni cablate prima di toccare qualsiasi altra cosa.
Dimensiona il jitter buffer di proposito. Parti intorno ai 30–50 ms sui dispositivi che lo permettono, e preferisci i buffer adattivi quando ci sono.
Scegli codec che tollerano la perdita. Sui tratti in cui scegli il codec, Opus porta la correzione d’errore in banda (RFC 6716). Sulla rete telefonica pubblica avrai G.711, che non ha questa protezione e si affida interamente al buffer.
Accorcia il percorso. Scegli fornitori con punti di presenza vicino a chi chiama. Ogni segmento di rete in più è un’altra coda che può riempirsi.
Accetta l’ultimo miglio. Non puoi sistemare il Wi-Fi del bar da cui chiama il cliente. Quello che puoi fare è misurarlo, così smetti di debuggare il tuo stack per colpa del suo router.

Il jitter e gli agenti vocali

La chiamata di un agente ha più anelli di una chiamata tra persone: il telefono di chi chiama, il suo operatore, il tuo provider di telefonia o trunk SIP, poi il tuo stack, e ritorno. Il jitter può entrare a ogni salto, e si somma alla latenza del modello nell’esperienza di chi chiama. Nessuno sente “la rete ha aggiunto 120 ms di buffer e poi il modello ha impiegato 90 ms”. Sente un unico agente lento e spezzato.

Due abitudini tengono onesta la rete:

Misura per tratto. Leggi le statistiche RTCP del tuo provider di telefonia e cronometra separatamente i salti di riconoscimento e di sintesi vocale. Cartesia pubblica una latenza di modello sotto i 90 ms per Sonic; quello è il modello, e il tratto di rete aggiunge il proprio ritardo sopra, esattamente il ritardo che la misurazione P95 e P99 esiste per catturare. Se il modello è veloce e la chiamata resta lenta o distorta, stai guardando del jitter.
Testa attraverso il percorso telefonico reale. L’audio telefonico viaggia a 8 kHz su G.711 μ-law o A-law, attraverso il jitter buffer di qualcun altro. Un agente che suona pulito sul tuo portatile può suonare rotto su una rotta d’operatore congestionata, quindi fai chiamate di prova da numeri veri, nelle ore di punta, prima di incolpare il modello vocale.

Dal lato di Cartesia, Sonic restituisce direttamente μ-law o A-law grezzi a 8 kHz ("encoding": "pcm_mulaw", "sample_rate": 8000), quindi l’audio telefonico non fa un passaggio di conversione in più, e Ink accetta gli stessi formati per il riconoscimento vocale in streaming. Managed Agents risponde alle chiamate su numeri Cartesia, Twilio o il tuo trunk SIP e gestisce il tratto telefonico per te. Le chiamate dell’agente costano 0,03 $ al minuto, e il supplemento di telefonia da 0,014 $ al minuto si applica solo ai numeri forniti da Cartesia. Le regioni di deployment — Stati Uniti, UE, Regno Unito, India e Australia — tengono corto il percorso di rete. I trunk SIP si collegano su TLS con media SRTP, e la guida ai trunk SIP copre la configurazione.

E se il tuo jitter risulta a posto e l’agente suona comunque robotico, allora sì, hai il nostro permesso di incolpare il modello.