TelePresence : Telefone IP Cisco Unified 7900 Series

Usando a Informação de Status 79xx para Troubleshooting

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


Índice


Introdução

Este documento centra-se sobre a informação de status que todos os Telefones IP de Cisco 79xx fornecem em seu indicador para pesquisar defeitos problemas. Esta informação pode ser usada para determinar o tipo de codec no uso para um atendimento em andamento. Igualmente fornece a informação em tempo real nas características de desempenho para um atendimento em andamento.

Antes de Começar

Convenções

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

Pré-requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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.

Exibição

O indicador do Cisco IP Phone 79xx pode ser utilizado para propósitos de Troubleshooting através do botão da informação (i) no telefone ao Exibir informação em um atendimento em andamento. Pressione este botão duas vezes durante uma chamada ativa para ativar esta característica.

/image/gif/paws/7415/telecaster-trouble_8.gif

Nota: “Eu” abotoo olhares como este /image/gif/paws/7415/telecaster-trouble_9.gif.

Este menu fornece a informação seguinte:

  • RxType/TxType — Os codecs utilizados atualmente na conversação atual da voz ativa.

  • RxSize/TxSize — O tamanho do payload dos codecs, neste caso 20 milissegundos da Voz/pacote.

    Nota: O apoio dos Telefones IP 79xx MGCP somente um tamanho de virulência de 10-40 milissegundo.

  • RxCount/TxCount — Uma quantidade de pacotes enviados/recebidos.

  • AvgJtr — O tremulação média é o tremulação média calculado observado nos últimos 16 pacotes RTP (a função de cálculo da média é apenas um filtro de passagem baixa simples).

  • MaxJtr — O tremulação máxima é o tremulação máxima visto durante a vida do RTP recebe o córrego. Recorde que isto não se realiza para a vida do atendimento, mas para o córrego. Se você põe uma pessoa sobre a posse, o córrego parte e precisa de ser reiniciado e daqui valores novos aqui.

  • RxDisc — O número de pacotes rejeitou de entrada neste Cisco IP Phone 79xx.

  • RxLost — O número de pacotes que não chegaram de entrada neste Cisco IP Phone 79xx.

Coisas a focalizar sobre para pesquisar defeitos:

  • O RxType/TxType diz-lhe que codec está sendo usado para a conversação entre este telefone IP e o outro dispositivo. Veja se combinam em ambos os lados. Se não combinam, verifique que o outro dispositivo pode segurar a conversação do codec ou que um transcodificador é no lugar segurar o serviço.

  • O tamanho dos exemplos de som deve combinar em ambos os dispositivos. Isto é encontrado nos campos RxSize/TxSize.

  • O RxCount/TxCount é útil para pesquisar defeitos pacotes descartado, problemas de uma Voz da maneira, e detecção de atividade da Voz (VAD).

Tremulação

No mundo da Voz, o tremor relaciona-se à diferença inter dos pacotes na rede. Idealmente, os pacotes de voz devem ser recebidos synchronously com (mas não demasiado por muito tempo) um atraso constante. Infelizmente, a maioria de redes entregam pacotes de voz assincronamente. Ou seja há uma variação no tempo entre pacotes de voz. Isto é referido como o tremor. Quando o tempo entre pacotes de voz (tremor) varia além dos bufferes de playout no dispositivo receptor, o número chamado ouvirá diferenças no fluxo de voz.

Em um mundo ideal, um córrego dos pacotes que contêm a Voz chegaria no dispositivo final (número chamado) com exatamente o mesmo valor da lacuna inter-pacotes. Isto conduziria a um valor do tremor de 0. No mundo real, a diferença entre pacotes de voz pode variar do pacote ao pacote que introduz o tremor na sequência.

Para lidar com esta edição, os telefones 79xx contêm um first in, a fila do first-out (FIFO, primeiro a entrar, primeiro a sair) (FIFO) que atua como um buffers de pacotes elástico. Tenta manter o fluxo dos pacotes de voz ao DSPs constantes jogando para fora os pacotes com uma lacuna inter-pacotes constante. Isto ajuda a assegurar a Qualidade de voz aceitável. O buffer do tremor 79xx segurará até dois segundos do tremor. O Jitter é medido na Senhora.

Se a lacuna inter-pacotes de um fluxo de voz de entrada varia entre 0 Senhoras e 2 s, o buffer FIFO 79xx's poderá mascarar esta variação e nenhuma diferença no fluxo de voz de entrada será detectada pelo número chamado. Por outro lado, se um fluxo de voz de entrada experimenta uma lacuna inter-pacotes além de 2 s, o buffer FIFO 79xx's terá sido drenado ao esperar o pacote de voz seguinte. Abre nesta situação no fluxo de voz será detectado. Isto é explicado com maiores detalhes abaixo.

No exemplo abaixo de cada pacote tem exatamente o mesmo valor do atraso entre ele e o próximo pacote na sequência. Neste caso o valor de atraso constante entre os pacotes (Senhora 5) conduz a um valor do tremor de 0.

/image/gif/paws/7415/telecaster_trouble_1.gif

Em uma situação da rede real o atraso do entre pacote é raramente constante:

/image/gif/paws/7415/telecaster_trouble_2.gif

Enquanto um córrego dos pacotes de voz passa através dos bufferes de todo o Roteadores e Switches que existirem entre a fonte e o destino, as diferenças são introduzidas entre os pacotes. Estas diferenças variarão em tamanho porque a carga no Roteadores e no Switches entre a fonte e o destino estará mudando constantemente.

No diagrama acima nós podemos ver a escala da lacuna inter-pacotes de 5 a 14 ao 10. Os dispositivos finais na rede (Telefones IP neste caso) têm que compensar estas variações de modo que os pacotes sejam jogados para fora ao ouvinte (número chamado) em uma taxa constante. Isto exige que os bufferes FIFO têm sempre os pacotes de voz disponíveis para jogar para fora.

O tamanho de um buffer FIFO 79xx's varia baseado na quantidade de tremor experimentada no fluxo de voz de entrada. Se o valor do tremor de um fluxo de voz de entrada é baixo, o 79xx usará um buffer FIFO menor do que quando o o valor do tremor de um fluxo de voz de entrada é alto. É possível contudo, isso que a taxa de alteração no valor do tremor será mais rápida do que o 79xx pode lidar com. Neste caso, o ouvinte (número chamado) experimentará uma breve diferença no fluxo de voz quando o 79xx ajustar seu tamanho de buffer FIFO.

Nota: O Cisco IP Phone 79xx aumenta o tamanho de buffer FIFO rapidamente e diminui-o lentamente.

O tamanho do buffer FIFO tem um efeito direto no atraso entre um pacote de voz que está sendo enviado e que está sendo recebido pelo destino. Enquanto o buffer FIFO cresce maior, o atraso em uns pacotes moventes fora do buffer FIFO aumenta. Veja a próxima seção no atraso para obter mais informações sobre deste assunto.

O seguinte diagrama mostra um buffer FIFO que remove o tremor de um fluxo de voz de entrada.

telecaster_trouble_3.gif

Se você está experimentando as diferenças em suas chamadas de voz (entalhes) verificam os valores de AvgJtr e de MaxJtr. Se, por exemplo, o valor do tremulação média é 5 e o valor do tremulação máxima é 3000, há uma possibilidade de um problema porque a variação entre os dois valores é muito alta. Se isto aconteceu rapidamente, não pôde ter havido bastante tempo para que a fila de FIFO 79xx's compense. Este tipo de comportamento pode ser encontrado nas redes que têm altas taxas periódicas de atividade tais como grandes atualizações da tabela de roteamento ou transferências de arquivo de lote. Nesses casos as cargas de tráfego vão de baixo ou de médio a elevado e de traseiro outra vez muito em um período de tempo curto.

Nota: O Cisco IP Phone 79xx pode tipicamente segurar até 20 por cento de perda de pacotes sem degradação de qualidade visível.

Retardo

O atraso é a quantidade de tempo que toma um pacote de voz (ou o fluxo de voz) para viajar da fonte ao destino. Na maioria dos casos o atraso variará no curso de um fluxo de voz (conversação). Em uma rede corretamente ajustada, o atraso máximo entre o tempo onde uma chamada originada fala e o número chamado ouve-se que o que foi dito é menos do que o que a pessoa média pode detectar. Ou seja não há nenhum atraso perceptível na conversação - as palavras são ouvidas assim que forem faladas.

Em alguns casos o atraso através da rede aumentará a um nível que seja detectável pelo ouvido humano. Em um cenário do pior caso a conversação deteriorar-se-á ao ponto onde cada pessoa tem que indicar que pararam o discurso de modo que a outra pessoa saiba que podem falar sem ser interrompida pelos pacotes de voz que não foram recebidos ainda. Se você é familiar com os Ethernet você pôde chamar este comportamento um colisão atrasada.

Todas as redes impõem algum atraso na transmissão de pacotes da fonte ao destino. Mesmo uma rede com uma lacuna inter-pacotes constante de < 1ms experimentará algum atraso no tempo entre quando um dispositivo de origem envia um pacote e o dispositivo de destino o recebe. Os enlaces serial da velocidade lenta (64K e abaixo) criam mais atraso do que um link de alta velocidade tal como um OC12 devido ao tempo onde tome para fabricar os bit no meio de transmissão.

As variações no atraso são causadas pelas mesmas situações que conduzem às lacunas inter-pacotess longas como descrito na seção no tremor acima. No caso do atraso, contudo, as causas duram tipicamente mais por muito tempo do que alguns pacotes de voz. Em vez de causar um aumento na lacuna inter-pacotes para alguns pacotes em uma conversação, estes problemas afetam conversações inteiras.

Nota: O Cisco IP Phone 79xx não fornece um contador do atraso. O atraso pode ser medido por analisadores de rede e por outros dispositivos de gerenciamento de rede.

Os Problemas secundários de retardo não afetam a Qualidade de voz tão ruim como o tremor pode. Isto é porque o tremor pode causar rupturas no fluxo de voz onde as palavras dita inteiras podem ser perdidas, visto que com atraso, todas as palavras dita chegarão eventualmente. Em outras palavras o tremor é muito similar à perda de pacotes em uma rede subscrita excedente - os pacotes sobre fluem os bufferes da relação e obtêm deixados cair, assim que significa que nunca chegam no destino.

O diagrama abaixo mostra o efeito combinado do atraso com tremor, que vão em conjunto. Os pacotes são transmitidos em uma taxa constante. A rede IP não envia os pacotes como rapidamente ou consistentemente, que conduziu às lacunas inter-pacotess maiores e variadas. Além, o quarto pacote está ainda em algum lugar na rede.

telecaster_trouble_6.gif

O retardo cumulativo em uma rede depende do quanto o roteador e comuta seu tráfego precisa de passar completamente entre a fonte e o destino de toda a conversação.

Em um ambiente IP, uma maneira de medir o atraso seria usar a ferramenta do traceroute, mas esta trabalhará somente para saltos do roteador. Além, alguns anfitriões que apoiam o traceroute executam-no em uma prioridade do CPU muito baixa, que ajude durante um ataque de recusa de serviço (DOS). Isto significa que há um atraso imposto da parte do CPU que será adicionado ao tempo que os pacotes tomaram para ir de um salto a outro. Em outras palavras - não coloque muita fé nos números relatados pelo traceroute.

Há as ferramentas de análise de rede da terceira que podem enviar pacotes e medida do atraso para baixo ao nanossegundo. São muito úteis para testar protótipos do projeto de rede sob circunstâncias carregadas antes de executá-las. Deve-se notar contudo que uma rede de voz robusta, bem-desenvolvida e ajustada não deve ter problemas consistentes do retardo e tremulação.

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: 7415