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

Introduction

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.

Prerequisites

Requirements

Os leitores deste documento devem estar cientes destes:

• Configuração básica de Voz de Pacote (VoIP, Voz sobre Frame Relay (VoFR) ou Voz sobre 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 se aplicam 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. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

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 evento, o gateway de destino deve prever qual o conteúdo do pacote perdido pode ser. A previsão leva a que a voz recebida não tenha as mesmas características da 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 estejam muito atrasados (e mais que isso, não variavelmente atrasados). Às vezes, a detecção de atividade de voz (VAD - Voice Activity Detection) adiciona o recorte de front-end a uma conversação de voz. Esta é outra causa de voz cortada (ou cortada).

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

Requisito de largura de banda

Antes de considerar a aplicação de quaisquer medidas 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 sobre um link de 64 kbps porque pelo menos 16 kbps dos pacotes (que é 20%) são descartados. Os requisitos de largura de banda variam com base no codec usado para compactação. Codecs diferentes têm payloads e necessidades de cabeçalho diferentes. O uso do VAD também afeta o requisito de largura de banda. Se a compactação de cabeçalho (cRTP - Real Time Protocol) for usada, ela poderá reduzir ainda mais a exigência 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 é como esta:

• Carga útil de voz + compactado (cabeçalho RTP + cabeçalho UDP (User Datagram Protocol) + cabeçalho IP) +cabeçalho da camada 2

Isso equivale a:

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

Isso é igual a:

• 28 bytes, já que a compactação do cabeçalho reduz o cabeçalho IP RTP para 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. O segundo é priorizar o tráfego de voz interessante marcado. As duas subseções aqui discutem várias abordagens para classificação, marcação e priorização de 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 precisa ser feita o mais longe possível da 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 com base 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 do DiffServ define o campo DiffServ. Ele substitui o byte ToS no IP V4 para tomar decisões de Comportamento por Salto (PHB - Per-Hop Behavior) sobre a classificação de pacotes e funções de 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 análise dos campos de 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 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 Rede Interconectada = Precedência 6

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

• 100 = Substituição de 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 = Atraso [D] (0 = Normal; 1 = Baixa)

• Bit 4 = Produtividade [T] (0 = Normal); 1 = Alto)

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

00000XX 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 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 VoIP que corresponda ao comando dial-peer voice 100 voip tem todos os pacotes de payload de voz definidos com IP Precedence 5. Isso significa que os três bits mais significativos do byte ToS IP sã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 de VoIP que corresponda ao comando dial-peer voice 100 voip tem todos os pacotes de payload de mídia (pacotes de voz) definidos com o padrão de bits 101110 de encaminhamento expresso (EF). Todos os pacotes de sinalização são definidos com o padrão de bit AF 011010.

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. IP precedence 5 (101) mapeia para IP DSCP 101000. Para obter mais informações, consulte Classificando a sinalização e a mídia VoIP com o 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. Este é 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 CLI de 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 à Access Control List (ACL) 100 é classificado como "class voip" e definido com IP Precedence 5. Isso significa que os três bits mais significativos do byte ToS IP são definidos como 101. ACL 100 corresponde às portas UDP comuns usadas por 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 a precedência de IP 0. A política é chamada de "mqc". Ele é aplicado ao tráfego de entrada na Ethernet 0/0.

Priorizando

Depois que cada salto na rede é capaz de classificar e identificar os pacotes VoIP (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 pacotes de dados grandes não interfiram na transmissão de dados de voz. Geralmente, isso é necessário em links de WAN mais lentos, onde há uma grande possibilidade de congestionamento. Quando todo o tráfego interessante for colocado em classes de QoS com base em seus requisitos de QoS, forneça garantias de largura de banda e manutenção de prioridade através de um mecanismo de enfileiramento de saída inteligente. Uma fila de prioridade é necessária para VoIP.

Observação: use qualquer mecanismo de enfileiramento que efetivamente dê alta prioridade ao VoIP. No entanto, o LLQ (Low Latency Queuing, Enfileiramento de latência baixa) é recomendado porque é flexível e fácil de configurar.

O LLQ usa o método modular de configuração de CLI de QoS para fornecer prioridade a certas classes e para fornecer largura de banda mínima garantida para outras classes. Durante os períodos de congestionamento, a fila de prioridade é policiada na taxa configurada para que o tráfego de prioridade não use toda a largura de banda disponível. (Se o tráfego prioritário monopoliza 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 deve 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 que aguardam em qualquer fila de classe específica. Há também um comando class-default que é usado para determinar o tratamento de todo o tráfego não classificado por uma classe configurada. O class-default é configurado com um comando fair-queue. Isso significa que cada fluxo não classificado recebe uma parcela aproximadamente igual da largura de banda restante.

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

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" (ou seja, tráfego de voz). Ela recebe uma alta prioridade 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 conforme vista na lista de acesso 102) e garante 64 kbps. A classe data2 corresponde ao tráfego Telnet (porta TCP 23 como vista na ACL 103) e garante 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 "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 de prioridade para todas as classes precisam ser menores que 75% 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 deixam a 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 pesos são usados para determinar quantos pacotes são servidos de cada 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 da fila para cada fila. Portanto, ele fornece a largura de banda alocada estatisticamente.	Está disponível há alguns anos. Permite alocação aproximada de largura de banda para diferentes filas.	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 serviço prioritário.	O tráfego de prioridade mais alta sobrecarrega 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.	Não é possível efetuar serviços de prioridade.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 garantia de largura de banda 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 separados de largura de banda de prioridade superior durante o congestionamento. No entanto, o compartilhamento da fila de prioridade entre aplicativos pode potencialmente introduzir o jitter.4

1. Não é adequado para voz.

2. Precisa de largura de banda garantida para voz.

3. Precisa de latência para cuidar.

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 das classes de largura de banda garantidas devem ser servidos com base no peso configurado. Se um pacote de voz de prioridade chegar na fila de saída enquanto esses pacotes estão sendo servidos, o pacote de voz pode aguardar 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 apresentar a pior forma de instabilidade para pacotes de voz. Se os pacotes de voz tiverem que aguardar atrás de um pacote de dados que tenha o tamanho de 1500 bytes, em um link mais lento, isso se traduzirá em um grande atraso. O atraso de serialização é muito diferente se o pacote de dados for de 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 pode ter 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 deve 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 geralmente são 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. Qualquer pacote que tenha atraso de serialização superior a 10 ms precisa ser fragmentado em blocos de 10 ms. Um pedaço ou fragmento de 10 ms é o número de bytes enviados pelo link em 10 ms. Calcule o tamanho usando a velocidade do link, como 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 é de 128 kbps que requer 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 é 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 1.500 bytes, o tamanho do fragmento é de 1.920 bytes. Portanto, não é necessária nenhuma fragmentação. O tamanho da fragmentação do 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.

Existem atualmente três mecanismos de fragmentação e intercalação 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 Enlace (LFI - Link Fragmentation and Interleave)	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 do MTU de 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 pacotes IP com o bit Não Fragmentar (DF) não definido podem lidar bem com a fragmentação. Altamente com uso intenso do processador. Não recomendado.
LFI MLPPP	Em links seriais ponto a ponto, o MLPPP deve primeiro ser configurado e, em seguida, um tamanho de 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. As 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. Substitui essas lacunas por ruído de conforto (ruído de fundo). Assim, uma quantidade de largura de banda é salva. Entretanto, existe uma troca. Há pouco tempo (em ordem de milissegundos), antes que os codecs detectem a atividade de fala seguida de 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 para compensar o recorte, o VAD espera aproximadamente 200 ms após a parada da fala antes de parar a transmissão. Ao reiniciar a transmissão, ele inclui os 5 ms anteriores de fala junto com o discurso 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 limite inicial é decidido que rege 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 Milliwatt (dBm) a -30 dBm. O valor padrão para isso é -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). Configurar um valor mais alto (mais próximo de -30 dBm) faz com que o VAD se torne ativo mesmo para uma pequena queda na intensidade do sinal de voz. Ele faz com que o playout reproduza pacotes de ruído de conforto com mais frequência. No entanto, isso às vezes leva a pequenos recortes 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 em 250 ms, o ruído de conforto começa. O intervalo deste cronômetro é de 250 ms a 65536 ms. Se um valor alto for configurado para isso, o ruído de conforto será reproduzido muito mais tarde (o ruído de fundo continua sendo 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. O lado negativo para configurar o comando voice vad-time para um nível alto é que ele não atinge os 30 a 35% 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 é um link frame-relay ou um link PPP. Estes 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. Há um máximo de quatro chamadas de voz simultâneas em qualquer momento. Configure a fragmentação em ambos os PVCs com base na CIR do PVC de menor largura de banda (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 de 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). Há um máximo de quatro chamadas de voz simultâneas em qualquer momento. A tarefa de configuração envolve a configuração dessa interface serial com encapsulamento PPP, tornando-a parte de um grupo multilink, criando uma interface multilink (que pertence ao mesmo grupo multilink) e configurando toda a QoS na interface multilink. Para obter mais detalhes sobre a configuração de VoIP sobre PPP, consulte VoIP sobre links PPP com qualidade de serviço (LLQ / IP RTP Priority, 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

Há sempre algumas entidades não controladas em uma rede que contribuem para mais atrasos e instabilidade nos pacotes de voz recebidos. Ao modificar o buffer de jitter no gateway de terminação, o jitter não controlado é resolvido na rede de voz.

Mecanismo de playout

O buffer de instabilidade é um buffer de tempo. É 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 espera do buffer de jitter, 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 ocultá-lo (prevê o pacote perdido). Se o VAD estiver ativado, 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 manipulados pelo alinhamento temporal dos pacotes de voz filtrados, reprodução de ruído de conforto (se o VAD estiver configurado) ou ainda pela regeneração de tons de multifrequência de tom duplo (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 alta taxa de bits (32 kbps a 64 kbps) pode resultar potencialmente em um mau encobrimento de previsão. A ocultação da 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. Ela começa quando há atrasos altos e maior número de perda de pacotes. A ocultação de silêncio demais leva à qualidade de voz instável. 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 baixa são considerados pacotes iniciais (ainda podem ser reproduzidos a tempo).

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

Para obter mais detalhes sobre o buffer de jitter, consulte Entendendo o jitter em redes de voz de pacote (plataformas Cisco IOS).

Identificar atraso e instabilidade

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

show call active voice

O comando show call ative voice brief fornece uma grande quantidade de informações sobre uma conversação em andamento. Esta saída exibe alguns pontos importantes aprendidos deste 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ê vê que o que for recebido no trecho de Telefonia (rx:7044) é transmitido ao trecho IP (tx:7044). O mesmo vale para os pacotes recebidos nos trechos de IP (26165) que são encaminhados para o trecho de Telefonia (26157). A diferença no número de pacotes recebidos no trecho IP versus o número de pacotes transmitidos no trecho de Telefonia contribui para pacotes atrasados que não chegam no tempo.

Esta saída do comando show call ative voice (sem a palavra-chave "brief") aponta para mais detalhes sobre 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 ser consolado no gateway ou, se você for Telnet em um gateway, certifique-se de ter emitido o comando terminal monitor a partir do nível exec.

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

Nesta saída, o valor para Rx Delay Est (ms) é 71. Esse é o valor atual do buffer de jitter. A este respeito, deduz-se um valor para a marca de água elevada e a marca de água baixa. 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 se pode ver na saída aqui, as quedas de ocultação da previsão estão próximas a 250 ms, enquanto o encobrimento de silêncio é de 30 ms. Há sempre um valor maior para o encobrimento de previsões, já que o encobrimento de silêncio é apenas um cenário pior de encobrimento de Predição. Para cada queda de ocultação de prognóstico, existe um aumento no descarte de excesso de buffer.

Se você vir um descarte de buffer, isso não significa necessariamente que você veja um aumento na marca de água alta. A marca d'água alta é o limite superior do buffer de jitter. Ela só muda se for observada uma tendência. 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 de á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. Uma vez que não é um valor positivo, conclui-se que também não houve perdas 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 de exemplo, conclui-se que o telefone conectado a esse roteador geralmente permanece silencioso, pois você tem muitos pacotes de conforto Tx. Ao mesmo tempo, você não tem pacotes de conforto Rx, o que significa que a outra extremidade fala continuamente.

Compare a saída aqui com a saída do comando anterior. Há um número maior de Rx Pkts atrasados (de 14 para 26). No entanto, não há qualquer aumento do valor da marca de água. Isso indica que os 12 pacotes estão esporadicamente atrasados. O descarte de estouro de buffer é aumentado para 910 mseg. No entanto, como não se observa qualquer tendência, a elevada margem de água não é aumentada.

Na saída aqui, você tem um Rx Early Pkts: 3. Isso significa que um pacote chega muito antes de ser esperado. Como visto na saída aqui, o buffer de variação de sinal se estendeu para acomodar mais pacotes iniciais, reduzindo a marca de água baixa 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 variação de sinal em um gateway

As diretrizes de QoS abordadas neste documento tratam do problema de qualidade de voz instável ou deteriorada. A configuração do buffer de retardo de playout é uma solução alternativa para a implementação de QoS incorreta na rede. Use-o apenas como uma correção de fim de intervalo ou como uma ferramenta para solução de problemas e redução dos problemas de tremulação introduzidos na rede.

Modo de retardo de playout

O buffer de variação de sinal está configurado para o modo fixo ou para 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 variação de sinal espera que os pacotes cheguem dentro do intervalo de valores nominais. O valor nominal deve ser igual ou maior que o mínimo e igual ou menor que o máximo. O buffer 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 do atraso máximo de playout, de modo que ele não introduza um atraso indesejado na rede. Esta saída é um exemplo do buffer de jitter 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 o valor mínimo e máximo para playout-delay, ele é ignorado quando configurado para o modo fixo. Quando no modo fixo, o valor da marca de água alta ou o valor da marca de água baixa permanecem sempre constantes. 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 estimado recebido for próximo de 100 ms, é isso que a marca de água alta e a marca de água baixa estão definidas para toda a duração da 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 fragmentação e intercalamento de link 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

Histórico de revisões