Troubleshooting Problemas de QoS (Qualidade de Serviço) de Voz Cortada

Introdução

Para que a solução de voz de pacote seja um substituto realista dos serviços padrão de telefonia de uma rede de telefonia pública comutada (PSTN), a qualidade recebida da voz de pacote deve ser comparável àquela dos serviços de telefonia básicos. Isso significa transmissões de voz de alta qualidade consistentemente. Como outros aplicativos em tempo real, o Packet Voice tem uma largura de banda ampla e é sensível a retardo. Para que as transmissões de voz sejam inteligíveis (não apresente baixa fluidez) ao receptor, os pacotes de voz não podem ser descartados, excessivamente atrasados ou sofrer variação no atraso (também conhecida como variação de sinal). Este documento descreve várias considerações de Qualidade de Serviço (QoS) que ajudam a solucionar problemas de voz cortada. As principais razões dos problemas de voz cortada são os pacotes de voz perdidos e atrasados.

Pré-requisitos

Requisitos

Os leitores deste documento devem estar cientes destes:

• Configuração básica do Packet Voice (VoIP, Voice over Frame Relay (VoFR) ou Voice over ATM (VoATM), de acordo com suas necessidades.

• Compreensão básica de priorização de voz, fragmentação, diferentes codecs e seus requisitos de largura de banda.

Componentes Utilizados

As informações neste documento aplicam-se a todas as versões de software e hardware de gateways de voz da Cisco.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Causas de voz cortada

Uma qualidade de voz cortada é provocada pelo atraso variável ou pela perda de pacotes de voz na rede. Quando um pacote de voz se atrasa em atingir o seu destino, o gateway de destino apresenta uma perda de informações em tempo real. Nesse caso, o gateway de destino deve prever qual pode ser o conteúdo do pacote perdido. A previsão leva a que a voz recebida não tenha as mesmas características que a voz transmitida. Isso leva a uma voz recebida que soa robótica. Se um pacote de voz estiver atrasado além da capacidade de previsão de um gateway de recebimento, o gateway deixará vazio a lacuna de tempo real. Sem nada para preencher essa lacuna na extremidade receptora, parte da fala transmitida é perdida. Isso resulta em voz cortada. Muitos dos problemas de voz cortada são resolvidos certificando-se de que os pacotes de voz não estão muito atrasados (e mais do que isso, não estão variavelmente atrasados). Às vezes, a detecção de atividade de voz (VAD - Voice Activity Detection) adiciona um recorte de front-end a uma conversação de voz. Essa é outra causa de voz cortada (ou cortada).

As várias seções neste documento mostram como minimizar a ocorrência de voz cortada. A maioria dessas medidas exige a garantia da introdução de um mínimo de jitter na sua rede de voz.

Requisito de largura de banda

Antes de considerar aplicar qualquer medida para minimizar o jitter, provisione largura de banda de rede suficiente para suportar o tráfego de voz em tempo real. Por exemplo, uma chamada VoIP G.711 de 80 kbps (payload de 64 kbps + cabeçalho de 16 kbps) parece ruim em um link de 64 kbps porque pelo menos 16 kbps dos pacotes (que é 20%) são descartados. Os requisitos de largura de banda variam de acordo com o codec usado para compactação. Codecs diferentes têm payloads e necessidades de cabeçalho diferentes. O uso de VAD também afeta o requisito de largura de banda. Se a compressão de cabeçalho (cRTP) do protocolo RTP (Real Time Protocol) for usada, ela poderá reduzir ainda mais o requisito de largura de banda.

Por exemplo, a largura de banda necessária para uma chamada de voz usando o codec G.729 (payload padrão de 20 bytes) com cRTP é a seguinte:

• Payload de voz + compactado (cabeçalho RTP + cabeçalho UDP + cabeçalho IP) + cabeçalho de Camada 2

Isso equivale a:

• 20 bytes + compactado (12 bytes + 8 bytes + 20 bytes) + 4 bytes

Isso equivale a:

• 28 bytes, já que a compactação de cabeçalho reduz o cabeçalho IP RTP a um máximo de 4 bytes. Isso produz 11.2 kbps em taxa de codec de 8 kbps (50 pacotes por segundo).

Para obter mais informações, consulte Voz sobre IP - Consumo de largura de banda por chamada.

Prioridade de tráfego de voz

Há dois componentes importantes na priorização de voz. A primeira é classificar e marcar o tráfego de voz interessante. A segunda é priorizar o tráfego de voz significativo marcado. As duas subseções aqui discutem várias abordagens para classificar, marcar e priorizar voz.

Classificação e marcação

Para garantir a largura de banda para pacotes VoIP, um dispositivo de rede deve ser capaz de identificar os pacotes em todo o tráfego IP que flui através dele. Os dispositivos de rede utilizam os endereços IP de origem e destino no cabeçalho IP, ou os números de porta UDP de origem e destino no cabeçalho UDP para identificar os pacotes VoIP. Esse processo de identificação e agrupamento é chamado de classificação. É a base para fornecer qualquer QoS.

A classificação de pacotes pode exigir muito do processador. Portanto, a classificação deve ser feita o mais longe possível em direção à borda da rede. Como cada salto ainda precisa determinar o tratamento que um pacote deve receber, será necessário usar um método de classificação mais simples e mais eficiente no centro de rede. Esta classificação mais simples é atingida por meio da marcação ou da configuração do byte de Tipo de Serviço (TOS) no cabeçalho IP. Os três bits mais significativos do byte ToS são chamados de bits de precedência de IP. A maioria dos aplicativos e fornecedores suporta atualmente a configuração e o reconhecimento desses três bits. O processo de marcação está evoluindo de tal maneira, que os seis bits mais significativos do byte ToS, denominado Ponto de Código de Serviços Diferenciados (DSCP), podem ser utilizados. Consulte o RFC (Request for Comments).

O Differentiated Services (DiffServ) é um novo modelo no qual o tráfego é tratado por sistemas intermediários com prioridades relativas baseadas no campo ToS. Definido no RFC 2474 e no RFC 2475 , o padrão diffserv substitui a especificação original para definir a prioridade de pacote descrita no RFC 791 . DiffServ aumenta o número de níveis de prioridade definíveis realocando bits de um pacote IP para marcação de prioridade. A arquitetura DiffServ define o campo DiffServ. Ele substitui o byte ToS no IP V4 para tomar decisões de comportamento por salto (PHB) sobre as funções de classificação de pacotes e condicionamento de tráfego, como medição, marcação, modelagem e vigilância. Além dos RFCs mencionados anteriormente, o RFC 2597 define as classes Assured Forwarding (AF). Esta é uma divisão dos campos DSCP. Para obter informações adicionais sobre DSCP, consulte Implementando a qualidade das políticas de serviço com o DSCP.

Byte ToS - P2 P1 P0 T3 T2 T1 T0 CU

Precedência IP: três bits (P2-P0), ToS: quatro bits (T3-T0), CU: um bit

Campo DiffServ - DS5 DS4 DS3 DS2 DS1 DS0 ECN

DSCP: seis bits (DS5-DS0), ECN: dois bits

XXX00000 Bits 0, 1, 2 (DS5, DS4, DS3) são bits de precedência, onde:

• 111 = Controle de Rede = Precedência 7

• 110 = Controle de Internetwork = Precedência 6

• 101 = CRÍTICO/ECP = Precedência 5

• 100 = Substituição Flash = Precedência 4

• 011 = Flash = Precedência 3

• 010 = Imediato = Precedência 2

• 001 = Prioridade = Precedência 1

• 000 = Rotina = Precedência 0

000XXX00 Bits 3, 4, 5 (DS2, DS1, DS0) são bits de Atraso, Throughput e Confiabilidade.

• Bit 3 = Retardo [D] (0 = Normal; 1 = Baixo)

• Bit 4 = Débito [T] (0 = Normal; 1 = Alto)

• Bit 5 = Fiabilidade [R] (0 = Normal; 1 = Alto)

000000XX Bits 6, 7: ECN

Estas duas seções discutem duas formas de classificação e marcação.

Peers de Discagem de Voz para Classificar e Marcar Pacotes

Com os gateways VoIP da Cisco, você geralmente usa os peers de discagem de voz para classificar os pacotes VoIP e marcar os bits de precedência de IP. Esta configuração mostra como marcar os bits de precedência de IP:

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5

No exemplo acima, qualquer chamada de VoIP que corresponda ao comando dial-peer voice 100 voip tem todos os seus pacotes de payload de voz definidos com Precedência de IP 5. Isso significa que os três bits mais significativos do byte de ToS de IP estão definidos como 101.

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip qos dscp ef media
ip qos dscp af31 signaling

No exemplo acima, qualquer chamada VoIP que corresponda ao comando dial-peer voice 100 voip tem todos os seus pacotes de payload de mídia (pacotes de voz) definidos com padrão de bits EF (Expedited Forwarding) 101110. Todos os pacotes de sinalização são definidos com 011010 de padrão de bit AF.

Observação: o comando ip qos dscp é suportado desde o Cisco IOS® Software Release 12.2(2)T. A Precedência de IP não está mais disponível no Cisco IOS Software Release 12.2T. No entanto, o mesmo é obtido pelo comando ip qos dscp. A precedência 5 do IP (101) é mapeada para o 101000 DSCP IP. Para obter mais informações, consulte Classificando a Sinalização e Mídia VoIP com DSCP para QoS.

Modular QoS CLI to Classify and Mark Packets

O método de classificação e marcação recomendado é o QoS CLI modular. Esse é um método de configuração baseado em modelo que separa a classificação da política. Isso permite que vários recursos de QoS sejam configurados juntos para várias classes. Use um comando class-map para classificar o tráfego com base em vários critérios de correspondência e um comando policy-map para determinar o que precisa acontecer a cada classe. Aplique a política ao tráfego de entrada ou saída em uma interface emitindo o comando service-policy. Este exemplo de configuração mostra como usar a CLI QoS modular para classificar e marcar pacotes:

access-list 100 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
class-map match-all voip
match access-group 100
class-map match-all control
match access-group 101
!
policy-map mqc
class voip
set ip precedence 5
class control
set ip precedence 5
class class-default
set ip precedence 0
!
interface Ethernet0/0
service-policy input mqc

Neste exemplo de configuração, qualquer tráfego que corresponda à ACL (Access Control List, lista de controle de acesso) 100 é classificado como "class voip" e definido com a precedência 5 do IP. Isso significa que os três bits mais significativos do byte ToS do IP são definidos como 101. A ACL 100 corresponde às portas UDP comuns usadas pelo VoIP. Da mesma forma, a ACL 101 corresponde ao tráfego de sinalização H.323 (porta 1720 do Transmission Control Protocol (TCP)). Todo o tráfego restante é definido com precedência de IP 0. A política é chamada de "mqc". Ele é aplicado ao tráfego de entrada na Ethernet 0/0.

Priorizando

Após cada salto na rede ser capaz de classificar e identificar os pacotes VoIP (seja através de informações de porta/endereço ou através do byte ToS), esses saltos fornecem a cada pacote VoIP a QoS necessária. Nesse ponto, configure técnicas especiais para fornecer enfileiramento de prioridade para garantir que grandes pacotes de dados não interfiram na transmissão de dados de voz. Isso geralmente é necessário em enlaces de WAN mais lentos onde há uma alta possibilidade de congestionamento. Quando todo o tráfego interessante for colocado nas classes de QoS com base em seus requisitos de QoS, forneça garantias de largura de banda e atendimento de prioridade por meio de um mecanismo inteligente de enfileiramento de saída. Uma fila de prioridade é necessária para VoIP.

Note:  Use qualquer mecanismo de enfileiramento que efetivamente dê alta prioridade ao VoIP. No entanto, o enfileiramento de baixa latência (LLQ) é recomendado porque é flexível e fácil de configurar.

O LLQ usa o método de configuração modular QoS CLI para fornecer prioridade a certas classes e para fornecer largura de banda mínima garantida para outras classes. Durante períodos de congestionamento, a fila de prioridade é vigiada na taxa configurada para que o tráfego de prioridade não use toda a largura de banda disponível. (Se o tráfego de prioridade monopolizar a largura de banda, ele impedirá que as garantias de largura de banda para outras classes sejam atendidas.) Se você provisionar o LLQ corretamente, o tráfego que entra na fila de prioridade nunca deverá exceder a taxa configurada.

O LLQ também permite que as profundidades da fila sejam especificadas para determinar quando o roteador precisa descartar pacotes se houver muitos pacotes aguardando em qualquer fila de classe específica. Há também um comando class-default usado para determinar o tratamento de todo o tráfego não classificado por uma classe configurada. O padrão de classe é configurado com um comando fair-queue. Isso significa que a cada fluxo não classificado é dado um compartilhamento aproximadamente igual da largura de banda restante.

Este exemplo mostra como configurar LLQ. Para obter mais informações, consulte Enfileiramento de latência baixa:

access-list 100 permit udp any any range 16384 32000
access-list 101 permit tcp any any eq 1720
access-list 102 permit tcp any any eq 80
access-list 103 permit tcp any any eq 23
!
class-map match-all voip
match access-group 100
class-map match-all voip-control
natch access-group 101
class-map match-all data1
match access-group 102
class-map match-all data2
match access-group 103
!
policy-map llq
class voip
priority 32
class voip-control
bandwidth 8
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq

Neste exemplo, qualquer tráfego que corresponda à ACL 100 é classificado como "class voip" (que significa tráfego de voz). Ele recebe uma prioridade alta de até 32 kbps. ACL 100 corresponde às portas UDP comuns usadas por VoIP. A lista de acesso 101 corresponde ao tráfego de sinalização H.323 (porta TCP 1720). A classe data1 corresponde ao tráfego da Web (porta TCP 80, como visto na Lista de Acesso 102) e garante 64 kbps. Os dados de classe 2 correspondem ao tráfego Telnet (porta 23 do TCP, como visto na ACL 103) e garantem 32 kbps. A classe padrão está configurada para proporcionar uma porção igual da largura de banda restante para fluxos não classificados. A política é chamada de "llq". Ele é aplicado ao tráfego de saída em Serial1/0, que tem uma largura de banda total de 256 kbps.

Observação: por padrão, a largura de banda total garantida e a largura de banda prioritária para todas as classes precisam ser menores que 75 por cento da largura de banda da interface. Modifique essa porcentagem emitindo o comando max-reserved bandwidth interface.

Esta tabela compara diferentes mecanismos de enfileiramento de software com seus respectivos benefícios e limitações.

Mecanismo de enfileiramento de software	Descrição	Benefícios	Limitações
First-In-First-Out (FIFO)	Os pacotes chegam e saem da fila exatamente na mesma ordem.	Configuração simples e operação rápida.	Não é possível garantir serviço de prioridade ou de largura de banda.1
Weighted-Fair Queuing (WFQ)	Um algoritmo de hash que flui em filas separadas onde os pesos são usados para determinar quantos pacotes são atendidos por vez. Você estabelece relevância ao definir valores de precedência do IP e DSCP.	Configuração simples. Padrão em links com menos de 2 Mbps.	Não é possível garantir serviço de prioridade ou de largura de banda.1
CQ	O tráfego é classificado em diversas filas com limites de enfileiramento configuráveis. Os limites da fila são calculados com base no tamanho médio do pacote, na Unidade máxima de transmissão (MTU) e na porcentagem de largura de banda a ser alocada. Os limites da fila (em número de bytes) são removidos para cada fila. Portanto, ele fornece a largura de banda alocada estatisticamente.	Está disponível há alguns anos. Permite alocação de largura de banda aproximada para filas diferentes.	Nenhuma manutenção de prioridade é possível. As garantias de largura de banda são aproximadas. Há um número limitado de filas. A configuração é relativamente difícil. 1
Enfileiramento de prioridades (PQ)	O tráfego é classificado em filas de prioridade alta, média, normal e baixa. O tráfego de alta prioridade é atendido primeiro, seguido pelo de média, normal e baixa prioridade.	Está disponível há alguns anos. Fornece manutenção prioritária.	O tráfego de prioridade mais alta consome as filas de prioridade mais baixa da largura de banda. Nenhuma garantia de largura de banda é possível.2
Enfileiramento moderado ponderado baseado em classe (CBWFQ - Class-Based Weighted Fair Queuing)	O QoS CLI modular é utilizado para classificar o tráfego. O tráfego classificado é colocado em fila de largura de banda reservada ou em uma fila padrão não reservada. Um agendador serve as filas com base nos pesos, portanto as garantias de largura de banda são honradas.	Semelhante ao LLQ, exceto que não há fila de prioridade. Configuração simples e capacidade de oferecer garantias de largura de banda.	Nenhuma manutenção de prioridade é possível.3
Priority Queue Weighted Fair Queuing (PQ-WFQ), também chamado de IP RTP Priority	Um único comando de interface é usado para fornecer serviço de prioridade para todos os pacotes de UDP destinados a números de porta pares em um intervalo especificado.	Configuração simples, de um único comando. Fornece serviço de prioridade aos pacotes de RTP.	Todo o tráfego restante é tratado com WFQ. O tráfego do protocolo RTCP não tem prioridade. Nenhuma capacidade garantida de largura de banda.4
LLQ, anteriormente Priority Queue Class-Based Weighted Fair Queuing (PQCBWFQ)	A CLI QoS modular com fila de prioridade é usada para classificar o tráfego. O tráfego classificado é colocado em uma fila de prioridade, em filas com largura de banda reservadas ou em uma fila sem reserva padrão. Um programador atende às filas de acordo com os pesos, de modo que o tráfego de prioridade seja enviado primeiro (até um determinado limite vigiado durante o congestionamento) e as garantias de largura de banda sejam atendidas.	Configuração simples. Capacidade de dar prioridade às diversas classes de tráfego e definir limites superiores para utilização prioritária de largura de banda. Você também pode configurar classes com largura de banda garantida e uma classe padrão.	Nenhum mecanismo para fornecer vários níveis de prioridade ainda, todo o tráfego de prioridade é enviado pela mesma fila de prioridade. Classes de prioridade separadas podem ter limites de largura de banda de prioridade superior separados durante o congestionamento. No entanto, o compartilhamento de fila de prioridade entre aplicativos pode introduzir instabilidade.4

1. Não adequado para voz.

2. Precisa de largura de banda garantida para voz.

3. Precisa que a latência seja atendida.

4. Suficiente para voz.

Retardo de serialização

Mesmo que o enfileiramento funcione no seu melhor e priorize o tráfego de voz, há momentos em que a fila de prioridade está vazia e um pacote de outra classe é atendido. Os pacotes de classes de largura de banda garantida devem ser servidos com base no peso configurado. Se um pacote de voz com prioridade chega à fila de saída enquanto esses pacotes estão sendo atendidos, o pacote de voz pode esperar uma quantidade significativa de tempo antes de ser enviado. Os pacotes de voz passam por retardo na serialização quando têm de esperar por pacotes de dados maiores.

O atraso de serialização pode introduzir a pior forma de jitter para pacotes de voz. Se os pacotes de voz tiverem que esperar atrás de um pacote de dados que é tão grande quanto 1500 bytes, em um link mais lento, isso se traduz em um grande atraso. O atraso de serialização será muito diferente se o pacote de dados tiver 80 bytes, como mostrado neste exemplo:

• Atraso de serialização em um link de 64 kbps devido a um pacote de 1500 bytes = 1500*8/64000 = 187,5 ms.

• Atraso de serialização em um link de 64 kbps devido a um pacote de 80 bytes = 80*8/64000 = 10 ms.

Portanto, um pacote de voz potencialmente tem que esperar até 187,5 ms antes de ser enviado se ficar preso atrás de um único pacote de 1.500 bytes em um link de 64 kbps. Por outro lado, outro pacote de voz tem que esperar apenas 10 ms no gateway de destino. Isso resulta em uma tremulação alta que ocorre devido à variância no retardo do inter-pacotes. No gateway de origem, os pacotes de voz são geralmente enviados a cada 20 ms. Com um orçamento de atraso de ponta a ponta de 150 ms e requisitos de variação de sinal estrita, uma lacuna de mais de 180 ms é inaceitável.

Introduzir um mecanismo de fragmentação que garanta que o tamanho de uma unidade de transmissão seja inferior a 10 ms. Quaisquer pacotes com mais de 10 ms de atraso de serialização precisam ser fragmentados em blocos de 10 ms. Um fragmento ou fragmento de 10 ms é o número de bytes enviados pelo link em 10 ms. Calcule o tamanho usando a velocidade do link, conforme mostrado neste exemplo:

• Tamanho da fragmentação = (0,01 segmentação * 64,000 bps) / (8 bits/byte) = 80 bytes

São precisos 10 ms para enviar um pacote de 80 bytes ou fragmento em um link de 64 kbps.

No caso de vários Circuitos Virtuais Permanentes (PVCs) de ATM ou Frame Relay em uma única interface física, configure valores de fragmentação (em todos os PVCs) com base no PVC que possui a menos largura de banda disponível. Por exemplo, se houver três PVCs que tenham uma largura de banda garantida de 512 kbps, 128 kbps e 256 kbps, configure todos os três PVCs com um tamanho de fragmento de 160 bytes (a velocidade mais baixa é 128 kbps, que exige um tamanho de fragmento de 160 bytes). Esses valores são recomendados para velocidades de link diferentes:

Link Speed (kbps)         Fragmentation Size (bytes) 
56                                  70 
64                                  80 
128                                 160 
256                                 320 
512                                 640 
768                                 960 
1024                                1280 
1536                                1920

Observação: nenhuma fragmentação será necessária se o tamanho do fragmento for maior que o tamanho da MTU do link. Por exemplo, para um link T1 com um MTU de 1500 bytes, o tamanho do fragmento é 1920 bytes. Portanto, não é necessária nenhuma fragmentação. O tamanho da fragmentação de pacote nunca deve ser inferior ao tamanho do pacote VoIP. Não fragmente pacotes VoIP. A fragmentação destes pacotes causa diversos problemas de configuração e qualidade de chamada.

Atualmente, há três mecanismos de fragmentação e intercalamento de link disponíveis. Para uma explicação mais completa dos vários atrasos introduzidos em uma rede de pacotes, consulte Understanding Delay in Packet Voice Networks (Compreendendo o Atraso em Redes de Voz de Pacotes). Esta tabela lista seus benefícios e limitações:

Mecanismo de Fragmentação e Intercalação de Enlaces (LFI)	Descrição	Benefícios	Limitações
Fragmentação de MTU com WFQ	Comando de nível de interface para alterar o tamanho da MTU ou o tamanho da MTU IP. Utilizado para fragmentar pacotes grandes de IP em um tamanho MTU especificado. O LFI usa WFQ para intercalar pacotes em tempo real entre os fragmentos.	Configuração simples.	Os fragmentos são reagrupados somente pelo aplicativo receptor. Portanto, o uso ineficiente da rede. Somente os pacotes IP com o bit Não Fragmentar (DF) não definido podem lidar bem com a fragmentação. Altamente processado. Não recomendado.
LFI MLPPP	Em links seriais ponto-a-ponto, o MLPPP deve ser configurado primeiro e, em seguida, o tamanho da fragmentação deve ser definido em ms. O entrelaçamento também deve ser habilitado na interface multilink.	Os pacotes são fragmentados em uma extremidade do enlace e remontados na outra. É possível combinar vários links para atuarem como uma grande tubulação virtual.	Disponível apenas nos links configurados para PPP. Soluções para PPP sobre Frame Relay ou PPP sobre ATM também são suportadas no Cisco IOS Software Release 12.1(5)T ou posterior.
Fragmentação do Frame Relay (FRF.12)	Em PVCs de Frame Relay, o comando frame-relay traffic-shaping deve ser ativado e o tamanho da fragmentação, definido na classe de mapa.	Os pacotes são fragmentados em uma extremidade do PVC e reagrupados na outra.	Disponível somente em PVCs de Frame Relay com o comando frame-relay traffic-shaping habilitado.

VAD

Uma conversação verbal regular consiste em vários momentos de silêncio. Uma conversação de voz típica consiste em 40 a 50 por cento de silêncio. Como não há voz atravessando a rede em 40 por cento das chamadas de voz, é possível economizar largura de banda distribuindo VAD. Com o VAD, o gateway procura lacunas na fala. Ele substitui essas lacunas por ruído de conforto (ruído de fundo). Assim, uma quantidade de largura de banda é economizada. Entretanto, existe uma troca. Há um tempo pequeno (na ordem de milissegundos), antes que os codecs detectem atividade de fala seguida por um período de silêncio. Esse tempo pequeno resulta no corte de front-end da voz recebida. Para evitar a ativação durante pausas muito curtas e compensar o corte, o VAD espera aproximadamente 200 ms após a interrupção da fala antes de parar a transmissão. Ao reiniciar a transmissão, ela inclui os 5 ms anteriores de fala junto com a fala atual. O VAD se desabilita automaticamente em uma chamadas se o ruído ambiente impedi-lo de distinguir a fala do barulho de fundo. No entanto, se a largura de banda não for um problema, desligue o VAD.

Ajuste os parâmetros de VAD

Há dois parâmetros que determinam o funcionamento do VAD. Esses são os comandos music-threshold e voice vad-time.

music-threshold

Um limiar inicial é decidido que governa quando o VAD precisa se tornar ativo. Isso é controlado pela definição do comando music-threshold threshold_value em uma porta de voz, como mostrado neste exemplo. O intervalo para isso é de -70 decibéis por miliwatt (dBm) a -30 dBm. O valor padrão é -38 dBm. A configuração de um valor mais baixo, (por volta de -70 dBm) faz com que a VAD se torne ativa a uma força de sinal muito mais baixa (o volume deve cair muito antes de ser considerado um silêncio). A configuração de um valor mais alto (próximo a -30 dBm) faz com que o VAD se torne ativo mesmo para uma pequena queda na intensidade do sinal de voz. Ele orienta o playout para reproduzir pacotes de ruído de conforto com mais frequência. No entanto, isso às vezes leva a cortes menores de áudio.

3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#music-threshold ?
WORD Enter a number b/w (-70 to -30)
3640-6(config-voiceport)#music-threshold -50
3640-6(config-voiceport)#end
3640-6#
3640-6#show run | be voice-portvoice-port 3/0/0 music-threshold -50

voice vad-time

Quando o VAD se torna ativo, o componente de ruído de fundo e ruído de conforto é controlado pela configuração do comando voice vad-time timer_value na configuração global, como mostrado neste exemplo. Esse é o tempo de retardo em milésimos de segundo para detecção de silêncio e supressão da transmissão do pacote de voz. O valor padrão do tempo remanescente do período anterior é de 250 ms. Isso significa que dentro de 250 ms, começa o ruído de conforto. O intervalo deste cronômetro é de 250 ms a 65536 ms. Se um valor alto for configurado para isso, o ruído de conforto entrará em jogo muito mais tarde (o ruído de fundo continua a ser reproduzido). Caso esteja configurado para 65536 m/s, então o ruído de conforto será desligado. Um valor maior para esse timer é desejado para realização de uma transição mais tranqüila entre o ruído de plano de fundo e o ruído de conforto. A desvantagem de configurar o comando voice vad-time em um nível alto é que ele não alcança os 30 a 35 por cento desejados de economia de largura de banda.

3640-6#
3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice vad-time ?
<250-65536> milliseconds
3640-6(config)#voice vad-time 750
3640-6(config)#end
3640-6#
3640-6#
3640-6#
3640-6#show run | be vad-time voice vad-time 750

Exemplos de configuração típica de QoS

Um cenário típico para configurar chamadas VoIP é sobre um link frame-relay ou sobre um link PPP. Esses são exemplos de configuração para esses cenários.

VoIPoFR - Exemplo de configuração de QoS

Neste exemplo (que contém apenas seções relevantes da configuração), supõe-se que a velocidade do circuito frame-relay é de 256 kbps. A Taxa de Informações Consolidada (CIR) garantida no PVC 100 é de 64 kbps e no PVC 200 é de 192 kbps. O PVC 100 é usado para transportar dados e voz. O PVC 200 é usado somente para transportar dados. Existem, no máximo, quatro chamadas de voz simultâneas por vez. Configure a fragmentação em ambos os PVCs com base na CIR do PVC de voz de largura de banda mais baixa (PVC transportando voz). Com base nos exemplos neste documento, isso significa que o tamanho da fragmentação é decidido com base na CIR do PVC 100 (que é de 64 kbps). Como mostrado na tabela da seção Retardo de Serialização, para um link de 64 kbps, é necessário um tamanho de fragmentação de 80 bytes. O mesmo tamanho da fragmentação precisa ser configurado para PVC 200.

Para obter mais detalhes sobre a configuração de VoIP sobre Frame Relay, consulte VoIP sobre Frame Relay com Qualidade de Serviço (Fragmentação, Modelagem de Tráfego, Prioridade LLQ / IP RTP).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoFR
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Serial4/0:0
bandwidth 256
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial4/0:0.1 point-to-point
bandwidth 64
ip address 10.10.10.10 255.255.255.0
frame-relay ip rtp header-compression
frame-relay interface-dlci 100
 class voice
!
interface Serial4/0:0.2 point-to-point
bandwidth 192
ip address 20.20.20.20 255.255.255.0
frame-relay interface-dlci 200
class data
!
map-class frame-relay data
frame-relay fragment 80
frame-relay adaptive-shaping becn
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 0
frame-relay mincir 192000
frame-relay fair-queue
!
map-class frame-relay voice
frame-relay fragment 80
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
service-policy output VoIPoFR
!
!
access-list 101 permit tcp any any eq 1720
!
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1

Exemplo de configuração de VoIP sobre PPP - QoS

Neste exemplo (que contém apenas seções relevantes da configuração), supõe-se que a QoS precisa ser configurada para um controlador T1 fracional ponto a ponto (que tem doze canais). Existem, no máximo, quatro chamadas de voz simultâneas por vez. A tarefa de configuração envolve configurar essa interface serial com encapsulamento PPP, tornando-a parte de um grupo multilink, criar uma interface multilink (que pertence ao mesmo grupo multilink) e configurar toda a QoS na interface multilink. Para obter mais detalhes sobre a configuração de VoIP sobre PPP, consulte Links VoIP sobre PPP com Qualidade de Serviço (LLQ / Prioridade IP RTP, LFI, cRTP).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoPPP
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Multilink7
bandwidth 768
ip address 10.10.10.10 255.255.255.0
ip tcp header-compression iphc-format
service-policy output VoIPoPPP
no cdp enable
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 7
ip rtp header-compression iphc-format
!
!
interface Serial4/0:0
bandwidth 768
no ip address
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 7
!
!
access-list 101 permit tcp any any eq 1720
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1
!

Mecanismo de tremulação e de playout

Sempre há algumas entidades não controladas em uma rede que contribuem para atrasos e jitter adicionais nos pacotes de voz recebidos. Ao modificar o buffer de variação de sinal no gateway de terminação, a variação de sinal não controlada é resolvida na rede de voz.

Mecanismo de playout

O buffer de jitter é um buffer de tempo. Ele é fornecido pelo gateway de terminação para tornar o mecanismo de playout mais eficaz. Este é um diagrama funcional do mecanismo de playout:

Quando o controle de playout recebe um pacote de voz, ele analisa o selo de data/hora do RTP. Se o pacote de voz for atrasado além da capacidade de retenção do buffer de variação de sinal, o pacote será imediatamente descartado. Se o pacote estiver dentro da capacidade de armazenamento em buffer, ele será colocado no buffer de controle de variação. A localização deste pacote no buffer de variação de sinal depende do rótulo de tempo RTP calculado para o pacote. Caso não haja nenhum pacote de voz disponível, o controle de playout tenta escondê-lo (prevê o pacote perdido). Se o VAD estiver habilitado, o ruído de conforto será reproduzido.

A responsabilidade do controle de playout é manejar os eventos de pacotes perdidos, duplicados, corrompidos ou fora de seqüência. Esses eventos são tratados pelo alinhamento de tempo dos pacotes de voz com variação de sinal, reproduzindo ruído de conforto (se o VAD estiver configurado) ou até mesmo regenerando tons de multifreqüência de tom dual (DTMF) a serem reproduzidos para o host.

A supressão de um pacote de voz é feita supressão de diagnóstico ou pela supressão de silêncio. O encobrimento do prognóstico é baseado no pacote anterior e no próximo pacote (se disponível). Funciona melhor com codecs de baixa taxa de bits (5 kbps a 16 kbps). A perda de pacotes de voz para um codec de taxa de bits alta (32 kbps a 64 kbps) pode resultar potencialmente em ocultação de previsões deficiente. A ocultação de previsão começa quando há atrasos baixos e pouco frequentes ou um número menor de perda de pacotes. Muito encobrimento de previsões pode levar a uma qualidade de voz robótica. O encobrimento do silêncio é a pior forma de encobrimento da previsão. Tem efeito quando não existem informações disponíveis para prever. É simplesmente uma supressão de fundo. Ele começa quando há atrasos altos e mais número de perda de pacotes. Muita dissimulação leva a qualidade de voz cortada. A ocultação do prognóstico é bom por 30 microssegundos, após os quais passa a vigorar a silence conceal.

Buffer de tremulação

O buffer de jitter está restrito por dois limites, o superior e o inferior. A marca d'água superior representa o limite superior de tempo em que se espera que um pacote chegue para playout pontual. Os pacotes que chegarem após a marca d'água elevada serão marcados como pacotes perdidos ou atrasados. A marca d’água baixa é o tempo mínimo no qual se espera que um pacote chegue em tempo para playout. Os pacotes que chegam antes da marca d'água inferior são considerados pacotes iniciais (ainda podem ser reproduzidos no prazo).

Se o gateway de terminação continuar a ver um incremento na chegada de pacotes atrasados, ele aumentará a marca d'água alta. Esse valor de marca d'água alta permanece o mesmo durante toda a chamada. Isso é aumentado até o máximo definido na configuração. De maneira semelhante, o gateway de terminação observa o número de pacotes recebidos antecipadamente. Se esses pacotes começarem a frequentar o gateway, isso reduzirá a marca d'água baixa. Esse valor permanece o mesmo durante toda a chamada. Esse modo de buffer de variação de sinal é conhecido como "modo adaptativo", em que o gateway de terminação adapta seu buffer de variação de sinal com base no padrão de tráfego. O outro modo é o “modo fixo". No modo fixo, há um valor inicial para a marca d'água inferior e a marca d'água superior. Esse valor é baseado no atraso recebido estimado (consulte a seção show voice call <número da porta> deste documento).

Para obter mais detalhes sobre buffer de variação de sinal, consulte Noções Básicas sobre Variação de Sinal em Redes de Voz de Pacotes (Plataformas Cisco IOS).

Identificar retardo e tremulação

Esta seção descreve como identificar o jitter em sua rede.

show call active voice

O comando show call ative voice brief fornece muitas informações sobre uma conversa em andamento. Esta saída exibe alguns pontos importantes que são aprendidos com este comando:

11E4 : 2170927hs.1 +600 pid:10 Answer 1000 active
dur 00:08:43 tx:26157/522967 rx:7044/139565
Tele 3/0/0:9: tx:151310/755/0ms g729r8 noise:-62 acom:0 i/0:-56/-48 dBm
11E4 : 2171198hs.1 +329 pid:20 Originate 2000 active
dur 00:08:43 tx:7044/139565 rx:26165/523127
IP 30.30.30.29:18682 rtt:51ms pl:148590/290ms lost:0/0/15 delay:65/60/132ms g729r8

Na saída do comando show call ative voice brief, você verá que o que for recebido no segmento de Telefonia (rx:7044) será transmitido para o segmento IP (tx:7044). O mesmo vale para os pacotes recebidos nos trechos IP (26165) que são encaminhados para o trecho de Telefonia (26157). A diferença no número de pacotes recebidos no segmento IP em relação ao número de pacotes transmitidos no segmento de telefonia contribui para os pacotes atrasados que não chegam a tempo.

Essa saída do comando show call ative voice (sem a palavra-chave "brief") aponta para mais detalhes sobre os parâmetros que identificam diretamente o jitter.

GapFillWithSilence=850 ms
GapFillWithPrediction=9230 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms

show voice call <número da porta>

O comando show voice call <número da porta> fornece informações úteis. Certifique-se de estar no console do gateway ou, se estiver conectado via Telnet a um gateway, certifique-se de ter emitido o comando terminal monitor do nível exec.

Observação: este comando não está disponível nas plataformas AS5x00/AS5x50.

Nesta saída, o valor de Rx Delay Est (ms) é 71. Este é o valor atual do buffer de jitter. Um valor para a marca d'água alta e a marca d'água baixa é deduzido com base nisso. Um valor inicial médio para a marca d'água superior é 70 m/s, enquanto a marca d'água inferior é de 60 msec. Depois de definido um valor inicial, o gateway controla os pacotes antecipados ou atrasados recebidos. Como é visto na saída aqui, as quedas de ocultação de previsão são próximas a 250 ms, enquanto o ocultação de silêncio é de 30 ms. Há sempre um valor mais alto para ocultação de previsão, já que a ocultação de silêncio é apenas um cenário de pior caso de ocultação de previsão. Para cada queda de ocultação de prognóstico, existe um aumento no descarte de excesso de buffer.

Se você vir o descarte de buffer, isso não significa necessariamente que você vê um aumento na marca d'água superior. A marca d'água superior é o limite superior do buffer de variação de sinal. Ela muda apenas se uma tendência for observada. Em outras palavras, deve haver um fluxo contínuo de pacotes atrasados. Isso resulta em um aumento do buffer de jitter. Na saída aqui, essa tendência está presente. Portanto, a marca d'água alta é aumentada de 70 ms para 161 ms. Se esse valor não for alterado (e se você ainda vir 14 pacotes atrasados), isso implica que esses são pacotes atrasados esporádicos, não formando uma tendência.

Na saída do comando show call ative voice, procure pacotes perdidos. Para cada pacote perdido, você vê dois pacotes que estão fora de sequência. Isso é visto na saída Rx Non-Seq Pkts. Como não é um valor positivo, conclui-se que também não houve nenhuma perda de pacotes.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 195, Tx Sig Pkts: 0, Tx Comfort Pkts: 10
Tx Dur(ms): 192070, Tx Vox Dur(ms): 388, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 9604, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 192070, Rx Vox Dur(ms): 191560, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 14
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 71
Rx Delay Lo Water Mark(ms): 60, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 250, Interpolate Conceal(ms): 0
Silence Conceal(ms): 30, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 500, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -49.9 from PBX/Phone, Tx -41.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.1
TDM Bgd Levels(dBm0): -58.9, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Observe as saídas Tx Comfort Pkts e Rx Comfort Pkts. A partir das saídas do exemplo, conclui-se que o telefone conectado a esse roteador se mantém basicamente silencioso, já que você tem muitos Tx Comfort Pkts. Ao mesmo tempo, você tem zero Rx Comfort Pkts, o que significa que a outra extremidade fala continuamente.

Compare a saída aqui com a saída do comando anterior. Há um aumento no número de Rx Late Pkts (de 14 para 26). No entanto, não há incremento no valor alto da marca d'água. Isso indica que os 12 pacotes estão esporadicamente atrasados. O descarte de Estouro de Buffer é aumentado para 910 ms. No entanto, uma vez que não se observou qualquer tendência, a marca da água elevada não é aumentada.

Na saída aqui, você tem um Rx Early Pkts: 3. Isso significa que um pacote chega muito antes do esperado. Como visto na saída aqui, o buffer de variação de sinal se expandiu para acomodar mais pacotes anteriores, reduzindo o limite inferior de água de 60 para 51.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 209, Tx Sig Pkts: 0, Tx Comfort Pkts: 11
Tx Dur(ms): 337420, Tx Vox Dur(ms): 416, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 16843, Rx Signal Pkts: 0, Rx Comfort Pkts: 1
Rx Dur(ms): 337420, Rx Vox Dur(ms): 335920, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 3, Rx Late Pkts: 26
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 72
Rx Delay Lo Water Mark(ms): 51, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 510, Interpolate Conceal(ms): 0
Silence Conceal(ms): 70, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 910, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -51.5 from PBX/Phone, Tx -44.1 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.9
TDM Bgd Levels(dBm0): -61.3, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Configurar o buffer de tremulação em um gateway

As diretrizes de QoS abordadas neste documento cuidam do problema de qualidade de voz cortada ou deteriorada. A configuração do buffer de retardo de playout é uma solução para a implementação de QoS inadequada na rede. Use-o apenas como uma correção de intervalo de parada ou como uma ferramenta para solucionar problemas e reduzir os problemas de jitter introduzidos na rede.

Modo de retardo de playout

O buffer de variação de sinal é configurado para o modo fixo ou o modo adaptativo. No modo adaptativo, o gateway permite configurar um valor mínimo para o buffer de variação de sinal, um valor máximo e um valor nominal. O buffer de jitter espera que os pacotes cheguem dentro do intervalo de valor nominal. O valor nominal deve ser igual ou maior que o mínimo e igual ou menor que o máximo. O buffer se expande até o valor máximo configurado. Isso pode se estender até 1700 ms. Um problema com a configuração do valor máximo é a introdução do atraso ponto a ponto. Escolha o valor de retardo máximo de playout, de forma que ele não introduza retardo indesejado na rede. Esta saída é um exemplo do buffer de variação de sinal configurado para o modo adaptativo:

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode adaptive
3640-6(config-voiceport)#playout-delay maximum 400
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#playout-delay minimum low
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay maximum 400
playout-delay nominal 70
playout-delay minimum low
playout-delay mode adaptive
!

No modo fixo, o gateway analisa o valor nominal configurado. Embora permita configurar os valores mínimo e máximo para o atraso de playout, ele é ignorado quando configurado para o modo fixo. Quando no modo fixo, o valor alto da marca d'água ou o valor baixo da marca d'água sempre permanece constante. Ele se baseia no valor nominal e no valor Rx Delay Est (ms). Portanto, é possível que, no modo fixo, você configure o valor como 200 ms. No entanto, se o atraso recebido estimado for próximo a 100 ms, isso será definido para a marca d'água superior e para a marca d'água inferior durante toda a chamada.

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode fixed
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay mode fixed
playout-delay nominal 70
!

Para obter mais detalhes sobre a configuração de retardo de playout, consulte Aprimoramentos de retardo de playout para Voz sobre IP.

Informações Relacionadas

• Implementando políticas de qualidade do serviço com DSCP
• Enfileiramento de latência baixa
• Comparando comandos de largura de banda e de prioridade de uma política de servidor de QoS
• Configurando a fragmentação e interfaceamento de link para Frame Relay e circuitos virtuais ATM
• Configurando a fragmentação e a intercalação de links para PPP multilink
• Suporte à Tecnologia de Voz
• Suporte aos produtos de Voz e Comunicações Unificadas
• Troubleshooting da Telefonia IP Cisco
• Suporte Técnico - Cisco Systems