Voz : Qualidade de voz

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

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice

VAD

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 ser conhecedors destes:

  • Configuração básica da voz de pacote de informação (VoIP, voz sobre o Frame Relay (VOFR) ou Voz sobre ATM (VoATM) conforme sua exigência).

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

Componentes Utilizados

A informação neste documento aplica a todos os ciscos voices gateways a versão de software e hardware.

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.

Convenções

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. Neste evento, o gateway de destino deve prever o que o índice do pacote faltado pode possivelmente ser. A previsão conduz à voz recebida que não tem as mesmas características que a Voz transmitida. Isto conduz a uma voz recebida que aquele soa robótico. 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. Com nada encher acima essa diferença na extremidade de recepção, o discurso transmitido é perdido parte de. Isto conduz à voz cortada. Muitas das edições da voz cortada são resolvidas certificando-se que os pacotes de voz não estão atrasados muito (e mais do que isso, atrasado não variavelmente). Às vezes, a detecção de atividade da Voz (VAD) adiciona o clipping de front end a uma conversação da Voz. Esta é uma outra causa (ou grampeado) da Voz agitado.

As várias seções neste documento mostram como minimizar o exemplo da voz cortada. A maioria destas medidas exigem a afirmação da introdução do tremor mínimo em sua rede de voz.

Requisito de largura de banda

Antes que você considere aplicar todas as medidas para o tremor de minimização, provision a suficiente largura de banda de rede para apoiar o tráfego de voz em tempo real. Por exemplo, uma chamada VoIP de G.711 de 80 kbps (64 payload dos kbps + encabeçamento de 16 kbps) soa deficiente sobre um link de KBPS 64 porque pelo menos 16 kbps dos pacotes (que é 20 por cento) são deixados cair. Os requisitos de largura de banda variam baseado no codec usado para a compressão. Codecs diferentes têm payloads e necessidades de cabeçalho diferentes. O uso do VAD igualmente afeta o requisito de largura de banda. Se a compressão de cabeçalhos do Real-Time Protocol (RTP) (cRTP) é usada, pode mais abaixar o requisito de largura de banda.

Por exemplo, a largura de banda exigida para uma chamada de voz usando o codec de G.729 (carga útil de byte do padrão 20) com cRTP, é como esta:

  • O payload de voz + comprimiu (encabeçamento do encabeçamento +IP do cabeçalho de RTP + do User Datagram Protocol (UDP)) o encabeçamento +Layer 2

Isto é equivalente a:

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

Isto iguala:

  • 28 bytes, desde que a compressão de cabeçalhos reduz o cabeçalho de 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 Voz da prioridade. O primeiro é de classificação e de marcação o tráfego de voz interessante. O segundo está dando a prioridade ao tráfego de voz interessante marcado. As duas subseções aqui discutem várias aproximações à classificação, marcando, e Voz da prioridade.

Classificação e marcação

A fim garantir a largura de banda para pacotes voip, um dispositivo de rede deve poder identificar os pacotes em todo o tráfego IP que corre através d. 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. Estes identificação e processo do agrupamento são chamados classificação. É a base para fornecer todo o QoS.

A classificação de pacote de informação pode ser utilização de processador. Consequentemente, a classificação precisa de ser tão distante feito para fora para a borda da rede como possível. 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. A classificação mais simples é atingida por meio de marcação ou de configuração do byte de ToS (Tipo de serviço) no cabeçalho de IP. Os três bit mais significativo do byte ToS são chamados bit de precedência 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).

Os Serviços diferenciados (DiffServ) são um novo modelo em que o tráfego é tratado por sistemas intermediários com as 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 .leavingcisco.com leavingcisco.com leavingcisco.com 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 de DiffServ define o campo do DiffServ. Substitui o byte ToS em IP V4 para fazer decisões do Per-Hop Behavior (PHB) sobre a classificação de pacote de informação e funções de condicionamento de tráfego tais como a medida, a marcação, dar forma, e policiar. Além do que os RFC previamente mencionados, o RFC 2597leavingcisco.com define as classes do 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 - T1 T0 CU do T2 T3 do P0 P2 P1

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

Campo do DiffServ - DS1 DS0 ECN ECN DS3 DS2 DS5 DS4

DSCP: seis bit (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 da rede interna = precedência 6

  • 101 = CRITIC/ECP = precedência 5

  • 100 = cancelamento 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 os bit 3, 4, 5 (DS2, DS1, DS0) são bit do atraso, da taxa de transferência, e da confiança.

  • 3 mordidos = [D] do atraso (0 = Normal; 1 = baixo)

  • 4 mordidos = [T] da taxa de transferência (0 = Normal; 1 = Alto)

  • Bit 5 = [R] da confiança (0 = Normal; 1 = Alto)

000000XX bit 6, 7: ECN

Estas duas seções discutem duas maneiras em que a classificação e marcação é feita.

Peers de Discagem de Voz para Classificar e Marcar Pacotes

Com Gateway Cisco VoIP, você usa geralmente dial peer da Voz para classificar os pacotes voip e para marcar os bit de precedência IP. Esta configuração mostra como marcar os bit de precedência IP:

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

No exemplo acima, toda a chamada VoIP que combinar o comando dial-peer voice 100 voip tem todos seus pacotes do payload de voz ajustados com Precedência IP 5. Isto significa que os três bit mais significativo do byte ToS IP estão ajustados a 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, toda a chamada VoIP que combinar o comando dial-peer voice 100 voip tem todos seus pacotes de carga úteis dos media (pacotes de voz) ajustados com padrão de bit 101110 do expedited forwarding (EF). Todos os pacotes da sinalização são ajustados com padrão de bit 011010 AF.

Nota: O comando ip qos dscp é apoiado desde o Software Release 12.2(2)T de Cisco IOS�. A Precedência IP está já não disponível no Cisco IOS Software Release 12.2T. Contudo, o mesmo é conseguido pelo comando ip qos dscp. A Precedência IP 5 (101) traça a 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 baseada em gabarito que separe a classificação da política. Isto permite que as características de QoS múltiplas sejam configuradas junto para classes múltiplas. Use um comando class-map classificar o tráfego baseado em vários critérios de verificação de repetição de dados e um comando policy-map determinar que necessidades de acontecer a cada classe. Aplique a política ao tráfego recebido ou enviado em uma relação emitindo o comando service-policy. Este exemplo de configuração mostra como usar o Modular QoS CLI 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, todo o tráfego que combinar o Access Control List (ACL) 100 é classificado como da “o voip classe” e o grupo com Precedência IP 5. Isto significa que os três bit mais significativo do byte ToS IP estão ajustados a 101. ACL 100 corresponde às portas UDP comuns usadas por VoIP. Similarmente tráfego de sinalização de H.323 dos fósforos do ACL 101 (porta 1720 do Transmission Control Protocol (TCP)). Todo tráfego restante é ajustado com Precedência IP 0. A política é chamada “mqc”. É aplicada ao tráfego de entrada no Ethernet0/0.

Priorizando

Depois que cada salto na rede pode classificar e identificar os pacotes voip (com a porta/informação de endereço ou através do byte ToS), aqueles saltos a seguir fornecem cada pacote voip o QoS exigido. Nesse ponto, configurar técnicas especiais fornecer filas de prioridade para certificar-se de que os grandes pacotes de dados não interferem com a transmissão dos dados de voz. Isto é exigido geralmente em uns links MACILENTOS mais lentos onde haja uma alta possibilidade da congestão. Uma vez que todo o tráfego interessante é colocado nas classes de QoS baseadas em seus requisitos de QoS, forneça garantias de largura de banda e serviço de prioridade através de um mecanismo de enfileiramento de saída inteligente. Uma fila de prioridade é necessária para VoIP.

Nota:  Use todo o mecanismo de filas que der eficazmente a alta prioridade de VoIP. Contudo, o Low Latency Queuing (LLQ) é recomendado porque é flexível e fácil configurar.

O LLQ usa o método de configuração do Modular QoS CLI para fornecer a prioridade a determinadas classes e para fornecer a largura de banda mínima garantida para outras classes. Durante períodos de congestionamento, a fila de prioridade é policiada na taxa configurada de modo que o tráfego de prioridade não se use acima de toda a largura de banda disponível. (Se o tráfego de prioridade monopoliza a largura de banda, impede que as garantias de largura de banda para outras classes estejam encontradas.) Se você provision o LLQ corretamente, o tráfego que entra na fila de prioridade deve nunca exceder a taxa configurada.

O LLQ igualmente permite que as profundidades de fila estejam especificadas para determinar quando o roteador precisa de deixar cair pacotes se há pacotes demais que esperam em toda a fila da classe particular. Há igualmente um comando class-default que seja 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. Isto significa que cada fluxo não classificado está dado uma parte aproximadamente igual da largura de banda remanescente.

Este exemplo mostra como configurar o LLQ. Para mais informação, refira o Enfileiramento da 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, todo o tráfego que combinar ACL 100 é classificado como da “o voip classe” (tráfego de voz do significado). É dado a uma alta prioridade até 32 kbps. ACL 100 corresponde às portas UDP comuns usadas por VoIP. O access-list 101 combina o tráfego de sinalização de H.323 (porta TCP 1720). Classifique o tráfego de web dos fósforos data1 (porta TCP 80 como visto na lista de acessos 102) e as garantias 64 kbps. Classifique o tráfego do telnet dos fósforos data2 (porta TCP 23 como visto no ACL 103) e as garantias 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”. É aplicada ao tráfego de saída no Serial1/0, que tem uma largura de banda total dos kbps 256.

Nota: À revelia, a largura de banda garantida e a largura de banda prioritária totais para todas as classes precisam de ser menos de 75 por cento da largura de banda de interface. Altere esta porcentagem emitindo o comando max-reserved bandwidth interface.

Esta tabela compara mecanismos de filas diferentes do software com seus benefícios e limitação respectivos.

Mecanismo de filas do 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 hashing que flua nas filas separadas onde os pesos são usados para determinar quantos pacotes são prestados serviços de manutenção em um momento. 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 de fila são calculados com base no tamanho médio do pacote, na unidade de transmissão máxima (MTU), e no porcentagem de largura de banda a ser atribuído. Os limites de fila (em número dos bytes) de-são enfileirados para cada fila. Consequentemente fornece a largura de banda atribuída estatisticamente. Esteve disponível por alguns anos. Permite a alocação de largura de banda aproximada para filas diferentes. Nenhum serviç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 alto, em médio, em normal, e filas de prioridade baixa. O tráfego de alta prioridade é atendido primeiro, seguido pelo de média, normal e baixa prioridade. Esteve disponível por alguns anos. Fornece o serviço de prioridade. Um tráfego mais prioritário morre de fome as filas de baixa prioridade da largura de banda. Nenhuma garantia de largura de banda é possible.2
Class-Based Weighted Fair Queuing (CBWFQ) 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. Nenhum serviço de prioridade é possible.3
Weighted Fair Queuing da fila de prioridade (PQ-WFQ), igualmente chamado 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 tráfego restante é tratado com o 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) O Modular QoS CLI com fila de prioridade é usado 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ê pode igualmente configurar classes garantidas largura de banda e uma classe padrão. Nenhum mecanismo para fornecer ainda níveis múltiplos da prioridade, todo o tráfego de prioridade é enviado através da mesma fila de prioridade. As classes de prioridade separadas podem ter limites superiores separados da largura de banda prioritária durante a congestão. Contudo, a partilha da fila de prioridade entre aplicativos pode potencialmente introduzir jitter.4

  1. Não apropriado para a Voz.

  2. Precisa a largura de banda garantida para a Voz.

  3. Precisa a latência de ser tomado de.

  4. Suficiente para a Voz.

Retardo de serialização

Mesmo se se enfileirar trabalha em seu melhor e dá a prioridade ao tráfego de voz, há as épocas em que a fila de prioridade está vazia e um pacote de uma outra classe está prestado serviços de manutenção. Os pacotes das classes da largura de banda garantida devem ser prestados serviços de manutenção basearam em seu peso configurado. Se um pacote de voz da prioridade chega na fila de saída quando estes pacotes estiverem prestados serviços de manutenção, o pacote de voz pode esperar uma quantidade significativa de tempo antes que esteja enviado. Os pacotes de voz passam por retardo na serialização quando têm de esperar por pacotes de dados maiores.

O retardo de serialização pode introduzir o pior formulário do tremor para pacotes de voz. Se os pacotes de voz têm que esperar atrás de um pacote de dados que seja tão grande como 1500 bytes, em um link mais lento, isto traduzem a um atraso enorme. O retardo de serialização é vastamente diferente se o pacote de dados é 80 bytes, segundo as indicações deste exemplo:

  • Retardo de serialização em um link de KBPS 64 devido a um pacote de bytes 1500 = a um 1500*8/64000 = Senhora 187.5.

  • Retardo de serialização em um link de KBPS 64 devido a um pacote 80bytes = a uma Senhora 80*8/64000 = 10.

Consequentemente, um pacote de voz potencialmente tem que esperar a Senhora até 187.5 antes que esteja enviado se obtém colado atrás de um único pacote 1500-byte em um link de KBPS 64. Por outro lado, um outro pacote de voz tem que esperar somente a Senhora 10 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 enviados geralmente a cada Senhora 20. 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.

Introduza um mecanismo de fragmentação que se assegure de que o tamanho de uma unidade de transmissão seja menos do que a Senhora 10. Alguns pacotes que tiverem mais do que a necessidade do retardo de serialização da Senhora 10 de ser fragmentado em pedaços da Senhora 10. Um pedaço ou um fragmento da Senhora 10 são o número de bytes que é enviado sobre o link na Senhora 10 calcula o tamanho usando a velocidade do link, segundo as indicações deste 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 há três PVC que têm uma largura de banda garantida de 512 kbps, de kbps 128, e de kbps 256, a seguir configurar todos os três PVC com um tamanho do fragmento de 160 bytes (a mais baixa velocidade é os kbps 128 que exige um tamanho do fragmento do 160-byte). Estes valores são recomendados para velocidades diferentes do link:

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

Nota: Não é exigida fragmentação se o tamanho da fragmentação for maior do que o tamanho do MTU do enlace. Por exemplo, para um link T1 com um 1500-byte MTU, o tamanho do fragmento é 1920 bytes. Consequentemente, nenhuma fragmentação é exigida. O tamanho da fragmentação de pacote de informação deve nunca ser mais baixo do que o tamanho de pacote voip. Não fragmente pacotes voip. A fragmentação destes pacotes causa diversos problemas de configuração e qualidade de chamada.

Há atualmente três mecanismos da fragmentação do link e da intercalação 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 alista seus benefícios e limitação:

Mecanismo do Link Fragmentation and Interleaving (LFI) Descrição Benefícios Limitações
Fragmentação de MTU com WFQ Comando interface level mudar o tamanho do MTU ou o tamanho do 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 remontam somente pelo aplicativo de recepção. Consequentemente, uso incapaz da rede. Somente os pacotes IP com não fragmentam (DF) mordido não ajustado podem segurar a fragmentação bem. Processador altamente intenso. Não recomendado.
LFI MLPPP Nos links do serial Point-to-Point, o MLPPP deve primeiramente ser configurado, a seguir um tamanho de fragmentação deve ser ajustado na Senhora que a intercalação deve igualmente ser permitida 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 o PPP sobre frame relay ou o PPP over ATM são apoiados igualmente no Cisco IOS Software Release 12.1(5)T ou Mais Recente.
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 típica da Voz consiste em 40 ao percentual de silêncio dos 50 pés. 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 VAD, o gateway olha para fora para diferenças no discurso. Substitui aquelas diferenças com o ruído de conforto (ruído de fundo). Assim, uma quantidade de largura de banda salvar. Entretanto, existe uma troca. Há uma estadia pequena (por ordem dos milissegundos), antes que os codecs detectem a atividade de discurso seguida em 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 curtos e compensar o grampeamento, o VAD espera a Senhora aproximadamente 200 depois que o discurso para antes que pare a transmissão. Em cima de reiniciar a transmissão, inclui a Senhora 5 precedente do discurso 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. Contudo, se a largura de banda não é uma edição, desligue o VAD.

Ajuste os parâmetros de VAD

Há dois parâmetros que ditam o funcionamento do VAD. Estes são os comandos music-threshold and voice vad-time.

music-threshold

Um limiar inicial está decidido que governe quando o VAD precisa de se tornar ativo. Isto é controlado definindo o comando music-threshold threshold_value em uma porta de voz, segundo as indicações deste exemplo. A escala para esta é de -70 decibéis por miliwatt (dBm) ao dBm -30. O valor padrão para este é o dBm -38. 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 perto do dBm -30) conduz ao VAD que torna-se ativo para mesmo uma gota pequena na força de sinal de voz. Conduz o playout para jogar mais frequentemente pacotes de ruído de conforto. Contudo, isto conduz às vezes à limitação menor do á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

Uma vez que o VAD se torna ativo, o componente do ruído de fundo e do ruído de conforto está controlado configurando o comando voice vad-time timer_value sob a configuração global, segundo as indicações deste 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. Isto significa que dentro de 250 milissegundos, o ruído de conforto começa. O intervalo deste cronômetro é de 250 ms a 65536 ms. Se um alto valor é configurado para este, o ruído de conforto entra o jogo muito mais tarde (o ruído de fundo continua a ser jogado). 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 downside a configurar o comando voice vad-time a um nível alto é que não consegue a economia de largura de banda desejada de 30 a 35 por cento.

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 estabelecer chamadas VoIP está sobre um Link do Frame Relay ou sobre um link de PPP. Estes são exemplos de configuração para estas encenações.

VoIPoFR - Exemplo da configuração de QoS

Neste exemplo (que contém somente seções relevantes da configuração), supõe-se que a velocidade de circuitos do Frame Relay é os kbps 256. 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 levar ambos os dados e Voz. O PVC 200 é usado para levar somente dados. Um máximo de quatro chamadas de voz simultânea existe a um momento determinado. Configurar a fragmentação em ambos os PVC baseados no CIR do baixo-largura de banda-Voz-PVC (Voz levando PVC). Baseado nos exemplos neste documento, esse significa que o tamanho de fragmentação está decidido com base no PVC 100's CIR (que é 64 kbps). Segundo as indicações da tabela da seção de retardo de serialização, para um link de KBPS 64, um tamanho de fragmentação de 80 bytes é exigido. O mesmo tamanho da fragmentação precisa ser configurado para PVC 200.

Para uns detalhes mais adicionais sobre a configuração do VOIP sobre o Frame Relay, refira o VOIP sobre o Frame Relay com Qualidade de Serviço (fragmentação, modelagem de tráfego, prioridade RTP LLQ/IP).

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

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

Neste exemplo (que contém somente seções relevantes da configuração), supõe-se que o QoS precisa de ser configurado para um controlador ponto a ponto do fracional T1 (de que tem doze canais). Um máximo de quatro chamadas de voz simultânea existe a um momento determinado. As tarefas de configuração envolvem configurar esta interface serial com o encapsulamento PPP, fazer-lhe parte de um grupo multilink, criar uma interface multilink (de que pertence ao mesmo grupo multilink), e configurar todo o QoS na interface multilink. Para uns detalhes mais adicionais sobre a configuração de VoIP sobre o PPP, refira VoIP sobre links de PPP com Qualidade de Serviço (prioridade RTP LLQ/IP, 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 controlada em uma rede que contribuem para mais retardo e tremulação nos pacotes de voz recebidos. Alterando o buffer do tremor no gateway de terminação o retardo de sincronismo não controlado é resolvido na rede de voz.

Mecanismo de playout

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

/image/gif/paws/20371/troubleshoot_qos_voice1.gif

Quando o controle de playout recebe um pacote de voz, ele analisa o selo de data/hora do RTP. Se o pacote de voz é atrasado além da capacidade de contenção do buffer do tremor, a seguir o pacote está deixado cair imediatamente. 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. No evento não há nenhum pacote de voz disponível, as tentativas do controle de playout para escondê-lo (prevê o pacote para fora faltado). Se o VAD é permitido, o ruído de conforto está jogado.

A responsabilidade do controle de playout é manejar os eventos de pacotes perdidos, duplicados, corrompidos ou fora de seqüência. Estes eventos são segurados no tempo que alinha os pacotes de voz tremidos, jogando o ruído de conforto (se o VAD é configurado), ou mesmo os tons multifrequency do tom dual da regeneração (DTMF) a ser jogados para fora ao 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). Trabalha melhor com os baixos codecs da taxa de bit (kbps 5 a 16 kbps). A perda de pacotes de voz para um codec de taxa de bit elevada (32 kbps a 64 kbps) pode potencialmente conduzir à prediction concealment deficiente. A prediction concealment começa quando há uns baixos e atrasos raros ou pouco número 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. Começa quando há uns atrasos altos e um mais número de perda de pacotes. Demasiada dissimulação do silêncio conduz à 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 que a marca d'água baixa esteja considerada pacotes adiantados (ele podem ainda ser jogados para fora no tempo).

Se o gateway de terminação continua a ver um incremento na chegada de pacotes atrasados, aumenta a marca d'água alta. Este valor para a marca d'água alta permanece o mesmo durante todo a duração do atendimento. Isto é aumentado até um máximo definido na configuração. De forma semelhante, o gateway de terminação observa o número de pacotes adiantados recebidos. Se estes pacotes começam frequentar o gateway, reduz a marca d'água baixa. Este valor permanece o mesmo durante todo a duração do atendimento. Este modo de buffer do tremor é referido como o “modo de adaptação,” onde o gateway de terminação adapta seu buffer do tremor baseado no teste padrão de tráfego. O outro modo é o “modo fixo". No modo fixo, há um valor inicial para a marca d'água baixa e a marca d'água alta. Este valor é baseado no retardo estimado recebido (veja a seção do <port-number> da chamada de voz da mostra deste documento).

Para uns detalhes mais adicionais no buffer do tremor, refira compreendendo o Jitter nas redes de voz de pacote de informação (plataformas do IOS da Cisco).

Identifique o retardo e tremulação

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

show call active voice

O comando show call ative voice brief dá muita informação sobre uma conversação contínua. Esta saída indica alguns pontos importantes que são instruídos 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

Da saída do comando show call ative voice brief, você vê que o que quer que é recebido no trecho de telefonia (rx:7044) é transmitido ao pé IP (tx:7044). O mesmo é verdadeiro para os pacotes recebidos nos pés IP (26165) que são enviados ao trecho de telefonia (26157). A diferença no número de pacotes recebidos no pé IP contra o número de pacotes transmitidos no trecho de telefonia é contribuída aos pacotes atrasados que não o fazem a tempo.

Esta saída do comando show call ative voice (sem a “breve” palavra-chave), pontos aos detalhes mais adicionais sobre os parâmetros que identificam diretamente o tremor.

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 ser consolado no gateway, ou se você é em telnet em um gateway, certifique-se de você ter emitido o comando terminal monitor do nível do executivo.

Nota: Este comando não está disponível nas plataformas AS5x00/AS5x50.

Nesta saída, o valor para o atraso Est RX (Senhora) é 71. Este é o valor de buffer atual do tremor. Um valor para a marca d'água alta e a marca d'água baixa é deduzido neste. 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 gotas da prediction concealment são próximas à Senhora 250, quando a dissimulação do silêncio for a Senhora 30. Há sempre um valor mais alto para a prediction concealment desde que a dissimulação do silêncio é somente um cenário de caso mais ruim da prediction concealment. Para cada queda de ocultação de prognóstico, existe um aumento no descarte de excesso de buffer.

Se você vê o buffer rejeitar, não significa necessariamente que você vê um aumento na marca d'água alta. A marca d'água alta é o limite superior do buffer do tremor. Muda somente se uma tendência é observada. Ou seja deve haver um fluxo contínuo de pacotes atrasados. Isto conduz a um aumento do buffer do tremor. Na saída aqui, tal tendência esta presente. Consequentemente, a marca d'água alta é aumentada de 70 milissegundos a 161 milissegundos. Se este valor não está mudado (e se você ainda vê 14 pacotes atrasados), implica que estes são pacotes atrasados esporádicos, não formando uma tendência.

Da saída do comando show call ative voice, olhe para fora para pacotes perdidos. Para cada pacote perdido, você vê dois pacotes que são fora da sequência. Isto é visto na saída RX NON-Segs. Pacotes. Desde que não é um valor positivo, conclui-se que não houve nenhuma perdas de pacotes tampouco.

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. Como das saídas de exemplo, conclui-se que o telefone conectado a este roteador mantém na maior parte o silêncio desde que você tem lotes de pacotes do conforto de Tx. Ao mesmo tempo, você tem os pacotes zero do conforto RX, assim que significa que a outra extremidade fala continuamente.

Compare a saída aqui com a saída precedente do comando. Há um número aumentado de pacotes atrasados RX (14 a 26). Contudo, não há nenhum incremento no valor de high water mark. Isto indica que os 12 pacotes estão atrasados esporadicamente. O descarte de sobrefluxo de buffer é aumentado a 910 msecs. Contudo, desde que não há nenhuma tendência observada, a marca d'água alta não é aumentada.

Na saída aqui, você tem pacotes adiantados RX: 3. Isto significa que um pacote chega muito antes que se esteja esperado. Como considerado da saída aqui, o buffer do Jitter esticou-se para acomodar para any more pacotes adiantados reduzindo a marca d'água baixa de 60 a 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 do Jitter em um gateway

As diretrizes QoS cobertas neste documento tomam da questão de qualidade de voz agitado ou deteriorada. A configuração do buffer de retardo de playout é uma solução de implementação imprópria de QoS na rede. Use somente isto como um reparo transitório ou como uma ferramenta para pesquisar defeitos e reduzir para baixo dos problemas de atraso de sincronização introduzidos na rede.

Modo de retardo de playout

O buffer do tremor é configurado para o modo fixo ou o modo de adaptação. 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 do tremor espera os pacotes chegar 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 expande até o valor máximo configurado. Isto pode estender até 1700 milissegundos. Um problema com a configuração do valor máximo é a introdução do atraso ponto a ponto. Escolha o valor do playout-atraso máximo tais que não introduz atraso indesejável na rede. Esta saída é um exemplo do buffer do tremor configurado para o modo de adaptação:

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 que você configure o mínimo e o valor máximo para o playout-atraso, é ignorado quando configurado para o modo fixo. Quando no modo fixo, o valor de high water mark ou o valor da marca d'água baixa permanecerem sempre constante. Ele se baseia no valor nominal e no valor Rx Delay Est (ms). Assim é possível que sob o modo fixo, você configura o AS200 milissegundo do valor. Contudo, se o retardo estimado recebido é próximo à Senhora 100, que é o que a marca d'água alta e a marca d'água baixa são ajustadas para à duração inteira do atendimento.

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.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 20371