VoIP na infraestrutura: codecs, QoS e o que derruba o MOS

Voz é a aplicação mais sensível que roda na sua rede: 100 kbps que precisam chegar agora, em ordem, sem exceção — enquanto backups, vídeos e atualizações disputam o mesmo cano. Fazer VoIP funcionar bem em infraestrutura corporativa é um problema de engenharia com três alavancas: o codec que comprime, o QoS que prioriza e o diagnóstico que mede. Este guia cobre as três.

Codecs: G.711, G.729 e Opus na prática

A regra de decisão é menos glamourosa do que parece: use G.711 até ter um motivo medido para não usar. Ele não paga royalties, não gasta CPU com transcodificação e entrega a qualidade de referência. O G.729 sobrevive em nichos de banda estreita; o Opus brilha em softphone e WebRTC, mas o elo com a rede pública ainda converge para G.711 — e cada transcodificação no caminho rouba MOS e adiciona latência.

Codec é negociado por chamada, no SDP — quem manda na negociação é a ordem da sua lista de codecs no PABX, como vimos no guia técnico do protocolo SIP. Lista curta e coerente entre PABX e provedor evita o 488 e a transcodificação silenciosa.

Dimensionando a banda

A conta é direta: banda = chamadas simultâneas de pico × consumo do codec × 2 direções + 20% de folga. Vinte chamadas G.711 = ~3,5 Mbps agregados — irrelevante em fibra, fatal em ADSL de 5 Mbps de upload. O número de canais do tronco deve seguir o mesmo pico, e o cálculo formal de quantos canais sua operação precisa (Erlang B, taxa de bloqueio) está no artigo de dimensionamento de canais.

Atenção ao detalhe que derruba operações: o gargalo de voz corporativa quase nunca é o download — é o upload, menor e disputado por backup e sincronização de nuvem. Dimensione (e priorize) olhando para ele.

QoS que funciona (e o que só finge)

QoS de verdade tem três componentes, e a maioria das redes implementa só o primeiro:

1. Marcação — PABX e telefones marcam RTP com DSCP EF (46) e sinalização com CS3. Qualquer equipamento decente faz;
2. Filas na LAN — switches honram a marcação com fila prioritária. Importa em rede congestionada internamente;
3. Fila na borda — o roteador de saída prioriza EF no upload. É aqui que o QoS decide o jogo, porque é aqui que o congestionamento real acontece — e é exatamente o componente que roteador de operadora não entrega configurado.

O teste de honestidade do seu QoS: sature o upload com um backup e faça uma chamada. Áudio limpo = QoS real. Áudio picotado = você tem marcação decorativa. E lembre: QoS governa a sua rede; do seu roteador para fora, quem manda é a rota do provedor — por isso trunk sério publica SLA e a saúde da plataforma, o mesmo princípio de operação em nuvem que a Nvoip descreve nas vantagens da telefonia em nuvem.

MOS: medindo o que o usuário sente

MOS (Mean Opinion Score) traduz a qualidade percebida em nota de 1 a 5. Acima de 4,0, ninguém reclama; abaixo de 3,5, o telefone da TI toca. O MOS estimado é calculado a partir de três métricas de rede que você já conhece: latência, jitter e perda de pacotes — as mesmas que o RTCP reporta por chamada e que PABXs modernos gravam por CDR.

Valores de referência para voz saudável: latência < 150 ms (ida), jitter < 30 ms, perda < 1%. A degradação não é linear: 0,5% de perda passa despercebida; 3% transforma G.729 em sopa. Monitore o MOS por rota e por horário — média diária esconde o pico das 14h que está matando as vendas.

Roteiro de diagnóstico de qualidade

1. Reproduza e capture: chamada de teste com sngrep/tcpdump rodando nas duas pontas que você controla;
2. Olhe o RTP, não o SIP: qualidade é problema de mídia — conte perda e jitter no fluxo RTP capturado;
3. Isole o segmento: teste do próprio servidor do PABX (elimina LAN), depois de um host na LAN (inclui switch), depois do Wi-Fi (inclui o pior caso);
4. Confira o óbvio escondido: SIP ALG ligado no roteador corrompe mais chamadas que qualquer congestão — o guia de NAT e SIP ALG lista os sintomas;
5. Só então, o provedor: com trace e métricas em mãos, o ticket resolve em horas em vez de semanas de "reiniciou o roteador?".