Perda de pacotes VoIP: como afeta a qualidade das chamadas e como o SBC a mitiga

Quando uma chamada apresenta cortes, perde sílabas ou fica entrecortada no meio de uma frase, a causa quase sempre é perda de pacotes. Não é um codec ruim, nem sinal fraco, nem o telefone da outra pessoa. Em algum ponto entre os dois terminais, partes do áudio saíram de um lado e nunca chegaram ao outro.

Neste artigo, vamos explicar o que é a perda de pacotes VoIP, por que a voz sofre com ela muito mais do que dados comuns, como ela é medida, os limites em que as chamadas começam a se degradar e onde um Controlador de Borda de Sessão (SBC) se encaixa na detecção e contenção do problema. Se você opera infraestrutura de voz e recebe chamados do tipo “a ligação estava péssima”, esta é a camada onde esses chamados se resolvem.

O que é perda de pacotes

Perda de pacotes é a falha de um ou mais pacotes de dados em alcançar seu destino em uma rede IP. É medida como porcentagem dos pacotes enviados: se 1.000 pacotes saem e 980 chegam, isso é 2% de perda de pacotes. Na prática, “perdido” abrange três casos. Um pacote pode simplesmente nunca chegar, pode chegar tão atrasado que o receptor já seguiu em frente e o descarta, ou pode chegar corrompido e ser descartado. Do ponto de vista do ouvinte, os três soam iguais.

É útil separar a perda de pacotes de seus dois parentes próximos. Latência é atraso, o tempo que um pacote leva para percorrer o caminho de ponta a ponta. Jitter é a variação nesse atraso, pacotes chegando com espaçamento irregular. Perda de pacotes é ausência, o pacote simplesmente não está lá. Os três interagem, jitter alto pode se transformar em perda quando um pacote chega tarde demais para ser usado, mas são problemas distintos com correções distintas.

A mídia de voz trafega pelo Real-time Transport Protocol (RTP), definido na RFC 3550. Cada pacote RTP carrega um número de sequência e um timestamp, que é o que torna a perda detectável: quando o receptor vê o pacote 41 chegar logo após o pacote 39, ele sabe que o pacote 40 se foi.

Por que a perda de pacotes afeta mais a voz do que dados

O tráfego de dados comum, como um download de arquivo ou uma página web, utiliza TCP, que retransmite tudo que se perde. Perca um pacote e o TCP simplesmente o envia novamente. O arquivo chega intacto, apenas um pouco mais lento, e você nem percebe.

A voz não funciona assim. Uma conversa ao vivo usa UDP e RTP sem retransmissão, porque um pacote de áudio que chega 300 milissegundos atrasado é inútil. O momento que ele deveria preencher já passou. Pedir novamente só aumentaria o atraso. Então, quando um pacote RTP é perdido, ele permanece perdido, e o áudio que ele carregava simplesmente desaparece.

Cada pacote RTP normalmente contém cerca de 20 milissegundos de som. Um único pacote perdido é um buraco de 20 milissegundos, ouvido como um clique sutil ou uma consoante cortada. Perca pacotes de forma dispersa e o cérebro compensa a maioria. O dano real vem da perda em rajada, vários pacotes consecutivos perdidos de uma vez, que deixa uma lacuna longa o suficiente para engolir uma palavra inteira. É por isso que duas chamadas com a mesma taxa de 2% de perda podem soar completamente diferentes: a que perde pacotes em rajadas é muito pior do que a que os perde aleatoriamente.

Como a perda de pacotes é medida e o que é considerado aceitável

A perda é expressa como porcentagem de pacotes RTP, e o receptor a calcula a partir das lacunas nos números de sequência. O protocolo complementar do RTP, o RTCP, transporta essas estatísticas de volta para que ambos os lados, e qualquer dispositivo no caminho de mídia, possam ver como uma chamada está se comportando em tempo real.

O outro número importante é o Mean Opinion Score (MOS), a classificação padrão de 1 a 5 da qualidade percebida da voz. A perda de pacotes é um dos maiores fatores no cálculo do MOS, junto com jitter e latência, então a perda geralmente aparece como um MOS em queda antes que alguém registre uma reclamação. O MOS está no centro de qualquer abordagem séria de monitoramento VoIP.

Como referência geral, e é apenas uma referência porque o codec em uso muda os números, uma perda abaixo de aproximadamente 1% é geralmente aceitável em uma chamada G.711 padrão. Entre 1% e 3%, torna-se perceptível, com palavras ocasionalmente cortadas. Acima de cerca de 5%, a maioria das chamadas fica inutilizável. Esses limites são amplamente divulgados, mas o ponto para um operador é mais simples: você não deveria estar adivinhando onde suas chamadas se situam nessa escala. Os números vêm de estatísticas RTP por chamada, e se você não está coletando essas estatísticas, está operando às cegas.

O que causa perda de pacotes em redes de voz

O congestionamento de rede é o culpado mais comum. Quando um link atinge sua capacidade máxima, as filas que o alimentam transbordam e o roteador não tem outra opção senão descartar pacotes. A voz, sendo pequena e constante, é pega no mesmo transbordamento que todo o resto, a menos que seja protegida.

Essa proteção é a segunda questão. Em um link sem política de Qualidade de Serviço (QoS) e sem marcação DSCP, os pacotes de voz competem em igualdade de condições com tráfego pesado como backups e transferências de arquivos, e uma única transferência grande pode sufocar uma chamada. Além do congestionamento, os suspeitos habituais são transições wireless e de última milha, interferência Wi-Fi e circuitos de acesso sobrecarregados, anomalias de roteamento que enviam pacotes pelo caminho mais longo ou para um buraco negro, e falhas simples de hardware como uma NIC com defeito ou uma porta de switch instável. Por fim, há a perda autoinfligida: empurrar mais chamadas simultâneas por um dispositivo de mídia do que ele foi dimensionado para suportar, fazendo com que ele descarte pacotes por conta própria. Quando a perda aparece, uma abordagem estruturada de troubleshooting VoIP é o que separa uma correção rápida de uma interrupção prolongada.

Como um SBC detecta e contém a perda de pacotes

É aqui que um Controlador de Borda de Sessão ganha seu lugar em uma rede de voz. Um SBC opera como um Agente de Usuário Back-to-Back (B2BUA), o que significa que ele encerra a relação de sinalização de um lado e origina uma nova do outro, em vez de simplesmente encaminhar pacotes. Quando ele está no caminho de mídia, pode medir a perda RTP em cada perna de forma independente.

Essa independência é a coisa mais útil que um SBC acrescenta ao troubleshooting de perda de pacotes. Uma reclamação genérica como “a chamada estava ruim” não diz nada sobre onde está o problema. Mas se o SBC mostra RTP limpo na perna de acesso em direção ao seu cliente e perda pesada na perna da operadora, o problema é da operadora, e você pode escalar com evidências em vez de começar um jogo de adivinhação. Inverta as leituras e o problema é do seu lado.

O ProSBC expõe essa visibilidade diretamente. Ele produz scores MOS por chamada junto com valores de jitter e perda de pacotes, e os disponibiliza via SNMP e saída de CDR (Registro de Detalhe de Chamada), para que os dados fluam para qualquer plataforma de monitoramento que você já utiliza. Para inspeção aprofundada, ele também suporta captura de pacotes em tempo real e rastreamento completo de chamadas SIP e RTP, permitindo que um engenheiro extraia os pacotes reais de uma chamada com problema em vez de trabalhar com contadores resumidos. A TelcoBridges tem mais de vinte anos de experiência em implantação de SIP e mídia por trás dessa capacidade, e o ProSBC processa mídia em escala de operadora.

O SBC também oferece duas alavancas para prevenir a perda em vez de apenas observá-la. A negociação de codec permite que o SBC estabeleça um codec adequado ao link, já que um codec de menor bitrate em uma conexão restrita exerce menos pressão e deixa mais margem. O controle de admissão de chamadas limita o número de sessões simultâneas, impedindo que o caminho de mídia seja levado ao congestionamento descrito acima. Usados em conjunto, eles eliminam a perda autoinfligida.

Uma ressalva honesta: um SBC não pode fabricar largura de banda, e não pode recuperar áudio que uma rede de terceiros já descartou. O que ele faz é medir a perda com precisão, localizá-la em um segmento específico e prevenir as condições de sobrecarga que causam perda dentro da sua própria infraestrutura. No dia a dia das operações, isso é a maior parte da batalha.

Reduzindo a perda de pacotes na prática

Alguns hábitos mantêm a perda sob controle. Provisione e priorize primeiro: marque o RTP com o valor DSCP correto para que ele receba prioridade QoS, e deixe margem real de largura de banda em vez de operar links no limite. Dimensione corretamente sua capacidade de chamadas simultâneas e aplique o controle de admissão, para que um pico de tráfego seja rejeitado na porta em vez de degradar todas as chamadas em andamento. Escolha codecs adequados ao link, optando por uma opção de menor bitrate onde a largura de banda é limitada. Acima de tudo, monitore continuamente em vez de reativamente, porque estatísticas por chamada revelam uma tendência antes dos clientes. E quando a perda aparecer, localize-a com dados por segmento antes de escalar, para que a conversa com sua operadora comece a partir de fatos.

Perguntas frequentes

Conclusão

Perda de pacotes é áudio ausente, som que a rede deveria entregar e não entregou. A voz sente isso de forma aguda porque, ao contrário de um download de arquivo, não pode esperar por uma segunda tentativa. Uma taxa de perda de apenas alguns por cento é suficiente para arruinar uma chamada, e a perda em rajada é pior do que a porcentagem sozinha sugere. O caminho de saída é medição e localização: conheça seus números de perda por chamada e saiba qual segmento é responsável antes de agir.