Compreendendo a tremulação em redes de voz de pacotes de informações (plataformas IOS da Cisco)

Introduction

Este documento descreve a variação de sinal e como medir e compensá-la.

Prerequisites

Requirements

Os leitores deste documento devem estar cientes destes tópicos:

• Configuração de voz básica do Cisco IOS®

• Compreensão básica da Qualidade de serviço (QoS, Quality of Service)

Componentes Utilizados

As informações contidas neste documento se aplicam aos roteadores e gateways de voz do Cisco IOS.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Tremulação nas Redes de voz de pacote de informação

O Jitter é definido como uma variação no atraso dos pacotes recebidos. No lado de envio, os pacotes são enviados em um fluxo contínuo com os pacotes espaçados com uma distância uniforme. Devido ao congestionamento da rede, ao enfileiramento impróprio ou aos erros de configuração, este fluxo constante pode tornar-se irregular ou o atraso entre cada pacote pode variar, em vez de permanecer constante.

Este diagrama ilustra como um fluxo contínuo de pacotes é tratado.

Quando um roteador recebe um fluxo de áudio do Real-Time Protocol (RTP) por meio de Voz sobre IP (VoIP), ele deve compensar a flutuação encontrada. O mecanismo que lida com essa função é o buffer de atraso de playout. O buffer de atraso de playout deve fazer o buffer desses pacotes e então colocá-los em um fluxo constante para os processadores de sinal digital (DSP, Digital Signal Processor) para serem convertidos de volta a um fluxo de áudio analógico. O buffer de retardo de playout também é chamado às vezes de buffer de controle de variação de sinal.

Esse diagrama ilustra como a tremulação é controlada.

Se o jitter for tão grande que faz com que os pacotes estejam recebidos fora do alcance do buffer, os pacotes fora de alcance serão descartados e as saídas serão ouvidas no áudio. Para as perdas tão pequenas quanto um pacote, o DSP fará a interpolação do que ele acredita ser o áudio e nenhum problema ficará audível. Quando a variação excede o que o DSP pode fazer para compensar os pacotes ausentes, pode-se perceber problemas de áudio.

Esse diagrama ilustra como o excesso de tremulação é controlado.

Determinar a severidade do Jitter

A presença de jitter excessivo pode ser confirmada pelo Cisco IOS através das seguintes etapas.

1. Assim que uma chamada for feita e estiver ativa e houver suspeita de variação de sinal, faça Telnet para um dos gateways envolvidos.

2. Habilite o Monitor do terminal para poder ver as mensagens do console através da seção Telnet.

   Observação: esta etapa não é necessária se você estiver conectado à porta do console.

3. Insira o comando show voice call summary. Aparece uma saída semelhante a esta:

   PORT         CODEC    VAD VTSP STATE            VPM STATE
   	============ ======== === ==================== ======================
   	1/0/0         -         -  -                     FXSLS_ONHOOK             
   	1/0/1         g729r8    y  S_CONNECT             FXSLS_CONNECT     

   Selecione a chamada onde há variação de sinal. Neste exemplo, ele é 1/0/1.

4. Para observar esta chamada específica, digite o comando show voice call.

   Neste exemplo, ela é show voice call 1/0/1. A saída gerada vem do DSP que processa a chamada e é semelhante a isto:

   1/0/1 vtsp level 0 state = S_CONNECT
   	vpm level 1 state = FXSLS_CONNECT
   	vpm level 0 state = S_UP
   
   	MS-2621-3B#     ***DSP VOICE VP_DELAY STATISTICS***
   	Clk Offset(ms): 0, Rx Delay Est(ms): 50
     	Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7 
   
   		***DSP VOICE VP_ERROR STATISTICS***
   	Predict Conceal(ms): 0, Interpolate Conceal(ms): 0
   	Silence Conceal(ms): 0, Retroact Mem Update(ms): 0
   	Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0
           						
   		***DSP VOICE RX STATISTICS***
   	Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
   	Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0
   	Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
   	Rx Early Pkts: 0, Rx Late Pkts: 0
           ***DSP VOICE TX STATISTICS***
   	Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0
   	Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0
           ***DSP VOICE ERROR STATISTICS***
   	Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0
           ***DSP LEVELS***
   	TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone
   	TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9
   	TDM Bgd Levels(dBm0): -49.4, with activity being voice

5. Veja a seção ***DSP VOICE VP_ERROR STATISTICS*** na saída do comando.

   Nesta seção, há vários parâmetros a serem analisados. O principal será o número de Buf Overflow Discard (ms) que forem observados. Ele conta os pacotes que estão fora do intervalo para o buffer de retardo de playout (descartados). Esse número pode ser válido, desde que não aumente sempre. É normal obter alguns excessos quando uma chamada for iniciada pela primeira vez, mas esse valor não deverá aumentar quando o comando show voice call X/X/X for repetido. Este número é uma indicação direta de atraso de sincronismo excessivo.

   Por padrão, esse buffer executa em um modo de adaptação onde se ajusta dinamicamente à quantidade de jitter presente (até certo ponto). Configure o comando playout-delay para alterar os padrões do comportamento dinâmico do buffer de não jitter. Esse buffer também pode ser definido no modo fixo. É possível que isso corrija alguns problemas de variação de sinal.B943 Para obter mais informações, consulte Aprimoramentos do atraso de playout para VoIP.

O que causa tremulação?

O Jitter é causado geralmente pelo congestionamento na rede IP. O congestionamento pode ocorrer nas interfaces do roteador ou em um provedor ou rede da portadora se o circuito não foi fornecido corretamente.

Considerações sobre encapsulamento

O lugar mais fácil e melhor para começar a procurar o jitter se encontra nas interfaces do roteador, já que você possui controle direto sobre essa parte do circuito. Como você monitora a fonte do jitter depende muito do encapsulamento e do tipo de link em que ele acontece. Em geral, os circuitos ATM não apresentam tremulação quando estão configurados corretamente devido à taxa de célula constante envolvida. Isto resulta em uma latência muito consistente. Se o jitter for visto em um ambiente de ATM, o exame da configuração de ATM será necessário. Quando o ATM funciona corretamente (nenhuma célula descartada), pode-se esperar que o jitter não seja uma questão. No encapsulamento do Protocolo ponto-a-ponto (PPP, Point-to-point Protocol), o jitter é quase sempre devido ao atraso da serialização. Isso pode ser facilmente gerenciado com fragmentação de enlace e intercalação do enlace PPP. A natureza do PPP significa que os pontos de extremidade do PPP falam diretamente um com os outros, sem que haja uma rede de switches entre eles. Isto ocorre de modo que o administrador de rede tenha o controle sobre todas as interfaces envolvidas.

Tremulação em um ambiente de Frame Relay

Três parâmetros precisam ser abordados para localizar o jitter em um ambiente de Frame Relay.

• Modelagem de tráfego

• Fragmentação

• Enfileiramento

Para exemplos de configurações e informações relacionadas a essa configuração, consulte VoIP pelo Frame Relay com qualidade de serviço.

Modelagem de tráfego

É preciso assegurar a modelagem do tráfego que sai do roteador para a Taxa de informação comprometida (CIR) real fornecida pela portadora. Verifique isso observando as estatísticas do Frame Relay e verifique com a portadora. O primeiro lugar a observar são as estatísticas de Frame Relay. Utilize o comando show frame-relay pvc xx, em que xx é o número identificador de conexão de enlace de dados (DLCI). Você deverá receber saída semelhante a esta:

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1

 input pkts 103611    output pkts 120054    in bytes 9909818
 out bytes 10962348    dropped pkts 0      in FECN pkts 0
 in BECN pkts 0       out FECN pkts 0     out BECN pkts 0
 in DE pkts 0        out DE pkts 0
 out bcast pkts 1366    out bcast bytes 448048
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 pvc create time 22:45:57, last time pvc status changed 22:45:57
 Queueing strategy: weighted fair
 Current fair queue configuration:
  Discard Dynamic Reserved
  threshold queue count queue count
  64   16   0
 Output queue size 0/max total 600/drops 18303
 fragment type end-to-end fragment size 1600
 cir 20000 bc 1000 be 0 limit 125 interval 50
 mincir 20000 byte increment 125 BECN response no IF_CONG no
 frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120
 shaping active
 traffic shaping drops 18303

Consulte a descrição do comando show frame-relay pvc para obter uma explicação completa sobre todos os campos.

O que procurar

A sua preocupação na saída do comando deve se limitar aos valores exibidos se tiver ocorrido um congestionamento na rede de quadros. Esses valores são os parâmetros de notificação de congestionamento explícito de encaminhamento (FECN, Forward Explicit Congestion Notification), da notificação de congestionamento explícita retrógrada (BECN, Backward Explicit Congestion Notification) e do elegível de descarte (DE, Discard Eligible). Você deve se preocupar somente com os pacotes de entrada, já que a Cisco não envia nenhum desses. Você pode ver um ou mais dos aumentos desses valores. Isso depende do tipo e da configuração dos switches de frame que o fornecedor utiliza. Em termos gerais, se você tiver o tráfego do Frame Relay em desenvolvimento e estiver configurado para o mesmo CIR que o circuito, nunca deverá ver o aumento desses valores. Se você vir que esses valores aumentam e combinar o CIR verdadeiro do circuito, algo na rede do fornecedor do frame não está configurado corretamente.

Um bom exemplo disso é se você adquirir um circuito CIR zero, mas tiver um valor de intermitência. Alguns provedores vendem o circuito virtual permanente (PVC) CIR zero. Isso é adequado para dados, mas causa problemas de qualidade de voz. Se você observar a saída do comando de um circuito CIR zero, o número de pacotes DE ou FECN é igual ao número de pacotes de entrada. Para avançar mais um pouco, se você tiver um PVC que é fornecido pela portadora como tendo 128 kbs e o CIR do roteador estiver definido a 512 kbs, você verá esses contadores aumentarem (a uma taxa mais lenta). Lembre-se que você está observando somente os pacotes que entram na interface do roteador e que essa taxa é controlada pelos parâmetros do desenvolvimento do tráfego configurados no roteador na extremidade oposta do PVC. Ao contrário, você controla o que é inserido no outro roteador pelo qual os parâmetros de desenvolvimento do tráfego são configurados na extremidade local.

É muito importante que você não ultrapasse o CIR para o PVC que é fornecido pela portadora. É possível estar abaixo desse CIR sem ter problemas. Porém, se você o ultrapassar, observará o congestionamento.

A razão pela qual você pode ver o congestionamento desta maneira é porque o CIR que está configurado para um PVC específico em um switch de frame dita a taxa na qual o tráfego será passado pelo switch em questão (para esse PVC). Quando o CIR configurado no switch do frame for ultrapassado pela taxa de dados real que recebe, ele deverá fazer o buffer dos frames que ultrapassarem o CIR até que a capacidade esteja disponível para encaminhar os pacotes que sofreram buffer. Os pacotes que sofrerem buffer obtêm tanto o conjunto de bits de DE ou o conjunto de bits FECN pelo switch do frame.

Como sempre, você também deseja examinar as estatísticas da interface e procurar descartes ou erros para ter certeza de que tudo funciona corretamente na camada física. Para fazê-lo, use o comando show interface.

A relação com o jitter é que, se isso ocorrer, e alguns pacotes precisarem sofrer buffer na rede do frame, eles terão uma latência mais longa para chegar ao roteador remoto. Entretanto, quando não houver congestionamento, eles passarão pelo tempo de latência que você normalmente espera. Isso causa uma variação no tempo delta entre os pacotes recebidos no roteador remoto. Desse modo, o jitter.

Fragmentação

A fragmentação se associa mais ao atraso de serialização do que ao jitter. Porém, sob certas condições, ela pode ser a causa do jitter. A fragmentação deve sempre ser configurada na classe de mapa do Frame Relay ao realizar o empacotamento de voz. A configuração deste parâmetro tem dois efeitos na interface. O primeiro efeito é que todos os pacotes maiores do que o tamanho especificado serão fragmentados. O segundo efeito é menos aparente mas tão importante quanto o outro. Se você observar a interface na qual a fragmentação está configurada, poderá ver o efeito desse comando. Sem a fragmentação, a estratégia de queueing mostrada na saída do comando show interface x mostra que o queueing FIFO está sendo utilizado. Uma vez que a fragmentação seja aplicada à classe de mapa do Frame Relay, a saída desse comando mostrará a estratégia de queueing como FIFO duplo. Isso cria a fila de prioridade utilizada para o tráfego de voz na interface. Recomenda-se que o valor de fragmentação seja definido aos valores aconselhados na seção Fragmentação do documento VoIP pelo Frame Relay com QoS. Se você ainda tiver problemas de jitter no valor recomendado, abaixe o valor de fragmentação em uma etapa de cada vez até que a qualidade de voz se torne aceitável.

Enfileiramento

Existem dois métodos de enfileiramento geralmente aceitos que são utilizados para tráfego de VoIP neste tipo de ambiente:

• IP RTP Priority Queueing

• Enfileiramento de latência baixa

Deve ser usado e configurado apenas um dos métodos. Se a operação de queueing parecer correta de acordo com a documentação, você poderá concluir que o queueing funciona corretamente e que o problema está em outra parte. O queueing geralmente não é uma causa de jitter, uma vez que as variações no atraso criado por ele são relativamente pequenas. Entretanto, se os pacotes VoIP não ficam enfileirados corretamente e se houver dados no mesmo circuito, poderá haver jitter.

Conclusão

O Jitter é uma variação na latência de pacote para pacotes de voz. Os DSPs dentro do roteador podem compensar parte da tremulação, mas podem ser superados por uma tremulação excessiva. Isso leva à pouca qualidade de voz. A causa deste jitter é que um pacote foi enfileirado ou atrasado em algum lugar do circuito, onde não houve atraso nem enfileiramento de outros pacotes. Isso causa uma variação na latência. O Jitter pode ser causado pelo erro de configuração do roteador e pelo erro de configuração do PVC por parte da portadora ou do fornecedor.

Informações Relacionadas

• Suporte à Tecnologia de Voz
• Suporte aos produtos de Voz e Comunicações Unificadas
• Troubleshooting da Telefonia IP Cisco
• Suporte Técnico - Cisco Systems