Jitter é a variação em quando os pacotes de voz chegam. Uma ligação VoIP corta a sua voz em pacotes pequenos, envia um a cada 20 milissegundos e espera que eles apareçam no mesmo ritmo constante. Quando chegam atrasados, adiantados ou fora de ordem, essa irregularidade é o jitter, e quem está do outro lado a ouve como palavras picotadas, áudio robótico ou buracos.
Se você opera um agente de voz, o jitter importa em dobro. Ele degrada o áudio de quem liga na entrada, então o seu modelo de fala para texto recebe um sinal pior, e degrada o áudio do agente na saída, então quem liga conclui que o seu produto está quebrado. Quando um agente soa robótico no telefone mas bem no navegador, olhe a rede antes de mexer no modelo.
Este guia cobre o que é jitter, o que o causa, como medi-lo numa ligação real e como corrigi-lo, incluindo as partes do caminho que quem constrói agentes de voz realmente controla.
Jitter em resumo
| Métrica | Confortável | Perceptível | Inutilizável |
|---|---|---|---|
| Jitter | Abaixo de 30 ms | 30–50 ms | Acima de 50 ms |
| Perda de pacotes | Abaixo de 1% | 1–3% | Acima de 3% |
| Latência de ida | Abaixo de 150 ms | 150–400 ms | Acima de 400 ms |
São regras práticas, não garantias. Os números de latência de 150 ms e 400 ms vêm da Recomendação G.114 da ITU sobre atraso de ida aceitável, e o valor de 30 ms de jitter é a orientação que você encontra na documentação dos fornecedores, como a nota da Cisco sobre jitter. Um bom buffer de jitter adaptativo consegue mascarar mais de 30 ms de jitter, ao preço de atraso extra. A experiência de escuta combinada dessas métricas é o que um mean opinion score tenta comprimir num único número.
O que o jitter realmente é
Voz sobre IP viaja sobre RTP, o Real-time Transport Protocol. O remetente marca cada pacote com um número de sequência e um timestamp (RFC 3550), então o receptor sabe tanto a ordem em que os pacotes foram enviados quanto o instante exato em que cada fatia de 20 ms de áudio deve tocar.
O jitter é a diferença entre essa agenda e a realidade. Se o pacote 41 chega 20 ms depois do 40, mas o 42 chega 60 ms depois do 41, o fluxo tem jitter. A mesma RFC também define como as pontas o reportam: todo fluxo RTP vem acompanhado de mensagens de controle RTCP, e o receptor devolve periodicamente um receiver report cujos campos incluem o jitter de interchegada medido. É por isso que qualquer sistema telefônico sério consegue te dizer o seu jitter sem instrumentação extra: o protocolo vem marcando os pontos o tempo todo.
Vale separar dois vizinhos, porque eles se parecem e se consertam de jeitos diferentes:
- Latência. É o quanto os pacotes chegam atrasados no geral. Faz as pessoas falarem uma por cima da outra sem querer, mas não distorce o áudio em si.
- Perda de pacotes. São os pacotes que nunca chegam (ou chegam tarde demais para servir, o que o receptor conta como perdidos). A perda remove fatias de áudio; o jitter só as entrega de forma irregular. Uma rajada de pacotes fora de ordem parece perda para o receptor, porque o decodificador não pode ficar esperando os atrasados.
Como o jitter soa
Numa ligação com jitter crescente, todo mundo descreve a mesma progressão. As palavras começam a se cortar nas bordas. As vozes ficam metálicas ou robóticas quando o decodificador interpola sobre os quadros que faltam. Depois vêm os buracos: silêncios de meio segundo enquanto o receptor espera pacotes que aparecem num bloco um instante depois. No extremo, a ligação cai.
Cada um desses sintomas é o buffer de jitter fazendo o seu trabalho e ficando sem margem. O que levanta a pergunta óbvia.
O buffer de jitter e o seu preço
Um buffer de jitter é uma pequena fila no lado receptor. Em vez de tocar cada pacote assim que ele chega, o receptor segura os pacotes por um instante e os solta numa cadência uniforme, de modo que um pacote que chega 30 ms atrasado ainda pega o seu lugar. Os buffers típicos seguram de 30 a 50 ms de áudio; os adaptativos crescem e encolhem com as condições, às vezes até 100 ou 200 ms.
A troca é atraso por suavidade. Cada milissegundo de buffer é um milissegundo a mais na ida e volta, e passados uns 150 ms de atraso adicionado uma conversa começa a parecer um papo de walkie-talkie: cada um espera, fala e espera de novo. Um buffer pequeno demais descarta os pacotes atrasados e você ouve cortes. Um grande demais esconde o jitter e te entrega latência no lugar. Não existe ajuste que dê os dois, e é por isso que consertar a rede ganha de ajustar o buffer.
Onde o buffer mora depende da ligação:
- Ligações de navegador e de app (WebRTC) incluem por padrão um buffer de jitter adaptativo e ocultação de perdas, como explica o guia WebRTC vs WebSocket. Você raramente ajusta isso.
- Telefones SIP, PBXs e session border controllers têm buffers configuráveis, e o padrão nem sempre é o certo para a sua rede.
- Integrações RTP cruas fazem de você o autor do buffer. Se você puxa o áudio de um tronco SIP para o seu próprio stack, dimensionar esse buffer é o seu trabalho.
De onde vem o jitter
O jitter é quase sempre um problema de filas: pacotes esperando tempos diferentes em algum ponto do caminho.
- Congestionamento. Uma porta de roteador ou switch que enche e esvazia segura os pacotes por tempos imprevisíveis. É a causa clássica, e aparece nos horários de pico.
- Wi-Fi e celular. Enlaces sem fio agendam tempo de antena e retransmitem em silêncio, então os tempos de chegada variam muito mais do que no Ethernet. Quem liga do Wi-Fi de hotel não está imaginando coisas.
- Falta de QoS. Sem marcação de qualidade de serviço, os pacotes de voz ficam na fila atrás de downloads pesados. Marcar o tráfego de voz (normalmente DSCP EF) permite que os seus roteadores e os backbones de muitas operadoras o priorizem, embora a marcação muitas vezes não sobreviva à internet pública.
- Mudanças de rota. Quando o tráfego muda de caminho no meio da ligação, o novo caminho tem tempos diferentes, e o fluxo engasga até o buffer se adaptar.
- Buffers grandes demais. O bufferbloat é o primo discreto do jitter: uma fila enorme em algum lugar adiciona um atraso permanente que varia com a carga, e não aparece como perda de pacotes em lugar nenhum.
Como medir o jitter
Você não precisa de equipamento especial; a ligação já está se medindo sozinha.
- Leia os receiver reports RTCP. O campo de jitter é o número autoritativo do que a outra ponta viveu, expresso nas unidades de timestamp do fluxo: numa ligação G.711 você divide por 8 para obter milissegundos (a maioria dos painéis já faz a conversão). PBXs, SBCs e painéis de CPaaS o mostram por ligação.
- Capture o fluxo no Wireshark. Telephony → RTP → Stream Analysis reporta jitter e perda por direção e deixa você ouvir exatamente com o que o receptor teve que trabalhar.
- Para WebRTC, abra chrome://webrtc-internals durante a ligação e observe
jitter,packetsLostejitterBufferDelayao vivo. - Como sonda rápida, dê ping na outra ponta. Uma grande diferença entre os tempos médio e máximo de ida e volta sugere jitter no caminho. É uma estimativa, não a métrica, porque o jitter RTP é medido nas unidades de timestamp do próprio fluxo de áudio.
Meça durante ligações reais no seu horário mais cheio. Medir num domingo tranquilo um problema de terça congestionada vai te dizer que está tudo bem.
Como corrigir
Trabalhe do trecho que você controla para fora:
- Priorize a voz na sua própria rede. Marque o RTP com DSCP EF e garanta que os seus roteadores a respeitem. Passe o tráfego de ligações para conexões cabeadas antes de mexer em qualquer outra coisa.
- Dimensione o buffer de jitter de propósito. Comece perto de 30–50 ms nos dispositivos que permitem, e prefira buffers adaptativos quando existirem.
- Escolha codecs que tolerem perda. Nos trechos em que você escolhe o codec, o Opus carrega correção de erros embutida (RFC 6716). Na rede telefônica pública você terá G.711, que não tem essa proteção e depende inteiramente do buffer.
- Encurte o caminho. Escolha fornecedores com pontos de presença perto de quem liga. Cada segmento de rede a mais é outra fila que pode encher.
- Aceite a última milha. Você não vai consertar o Wi-Fi do café de quem liga. O que dá para fazer é medi-lo, para parar de depurar o seu próprio stack por causa do roteador dos outros.
Jitter e agentes de voz
A ligação de um agente tem mais elos do que uma ligação entre pessoas: o telefone de quem liga, a operadora, o seu provedor de telefonia ou tronco SIP, depois o seu stack de agente, e a volta. O jitter pode entrar em qualquer salto, e se soma à latência do modelo na experiência de quem liga. Ninguém ouve “a rede adicionou 120 ms de buffer e depois o modelo levou 90 ms”. Ouvi-se um único agente lento e picotado.
Dois hábitos mantêm a rede honesta:
- Meça por trecho. Leia as estatísticas RTCP do seu provedor de telefonia e cronometre separadamente os saltos de fala para texto e de texto para fala. A Cartesia publica latência de modelo abaixo de 90 ms para o Sonic; isso é o modelo, e o trecho de rede adiciona o próprio atraso por cima, exatamente o atraso que a medição de P95 e P99 existe para pegar. Se o modelo é rápido e a ligação continua lenta ou distorcida, você está olhando para jitter.
- Teste pelo caminho telefônico real. O áudio de telefone corre a 8 kHz sobre G.711 μ-law ou A-law, através do buffer de jitter de outra pessoa. Um agente que soa limpo no seu laptop pode soar quebrado numa rota de operadora congestionada, então faça ligações de teste de números reais, nos horários de pico, antes de culpar o modelo de voz.
Do lado da Cartesia, o Sonic devolve μ-law ou A-law crus a 8 kHz diretamente ("encoding": "pcm_mulaw", "sample_rate": 8000), então o áudio de telefonia não passa por uma conversão extra, e o Ink aceita os mesmos formatos para reconhecimento de fala em streaming. O Managed Agents atende ligações em números Cartesia, Twilio ou o seu próprio tronco SIP e opera o trecho telefônico por você. As ligações do agente custam US$ 0,03 por minuto, e o adicional de telefonia de US$ 0,014 por minuto se aplica apenas a números provisionados pela Cartesia. As regiões de implantação — EUA, UE, Reino Unido, Índia e Austrália — mantêm o caminho de rede curto. Os troncos SIP conectam por TLS com mídia SRTP, e o guia de SIP trunking cobre a configuração.
E se o seu jitter estiver ótimo e o agente ainda soar robótico, aí sim, você tem a nossa permissão para culpar o modelo.