Monitoramento de PABX Asterisk: MOS, jitter e por que suas ligações ficam ruins

A cena se repete em toda operação com telefonia IP. Alguém reclama que a ligação está picotando. O responsável reinicia o PABX, a reclamação some por uns dias e depois volta. Ninguém mediu nada. Picotar não é diagnóstico, é sintoma. Este artigo é sobre transformar reclamação em dado.

Por que o CDR não conta a história toda

A primeira reação de quem administra Asterisk é olhar o CDR, o registro de chamadas. O problema: o CDR diz que a chamada aconteceu, quanto durou e para onde foi. Ele não diz se a chamada foi boa.

Uma ligação de 14 minutos com voz robotizada, em que o cliente pede para repetir a cada frase, aparece no CDR igual a uma ligação perfeita: ANSWERED, 840s.

Qualidade de voz mora em outra camada: no fluxo RTP e nos relatórios RTCP que os dois lados trocam durante a chamada. É lá que estão as quatro métricas que importam.

As quatro métricas e o que cada uma faz com a conversa

1. Latência (RTT)

O tempo que o áudio leva para ir e voltar. A recomendação clássica da ITU-T (G.114) é manter o atraso de um sentido em até 150 ms. Acima disso, a conversa começa a atropelar: as duas pessoas falam juntas, param juntas e pedem desculpa juntas. Com RTT acima de uns 300 ms, a ligação vira walkie-talkie.

2. Jitter

A variação da latência. Os pacotes de voz saem em intervalos regulares, tipicamente a cada 20 ms, mas a rede não garante a chegada nesse ritmo. O receptor usa um jitter buffer para reordenar e regularizar. Só que buffer adiciona atraso, e o que chega tarde demais é descartado.

Jitter sustentado acima de 30 ms é sinal amarelo. O sintoma típico é voz metálica, com falhas curtas e regulares.

3. Perda de pacotes

Voz é UDP. Pacote perdido não é retransmitido: é interpolado ou vira silêncio. Com G.711, perdas a partir de 1% já são audíveis. Acima de 3%, a ligação fica inaceitável para uso profissional.

Um detalhe que engana muita gente: perda em rajada soa muito pior que perda espalhada, mesmo com o mesmo percentual. Olhar só a média esconde o problema.

4. MOS

O Mean Opinion Score resume tudo numa nota de 1 a 5, calculada a partir das métricas acima pelo E-model da ITU-T G.107. Referência prática de operação:

Onde medir isso no Asterisk

Com chan_pjsip, o Asterisk expõe as estatísticas RTCP por canal. O ponto de partida no CLI:

asterisk*CLI> pjsip show channelstats

; ...Receive...             ...Transmit...
; BridgeId Channel  Uptime  Cnt Lost Pct Jitter  Cnt Lost Pct Jitter RTT
; e654e412 PJSIP/50800  84  4200   2  0.0  0.004  4180  0   0.0 0.003 0.021

Ali estão perda, jitter e RTT por perna de chamada, ao vivo. Para guardar histórico, os caminhos usuais são capturar os eventos via AMI ou ARI, gravar as estatísticas no fim de cada chamada, ou exportar para uma stack HEP como o Homer quando o volume justifica.

O essencial é medir por chamada, continuamente. Abrir o CLI só quando alguém reclama não funciona. O problema intermitente nunca está lá na hora em que você olha.

Onde os problemas nascem de verdade

Depois de anos operando PABX em produção, a distribuição de causas que encontramos é mais ou menos esta, em ordem decrescente:

1. Rede local sem QoS. A voz disputa fila com backup, atualização do Windows e vídeo. Sem VLAN de voz e marcação DSCP de ponta a ponta, a qualidade da ligação depende do que mais passa no fio naquele segundo. É a causa número 1. E é a que menos aparece, porque é intermitente por natureza.
2. Ramal em Wi-Fi. Softphone em notebook no Wi-Fi compartilhado é pedido de jitter. Wi-Fi tem retransmissão e disputa de meio por design. Funciona até não funcionar, geralmente na ligação importante.
3. Link saturado no horário de pico. Em teoria, um upload de 20 Mbps segura 40 ligações G.711 com folga. Na prática, o backup em nuvem das 14h ocupa tudo. E o bufferbloat do roteador transforma saturação em segundos de latência.
4. NAT e ALG do roteador da operadora. O SIP ALG que vem ligado de fábrica reescreve pacotes e quebra o áudio de formas criativas: chamada muda, áudio só de um lado, ramal que toca e não atende. Primeira providência em qualquer instalação: desligar o ALG.
5. Transcodificação desnecessária. Cada conversão de codec gasta CPU e degrada o áudio. Alinhar os codecs de ponta a ponta elimina uma classe inteira de problema, em silêncio.
6. A operadora. Existe e acontece, mas é minoria. E é sempre a primeira acusada, porque é a única parte que você não enxerga. Com métrica por chamada, a conversa com o suporte muda de figura: "perda de 4% no tronco X entre 14h10 e 14h40, segue o gráfico". Uma conversa dessas paga o monitoramento inteiro.

O dicionário sintoma → métrica

O atalho de diagnóstico que usamos na operação. O que o usuário descreve aponta para onde olhar primeiro:

O que quase ninguém monitora: segurança do PABX

Um Asterisk com a porta SIP exposta na internet começa a receber tentativas de registro em minutos. Qualquer honeypot SIP demonstra isso. O objetivo do atacante quase nunca é derrubar o PABX. É registrar um ramal e originar tráfego internacional às suas custas.

Fraude de tarifação é prejuízo direto, em dinheiro. E costuma ser descoberta na fatura.

Por isso, monitoramento de PABX que só olha qualidade está incompleto. O mínimo: taxa de falhas de autenticação SIP, registros de origem inesperada, chamadas internacionais fora do padrão da empresa e fail2ban com log acompanhado, não só instalado.

A lista mínima de monitoramento contínuo

• Por chamada: MOS, jitter, RTT e perda, com histórico, não só ao vivo
• Por endpoint: estado de registro dos ramais PJSIP, quantos online agora contra o esperado
• Por tronco: disponibilidade, taxa de completamento e qualidade média
• Capacidade: chamadas simultâneas contra licenciamento e banda
• Segurança: falhas de REGISTER, destinos anômalos, origem dos registros
• Tendência: MOS médio por dia e por semana. Degradação lenta é invisível no dia a dia e óbvia no gráfico

Por que construímos o 9level-monitor

Nada do que está acima é segredo. Está espalhado em documentação, listas de discussão e experiência acumulada. Nosso problema era prático: ver tudo isso num painel só, em tempo real, para um parque com mais de 1.500 endpoints. E sem montar uma stack de observabilidade inteira só para telefonia.

Não achamos ferramenta que resolvesse do nosso jeito. Então escrevemos o 9level-monitor: binário Go, painel Vue, Docker, licença MIT. MOS, jitter e RTT por chamada, estado dos endpoints PJSIP, alertas de segurança e tendência histórica. git clone, docker compose up -d, painel na porta 8100.

Se você opera Asterisk, use de graça. Se quiser ajuda para implantar ou sustentar, é o que fazemos.