Voz e comunicações unificadas : Cisco Unified Communications Manager (CallManager)

Manual de Troubleshooting de Cisco IP Telephony para o Cisco CallManager Release 3.0(x)

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


Índice


Introdução

Este guia de Troubleshooting descreve as ferramentas e utilitário usadas para configurar, monitorar, e pesquisar defeitos gateways e porteiro do ½ do ¿  da revisão do CallManager da Cisco 3.0(1), do Cisco IOSïÂ. Este documento fornece exemplos detalhados de três fluxos de chamadas diferentes e estudos de caso são fornecidos para explicar melhor os conceitos.

Nos primeiros Casos Práticos, um Cisco IP Phone chama um outro Cisco IP Phone dentro de um conjunto (chamada de intra-grânulo). Nos segundos Casos Práticos, um Cisco IP Phone chama através de um Cisco IOS gateway a um telefone conectado com um PBX local ou na rede telefônica pública comutada (PSTN). Nos terceiros Casos Práticos, um Cisco IP Phone chama um outro Cisco IP Phone em um cluster diferente (chamada inter-grânulo).

Uma vez que você compreende o fluxo de chamadas e debuga traços, será mais fácil isolar um problema e determinar que componente está causando o problema. Este documento descreve as ferramentas disponíveis para pesquisar defeitos problemas potenciais. Igualmente descreve como os rastreamentos de chamada e os resultados do debug podem o ajudar a compreender fluxos de chamadas e série de eventos.

Caso você dever contactar o centro de assistência técnica da Cisco (TAC), muitas das ferramentas explicadas aqui serão instrumentais em recolher os dados exigidos pelo TAC. A definição de problema será mais rápida se você tem recolhido já estes dados antes de chamar o TAC.

Pré-requisitos

Requisitos

Use a seguinte lista de verificação para ter certeza que você tem a documentação apropriada em sua topologia de rede.

  • Topologia que mostra todos os dispositivos de rede e componentes críticos com a porta/números de interface a que são anexados e a ao que VLAN pertencem (se aplicável). As designações especiais devem ser usadas para as portas que reagem do entroncamento ou o modo de canalização.

  • A raiz da medir-árvore deve ser configurada e todas as portas deobstrução devem ser identificadas.

  • Todos os circuitos MACILENTOS devem ser identificados com a quantidade da largura de banda (CIR no caso do Frame Relay).

Nota: O Cisco IP Phone 7960 tem uma porta de rede 10/100-switched e uma porta de PC de 10/100. Cisco não apoia telefones “de conexão em cascata” fora da porta de PC. Nós não recomendamos anexar a rede e portas de PC a um interruptor (que cria desse modo um laço físico na rede).

Toda a interface WAN exigirá a consideração especial, desde que este é um origem potencial da congestão. Os Telefones IP e os gateways de Cisco ajustam o campo de precedência IP do córrego do Real-Time Transport Protocol (RTP) a cinco, porém este etiqueta somente o pacote RTP. Incumbe o administrador de rede para assegurar-se de que a rede esteja configurada para a prioridade e o controle de admissão da chamada de modo que a Voz sobre o tráfego IP (VoIP) possa ser prestada serviços de manutenção com o retardo mínimo e a contenção para recurso. Para obter informações adicionais sobre deste assunto, refira:

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.

Nota: Todas as discussões neste documento são escritas para a revisão do CallManager da Cisco 3.0(1), salvo indicação em contrário.

Convenções

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

Informações de Apoio

Topologia

Você deve ter uma topologia de rede exata que contém as portas a que os vários componentes são conectados, como VLAN, Roteadores, Switches, gateways, e assim por diante. Uma topologia bem documentado ajuda ao pesquisar defeitos problemas com o sistema. Seja certo que você tem uma topologia precisa, junto com o acesso a todos os dispositivos de rede e serviços terminal para o Gerenciamento do CallManager da Cisco.

O planejamento significativo é exigido a fim adicionar com sucesso a Telefonia IP a um novo ou a uma rede existente. Desde que o tráfego de tempo real tem exigências diferentes do que o tráfego de dados, a rede deve ser projetada com latência baixa e Qualidade de Serviço (QoS) na mente. Como com toda a rede que levar o tráfego de missão crítica, é imperativo que o administrador de rede mantém exato, diagramas detalhados da topologia de rede. Em uma situação de crise é importante conhecer não apenas a visão geral ampla da rede, mas também que as portas são conectadas aos componentes de rede (Roteadores, Switches, servidores do CallManager da Cisco, gateways, e outros dispositivos críticos). É importante planejar a rede com Redundância e a escalabilidade na mente.

cuidado Cuidado: Cisco não apoia o uso do Hubs para a Conectividade compartilhada ao Switches. O Hubs pode interferir com o funcionamento correto do sistema de telefonia IP.

Ao trabalhar com redes comutadas, é crítico que você conhece o estado da medir-árvore (para a Redundância). O estado da rede deve ser documentado antes que toda a falha ocorra.

Glossário de termos

As lista abaixo da tabela alguns termos e acrônimo comuns que podem ser usados neste documento.

Glossário
Acrônimo/termo Definição
.cnf Arquivo de configuração usado por dispositivos.
½ do ¿  ï - lei (“Mu-law”) Técnica de compactação e expansão de uso geral em America do Norte. ½ do ¿  ï - a lei é estandardizada como um codec 64-kbps no ITU-T G.711.
A-law Padrão companding do ITU-T usado na conversão entre sinais analógicos e digitais em sistemas da modulação de código de pulso (PCM). O a-law é usado primeiramente em redes telefônica europeias e é similar ao ½ norte-americano do ¿  ï - padrão da lei.
ACF Admission Confirm.
ANI O número chamado.
ARQ Pedido de admissão.
Canal B Canal do portador. No ISDN, este é um FULL-frente e verso, o canal 64-kbps usado para enviar dados do usuário.
Espaço de pesquisa de chamada O Calling Search Space define que os números de diretório e as rotas padrão um dispositivo dado podem chamar. É um agrupamento das separações através de que para olhar ao fazer um atendimento. Por exemplo, supõe que há diversas separações em um Calling Search Space que são nomeadas “executivo.” Neste exemplo, um número de telefone do IP Cisco está no Calling Search Space “executivo”. Ao iniciar um atendimento, o número de telefone do IP Cisco procura com o “NYInternationalCall,” “NYLongDistance”, “NYLocalCall,” e separações disponíveis de "NY911". Um número de telefone do IP Cisco que tivesse um Calling Search Space do “convidado”, por exemplo, pôde somente ser permitido procurar através do “NYLocalCall” e das separações de "NY911". Consequentemente, se o usuário tenta discar um número internacional, o número não encontrará que um fósforo e o atendimento não estarão distribuídos.
CCAPi Controle de chamada API. Usado pelo Cisco IOS para segurar o processamento de chamada VoIP.
CCO Cisco Connection Online (http://www.cisco.com). Fornece a informação a mais atrasada no Produtos da Cisco, na informação de suporte técnico, e na documentação técnica.
CDR Registro dos destalhes da chamada. Fornece informação sobre o origem de chamada, o destino, e a duração. Isto é usado para criar registros de faturamento.
Cisco IOS Software do sistema de Cisco que fornece a funcionalidade comum, a escalabilidade, e a Segurança para todo o Produtos sob a arquitetura ciscofusion. O Cisco IOS reserva a instalação e gerenciamento de inter-redes centralizado, integrado, e automatizado, ao assegurar apoio para uma ampla variedade de protocolos, media, serviços, e Plataformas.
Conjunto Cluster do CallManager daCisco. Um agrupamento lógico de diversos servidores do CallManager da Cisco.
CMR Call Management Records, igualmente conhecido como CDR diagnósticos. Estes são os registros que contêm a contagem dos bytes enviados, os pacotes enviados, tremor, latência, pacotes descartado, e assim por diante.
codec Codificador-decodificador. Um algoritmo de software da peça de específico de domínio (DSP) usado para comprimir/descomprime o discurso ou os sinais de áudio.
Canal D Canal de dados. Canal do Full-duplex, 16-kbps (BRI) ou 64-kbps (PRI) ISDN. Usado para a sinalização e o controle.
DCF O desencargo confirma.
DHCP Protocolo de configuração dinâmica host. Fornece um mecanismo atribuindo endereços IP de Um ou Mais Servidores Cisco ICM NT dinamicamente de modo que os endereços possam ser reutilizados quando os anfitriões já não os precisam.
DN Número de diretório. Este é o número de telefone de um dispositivo final. Pode ser um número atribuído a um Cisco IP Phone, a um Cisco IP SoftPhone, à máquina de fax, ou ao telefone analógico anexado a um gateway. Os exemplos incluem 1000 e 24231.
DNIS Dialed Number Identification Service.
DNS Domain Name System. Este é o sistema usado no Internet traduzindo nomes dos nós de rede em endereços.
DRQ Requisição de desligamento.
DTMF Tom dual Multifrequency. Este é o uso de dois tons simultâneos da banda de voz para discar (tal como o tom do toque).
Fluxo Um fluxo de dados que viaja entre dois valores-limite através de uma rede (de uma estação LAN a outra, por exemplo). Os fluxos múltiplos podem ser transmitidos em um único circuito.
Full-duplex A capacidade para a transmissão simultânea de dados de uma estação de envio e de uma estação de recepção.
G.711 Descreve a técnica de codificação de voz 64-kbps PCM. Em G.711, a voz codificada está já no formato correto para a entrega de voz digital no PSTN ou com os PBX. Isto é descrito no padrão do ITU-T em suas recomendações G Series.
G.729 Descreve o compactação de predição linear despertada por código (CELP) onde a Voz é codificada nos córregos 8-kbps. Há duas variações deste padrão (G.729 e anexo A de G.729) que diferem principalmente na complexidade computacional; ambos fornecem a qualidade de discurso similar à compressão digital de ondas sonoras 32-kbps (ADPCM). Isto é descrito no padrão do ITU-T em suas recomendações G Series.
H.225 Um padrão de ITU que governe o estabelecimento de sessão H.225 e o empacotamento. O H.225 descreve realmente diversos protocolos diferentes: RAS, o uso do Q.931, e o uso do RTP.
H.245 Um padrão de ITU que governe o controle de valor-limite H.245.
H.323 Uma extensão do padrão H.320 do ITU-T que permite a Videoconferência sobre LAN e outras redes de pacote comutado, assim como vídeo sobre o Internet.
Meio - duplex A capacidade para a transmissão de dados em somente um sentido de cada vez entre uma estação de envio e uma estação de recepção. Uma comunicação síncrona binária (BSC) é um exemplo de um protocolo metade-frente e verso.
Hookflash Um período curto do em-gancho, gerado geralmente pela telefone-como o dispositivo durante um atendimento, para indicar que o telefone está tentando executar um cancelamento do tom de discagem de um PBX. O hookflash é usado frequentemente executar transferência de chamada.
ICCP Protocolo de controle do Intracluster
ISDN Integrated Services Digital Network. Um protocolo de comunicação, oferecido por companhias telefônica, que permita redes telefônica levar dados, exprime, e o outro tráfego de origem.
Tremulação A variação no tempo de chegada dos pacotes de voz.
MGCP Protocolo de controle de gateway de mídia. Um protocolo para que o CallManager da Cisco controle Gateway VoIP (pontos finais de MGCP).
MTP Media Termination Point.
Separação Uma separação é um agrupamento lógico dos números de diretório (DN) e das rotas padrão com características de alcançabilidade similares. Para a simplicidade, estes são nomeados geralmente para sua característica, tal como o “NYLongDistance”, "NY911", e assim por diante. Quando um DN ou uma rota padrão são colocados em uma determinada separação, este cria uma regra para quem pode chamar essa lista do dispositivo ou da rota.
PBX Central telefônica privada. Digitas ou switchboard de telefone analógico situadas nos locais do assinante e usadas para conectar privado e redes de telefonia públicas.
PRI Relação da taxa principal. O acesso de taxa principal consiste em um único canal D 64-Kbps mais 23 (T1) ou 30 canais B (E1) para a Voz ou os dados.
PSTN Rede telefônica pública comutada. Termo geral que refere a variedade de redes telefônica e de serviços no lugar no mundo inteiro.
Q.931 Padrão de ITU que descreve a sinalização ISDN. O padrão H.225.0 usa uma variação do Q.931 para estabelecer e desligar sessões de H.323.
RAS Registro, Admissão e Protocolo de Status. Este é o protocolo usado no conjunto de protocolos de H.323 descobrindo e interagindo com um porteiro.
Filtro da rota Um filtro da rota pode ser usado para restringir não somente discar, mas para identificar igualmente um subconjunto de um padrão de wildcard (ao usar @ o convite no plano de discagem norte-americano). Por exemplo, poderia ser usado para obstruir discar de 900 códigos de área. Na lata seja usado igualmente conjuntamente com separações e Calling Search Spaces para estabelecer regras complexas. Por exemplo, supõe que você tem três grupos de usuário estabelecidos: Executivo, pessoal, e convidado. Um filtro da rota pode permitir que o grupo executivo de usuário disque números internacionais, o grupo de usuário de grupo para discar números locais ou chamadas interurbanas, e o grupo de usuário convidado para discar somente 911, e 800 os números dos números locais.
Grupo de rotas Um grupo de rotas é uma lista de uns ou vários gateways ou portas nos gateways que são vistos como o acesso igual. É análogo a um grupo de troncos na terminologia tradicional de PBX. Por exemplo, você pode ter dois circuitos PRI ao mesmo portador que pode ser usado arbitrariamente. Um gateway (ou uma porta particular em um gateway) podem somente ser adicionados a um grupo de rotas.
Lista da rota O ponto de rota anteriormente chamado, a lista da rota permite que o CallManager da Cisco cace através de uma lista de grupos de rotas em um ordem de preferência configurado. As listas de rota múltipla podem apontar aos mesmos grupos de rotas.
Rota padrão Um número específico ou, mais comumente, uma escala dos números discados que serão usados para distribuir atendimentos a um dispositivo (tal como um gateway do acesso DT-24+ de Cisco ou um roteador com capacidade de voz) ou indiretamente através de uma lista da rota. Por exemplo, 1XXX significa 1000 a 1999. O “x” em 1XXX significa um de um único dígito; um convite. Há outros tais convites (como @. ! , e assim por diante). Uma rota padrão não tem que ser original dentro de uma separação enquanto o filtro da rota é diferente.
RRJ Registration Reject.
RTP Protocolo de transporte em tempo real, um dos protocolos do IPv6. O RTP é projetado fornecer funções do transporte de rede de ponta a ponta para os aplicativos que transmitem dados de tempo real, tais como dados audio, video, ou da simulação, sobre serviços de rede do Multicast ou do unicast. O RTP proporciona serviços tais como a identificação de tipo de virulência, a numeração de sequência, o tempo que carimbam, e o monitoramento de entrega aos aplicativos em tempo real.
SEP Telefone dos Ethernet de Selsius. Este acrônimo precede endereços MAC em Telefones IP de Cisco, e representa um identificador de dispositivo exclusivo.
Supressão de silêncio (detecção de ativação da Voz) A supressão de silêncio permite que um Cisco IP Phone detecte a ausência de áudio e consequentemente não transmite pacotes sobre a rede. A qualidade do som pode levemente ser degradada mas a conexão pode igualmente usar menos largura de banda. A supressão de silêncio é desabilitada à revelia.
SNMP: Protocolo administración de red simple. O protocolo de gerenciamento de rede é usado quase exclusivamente em redes TCP/IP. O SNMP oferece um meio para monitorar e controlar dispositivos de rede e para gerenciar configurações, coleta de estatísticas, desempenho e segurança.
SQL Língua de consulta estruturada. Língua de internacional padrão para bases de dados relacionais de definição e de acesso.
T1/CAS O T1 é uma facilidade de portadora de WAN digital, transmitindo dados DS-1-formatted no 1.544 Mbps através da rede de switching de telefone, usando a codificação AMI ou B8ZS. CAS é uma relação de sinalização associada a canal.
T1/PRI O T1 é uma facilidade de portadora de WAN digital, transmitindo dados DS-1-formatted no 1.544 Mbps através da rede de switching de telefone, usando a codificação AMI ou B8ZS. O PRI é relação da taxa principal. O acesso de taxa principal consiste em um único canal D 64-Kbps mais 23 (T1) ou 30 canais B (E1) para a Voz ou os dados.
TCP Protocolo Protocolo de control de transmisión (TCP). Este é o protocolo de camada do transporte orientado por conexão que fornece seguro, transmissão dos dados bidirecionais. O TCP é parte da pilha de protocolos TCP/IP.
TFTP Protocolo trivial file transfer. Versão simplificada do FTP que permite que os arquivos sejam transferidos de um computador a outro sobre uma rede.
Teste padrão da tradução Usado para traduzir chamado (DNIS) e chamando números da identificação de número automática (ANI) antes de distribuir o atendimento. Por exemplo, um atendimento pode entrar a um conjunto de número (919 392-3XXX) essa necessidade de ser traduzido a um grupo de Telefones IP de Cisco que está na escala de 2XXX. O CallManager da Cisco tem um teste padrão da tradução estabelecido para 919 392-3XXX. Este teste padrão traduz os 919 392-3 de condução simplesmente a 2, ao deixar os dígitos remanescente intactos. O atendimento é distribuído então ao Cisco IP Phone apropriado. Os testes padrão da tradução são usados somente para traduções verdadeiras e não devem ser usados para a retirada e prefixação de dígito simples.
UDP Protocolo de datagrama de usuário. Este é um protocolo de camada de transporte sem conexão na pilha de protocolos TCP/IP. O UDP é um protocolo simples que troque datagramas sem os reconhecimentos ou a entrega garantida, exigindo que o processamento do erro e a retransmissão estejam segurados por outros protocolos. O UDP é definido no RFC 768.
Detecção de ativação da Voz (supressão de silêncio) A detecção de ativação da Voz permite que um Cisco IP Phone detecte a ausência de áudio e consequentemente não transmite pacotes sobre a rede. A qualidade do som pode levemente ser degradada mas a conexão pode igualmente usar menos largura de banda. A supressão VAD/Silence é desabilitada à revelia.
VoIP Voz sobre o IP.
VLAN LAN virtual. Um grupo de dispositivos em uns ou vários LAN que são configurados (usando o software de gestão) de modo que possa se comunicar como se foi anexado ao mesmo fio, quando for ficado situado de fato em um número de segmentos de LAN diferentes. Porque os VLAN são baseados em lógico em vez das conexões física, são extremamente flexíveis.

Ferramentas e utilitários para monitorar e solucionar problemas do Cisco CallManager

Esta seção endereça as ferramentas e utilitário para configurar, monitorar e pesquisar defeitos o CallManager da Cisco.

Detalhes de administração do Cisco CallManager

A administração do CallManager da Cisco fornece a informação de versão para o sistema, o base de dados, e os outros componentes. Na página da abertura, clique sobre o botão Details Button e escreva para baixo as versões no uso.

ccm_admin.gif

Mais explicação detalhada da administração do CallManager da Cisco está disponível na documentação on-line do CallManager da Cisco.

Desempenho Microsoft

O desempenho (monitor) é um aplicativo de servidor do Windows 2000 que possa indicar as atividades e o estado de seu sistema do CallManager da Cisco. Relata a informação geral e específica no tempo real. Você pode usar o desempenho do Windows 2000 para recolher e as estatísticas do sistema de exibição e do dispositivo para toda a instalação do CallManager da Cisco. Esta ferramenta administrativa permite que você ganhe um entendimento completo de um sistema sem estudar a operação de cada um de seus componentes.

Você pode usar o desempenho para monitorar uma variedade de variáveis de sistema no tempo real. Após ter adicionado os parâmetros do CallManager da Cisco, você pode definir os termos sob que o CallManager da Cisco indicará as estatísticas geradas pelo sistema. Por exemplo, você pode monitorar o número de atendimentos em andamento a qualquer hora, ou o número de atendimentos que passam atualmente através de um gateway específico. O desempenho mostra o general e o Cisco informação de status CallManager-Specific no tempo real.

/image/gif/paws/30266/ms_perf.gif

Desempenho Microsoft de abertura

Para abrir o desempenho no CallManager da Cisco running do server PC, começo do clique > ajustes > Control Panel > ferramentas de administração > desempenho.

Personalizando o desempenho

O monitoramento de desempenho deve ser personalizado para ver os parâmetros CallManager-relacionados de Cisco que você deseja monitorar. Escolha o objeto, contador, e cite-o como exemplo querem incluir. Refira configurar a Capacidade de Serviço Remoto para o CallManager da Cisco, libere o 3.0 para instruções em como usar objetos e contadores para personalizar o desempenho Microsoft para operações do CallManager da Cisco.

Microsoft Event Viewer

Microsoft Event Viewer é um aplicativo de servidor do Windows NT que sistema de indicadores, Segurança, e eventos de aplicativo (que incluem o CallManager da Cisco) para o server de Windows NT. Se um serviço (que inclui o TFTP) não pode ler o base de dados (onde obtém a configuração do traço), adicionará erros ao visualizador de eventos. O visualizador de eventos é o único lugar onde estes tipos de erros aparecerão. A seguinte ilustração mostra os log do aplicativo que são executado em um server de Windows NT.

ms_event_viewer.gif

Visualizador de eventos de abertura

Para abrir o evento entre o CallManager da Cisco running do server PC, começo do clique > ajustes > Control Panel > ferramentas administrativas > visualizador de eventos. O visualizador de eventos fornece log de erros para o sistema, a Segurança, e os aplicativos. Os erros do CallManager da Cisco são registrados sob o log do aplicativo.

Informação detalhada sobre eventos

Você pode fazer duplo clique um evento no log para aprender mais informação sobre o evento.

/image/gif/paws/30266/event_prop.gif

Rastreamento de SDI

Os traços SDI são arquivos de Log. O endereço IP de Um ou Mais Servidores Cisco ICM NT, o punho TCP, o nome de dispositivo, ou o selo de tempo podem ser usados ao rever o traço SDI para monitorar a ocorrência ou a disposição de um pedido. Este nome de dispositivo poderia ser seguido de volta à construção do arquivo, que mostra o pool de dispositivos e o modelo. O pool de dispositivos e o modelo podem ser seguidos de volta à construção do protótipo do arquivo de configuração, que alistará o endereço de rede do CallManager da Cisco e da porta da conexão de TCP.

Quando observar o SDI seguir, observar que os nomes da classe e da rotina do C++ estão incluídos com a maioria de linhas de rastreamento. A maioria de rotinas associadas com o serviço de um pedido particular incluem a linha ID em um formato padrão.

Os traços SDI serão explicados em detalhe nos Casos Práticos.

Saídas de rastreamento SDI

Os traços SDI gerenciem arquivos (por exemplo, CCM000000000) traços dessa loja de atividades do CallManager da Cisco. Estes traços fornecem a informação sobre o processo de inicialização do CallManager da Cisco, o processo de registro, o processo de keepalive, o fluxo de chamadas, a análise de dígitos, e os dispositivos relacionados tais como Telefones IP, gateways, porteiros, e mais de Cisco. Esta informação pode ajudá-lo a isolar problemas ao pesquisar defeitos o CallManager da Cisco. Para seguir corretamente a informação que você precisa e somente a informação você precisa, ele é importante compreender como ajustar as opções na interface de configuração do traço.

Os arquivos de rastreamento são armazenados no seguinte local padrão: C:\Program Files\cisco\bin. Um arquivo de rastreamento novo está ligado cada vez que o CallManager da Cisco reinicia, ou quando o número de linha designado esteve alcançado.

Seguir é uma ilustração da interface de configuração do traço da administração do CallManager da Cisco. Você deve permitir o traço, escolher o nível na informação necessária, e verificar a máscara do usuário para obter o nível desejado da informação.

/image/gif/paws/30266/trace_config.gif

Se o traço não é configurado corretamente, gerará uma grande quantidade de informação que faz o muito difícil isolar problemas. A seguinte seção explica como configurar corretamente um traço útil.

Configurando traços

Os traços são compostos das bandeiras da máscara do usuário (igualmente conhecidas como bit) e dos níveis de rastreamento. Abra a administração do CallManager da Cisco. Para girar sobre o seguimento, ajuste seus parâmetros do traço (que incluem o serviço configurado, os bit, e assim por diante) Service > Trace na tela. Refira o guia da administração do CallManager da Cisco, libere 3.0(1) para obter informações completas sobre de girar o seguimento sobre e fora, e para descrições das máscaras do usuário e níveis para cada serviço configurado, e mais.

Seguir é dois exemplos dos bit de máscara do traço que seriam permitidos com base no problema particular.

  • Para a eliminação de erros do mensagem normal, gire sobre os bit 5, 6, 7, 8, 11, e 12 do subsistema

  • Para debugar gateways, gire sobre os bit 3, 4 do subsistema, o 5, o 6, o 7, os 8, o 9, os 11, os 12, e os 13

Seguir é dois exemplos dos níveis de rastreamento desejados baseados no problema particular

  • Para a eliminação de erros normal, o nível de rastreamento deve ser ajustado a SDI_LEVEL_ARBITRARY

  • Para o sistema de execução normal, o nível de rastreamento deve ser ajustado a SDI_LEVEL_ERROR

Rastreamento de SDL

Traços do uso SDL dos engenheiros da Cisco para encontrar a causa de um erro. Você não é esperado compreender inteiramente a informação contida em um traço SDL. Contudo, ao trabalhar com TAC, você pode ser pedido para permitir o traço SDL e para o fornecer ao TAC. Os arquivos de rastreamento SDL podem ser salvar aos diretórios locais, ao visualizador de eventos do Windows NT, e ao CiscoWorks2000. Para evitar toda a degradação do desempenho no server, seja certo que você desliga o SDL traçado depois que o traço foi capturado.

O traço SDL fornece a relação corrente alternada para seguir e os alarmes. Os alarmes são usados para informar o administrador de eventos inesperados, tal como ser incapazes de alcançar um arquivo, um base de dados, um Winsock, ou ser incapazes de atribuir outros recursos do sistema operacional.

Permitindo o traço SDL

Os traços SDL são permitidos no serviço > área de parâmetro de serviço na administração do CallManager da Cisco. Recorde que estes traços devem ser girados sobre somente quando pedidos por um coordenador TAC. Note os valores escolhidos girar sobre o traço SDL na seguinte ilustração.

/image/gif/paws/30266/serv_param_config.gif

Uma vez que os traços SDL são permitidos, recolha os traços. Se os traços estão sendo enviados à unidade local, a seguir você pode recuperá-los no sub-diretório de Cisco \ traço. Alternativamente, os arquivos de rastreamento podem ser enviados a um log de eventos ou ao CiscoWorks2000.

Os bit de flag SDL descritos na tabela a seguir são ajustados na área do serviço > de parâmetros de serviço na administração do CallManager da Cisco. Seguir é dois exemplos dos valores desejados baseados no problema particular.

  • O valor recomendado para a eliminação de erros da chamada normal é SdlTraceTypeFlags=0x00000b04

  • O valor recomendado para a eliminação de erros de baixo nível ou os gateways da eliminação de erros é SdlTraceTypeFlags=0x00004b05

Definições de SdlTraceTypeFlags
SDLTraceTypeFlag Valor Definição
traceLayer1 = 0x00000001 Todo o traço do Layer 1 sobre
TraceDetailLayer1 = 0x00000002 Traço do Layer 1 do detalhe sobre
TraceSdlLinkAdmin = 0x00000004 Links do CallManager de inter-Cisco do traço dentro de um conjunto
traceUnused = 0x00000008 Não utilizado
traceLayer2 = 0x00000010 Todos mergulham o traço 2 sobre
traceLayer2Interface = 0x00000020 Traço da interface de camada 2 sobre
traceLayer2TCP = 0x00000040 Traço da camada 2 TCP sobre
TraceDetailLayer2 = 0x00000080 Mais descarga do detalhe de quadros da camada 2.
traceLayer3 = 0x00000100 Todos mergulham o traço 3 sobre
traceCc = 0x00000200 Todo o traço do Controle de chamadas sobre
traceMiscPolls = 0x00000400 Votações variadas do traço
traceMisc = 0x00000800 Traço variado em (sinais do base de dados)
traceMsgtrans = 0x00001000 A tradução de mensagem sinaliza (TranslateIsdnToSdlReq, TranslateIsdnToSdlRes TranslateSdlToIsdnReq, TranslateSdlToIsdnRes)
traceUuie = 0x00002000 Traço da saída UUIE sobre
traceGateway = 0x00004000 Sinais de gateway

Os bit de dados descritos na tabela a seguir são ajustados na área do serviço > de parâmetros de serviço na administração do CallManager da Cisco. Seguir é dois exemplos dos valores desejados baseados no problema particular.

  • O valor recomendado para a eliminação de erros normal do sistema é SdlTraceDataFlags=0x110

  • O valor recomendado ao seguir problemas com links SDL é 0x13D (traço NON-comprimido; se um traço compacto é desejado, 0x200 mordido deve ser ajustado. Pode ser ajustado em combinação com todos os outros bit)

Definições de SDLTraceDataFlags
SDLTraceDataFlag Valor Definição
TraceSdlLinkState = 0x001 Permita o traço de iniciação do link SDL
TraceSdlLowLevel = 0x002 O traçado Enable de eventos de baixo nível SDL, fileOpen e de eventos do soquete (por exemplo)
TraceSdlLinkPoll = 0x004 Traçado Enable da mensagem da votação do link SDL
TraceSdlLinkMsg = 0x008 Traçado Enable da mensagem do link SDL
traceRawData = 0x010 Permita o traço cru dos dados do sinal em todos os sinais
TraceSdlTagMap = 0x020 Permita o mapeamento da etiqueta
traceCreate = 0x100 Permita o processo criam e param traços
TraceNoPrettyPrint = 0x200 Bela impressão do desabilitação dos arquivos de rastreamento

Aviso do espaço de disco

aviso aviso: Seja recomendado que a informação obtida desta relação poderia ser muito detalhada, e consome consequentemente uma grande quantidade do espaço de disco. Por este motivo, nós recomendamo-lo girar sobre o arquivo de rastreamento para uma quantidade de tempo específica, rever a informação, e desligar o traço.

Rastreamento de farejador

Um sniffer é um aplicativo de software que monitore o tráfego IP em uma rede e forneça a informação sob a forma de um traço. Os farejadores de rastreamento fornecem a informação sobre a quantidade e o tipo de tráfego de rede em sua rede. O TCP/IP ou os pacotes de UDP são protocolos utilizados pelo CallManager da Cisco e por dispositivos de ponto final, tais como telefones e gateways. Os farejadores de rastreamento podem igualmente ajudá-lo a identificar os níveis altos do tráfego de broadcast que poderiam conduzir aos problemas de áudio ou às chamadas descartada da Voz. Os aplicativos comuns de farejador incluem associados à rede SnifferPro, consultivo de internet do Hewlett Packard, e Acterna domino. O dominó oferece soluções de hardware e de software do sniffing e um analisador de rede. Se você quer usar o dominó, nós recomendamos usar o software de análise para avaliar um arquivo de rastreador capturado (como do aplicativo SnifferPro).

Call Detail Records (CDR) e Call Management Records (CMR)

O CDR é uma opção do relatório que registre cada atendimento feito (ou tentou) de todo o Cisco IP Phone. Há dois tipos dos CDR: CDR básicos e CDR diagnósticos (ou CMR). Uma vez que permitido, você pode abrir CDR ou CDR diagnósticos (CMR) na enterprise manager do servidor SQL. Os arquivos CDR salvar em um base de dados SQL que possa ser exportado para quase todo o aplicativo, incluindo Microsoft Access ou Excel.

Os registros de CDR contêm a informação necessária gerar registros de faturamento. Em um ambiente distribuído, todos os dados CDR são recolhidos em um local central, ou em um grupo de lugar. A falha de um nó do CallManager da Cisco não faz os dados CDR associados com esse nó não disponíveis. Os dados são armazenados já não no disco do CallManager da Cisco como um arquivo plano, mas armazenados pelo contrário em uma base de dados central nas tabelas.

Se o CallManager da Cisco falha antes que todos os registros estejam redigidos, nenhum registro do atendimento existirá. Isto significa que nenhum registro estará redigido para os atendimentos que são ativos em um CallManager da Cisco dado quando falham antes que os atendimentos terminem.

Refira a seção dos registros dos destalhes da chamada deste documento para informações detalhadas sobre dos CDR e dos CMR.

A informação fornecida inclui:

  • Registros da leitura e da escrita

  • Problemas conhecidos

  • Lista de tipos de registro gerados

  • Lista de campos contidos em cada registro e em uma descrição do que esse campo representa

  • Descrição dos tipos de atendimentos registrados, e os campos registrados com o cada um deles

  • Lista de códigos de causa que podem aparecer nos registros de CDR

CDR de possibilidade ou de desabilitação

A criação de registro de CDR está desabilitada à revelia quando o sistema é instalado. Se você deseja ter dados CDR, você deve permitir CDR na área do serviço > de parâmetros de serviço da administração do CallManager da Cisco. O processamento CDR pode ser permitido e desabilitado a qualquer hora quando o sistema estiver na operação. Você não precisa de reiniciar o CallManager da Cisco para a possibilidade ou a desabilitação dos CDR tomar o efeito. O sistema responderá a todas as mudanças dentro de alguns segundos. O CMR ou os dados de diagnóstico são permitidos separadamente dos dados CDR. Os dados CMR não serão gerados a menos que ambos os CDR e diagnósticos do atendimento forem permitidos, mas os dados CDR podem ser gerados e registrado sem dados CMR.

Use as seguintes etapas para permitir CDR.

  1. Abra a administração do CallManager da Cisco.

  2. Selecione o serviço > os parâmetros de serviço.

  3. Selecione o endereço IP de Um ou Mais Servidores Cisco ICM NT de sua instalação do CallManager da Cisco.

  4. Da lista de parâmetros, selecione CDREnabled.

  5. Defina o tipo como booleano.

  6. Selecione T para verdadeiro.

    /image/gif/paws/30266/serv_param_config2.gif

  7. Atualização.

    Resultado: Os registros dos destalhes da chamada começarão registrar imediatamente.

    cuidado Cuidado: A conectividade de voz de seguimento exige que o logging CDR esteja permitido em cada instalação do CallManager da Cisco em um conjunto.

    /image/gif/paws/30266/log_enable.gif

CDR

Os CDR fornecem a informação básica que pode o ajudar a compreender mais informação detalhada contida em traços SDI. Os CDR básicos fornecem a informação tal como o número chamado, número chamado, originando o endereço IP de Um ou Mais Servidores Cisco ICM NT, endereço IP de destino, duração da chamada, e assim por diante. Os CDR podem ajudá-lo a pesquisar defeitos problemas do telefone. Por exemplo, se um usuário relata um problema com um atendimento que ocorre em umas horas específicas, você pode consultar os CDR que ocorreram em torno do tempo indicado para aprender a informação adicional sobre esse atendimento e outro. Os CDR são de uso geral para faturar.

CDR diagnósticos (igualmente conhecidos como CMR)

Os CDR diagnósticos fornecem informação de chamada detalhada tal como o número de pacotes enviados, recebidos, e perdidos, e a quantidade de tremor e de latência. Este nível de detalhe pode fornecer explicações para alguns problemas, tais como o áudio de sentido único. Por exemplo, um problema do áudio de sentido único é indicado se um tamanho do pacote de 10,000 é enviado, mas o tamanho recebido é somente 10.

Troubleshooting de Problemas de CallManager com Windows NT e Internet Information Server (IIS)

Esta seção endereça algumas categorias do problema comum que podem ocorrer com CallManager da Cisco e os dispositivos relacionados. Cada categoria de problema sugere ferramentas de Troubleshooting que você deve se usar para ajudar a isolar o problema. Este documento fornece categorias gerais de problemas potenciais e de sugestões em como pesquisar defeitos aqueles problemas. Não fornece uma lista exaustiva dos problemas e das definições. Se você encontra um problema que não possa ser resolved usando as ferramentas e utilitário descritas neste documento, consulte o centro de assistência técnica da Cisco (TAC) para o auxílio. Seja certo ter os detalhes de administração do CallManager da Cisco disponíveis, mais toda a informação de diagnóstico (tal como traços) que você recolheu até o ponto de chamar o TAC.

Qualidade de Voz

As questões de qualidade de voz incluem áudio perdido ou distorcido durante chamadas telefônica. Os problemas comuns incluem as rupturas no som que fazem com o áudio seja intermitente (como palavras quebradas), ou a presença de ruídos impares que distorcem o áudio (eco) ou os efeitos que fazem com que as palavras dita soem aquosas ou robóticos. O áudio de sentido único, isto é, uma conversação entre dois povos onde somente uma pessoa pode ouvir qualquer coisa, não é realmente uma questão de qualidade de voz. Isto será discutido mais tarde nesta seção.

Uns ou vários dos seguintes componentes podem causar problemas de áudio:

  • Gateway

  • Fone

  • Rede

Para pesquisar defeitos corretamente questões de qualidade de voz, você deve considerar infraestrutura e todos os dispositivos para gotas e atrasos.

Áudio perdido ou distorcido

Um dos problemas mais comuns encontrados é uma “quebra acima” do áudio (descrito frequentemente como o discurso truncado ou uma perda de sílabas dentro de uma palavra ou de uma frase). Há duas causas comum para esta: perda de pacotes e/ou tremor. A perda de pacotes significa que os pacotes de áudio não chegam em seu destino porque foram deixados cair ou chegados demasiado tarde para ser úteis. O Jitter é a variação no tempo de chegada dos pacotes. Na situação ideal, todos os pacotes voip de um telefone a outro chegariam exatamente a uma taxa de 1 cada Senhora 20. Observe que isto não menciona quanto tempo toma para que um pacote consiga do ponto A apontar B, simplesmente a variação no tempo de chegada.

Há muitas fontes de retardo variável em uma rede real. Alguma destes não pode ser controlada, e algumas podem. O retardo variável não pode ser eliminado inteiramente em uma rede de voz empacotada. Os processadores do sinal digital (DSP) em telefones e em outros dispositivos Voz-capazes são projetados proteger algum do áudio, em antecipação ao retardo variável. Isto “que dejittering” é feito somente quando o pacote de áudio alcançou seu destino e está pronto para ser posto em um fluxo de áudio convencional (isto é, jogado na orelha do usuário, enviada ao PSTN através de um córrego digital PCM). O Cisco IP Phone 7960 pode proteger tanto quanto o segundo dos exemplos de voz. O buffer do tremor é adaptável, significando se uma explosão dos pacotes é recebida, o Cisco IP Phone 7960 pode jogá-los para fora na tentativa de controlar o tremor. O administrador de rede precisa de minimizar a variação entre tempos de chegada de pacote aplicando o Qualidade de Serviço (QoS) e as outras medidas adiantado (especialmente se os atendimentos cruzam uma rede de área ampla).

Quando enfrentado com um problema de áudio perdido ou distorcido, você deve primeiramente tentar isolar o trajeto do áudio. Tente identificar cada dispositivo de rede (Switches e Roteadores) no trajeto do fluxo de áudio do atendimento. Mantenha na mente que o áudio pode ser entre dois telefones, entre um telefone e um gateway, ou poderia ter os vários trechos (de um telefone a um dispositivo transcoding e de lá a um outro telefone). Tente identificar e assim por diante se o problema ocorre somente entre dois locais, somente através de um determinado gateway, em uma determinada sub-rede. Isto ajudará a reduzir para baixo que os dispositivos você precisam de examinar mais com cuidado. Em seguida, é frequentemente o melhor desabilitar a supressão de silêncio (igualmente conhecida como a detecção de ativação da Voz ou o VAD) se isto não tem sido feito já. Este mecanismo salvar a largura de banda não transmitindo o áudio quando há um silêncio, mas pode causar o grampeamento visível (e inaceitável) no início das palavras. Você pode desabilitar este na administração do CallManager da Cisco, sob o serviço > os parâmetros de serviço. De, seleciona o server e o serviço do CallManager da Cisco. Ajuste SilenceSuppressionSystemWide a “F” (alternativamente você pode ajustar SilenceSuppressionWithGateways a “F”, mas este não se aplica a Gateways H.323 ou aos gateways MGCP). Em caso de dúvida, desligue ambos selecionando o valor F para cada um.

/image/gif/paws/30266/serv_param.gif

Se um analisador de rede está disponível, um atendimento monitorado entre dois telefones deve ter pacotes dos 50 pés por segundo (ou 1 pacote cada Senhora 20) quando a supressão de silêncio é desabilitada. Com filtração apropriada, deve ser possível identificar se os pacotes estão sendo perdidos ou atrasados excessivamente.

Recorde que o atraso por si só não causará o grampeamento, simplesmente o retardo variável vai faz4e-lo. Na tabela abaixo, que representa um traço perfeito, o tempo de chegada entre os pacotes de áudio (que terão um cabeçalho de RTP) será a Senhora 20. Em um atendimento de má qualidade (tal como um atendimento com muito tremor), o tempo de chegada variaria extremamente.

Um traço perfeito
Número do pacote Tempo: absolute (Senhora) Tempo: delta (Senhora)
1 0
2 0.02 20
3 0.04 20
4 0.06 20
5 0.08 20

Colocar o analisador de pacote em vários pontos na rede ajudará a reduzir para baixo de onde o atraso está vindo. Se nenhum analisador está disponível, outros métodos estarão exigidos. É importante examinar estatísticas da relação de cada dispositivo no trajeto do áudio. Uma outra ferramenta para seguir atendimentos com qualidade de voz deficiente é os registros dos destalhes da chamada diagnósticos (CDR). Veja as ferramentas e utilitário secionar e a seção dos registros dos destalhes da chamada para obter mais informações sobre dos CDR.

Os valores para o tremor e a latência podem ser recuperados para todos os atendimentos (mas somente depois que o atendimento terminou). Seguir é uma amostra CDR diagnóstico (o CallDetailRecordDiagnostic é o nome da tabela real). O número de pacotes enviados, recebido, perdido, tremor, e latência todos é gravado. O valor do globalCallID pode ser usado para encontrar o atendimento na tabela regular CDR de modo que a causa da desconexão e a outra informação possam ser obtidas. O diagrama abaixo mostra ambas as tabelas abertas. Observe que no CDR diagnóstico, cada dispositivo que pode possivelmente relatar esta informação é incluído. Assim, se o problema está entre dois Telefones IP de Cisco, nós vemos duas entradas de tabela pelo atendimento. Se nós temos um atendimento através de um Cisco IOS gateway, por exemplo, nós vemos somente a informação de diagnóstico do Cisco IP Phone, não o gateway porque não há nenhum mecanismo para que notifique o base de dados SQL com esta informação.

ibutton.gif

ajuda de botão I Button

O Cisco IP Phone 7960 fornece uma outra ferramenta para diagnosticar problemas de áudio possíveis. Em uma chamada ativa, você pode pressionar o botão I Button duas vezes (rapidamente) e o telefone indica uma tela de informação que contenha o pacote receba e transmita estatísticas, assim como contadores da média e do tremulação máxima. Nesta tela, não esse tremor é a média dos últimos cinco pacotes que chegaram; o tremulação máxima é a marca da água superior para o tremulação média.

A maioria de origens comuns para o atraso e a perda de pacotes são os dispositivos onde uma relação mais alta da velocidade alimenta em uma relação da velocidade mais baixa. Por exemplo, um roteador pode ter uma interface rápida de Ethernet do 100 Mb conectada ao LAN e um Frame Relay lento conectado a WAN. Quando a qualidade ruim ocorrer somente ao se comunicar ao local remoto (somente o local remoto pode relatar a qualidade de voz deficiente quando no outro sentido tudo parecer ser fino), estão abaixo as causas mais prováveis de problema:

  • O roteador não foi configurado corretamente para dar a prioridade do tráfego de voz sobre o tráfego de dados.

  • Há atendimentos demais ativos para que WAN apoie (isto é, não há nenhum controle de admissão da chamada para restringir o número de atendimentos que podem ser colocados).

  • Há uns erros da porta física.

  • Há a congestão em WAN própria.

No LAN, os problemas mais comuns são erros do nível físico (tais como erros CRC) causados por cabos defeituosos e por relações, ou por dispositivos incorreto-configurados (tais como uma velocidade de porta ou uma incompatibilidade duplex (bidirecional)). Certifique-se de que o tráfego não está cruzando nenhum dispositivo da mídia compartilhada, tal como um hub. Poderia igualmente haver as situações onde o tráfego está tomando um trajeto mais lento através da rede do que esperada. Se QoS foi configurado corretamente, é possível que não há nenhum controle de admissão da chamada. Segundo sua topologia, isto pode ser realizado com o uso dos lugar na configuração da administração do CallManager da Cisco, ou usando um roteador do Cisco IOS como um porteiro. Em todo caso, você deve sempre saber quantos atendimentos poderiam ser apoiados através de seu WAN. Se possível, teste isto pela supressão de silêncio de desabilitação como descrito mais cedo, a seguir coloque atendimentos entre os dois locais. Não coloque chama a posse ou no mudo, desde que isto parará pacotes de ser transmitido. Com o número máximo de atendimentos através de WAN, os atendimentos se todos tiverem a qualidade aceitável. Teste para certificar-se de que um ocupado rápido está retornado ao tentar fazer mais um atendimento.

Estalando

Um outro sintoma “de má qualidade” pode ser uma crepitação, que seja causada às vezes por uma fonte de alimentação defeituosa ou por algum tipo de interferências elétricas fortes perto do telefone. Tente trocar a fonte de alimentação e mover o telefone para um lugar diferente.

Verifique suas cargas

Além, você deve sempre verificar os telefones e os gateways para assegurar as cargas do software mais recente estão no uso. Em caso de dúvida, verificação CCO (Cisco Connection Online em www.cisco.com) para as cargas do software mais recente, correções de programa novas, ou Release Note em relação ao problema.

Eco

O eco (igualmente conhecido como o “talker echo”) ocorre quando as energias do discurso de um orador, transmitidas abaixo do trajeto do sinal principal, são acopladas no trajeto da recepção da ponta oposta. O orador ouve então sua própria Voz, atrasada no tempo de atraso de trajeto total do eco.

/image/gif/paws/30266/voice.gif

No diagrama acima, a Voz de John (no azul) está sendo refletida para trás. Isto pode acontecer mas ir despercebido em uma rede de voz tradicional porque o atraso é tão baixo. Ao usuário, soa mais como um tom lateral do que um eco. Em uma rede voip, será sempre visível, desde que o empacotamento e a compressão contribuem sempre bastante atraso. O importante a recordar é que a causa do eco é sempre com componentes analógicos e fiação. Por exemplo, os pacotes IP não podem simplesmente girar ao redor e ir para trás à fonte a nível de áudio mais baixo. O mesmo é impossível nos circuitos T1/E1 digitais. Assim em um atendimento de um Cisco IP Phone a outro, deve nunca haver todo o problema. A única exceção pode ser se um partido está usando um telefone com altofalante que tenha o conjunto de volume demasiado altamente ou alguma outra situação onde um laço audio é criado.

Ao pesquisar defeitos problemas de eco, se certifique de que os telefones que estão sendo testados ou examinados não estão usando o telefone com altofalante e de que têm o conjunto de volume dos auriculares aos níveis razoáveis (começo com por cento dos 50 pés do nível de áudio máximo). Na maioria das vezes, os problemas ocorrerão ao anexar ao PSTN por um digital ou um gateway analógico. Os usuários do Cisco IP Phone podem queixar-se que ouvem sua própria Voz que está sendo refletida de volta a eles. Embora o origem verdadeira do problema esteja quase sempre na ponta oposta, é quase sempre impossível mudar qualquer coisa no PSTN. Assim, a primeira etapa é determinar que gateway está sendo usado. Se um gateway digital está no uso, pode ser possível adicionar o preenchimento adicional no transmitir direção (para o PSTN) nas esperanças que a baixa intensidade de sinal renderá menos energias refletida. Adicionalmente, você pode ajustar o nível da recepção de modo que todo o áudio refletido seja mesmo mais adicional reduzido. É muito importante recordar fazer ajustes pequenos em um momento. Demasiada atenuação do sinal fará o áudio impossível ouvir-se em ambos os lados. Alternativamente, você pode contactar o portador e o pedido para ter as linhas verificadas. Em um circuito típico T1/PRI em America do Norte, o sinal de entrada deve ser DB -15. Se o nível de sinal é muito mais alto (DB -5, por exemplo), o eco será o resultado provável.

Mantenha um log de todos os atendimentos que experimentam o eco. A época do problema, do número de telefone da fonte, e do número chamado se todos forem gravados. Os gateways têm uma estadia fixa da Senhora 16 do cancelamento de eco. Se o atraso no áudio refletido é mais longo do que este, o chanceler do eco será incapaz de trabalhar corretamente. Esta não deve ser uma edição para chamadas local, e as chamadas interurbanas devem ter os chanceleres do eco externo construídos na rede no escritório central. Esta é uma das razões pelas quais é importante notar o número de telefone externo de um atendimento que as experiências ecoem.

Verifique suas cargas

As cargas do gateway e do telefone devem ser verificadas. Verifique CCO (Cisco Connection Online em www.cisco.com) para ver se há as cargas do software mais recente, as correções de programa novas, ou os Release Note em relação ao problema.

Áudio de sentido único ou não audio

O áudio de sentido único ocorre quando uma pessoa não pode ouvir uma outra pessoa durante um atendimento. Isto pode ser causado por um Cisco IOS gateway impróprio-configurado, por um Firewall, ou por um roteamento ou por um problema do gateway padrão, entre outras coisas.

Há um número causas para o áudio de sentido único ou não de audio durante um atendimento. A maioria de causa comum é um dispositivo impróprio-configurado. Por exemplo, o CallManager da Cisco segura a configuração de chamada para um Cisco IP Phone. O fluxo de áudio real ocorre entre os dois Telefones IP de Cisco (ou entre o Cisco IP Phone e um gateway). Assim, é inteiramente possível que o CallManager da Cisco pode sinalizar a um telefone de destino (que faz lhe o anel) quando o telefone que origina o atendimento não tem uma rota IP ao telefone de destino. Isto ocorre geralmente quando o gateway padrão no telefone é configurado impropriamente (manualmente ou no server do protocolo de configuração dinâmica host (DHCP)).

Se um atendimento tem consistentemente o áudio de sentido único, tente sibilar o Cisco IP Phone do destino usando um PC que esteja na mesma sub-rede como o telefone e tenha o mesmo gateway padrão. Tome um PC que esteja na mesma sub-rede como o telefone de destino (com o mesmo gateway padrão que o telefone de destino) e sibile o telefone da fonte. Ambos aqueles testes devem trabalhar. O tráfego de áudio pode igualmente ser afetado por um Firewall ou por um filtro de pacote (tal como Listas de acesso em um roteador) que possam obstruir o áudio em um ou ambos sentidos. Se o áudio de sentido único ocorre somente através de um Cisco IOS gateway ativado por voz, verifique a configuração com cuidado. Roteamento IP deve ser permitido (examine a configuração para se certificar de que nenhum Roteamento IP não está encontrado perto do começo da configuração). Igualmente, se você está usando o RTP Header Compression para salvar a largura de banda através de WAN, certifique-se de que está permitido em cada tráfego de voz levando do roteador que anexa ao circuito MACILENTO. Não deve haver uma situação onde o cabeçalho de RTP seja comprimido em uma extremidade mas não pode estar de-comprimido no outro lado de WAN. Um sniffer é muito uma ferramenta útil ao pesquisar defeitos problemas do áudio de sentido único porque você pode verificar que o telefone ou o gateway são realmente de emissão ou de recepção pacotes. Os CDR diagnósticos são úteis em determinar se um atendimento está experimentando o áudio de sentido único porque registram transmitido e os pacotes recebidos (consulte áudio perdido ou distorcido). Você pode igualmente pressionar o botão I Button duas vezes (rapidamente) em um Cisco IP Phone 7960 durante uma chamada ativa para ver detalhes sobre transmitido e pacotes recebidos.

Nota: Quando um atendimento estiver abafado (botão mudo pressionado em um telefone), nenhum pacote estará transmitido. O botão Hold Button para o fluxo de áudio, assim que nenhum pacote é enviado em um ou outro sentido. Quando o botão Hold Button é liberado, todos os contadores de pacote de informação estão restaurados. Recorde que a supressão de silêncio deve ser desabilitada em dispositivos para que os contadores TX e RX fiquem igual. A supressão de silêncio de desabilitação sistema-larga não afetará Cisco IOS gateway.

MTP e áudio de sentido único

Se você está usando o Media Termination Point (MTP) em um atendimento (para apoiar serviços suplementares tais como a posse e a transferência com dispositivos de H.323 que não apoiam a versão 2 de H.323), verifique para ver se o MTP atribuído está trabalhando corretamente. O Roteadores do Cisco IOS apoia o começo da versão 2 de H.323 na liberação 11.3(9)NA e 12.0(3)T. Começando com Cisco IOS Release 12.0(7)T, H.323 opcional aberto/LogicalChannel próximo é apoiado, de modo que o MTP com base no software seja exigido já não para serviços suplementares.

O dispositivo MTP, assim como bridge de conferência e transcodificador, construirá uma ponte sobre dois ou mais fluxos de áudio. Se o MTP, o bridge de conferência, ou o transcodificador não estão trabalhando corretamente, o áudio de sentido único ou a perda de áudio puderam ser experiente. Feche o MTP para encontrar se o MTP está causando o problema.

Redefinições de telefone

Ciclo ou restauração da força de vontade dos telefones para uma das seguintes duas razões:

  • Falha TCP que conecta ao CallManager da Cisco, ou

  • Falha receber um reconhecimento aos mensagens de keepalive do telefone.

Estão abaixo as etapas para pesquisar defeitos restaurações do telefone:

  1. Verifique os telefones e os gateways para assegurar-se de que você esteja usando as cargas do software mais recente.

  2. Verifique CCO (Cisco Connection Online em www.cisco.com) para ver se há as cargas do software mais recente, as correções de programa novas, ou os Release Note em relação ao problema.

  3. Verifique o visualizador de eventos para ver se há exemplos da restauração dos telefones. As restaurações do telefone são consideradas eventos da informação, segundo as indicações da seguinte ilustração.

    /image/gif/paws/30266/event_prop.gif

  4. Procure estes e todos os erros que puderem ter ocorrido em torno do tempo esse a restauração dos telefones.

  5. Comece um traço SDI e tente-o isolar o problema identificando todas as características comum nos telefones que estão restaurando. Por exemplo, verifique se todos estejam ficados situados na mesma sub-rede, o mesmo VLAN, e assim por diante. Olhe o traço e determine se:

    • as restaurações ocorrem durante um atendimento ou acontecem intermitentemente, ou

    • há todas as similaridades do modelo do telefone: Cisco IP Phone 7960, Cisco IP Phone 30VIP, e assim por diante.

  6. Comece um farejador de rastreamento em um telefone que restaure frequentemente. Depois que restaurou, olhe o traço para determinar se há alguma ocorrência das novas tentativas TCP. Em caso afirmativo, isto indica um problema de rede. O traço pode mostrar algumas consistências nas restaurações, tais como o telefone que restaura cada sete dias. Isto pôde indicar uma expiração do aluguel de DHCP cada sete dias (este valor é configuráveis pelo usuário e poderia ser cada dois minutos, e assim por diante).

Chamadas descartadas

As chamadas descartada ocorrem quando um atendimento é terminado prematuramente. Você pode usar CDR para determinar a causa possível das chamadas descartada, particularmente se o problema é intermitente. As chamadas descartada podem ser o resultado de um telefone ou reconfiguração de gateway (veja a seção acima) ou um problema de circuito, tal como a configuração incorreta de PRI ou o erro.

A primeira etapa é determinar se este problema é isolado a um telefone ou a um grupo de telefones. Talvez todos os telefones afetados são em uma sub-rede particular ou em um lugar. A próxima etapa é verificar o visualizador de eventos para ver se há restaurações de telefone ou de gateway.

/image/gif/paws/30266/drop_call.gif

Deve haver um aviso e um Mensagem de Erro para cada telefone que restaura. Neste caso, o problema é frequentemente que o telefone não pode manter sua conexão de TCP ao CallManager da Cisco viva, assim o CallManager da Cisco restaura a conexão. Isto pode ser porque um telefone foi desligado ou pode haver um problema na rede. Se este é um problema intermitente, pode ser útil usar o desempenho Microsoft para gravar registros do telefone.

/image/gif/paws/30266/drop_call2.gif

Se o problema parece ocorrer somente através de um determinado gateway, tal como um acesso DT-24+ de Cisco, o melhor curso de ação é permitir o seguimento e/ou ver os CDR. Os arquivos CDR dão uma causa da terminação (COT) que possa ajudar a determinar a causa do problema.

drop_call3.gif

Os valores da causa da desconexão (o origCause_value e o destCause_value, segundo que lado pendurado acima do atendimento), traçam aos códigos da causa da desconexão Q.931 (no decimal) que podem ser encontrados em tipos de switch ISDN, em códigos, e em valores. No exemplo acima, a causa 16 refere um esclarecimento de chamada normal. Se o atendimento está saindo um gateway ao PSTN, o CDR pode ser usado para determinar que lado está pendurando acima do atendimento. Muita da mesma informação pode ser obtida permitindo o seguimento no CallManager da Cisco. Use a ferramenta do traço somente como um último recurso ou se a rede não está ainda na produção.

Verifique suas cargas

Como com todo o problema, verifique as cargas do telefone e do gateway e CCO (Cisco Connection Online em www.cisco.com) para ver se há as cargas do software mais recente, as correções de programa novas, ou os Release Note em relação ao problema.

Problemas de recursos do Cisco CallManager

Os problemas podem ocorrer com características, tais como o bridge de conferência ou o Media Termination Point, que são usadas conjuntamente com o CallManager da Cisco. Alguns destes problemas da característica são causados por erros de configuração ou por uma falta dos recursos. Por exemplo, os usuários não podem poder às teleconferências se o número especificado de recursos da Conferência Ad-Hoc foi excedido. O resultado seria uma chamada descartada quando o usuário tentou iniciar a característica da conferência. Esta poderia parecer ser uma edição da característica do CallManager da Cisco, quando de fato é um problema com o número de recursos de conferência disponíveis. O número de vezes uns recursos de conferência foi exigido, mas não disponível, está um do desempenho Microsoft entrado contadores. O mesmo comportamento ocorre se há uns recursos de conferência disponíveis, mas o serviço de conferência tinha parado.

Codec/regiões: Incompatibilidade de codec

Se um usuário obtém uma reordenar tom quando fora-gancho indo, poderia ser o resultado do desacordo do codec entre regiões. Verifique que ambas as extremidades do atendimento apoiam pelo menos um codec comum (por exemplo, G.711). Se não, você precisará de usar transcodificadores.

Uma região especifica a escala dos codecs apoiados que podem ser usados com a cada um das outras regiões. Cada dispositivo pertence a uma região.

Nota:  A negociação codec com um roteador do Cisco IOS não é apoiada.

Region1<->Region2 = G.711 significam que um atendimento entre um dispositivo em Region1 e um dispositivo em Region2 pode usar G.711 ou qualquer outro o codec apoiado que exige a largura de banda igual ou inferior como G.711 (alguns codecs apoiados dentro de G.711, de G.729, de G.723, e assim por diante).

Nota:  Os seguintes codecs são apoiados para cada dispositivo:

  • ½ do ¿  do Cisco IP Phone 7960 G.711A-law/ï - lei, G.729AnnexB

  • SP12 Series do Cisco IP Phone e ½ do ¿  VIP30 G.711A-law/ï - lei, G.723.1

  • Gateway de acesso DE30 de Cisco e ½ do ¿  DT-24+ G.711A-law/ï - lei, G.723.1

Lugar

Se um usuário recebe uma reordenar tom após ter discado um número, poderia ser porque a alocação de largura de banda do CallManager da Cisco para o lugar de um dos dispositivos finais do atendimento foi excedida (menos do que 24k). O CallManager da Cisco verifica para ver se há a largura de banda 24k disponível para cada dispositivo antes de fazer um atendimento. Se menos do que a largura de banda 24k está disponível, o CallManager da Cisco não setup o atendimento e o usuário ouvirá uma reordenar tom.

12:42:09.017 Cisco CallManager|Locations: Orig=1 BW=12 Dest=0 BW=-1 
(-1 implies infinite bw available)

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallState tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallInfo CallingPartyName=, CallingParty=5003, CalledPartyName=,
 CalledParty=5005, tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputStartTone: 37=ReorderTone tcpHandle=0x4f1ad98 

O atendimento é estabelecido uma vez, o CallManager da Cisco subtrai a largura de banda dos lugar segundo o codec usado nesse atendimento. Se o atendimento está usando G.711, o CallManager da Cisco subtrai 80k; se o atendimento está usando G.723, o CallManager da Cisco subtrai 24k; se o atendimento está usando o G729, o CallManager da Cisco subtrai 24k.

Bridge de conferência

Use a informação seguinte para ajudar a não pesquisar defeitos “nenhum problema disponível do bridge de conferência”. Este podia ser um software ou um problema de hardware.

Primeiramente, verificação para ver se você tem quaisquer recursos disponíveis do bridge de conferência registrados com CallManager da Cisco (software ou hardware). Para fazer assim, você pode usar o desempenho Microsoft para verificar o número de “unicast AvailableConferences.”

O aplicativo fluente das mídias de voz IP de Cisco executa a função do bridge de conferência. Uma instalação de software da fluência das mídias de voz IP de Cisco apoiará 16 conferências disponíveis do unicast (3 povos/conferências), segundo as indicações do seguinte traço.

10:59:29.951 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB_kirribilli - Registered - ConfBridges= 16,
 Streams= 48, tcpHandle=4f12738

10:59:29.951 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??%? - DeviceType= 50, ResourcesAvailable= 16, 
deviceTblIndex= 0 

Uma porta E1 (o cartão WS-X6608-E1 contém as portas E1 8x) fornece cinco conferências disponíveis do unicast (tamanho máximo da conferência = 6), segundo as indicações do seguinte traço.

11:14:05.390 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB00107B000FB0 - Registered - ConfBridges= 5, Streams= 16, 
tcpHandle=4f19d64

11:14:05.480 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??% - DeviceType= 51, ResourcesAvailable= 5,
 deviceTblIndex= 0 

O seguinte traço do hardware na porta de voz 8 T1/E1 do Cisco catalyst 6000 e no Módulo de serviços indica que a porta E1 4/1 no cartão se registrou como um bridge de conferência com CallManager da Cisco.

greece-sup (enable) sh port 4/1

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/1 enabled 1 full - Conf Bridge


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/1 disable 00-10-7b-00-0f-b0 10.200.72.31 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/1 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/1 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/1 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/1 disabled disabled

Em segundo, verifique o número máximo de usuários configurado na conferência (ad hoc ou Reunião-mim) para determinar se o problema ocorreu porque este número foi excedido.

Problemas Transcoding

Se você instalou um transcodificador de hardware na porta de voz 8 T1/E1 do Cisco catalyst 6000 e no Módulo de serviços, e não trabalha como esperado (o significar não pode fazer atendimentos entre dois usuários sem o codec comum), verifique para ver se você tem quaisquer recursos do transcoder disponíveis registrados com CallManager da Cisco (este deve ser hardware). Use o desempenho Microsoft para verificar o número de “MediaTermPointsAvailable” disponível.

Uma porta E1 (o cartão WS-X6608-E1 contém as portas E1 8x) fornece recursos do Transcodificador/MTP para 16 atendimentos, segundo as indicações do seguinte traço.

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

O seguinte traço do hardware na porta de voz 8 T1/E1 do Cisco catalyst 6000 e no Módulo de serviços indica que a porta E1 4/2 no cartão se registrou como um MTP/transcoder com CallManager da Cisco.

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

Nota: A mesma porta E1 não pode ser configurada para o bridge de conferência e o Transcodificador/MTP

A fim fazer um atendimento entre dois dispositivos usando um código do Low Bit Rate (tal como G.729 e G.723) que não apoia o mesmo codec, uns recursos do transcoder são exigidos. Considere a seguinte ilustração:

/image/gif/paws/30266/ccm_ill.gif

Supõe que o CallManager da Cisco esteve configurado tais que o codec entre Region1 e Region2 é G.729. As seguintes encenações são possíveis:

  • Se o chamador no telefone A inicia um atendimento, o CallManager da Cisco realiza que é um Cisco IP Phone 7960, que acontece apoiar G.729. Depois que os dígitos foram recolhidos, o CallManager da Cisco determina que o atendimento é destinado para o usuário D que está na região 2. Desde que o dispositivo de destino igualmente apoia G.729, o atendimento estabelece-se e os fluxos do áudio diretamente entre o telefone A e o telefone D.

  • Se um chamador no telefone B, que tem um Cisco IP Phone 12SP+, devia iniciar um atendimento para telefonar a D, esta vez o CallManager da Cisco realizaria que o telefone de origem apoia somente G.723 ou G.711. O CallManager da Cisco precisaria de atribuir um recurso transcoding de modo que o áudio fluísse como G.711 entre o telefone B e o transcodificador, mas como G.729 entre o transcodificador e o telefone D. Se nenhum transcodificador estava disponível, o telefone do d do telefone soaria, mas assim que o atendimento fosse respondido, o atendimento desligaria.

  • Se um usuário no telefone B devia chamar o telefone F (Cisco IP Phone 12SP+), os dois telefones usariam realmente G.723, mesmo que G.729 fosse configurado como o codec para se usar entre as regiões. G.723 é usado porque ambos os valores-limite o apoiam e usa menos largura de banda do que G.729.

  • Se um sistema de correio de voz do Cisco uOne é adicionado (que apoia somente G.711) ou um roteador do Cisco IOS configurado para G.711 à região 1, a seguir um dispositivo transcoding deve ser usado se chamando da região 2. Se nenhum está disponível, a seguir o atendimento falhará.

Problemas dos recursos de MTP

Um problema dos recursos de MTP poderia ser o culpado se um atendimento é estabelecido e os serviços suplementares não estão disponíveis em um dispositivo de H.323 que não apoiasse H323v2. Primeiramente, determine se você tem quaisquer recursos de MTP disponíveis (software ou hardware) registrados com CallManager da Cisco. Você pode fazer assim usando o desempenho Microsoft para verificar o número de “MediaTermPointsAvailable.”

Um aplicativo de software MTP apoia 24 atendimentos (que usam o MTP para apoiar serviços suplementares com dispositivos de H.323 que não apoiam H.323v2), segundo as indicações do seguinte traço.

10:12:19.161 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP_kirribilli. - Registered - Supports 24 calls

Uma porta E1 (o cartão WS-X6608-E1 contém as portas E1 8x) fornece recursos de MTP para 16 atendimentos, segundo as indicações do seguinte traço.

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

O seguinte traço do hardware, da porta de voz 8 T1/E1 do Cisco catalyst 6000 e do Módulo de serviços, indica que a porta E1 4/2 no cartão se registrou como um MTP/transcoder com CallManager da Cisco.

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

Em segundo, veja se o Media Termination Point exigiu a caixa de seleção é selecionado na tela da configuração de gateway da administração do CallManager da Cisco.

Em terceiro lugar, verifique que o CallManager da Cisco atribuiu o número obrigatório de dispositivos MTP.

Do arquivo SDI:

15:22:23.848 Cisco CallManager|MediaManager(40) started

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - Transcoder 
  Enabled

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - party1(16777357), 
  party2(16777358), proxies=1, connections=2, current proxies=0

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - proxy 
  connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - allocating 
  MTP(ci=16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - start 2 connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777357) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777358) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource - 
  CI=16777359 count=1

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource 
  - CI=16777359 count=2

Planos de discagem

Um Plano de discagem é uma lista de números (e de grupos de números) que diga o CallManager da Cisco a que os dispositivos (telefones, gateways, e assim por diante) para enviar atendimentos quando alguma série de dígito é recolhida. Ele é análogo a uma tabela de roteamento estático em um roteador. Esteja por favor certo que seus conceitos, roteamento básico de chamada, e planeamento do Plano de discagem estiveram considerados com cuidado e configurados corretamente antes de tentar pesquisar defeitos uma edição potencial do Plano de discagem. Muito frequentemente, o problema encontra-se com planeamento e configuração.

Considere as seguintes perguntas ao pesquisar defeitos problemas dos Planos de discagem:

  • Que é o número de diretório (DN) que origina o atendimento?

  • Que é o Calling Search Space deste DN?

  • Se aplicável, que é o Calling Search Space do dispositivo (tal como um Cisco IP Phone) com que o DN é associado? Certifique-se de que você identifica o dispositivo correto; as aparências de linha múltipla são apoiadas, e é possível ter um DN em dispositivos múltiplos. Note o Calling Search Space do dispositivo. Se o atendimento é originado por um Cisco IP Phone, recorde que a linha particular (DN) e o dispositivo a que essa linha é vontade associada cada um tem o Calling Search Spaces. Serão combinados ao fazer um atendimento. Como um exemplo, supõe que a linha exemplo 1000 tem um Calling Search Space do AccessLevelX e o Cisco IP Phone que tem a extensão 1000 configurada nele tem o AccessLevelY como seu Calling Search Space. Consequentemente, ao fazer um atendimento dessa aparência de linha, o CallManager da Cisco procurará através das separações contidas no AccessLevelX e no AccessLevelY do Calling Search Space.

  • Que separações são associadas com o Calling Search Space?

  • Que é a separação do dispositivo a que o atendimento deve (ou não deva) ir?

  • Que é o número que está sendo discado? Note se e quando os chamadores estão obtendo um tom de discagem secundário, em toda a fase. Também, que os chamadores ouvem afinal os dígitos para ter sido entrado (requisite novamente, rápido sinal de ocupado)? Obtêm os toms de progresso antes que esperem ouvir qualquer coisa? Certifique-se que os chamadores esperam pelo menos o 10 segundos após ter incorporado o dígito último, desde que podem ter que esperar o temporizador entre dígitos para expirar.

  • Gerencia um relatório do plano de rota na administração do CallManager da Cisco. Use-o para examinar todas as rotas padrão para as separações que estão no Calling Search Space para o atendimento.

  • Caso necessário, adicionar ou altere as rotas padrão ou distribua filtros.

  • Se você pode encontrar a rota padrão a que o atendimento está sendo enviado, note a lista ou o gateway da rota a que o teste padrão aponta.

  • Para uma lista da rota, verificação que os grupos de rotas são parte da lista e que os gateways são parte dos grupos de rotas.

  • Verifique que os dispositivos aplicáveis estão registrados com CallManager da Cisco.

  • Se não há nenhum acesso ao CallManager da Cisco, consiga a tecnologia da mostra capturar esta informação e verificá-la.

  • Olhe para fora para @ o sinal. Este é um macro que possa expandir para incluir muitas coisas diferentes. É usado frequentemente em combinação com opções de filtragem.

  • Se um dispositivo não é parte de uma separação, seriam parte do zero ou a divisória padrão. Cada usuário deve poder chamar esse dispositivo. A separação nula é procurada sempre por último.

  • Se você disca um número exterior que esteja combinando um teste padrão 9.@ e tome os segundos 10 antes que o atendimento vá completamente, verifique as opções de filtragem. Um teste padrão 9.@, ao discar um número do 7-dígito, (à revelia) esperará os segundos 10. Você precisa de aplicar um filtro da rota ao teste padrão que diz LOCAL-AREA-CODE DOES-NOT-EXIST e END-OF-DIALING DOES-NOT-EXIST.

Separações

As separações da rota herdam as capacidades da manipulação de erros do Software do CallManager da Cisco. Isto é, um console e do arquivo SDI traço são fornecidos para a informação de registro e os Mensagens de Erro. Estas mensagens serão parte do componente da análise de dígitos dos traços. Mesmo com os traços abaixo, uma compreensão das configurações das separações e do Calling Search Spaces e que dispositivos está em cada separação, junto com seu Calling Search Space associado, é vital em determinar o problema.

O traço abaixo é um exemplo de um número discado que esteja no Calling Search Space do dispositivo. Para mais explicações detalhadas sobre traços SDI, reveja por favor os Casos Práticos neste documento.

08:38:54.968 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:54.968 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028|

  08:38:54.968 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

No componente da análise de dígitos do traço (acima), os “pss” (o espaço de pesquisa da separação, igualmente conhecido como o Calling Search Space) estão listados para o dispositivo que coloca o atendimento. Abaixo, você pode ver aquele “RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP” é as separações que este dispositivo é permitido chamar.

08:38:54.968 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:54.968 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 5 tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5")

  08:38:55.671 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.015 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.015 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="50")

  08:38:56.015 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.187 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.187 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="500")

  08:38:56.187 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.515 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 3 tcpHandle=0x6b88028

  08:38:56.515 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5003")

  08:38:56.515 Cisco CallManager|Digit analysis: analysis results

  08:38:56.515 Cisco CallManager||PretransformCallingPartyNumber=5000

Do exemplo acima, foi chave que você observa que “PotentialMatchesExist” é o resultado de uma análise de dígitos dos números que estiveram discados até que o exato - o fósforo é encontrado e o atendimento é distribuído em conformidade.

Está abaixo um traço onde o número que foi tentado ser discado (1001) não está no Calling Search Space do dispositivo. Além disso, foi chave que você nota que a rotina da análise de dígitos teve fósforos potenciais até que somente o primeiro dígito esteve discado. A rota padrão associada com o dígito "1" está em uma separação que não esteja no Calling Search Space do dispositivo, “RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP”. Consequentemente o telefone foi enviado a reordenar tom.

08:38:58.734 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:58.734 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

  08:38:58.734 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:58.734 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 1 tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="1")

  08:38:59.703 Cisco CallManager|Digit analysis: potentialMatches=NoPotentialMatchesExist

  08:38:59.703 Cisco CallManager|StationD - stationOutputStartTone: 37=ReorderTone 
  tcpHandle=0x6b88028

As separações da rota trabalham associando um nome da separação com cada número de diretório no sistema. O número de diretório pode ser chamado somente se o dispositivo chamando contém a separação dentro de uma lista de separações a que está permitida para colocar atendimentos em seu espaço de pesquisa da separação. Isto fornece o controle extremamente poderoso sobre o roteamento.

Quando um atendimento for colocado, tentativas da análise de dígitos de resolver o endereço discado somente naquelas separações que o espaço de pesquisa da separação especifica. Cada nome da separação compreende um subconjunto distinto do espaço de endereços global do que permite discagem. De cada separação listada, a análise de dígitos recupera o teste padrão que esse melhor combina a sequência dos dígitos discados. Então, entre dos testes padrões de harmonização, a análise de dígitos escolhe o melhor fósforo. Se dois testes padrões combinam ingualmente a sequência dos dígitos discados, a análise de dígitos seleciona o teste padrão associado com a separação alistada primeiramente no espaço de pesquisa da separação (para mais informação, reveja a documentação sobre o roteamento do Próximo-fósforo).

Segurança

O CallManager da Cisco pode ser configurado para criar um plano marcando seguro para usuários. Isto pode ser feito com o uso das separações e do Calling Search Spaces, além do que uma filtração mais comum baseada em seções “@” do macro (que representa o North American Numbering Plan) em uma rota padrão, tal como o código de área. As separações e o Calling Search Spaces são uma parte integral de Segurança e são especialmente úteis para ambientes do multi-inquilino e criação de um nível de usuário individual. Filtrar é um subconjunto do conceito do Calling Search Space/separação que pode adicionar a granularidade adicional ao plano da Segurança.

Esta é uma extensão à seção do Plano de discagem, acima. Seja recomendado, ele não é aconselhável executar um traço SDI ao tentar fixar um problema de filtração. Não há bastante informação e o potencial para causar o dano adicional é demasiado grande.

Execute uma tecnologia da mostra no CallManager da Cisco. A informação seguinte aparece na seção do filtro da rota.

Mostra-tecnologia
Nome dialPlanWizardG Cláusula
CiscoDallasInte 1 (INTERNATIONAL-
CiscoRTPTollByP 1 (== 9 AREA-CODE
CiscoRTPLongDis 1 (AREA-CODE EXI
CiscoDallasToll 1 (== 9 AREA-CODE
CiscoDallas911R 1 (== 911 do SERVIÇO
CiscoRTPLocal7D 1 (O AREA-CODE FAZ
CiscoDallasLong 1 (AREA-CODE EXI
CiscoRTP911RF 1 (== 911 do SERVIÇO
CiscoRTPInterna 1 (INTERNATIONAL-
CiscoDallasLoca 1 (LOCAL-AREA-COD

Infelizmente, este indicador está incompleto. , Contudo, dá uma lista de todos os filtros da rota no sistema. O comando show não permite que você considere que filtros são associados com que rota padrão. Um outro método para compreender melhor o Plano de discagem é ir à página do relatório do plano de rota. Está abaixo uma opção no lado direito distante “a ver no arquivo”.

file_dl.gif

A saída será um arquivo vírgula-separado que possa ser visto em Microsoft Excel ou em um aplicativo similar:

saída do arquivo da Mostra-tecnologia
Pattern/DN Separação Uso do teste padrão Nome de dispositivo Descrição do dispositivo
1000 Dispositivo SEP003094C2635E Telecaster
1010   Dispositivo SEP003094C2635E Telecaster
1111   Dispositivo SEP00308062CDF1 SEP00308062CDF1
1211   Dispositivo SEP00308062CDF1 SEP00308062CDF1
2999   Dispositivo SAA0010EB007FFE SAA0010EB007FFE
4444   Dispositivo SEP003094C26302 Convidado
4500   Conferência  
9.@ CiscoRTPLocalPT Rota CiscoRTPLocalRL
9.@ CiscoDallasLocalPT Rota CiscoDallasLocalRL
9.@ CiscoRTPIntlPT Rota CiscoRTPIntlRL
9.@ CiscoDallasLongDistPT Rota CiscoDallasLongDistRL
9.@ CiscoRTP911PT Rota CiscoRTP911RL
9.@ CiscoRTPLongDistPT Rota CiscoRTPLongDistRL
9.@ CiscoTollByPassToDallasPT Rota CiscoTollByPassToDallasRL
9.@ CiscoDallasIntlPT Rota CiscoDallasIntlRL
9.@ CiscoDallas911PT Rota CiscoDallas911RL
9.@ CiscoTollByPassToRTPPT Rota CiscoTollByPassToRTPRL

Isto mostra as rotas padrão e suas separações correspondentes. Não mostra os filtros da rota ou o Calling Search Spaces dos números de diretório. Mais informação está disponível no relatório do plano da rota real. Se você precisa de contactar o tac Cisco, você deve enviar esta página através do email (se o CallManager da Cisco é inacessível).

Está abaixo uma disposição das rotas padrão, das separações, e da lista da rota/grupo de rotas/gateway.

route_plan_rpt.gif

Resposta lenta do servidor

A resposta lenta do server poderia resultar se o duplex do interruptor não combina o duplex do servidor do CallManager da Cisco. Para o desempenho ótimo, ajuste o interruptor e o server a "100/Full." que nós não recomendamos usar o “automóvel” no interruptor ou no server. Você deve reiniciar o servidor do CallManager da Cisco para que a mudança tome o efeito.

Reordenar tom pelos gateways

Os usuários que colocam um atendimento através do gateway puderam obter uma reordenar tom se estão tentando fazer um atendimento restrito ou chamar um número que fosse obstruído. Uma reordenar tom pode ocorrer se o número discado é fora de serviço ou se o PSTN tem um problema do equipamento ou do serviço. Seja certo que o dispositivo que dá a reordenar tom se registrou. Também, verifique sua configuração de dial plan para assegurar-se de que o atendimento possa com sucesso ser distribuído.

Etapas para pesquisando defeitos reordenares tom através dos gateways:

  1. Verifique os gateways para assegurar-se de que você esteja usando as cargas do software mais recente.

  2. Verifique CCO (Cisco Connection Online em www.cisco.com) para ver se há as cargas do software mais recente, as correções de programa novas, ou os Release Note em relação ao problema.

  3. Comece um traço SDI e recreie o problema. As reordenares tom poderiam ser o resultado de um problema de configuração com controle de admissão com base na localização ou controle de admissão porteiro-baseado onde o CallManager da Cisco pôde limitar o número de atendimentos permissíveis. No traço SDI, encontre o atendimento para determinar se foi obstruído intencionalmente por uma rota padrão ou pelo Calling Search Space, ou por todo o outro ajuste de configuração.

  4. As reordenares tom podem igualmente ocorrer ao chamar com o PSTN. Verifique o traço SDI para ver se há mensagens de disconexão Q.931. Se uma mensagem da disconexão Q.931 esta presente, significa que o outro partido causou a disconexão e nós não podemos corrigir aquele.

Problemas de registro de gateway

Um da maioria de problemas comuns encontrados com gateways em um CallManager da Cisco é um problema de registro. O registro pode falhar por vários motivos.

Esta seção trata os dois similares, mas diferentes, categorias de gateways. O acesso analógico AS-X, AT-X e acesso digital DT-24+ e DE-30+ pertence a uma categoria. Estes gateways são as unidades stand-alone que não são conectadas diretamente a um processador de gerenciamento de rede (NMP). A segunda categoria inclui o acesso analógico WS-X6624 e o acesso digital WS-X6608. Estes gateways são lâminas instaladas em um chassi do catalizador 6000 com conectividade direta ao NMP para o controle e statusing.

Nos exemplos abaixo, as mensagens que estão sendo explicadas são identificadas usando o texto em negrito. Este é facilitá-lo para que você ver. Nas saídas de exibição reais, o texto não é negrito. Os exemplos são de um WS-X6624.

A primeira coisa a verificar é que o gateway é em serviço. Todos os gateways têm um diodo emissor de luz da “pulsação do coração” que pisque 1-second sobre, 1-second fora de quando o software de Gateway está sendo executado normalmente. Se este diodo emissor de luz não está piscando de todo, nem está piscando muito rapidamente, a seguir o software de Gateway não está sendo executado. Normalmente, isto conduzirá a uma reinicialização automática do gateway. Também, é normal para o gateway restaurar-se se não pode terminar o processo de registro após aproximadamente 2 a 3 minutos. Assim, você pode acontecer olhar o diodo emissor de luz da pulsação do coração quando o dispositivo restaurar. Se o teste padrão normal piscar não aparece no 10 a 15 segundos, a seguir o gateway sofreu uma falha grave. No gateway AS-X ou AT-X, o diodo emissor de luz da pulsação do coração é o LED verde do extrema direita que mostra no painel dianteiro. No gateway DT-24+ ou DE-30+, é o LED vermelho da extrema esquerda na margem superior do cartão. No acesso analógico WS-X6624, é um LED verde dentro da lâmina (não visível do painel dianteiro) à direita a margem da placa do extrema direita perto da parte dianteira. Finalmente, no acesso digital WS-X6608 há um diodo emissor de luz separado da pulsação do coração para cada um dos 8 períodos na lâmina. Há 8 LED vermelho através do cartão (não visível do painel dianteiro) aproximadamente 2/3 da maneira para trás.

A segunda coisa a verificar é que o gateway recebeu seu endereço IP de Um ou Mais Servidores Cisco ICM NT. Um gateway independente deve receber seu endereço IP de Um ou Mais Servidores Cisco ICM NT através do DHCP ou do BOOTP. Um Catalyst Gateway pode receber seu endereço IP de Um ou Mais Servidores Cisco ICM NT pelo DHCP, BOOTP, ou pela configuração manual com o NMP. Se você tem o acesso ao servidor DHCP, a melhor maneira de verificar um gateway independente é verificar que o dispositivo tem um aluguer proeminente em um endereço IP de Um ou Mais Servidores Cisco ICM NT. Se o gateway aparece em seu server, este é uma boa indicação, mas não definitivo. Suprima do aluguer no servidor DHCP, e restaure então o gateway. Se o gateway reaparece no server com um aluguer dentro de um par minutos, a seguir tudo está trabalhando muito bem nesta área. Se não, então ou o gateway não pode contactar o servidor DHCP (é um roteador configurado impropriamente e que não envia transmissões de DHCP? É o server que é executado?), ou não pode obter uma resposta positiva (é o pool do endereço IP de Um ou Mais Servidores Cisco ICM NT esgotado?). Se verificar estas sugestões não rende a resposta, use um farejador de rastreamento para determinar o problema específico.

Para um gateway do catalizador 6000, você deve certificar-se de que o NMP pode se comunicar com o gateway. Você pode verificar este tentando sibilar seu endereço IP interno do NMP. O endereço IP de Um ou Mais Servidores Cisco ICM NT está no formato:

127.1.module.port

Assim, em nosso exemplo, nós faríamos:

Console (enable) ping 127.1.7.1

127.1.7.1 is alive

Se sibilando trabalhos, então o comando show port mostrará a informação do endereço IP de Um ou Mais Servidores Cisco ICM NT. Certifique-se que a informação do endereço IP de Um ou Mais Servidores Cisco ICM NT e o endereço IP de Um ou Mais Servidores Cisco ICM NT TFTP estão corretos também. Se o gateway não está obtendo a informação de DHCP válida, o utilitário de controle (que pode ser fornecido pelo tac Cisco) pode ser usado para determinar o problema. Emita o comando de Cat6000 CLI:

porta modificação do tracy_start

Neste exemplo, o WS-X6624 é o módulo 7 e tem somente um único processador 860, assim que é a porta 1. O comando que nós emitiríamos é o tracy_start 7 1

A seguinte saída é realmente 860-console da porta na placa do gateway próprio. Contudo, a saída do comando tracy não é nada mais do que uma cópia remota da porta 860-console.

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.870 (CFG) Starting DHCP
00:00:02.870 (CFG) Booting DHCP for dynamic configuration.
00:00:06.570 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:06.570 (CFG) DHCP Server Response Processed, DHCPState = INIT_REBOOT
00:00:06.780 (CFG) IP Configuration Change! Restarting now...
00:00:10.480 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT
00:00:14:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:22:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:38:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT

Se o mensagem de timeout acima continua a enrolar por, a seguir há um problema que contacta o servidor DHCP. Certifique-se da porta de gateway do catalizador 6000 esteja no VLAN correto.

Esta informação está no comando show-++ port de antes. Se o servidor DHCP não está no mesmo VLAN que o gateway do catalizador 6000, a seguir certifique-se dos endereços IP auxiliares apropriados ter sido configurado para enviar as requisições DHCP ao servidor DHCP. É possível para o gateway obter colado no estado de INIT após uma mudança do número de VLAN até as restaurações do gateway. Quando neste estado, você puder tentar restaurar o gateway. Cada vez que os 860 são restaurados, sua sessão de controle estará perdida. Consequentemente, você deve fechar sua sessão existente e restabelecer um novo emitindo os comandos seguintes:

porta modificação do tracy_close

porta modificação do tracy_start

Se todo o isto verifica para fora e você ainda está vendo o DHCPState = os mensagens de INIT, a seguir verifique para ver se o servidor DHCP está funcionando corretamente. Em caso afirmativo, comece um farejador de rastreamento ver se os pedidos estão sendo enviados e se o server está respondendo.

Uma vez que o DHCP está trabalhando corretamente, o gateway terá um endereço IP de Um ou Mais Servidores Cisco ICM NT que permita o uso da utilidade de tracy debugging. Esta utilidade é uma característica incorporado do comando set NMP para os Catalyst Gateways e está disponível como um aplicativo de ajudante que seja executado em Windows 98/NT/2000 para os gateways independentes. Para usar o utilitário de controle do aplicativo de ajudante, você precisa o " conectar " ao gateway usando o endereço IP de Um ou Mais Servidores Cisco ICM NT a que é atribuído. Este aplicativo do rastreamento trabalha em todos os gateways, fornece um indicador separado do traço para cada gateway (até oito podem ser seguidos imediatamente), e permite que os traços sejam registrados diretamente a um arquivo que você especifica.

A próxima etapa é verificar que o endereço IP do servidor de TFTP esteve fornecido corretamente ao gateway. Isto é fornecido normalmente pelo DHCP na opção 66 (por nome ou endereço IP de Um ou Mais Servidores Cisco ICM NT), na opção 150 (endereço IP de Um ou Mais Servidores Cisco ICM NT somente), ou no si_addr (endereço IP de Um ou Mais Servidores Cisco ICM NT somente). Se seu server tem as opções múltiplas configuradas, o si_addr tomará a precedência sobre opção 150, que tomará a precedência sobre opção 66. Se a opção 66 fornece o DNS_NAME do servidor TFTP, a seguir o endereço IP de Um ou Mais Servidores Cisco ICM NT dos server DNS deve ter sido especificado pelo DHCP, e o nome dado entrada com na opção 66 deve resolver ao endereço IP do servidor de TFTP correto. Um Catalyst Gateway poderia ser configurado pelo NMP para desabilitar o DHCP, e o operador NMP deve então incorporar todos os parâmetros de configuração à mão no console, incluindo o endereço de servidor de TFTP.

Adicionalmente, os gateways tentarão sempre resolver o nome "CiscoCM1" através do DNS. Se bem sucedido, o endereço IP de Um ou Mais Servidores Cisco ICM NT do CiscoCM1 tomará a precedência sobre qualquer coisa o servidor DHCP ou o NMP di-lo para o endereço de servidor de TFTP, mesmo se o NMP tem o DHCP desabilitado.

Você pode verificar o endereço IP do servidor de TFTP atual em um gateway usando o utilitário de controle. Inscreva o comando seguinte obter o número das tarefas de configuração:

TaskID: 0

Cmd: mostre o tl

Procure uma linha com “configuração” ou “CFG” e use o número de correspondência como o taskID para a linha seguinte. Por exemplo, para o gateway do acesso digital WS-X6624, o comando despejar a informação DHCP é:

TaskID: 6

Cmd: mostre o DHCP

O endereço IP do servidor de TFTP é mostrado então claramente. Se não está correto, verifique que suas opções de DHCP e a outra informação que fornece está correta.

Uma vez que o endereço TFTP está correto, a próxima etapa é assegurar-se de que o gateway esteja obtendo seu arquivo de configuração do servidor TFTP. Se você vê o seguinte na saída do rastreamento, seu serviço TFTP não pode trabalhar corretamente ou o gateway não pôde ser configurado no CallManager da Cisco:

00:09:05.620 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server

    00:09:18.620 (CFG) TFTP 
    Error: Timeout Awaiting Server Response for .cnf File!

O gateway tentará conectar ao mesmo endereço IP de Um ou Mais Servidores Cisco ICM NT que o servidor TFTP se não recebe um arquivo de configuração. Isto é muito bem a menos que você estiver em um ambiente aglomerado em que o gateway precisa de receber sua lista de CallManagers redundantes de Cisco. Se o cartão não está recebendo sua informação de TFTP corretamente, verifique o serviço TFTP no CallManager da Cisco e certifique-se que está sendo executado. Também, verifique o traço TFTP no CallManager da Cisco também.

Um outro problema comum é que o gateway não está configurado corretamente no CallManager da Cisco. Um erro típico está incorporando um endereço MAC incorreto para o gateway. Se esta é a caixa, para um gateway do catalizador 6000, você obterá provavelmente aos seguintes mensagens no console NMP cada dois minutos:

2000 Apr 14 19:24:08 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:26:05 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:28:02 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously

Este é o que a saída do rastreamento olharia como se o gateway não está na base de dados do CallManager da Cisco:

00:00:01.670 (CFG) Booting DHCP for dynamic configuration.
00:00:05.370 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.370 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.370 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.370 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.370 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.370 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.370 (CFG) TFTP Error: .cnf File Not Found!
00:00:05.370 (CFG) Requesting SAADefault.cnf File From TFTP Server
00:00:05.380 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.380 (CFG) Updating Configuration ROM...
00:00:05.610 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.610 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.610 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.610 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.610 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.610 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:05.680 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:00:05.680 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:00:20.600 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:00:20.600 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:20.600 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:20.600 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM

Um outro problema de registro possível poderia ser se a informação de carga está incorreta ou o arquivo da carga é corrompido. O problema também pode ocorrer caso o servidor TFTP não esteja funcionando. Nesse caso, o rastreamento mostra claramente que o servidor TFTP reportou que o arquivo não foi encontrado:

00:00:07.390 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:08.010 GMSG: TFTP Request for application load A0021300
00:00:08.010 GMSG: CCM#0 CPEvent = LOADID --> CPState = AppLoadRequest
00:00:08.010 GMSG: ***TFTP Error: File Not Found***
00:00:08.010 GMSG: CCM#0 CPEvent = LOAD_UPDATE --> CPState = LoadResponse

Neste caso, você pode ver que o gateway está pedindo a carga A0021300 do aplicativo, embora o nome de carga correto seja A0020300. Para um gateway do catalizador 6000, o mesmo problema pode ocorrer quando uma carga do aplicativo novo precisa de obter também sua carga correspondente DSP. Se a carga nova DSP não é encontrada, uma mensagem similar aparecerá.

As seguintes mostras a saída quando um acesso analógico WS-X6224 for configurado para recuperar uma carga incorreta do aplicativo. A saída olha similar àquela de um gateway que não seja configurado no CallManager da Cisco:

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.030 (CFG) Starting DHCP
00:00:02.030 (CFG) Booting DHCP for dynamic configuration.
00:00:05.730 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.730 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.730 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.730 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.730 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.730 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.730 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.730 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.730 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.730 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.730 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.730 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.730 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:06.320 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
00:01:36.300 GMSG: CCM#0 CPEvent = TIMEOUT --> CPState = BadCCM
00:01:36.300 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:01:46.870 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:01:51.300 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:01:51.300 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:01:51.300 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:01:51.300 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:01:51.300 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:01:51.300 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:01:51.890 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse

A diferença aqui é que o gateway obtém colado na fase de LoadResponse e cronometra eventualmente para fora. Este problema pode ser resolvido corrigindo o nome de arquivo da carga na área dos padrões do dispositivo da administração do CallManager da Cisco.

Problemas com gatekeeper

Antes de começar qualquer Troubleshooting de Gateway-To-Gatekeeper, verifique que há uma conectividade IP dentro da rede. Supondo que há uma conectividade IP, use a informação nesta seção para pesquisar defeitos seu gateway.

Troncos inter-grânulo somente

Note que o controle do porteiro para a revisão do CallManager da Cisco 3.0(1) está somente disponível para troncos inter-grânulo. O controle do porteiro é configurável para outros dispositivos, mas a configuração não é apoiada.

Rejeições da admissão (ARJ)

Os ARJ são emitidos quando o CallManager da Cisco se registrou com o porteiro, mas não podem enviar uma chamada telefônica. Os problemas de configuração no porteiro devem ser o foco preliminar quando o porteiro está emitindo um ARJ. Contudo, estão abaixo as diretrizes gerais para pesquisar defeitos:

  1. Verifique a conectividade IP do gateway ao porteiro.

  2. Mostre o estado do porteiro: verifique que o estado do porteiro está acima.

  3. Há uma sub-rede da zona definida no porteiro? Em caso afirmativo, verifique que a sub-rede do gateway está nas sub-redes permitidas.

Rejeições do registro (RRJ)

Os RRJ são emitidos quando o CallManager da Cisco não pode se registrar com o porteiro. Os problemas de configuração no porteiro devem ser o foco preliminar quando o porteiro está emitindo um RRJ.

Contudo, estão aqui as diretrizes gerais para pesquisar defeitos:

  1. Verifique a conectividade IP do gateway ao porteiro.

  2. Mostre o estado do porteiro: verifique que o estado do porteiro está acima.

  3. Há uma sub-rede da zona definida no porteiro? Em caso afirmativo, verifique que a sub-rede do gateway está nas sub-redes permitidas.

Sinal de ocupado rápido ao discar o número piloto do correio de voz

Se você parou e gerenciador de chamada começado após ter feito a alguns mudanças, certifique-se de que você começa processos do utel, do ulite, do ulogremover e do upilot. Isto foi testado no laboratório pelo submitter de CM 2.4.3 e pelo uone 4.1e. Essencialmente os dispositivos UM não se registrarão novamente com gerenciador de chamada a menos que os processos forem reiniciados.

Casos Práticos mim: Chamadas de intra-grânulo de Cisco IP Phone para Cisco IP Phone

Estes Casos Práticos discutem em detalhe o fluxo de chamadas entre dois Telefones IP de Cisco dentro de um conjunto, chamado uma chamada de intra-grânulo. Estes Casos Práticos igualmente centram-se sobre a iniciação do CallManager da Cisco e do Cisco IP Phone, o registro, e os processos de keepalive. Isso é seguido por uma explicação detalhada de um fluxo da chamada de intra-grânulo. Estes processos são explicados usando utilitários de rastreamento e ferramentas discutidos em uma seção anterior.

Topologia de exemplo

O seguinte diagrama descreve o exemplo de topologia para estes Casos Práticos. No diagrama há dois conjuntos nomeados Conjunto 1 e conjunto 2. Os dois CallManagers de Cisco no conjunto 1 estão chamados CCM3 e CCM4, quando os dois CallManagers de Cisco no conjunto 1 forem nomeados CCM1 e CCM2. Os traços recolhidos para estes Casos Práticos são do CCM1, que é ficado situado no conjunto 2. O fluxo de chamadas é baseado nos dois Telefones IP de Cisco no conjunto 2. Os endereços IP de Um ou Mais Servidores Cisco ICM NT destes dois Telefones IP de Cisco são 172.16.70.230 (número de diretório 1000) e 172.16.70.231 (número de diretório 1001), respectivamente.

ios_gatekeeper.gif

Processo de inicialização do Cisco IP Phone

Do Cisco IP Phone da iniciação (ou a “bota o processo acima”) é explicado em detalhe abaixo.

  1. Na iniciação, o Cisco IP Phone envia um pedido ao servidor DHCP obter um endereço IP de Um ou Mais Servidores Cisco ICM NT, um endereço de servidor de DNS, e um nome ou um endereço de servidor TFTP, se apropriado. As opções são ajustadas no servidor DHCP (opção 066, opção 150, e assim por diante). Igualmente obtém um endereço de gateway padrão se ajustado no servidor DHCP (opção 003).

  2. Se um nome de DNS do TFTP separa está enviado pelo DHCP, a seguir um DNS separa o endereço IP de Um ou Mais Servidores Cisco ICM NT está exigido para traçar o nome a um endereço IP de Um ou Mais Servidores Cisco ICM NT. Esta etapa é contorneada se o servidor DHCP envia o endereço IP de Um ou Mais Servidores Cisco ICM NT do servidor TFTP. Estude neste caso, o servidor DHCP enviado o endereço IP de Um ou Mais Servidores Cisco ICM NT do TFTP porque o DNS não foi configurado.

  3. Se um nome de servidor TFTP não é incluído na resposta DHCP, a seguir o Cisco IP Phone usa o nome do servidor de padrão.

  4. O arquivo do arquivo de configuração (.cnf) é recuperado do servidor TFTP. Todos os arquivos do .cnf têm o nome SEP<mac_address>.cnf, onde o “SEP” é um acrônimo para o telefone dos Ethernet de Selsius. Se isto é a primeira vez o telefone está registrando-se com o CallManager da Cisco, a seguir um arquivo padrão, SEPdefault.cnf, é transferido ao Cisco IP Phone. Estude neste caso, o primeiro Cisco IP Phone usa o endereço IP 172.16.70.230 (seu MAC address é SEP0010EB001720), e o segundo Cisco IP Phone usa o endereço IP 172.16.70.231 (seu MAC address é SEP003094C26105).

  5. Todos os arquivos do .cnf incluem o endereço IP de Um ou Mais Servidores Cisco ICM NT do CallManager da Cisco preliminar e secundário. O Cisco IP Phone usa o endereço IP de Um ou Mais Servidores Cisco ICM NT para contactar o CallManager da Cisco principal e para registrar-se.

  6. Uma vez que o Cisco IP Phone conectou e se registrou com CallManager da Cisco, o CallManager da Cisco diz ao Cisco IP Phone que versão executável (chamada um ID de carga) a ser executado. Se a versão especificada não combina a versão da execução no Cisco IP Phone, o Cisco IP Phone pedirá o executável novo do servidor TFTP e restaurá-lo-á automaticamente.

O seguinte exemplo do farejador de rastreamento resume o processo de inicialização do telefone. Este exemplo de rastreamento não é tomado para o exemplo de topologia destes Casos Práticos, mas fornece um exemplo da série de eventos que ocorre durante o processo de inicialização do Cisco IP Phone.

sniffer_trace.gif

Processo de registro de estação mirrada

Os Telefones IP de Cisco comunicam-se com o CallManager da Cisco usando o protocolo de estação mirrada de Cisco. O processo de registro permite que uma estação mirrada, tal como um Cisco IP Phone, informe o CallManager da Cisco de sua existência e faça a chamada possível. A seguinte figura mostra as mensagens diferentes que são trocadas entre o Cisco IP Phone (a “estação”) e o CallManager da Cisco.

/image/gif/paws/30266/skinny.gif

Os mensagens principais no processo de registro da estação mirrada são descritos na tabela a seguir.

Descrições de processo de registro da estação mirrada
Mensagem Descrição
Registro da estação A estação envia esta mensagem para anunciar sua existência ao CallManager da Cisco de controlo.
Restauração da estação O CallManager da Cisco envia esta mensagem para comandar a estação para restaurar seus processos.
Porta IP da estação A estação envia esta mensagem para fornecer o CallManager da Cisco a porta do User Datagram Protocol (UDP) a ser usada com o córrego RTP.
O registro da estação reconhece O CallManager da Cisco envia esta mensagem para reconhecer o registro de uma estação.
Rejeição do registro da estação O CallManager da Cisco envia esta mensagem para rejeitar uma tentativa do registro do telefone indicado.
 
char text[StationMaxDisplayTextSize]; 

};
Em que: o texto é uma sequência de caracteres, um comprimento máximo de 33 bytes, contendo uma descrição textual da razão que o registro está rejeitado.
Pedido das capacidades da estação O CallManager da Cisco envia esta mensagem para pedir os recursos atual da estação. As capacidades da estação podem incluir o padrão de compactação e as outras capacidades de H.323.
Pedido da versão da estação A estação envia esta mensagem para pedir o número de versão do carregamento de software para a estação.
Resposta da versão da estação O CallManager da Cisco envia esta mensagem para informar a estação do número de versão de software apropriado.
Resposta das capacidades da estação A estação envia esta mensagem ao CallManager da Cisco em resposta a um pedido das capacidades da estação. As capacidades da estação são postas em esconderijo no CallManager da Cisco e usadas para negociar recursos de terminal com um terminal complacente de H.323.
Pedido do botão de template da estação A estação envia esta mensagem para pedir a definição de botão de template para esse terminal específico ou Cisco IP Phone.
Resposta do botão de template da estação O CallManager da Cisco envia esta mensagem para atualizar a informação do botão de template contida na estação.
Pedido da data do tempo de estação A estação envia esta mensagem para pedir a data atual e hora para o uso interno e para indicar como uma sequência de caracteres de texto.
A estação define horas e data O CallManager da Cisco usa esta mensagem para fornecer a informação da data e hora à estação. Fornece a sincronização de tempo para as estações.

Fluxo de chamada de Telefone IP Cisco para Telefone IP Cisco dentro de um cluster

Esta seção descreve um Cisco IP Phone (número de diretório 1000) que chama um outro Cisco IP Phone (número de diretório 1001) dentro do mesmo conjunto. O conjunto é um grupo de CallManagers de Cisco que têm um base de dados SQL comum do Publicador e muitos Bases de dados de SQL de assinante.

Em nosso exemplo de topologia, o CCM1 é o editor e o CCM2 é um subscritor. Os dois Telefones IP de Cisco (1000 e 1001) são registrados ao CCM1 e ao CCM2, respectivamente. O fluxo de chamadas é mostrado no diagrama abaixo. Os dois CallManagers de Cisco dentro de um conjunto comunicam-se um com o otro usando o protocolo de controle do Intracluster (ICCP). Quando um Cisco IP Phone vai fora-gancho, abre uma sessão da estação mirrada do controle (com o TCP como o protocolo subjacente) com o CallManager da Cisco. Depois que a sinalização do Controle de chamadas é estabelecida entre os dois Telefones IP de Cisco e seus CallManagers respectivos de Cisco, o córrego RTP começa fluir diretamente entre os dois telefones, segundo as indicações do diagrama abaixo. As mensagens do fluxo de chamadas de estação mirrada para esta chamada de intra-grânulo são explicadas na próxima seção.

/image/gif/paws/30266/1000_calls_1001.gif

Intercâmbio de Cisco IP Phone com Cisco IP Phone de mensagens de estação skinny durante o fluxo da chamada

A seguinte figura mostra uma troca da amostra das mensagens entre duas estações mirrada. A estação mirrada, ou o Cisco IP Phone, iniciam uma conexão ao CallManager da Cisco, e então o CallManager da Cisco executa a análise de dígitos antes de abrir uma sessão do controle com a estação mirrada do destino. Enquanto o seguinte diagrama indica, os mensagens de estação mirrada estão redigidos usando o inglês simples assim que podem prontamente ser compreendidos por utilizadores finais. Devido a isto, estas mensagens não são explicadas nesta seção. Contudo, estes mensagens de estação mirrada do fluxo de chamadas são explicados com maiores detalhes nas seções mais recente quando os traços estão sendo examinados.

/image/gif/paws/30266/call_flow.gif

Processo de inicialização do Cisco CallManager

Nesta seção o processo de inicialização de CallManager da Cisco será explicado com a ajuda dos traços que são capturados do CCM1 (identificado pelo endereço IP de Um ou Mais Servidores Cisco ICM NT 172.16.70.228). Como descrito previamente, os traços SDI são muito uma ferramenta do Troubleshooting efetivo porque detalham cada pacote enviado entre valores-limite. Esta seção descreverá os eventos que ocorrem quando o CallManager da Cisco é inicializado. Compreender como ler o traço ajuda o a pesquisar defeitos corretamente os vários processos do CallManager da Cisco, e o efeito daqueles processos em serviços tais como Conferências, encaminhamento de chamada, e assim por diante.

Os seguintes mensagens do utilitário de rastreamento do CallManager da Cisco SDI mostram o processo de inicialização em um dos CallManagers de Cisco, neste caso, CCM1. Reveja as descrições de cada mensagem abaixo.

  • A primeira mensagem indica que o CallManager da Cisco começou seu processo de inicialização.

  • A segunda mensagem indica que o CallManager da Cisco leu os valores do base de dados do padrão, que seriam os preliminares ou a base de dados do editor (para este caso).

  • A terceira mensagem indica que o CallManager da Cisco escutou as várias mensagens na porta TCP 8002.

  • A quarta mensagem mostra que, após a escuta estas mensagens, o CallManager da Cisco adicionou um segundo CallManager da Cisco a sua lista: CCM2 (172.16.70.229).

  • A quinta mensagem indica que o CallManager da Cisco começou e é a versão do CallManager da Cisco running 3.0.20.

16:02:47.765 CCM|CMProcMon - CallManagerState Changed - Initialization Started.
16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CM Database Defaults Read
16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: [172.16.70.228], Listen Port: [8002]
16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: [172.16.70.229]
16:02:51.031 CCM|NodeId: 1, EventId: 1 EventClass: 3 EventInfo: Cisco CallManager Version=<3.0(0.20)> started

Processos de início automático

Uma vez que o CallManager da Cisco é em serviço, começa diversos outros processos dentro dse. Alguns destes processos são mostrados abaixo, incluindo o gerenciador de Ponto de Transmissão múltipla, o gerenciador de UnicastBridge, a análise de dígitos, e a lista da rota. As mensagens descritas durante estes processos podem ser muito úteis ao pesquisar defeitos um problema relativo às características no CallManager da Cisco.

Por exemplo, supõe que as lista da rota não estão funcionando e são inusáveis. Para pesquisar defeitos este problema, você monitoraria estes traços para determinar se o CallManager da Cisco começou RoutePlanManager e se está tentando carregar as lista da rota. Na configuração de exemplo abaixo, RouteListName= '' ipwan” e RouteGroupName= '' ipwan” estão carregando e estão começando.

16:02:51.031 CCM|MulicastPointManager - Started
16:02:51.031 CCM|UnicastBridgeManager - Started
16:02:51.031 CCM|MediaTerminationPointManager - Started
16:02:51.125 CCM|MediaCoordinator(1) - started
16:02:51.125 CCM|NodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager started
16:02:51.234 CCM|NodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager started
16:02:51.390 CCM|NodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis started
16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists
16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists
16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups
16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection Order
16:02:51.671 CCM|RouteList - RouteListName=''ipwan''
16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan''
16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection Order
16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''

O seguinte traço mostra o grupo de rotas que adiciona o dispositivo 172.16.70.245, que é CCM3 situado no conjunto 1 e considerou um dispositivo de H.323. Neste caso, o grupo de rotas é criado para distribuir atendimentos ao CCM3 no conjunto 1 com permissão do Gatekeeper. Se há um problema que distribui o atendimento a um Cisco IP Phone situado no conjunto 1, a seguir os seguintes mensagens ajudá-lo-iam a encontrar a causa do problema.

16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup -AllPorts

Parte do processo de inicialização mostra que o CallManager da Cisco está adicionando DN. Revendo estas mensagens, você pode determinar se o CallManager da Cisco leu o número de diretório do base de dados.

16:02:51.671 CCM|NodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control started
16:02:51.843 CCM|ProcessDb - Dn = 2XXX, Line = 0, Display = , RouteThisPattern, 
NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause =
16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCM|ForwardManager - Started
16:02:51.984 CCM|CallParkManager - Started
16:02:52.046 CCM|ConferenceManager - Started

Nos seguintes traços o gerenciador de dispositivo no CallManager da Cisco está inicializando estaticamente dois dispositivos. O dispositivo com endereço IP 172.17.70.226 é um porteiro e o dispositivo com endereço IP 172.17.70.245 é um outro CallManager da Cisco em um cluster diferente. Esse CallManager da Cisco é registrado como um gateway de H.323 com este CallManager da Cisco.

16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.226
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.245

Processo de registro do Cisco CallManager

Uma outra parte importante do traço SDI é o processo de registro. Quando um dispositivo é posto acima, obtém a informação através do DHCP, conecta-a ao servidor TFTP para seu arquivo do .cnf, e conecta-a então ao CallManager da Cisco especificado no arquivo do .cnf. O dispositivo podia ser um gateway MGCP, um gateway skinny, ou um Cisco IP Phone. Consequentemente, é importante poder descobrir mesmo se os dispositivos se registraram com sucesso na rede do Cisco AVVID.

No seguinte traço, o CallManager da Cisco recebeu novas conexões para o registro. Os dispositivos registrando-se são "MTP_nsa-cm1" (serviços MTP no CCM1), e "CFB_nsa-cm1" (serviço do bridge de conferência no CCM1). Estes são serviços de software que são executado no CallManager da Cisco mas são tratados internamente como serviços externos diferentes e atribuídos consequentemente um tcpHandle, número do soquete, e número de porta assim como um nome de dispositivo.

16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbaa00, 
Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[0,0,0]
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fe05e8, 
Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[0,0,0]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=MTP_nsa-cm1, 
TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[1,45,2]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=CFB_nsa-cm1, 
TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[1,96,2]

No seguinte traço, os mensagens de estação mirrada são enviados entre um Cisco IP Phone e o CallManager da Cisco. O Cisco IP Phone (172.16.70.231) está registrando-se com CallManager da Cisco. Refira as descrições dos mensagens de estação mirrada mais cedo nesta seção para mais informação. Assim que o CallManager da Cisco receber a requisição de registro de um Cisco IP Phone, atribui um número do tcpHandle a este dispositivo. Este número permanece o mesmo até o dispositivo ou o CallManager da Cisco é reiniciado. Consequentemente, você pode seguir todos os eventos relativos a um dispositivo particular procurando por ou manter-se a par do número do tcpHandle do dispositivo, que aparece dentro encanta. Também, observe que o CallManager da Cisco fornece o ID de carga ao Cisco IP Phone. Baseado neste ID de carga, o Cisco IP Phone executa o arquivo executável (adquirido do servidor TFTP) que corresponde ao dispositivo.

16:02:57.000 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbbc30, 
Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[0,0,0]
16:02:57.046 CCM|NodeId: 1, EventId: 1703 EventClass: 2 EventInfo: Station Alarm, 
TCP Handle: 4fbbc30, Text: Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr 
LastTime=A P1: 2304(900) P2: -414838612(e74610ac)
16:02:57.046 CCM|StationInit - ***** InboundStim - AlarmMessageID 
tcpHandle=0x4fbbc30 Message="Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr LastTime=A" 
Parm1=2304 (900) Parm2=-414838612 (e74610ac)
16:02:57.093 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=SEP003094C26105, 
TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]
16:02:57.093 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) 
tcpHandle=0x4fbbc30

Processo de manutenção de atividades do Cisco CallManager

Amba a estação, o dispositivo, ou o serviço e o CallManager da Cisco usam os seguintes mensagens para manter um conhecimento do canal de comunicações entre eles. As mensagens são usadas para começar a sequência do KeepAlive que se assegura de que o link de comunicações entre o CallManager da Cisco e a estação permaneça ativo. Os seguintes mensagens podem originar do CallManager da Cisco ou da estação.

16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=MTP_nsa-cm2, TCPHandle=0x4fa7dc0, Socket=0x568, IPAddr=172.16.70.229, Port=1556, 
StationD=[1,45,1]
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=CFB_nsa-cm2, TCPHandle=0x4bf8a70, Socket=0x57c, IPAddr=172.16.70.229, Port=1557, 
StationD=[1,96,1]
16:03:06.640 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP0010EB001720, TCPHandle=0x4fbb150, Socket=0x600, IPAddr=172.16.70.230, Port=49211, 
StationD=
[1,85,2]
16:03:06.703 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, 
StationD=
[1,85,1]

As mensagens no seguinte traço descrevem a sequência do KeepAlive que indica que o link de comunicações entre o CallManager da Cisco e a estação é ativo. Além disso, estas mensagens podem originar pelo CallManager da Cisco ou pela estação.

16:03:02.328 CCM|MediaTerminationPointControl - stationOutputKeepAliveAck tcpHandle=4fa7dc0
16:03:02.328 CCM|UnicastBridgeControl - stationOutputKeepAliveAck tcpHandle=4bf8a70
16:03:06.703 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) tcpHandle=0x4fbbc30
16:03:06.703 CCM|StationD - stationOutputKeepAliveAck tcpHandle=0x4fbbc30

Rastreios de fluxo de chamadas intraclusters Cisco CallManager

Os seguintes traços SDI exploram em detalhe o fluxo da chamada de intra-grânulo. Os Telefones IP de Cisco no fluxo de chamadas podem ser identificados pelo DN, pelo tcpHandle, e pelo endereço IP de Um ou Mais Servidores Cisco ICM NT. Um Cisco IP Phone (DN=1001, tcpHandle=0x4fbbc30, IP address=172.16.70.231) situado no conjunto 2 está chamando um outro Cisco IP Phone no mesmo conjunto (DN=1000, tcpHandle= 0x4fbb150, endereço IP de Um ou Mais Servidores Cisco ICM NT = 172.16.70.230). Recorde que você pode seguir um dispositivo através do traço olhando o valor, o selo de tempo, ou o nome do punho TCP do dispositivo. O valor do punho TCP para o dispositivo permanece o mesmo até que o dispositivo esteja recarregado ou vai off line.

Os seguintes traços mostram que o Cisco IP Phone (1001) tem o fora-gancho ido. O traço abaixo mostra os mensagens exclusiva, o punho TCP, e o número chamado quais são indicados no Cisco IP Phone. Não há nenhum número chamado neste momento, porque o usuário não tentou discar nenhuns dígitos. A informação abaixo é sob a forma dos mensagens de estação mirrada entre os Telefones IP de Cisco e o CallManager da Cisco.

16:05:41.625 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:41.625 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001

O traço seguinte mostra os mensagens de estação mirrada que vão do CallManager da Cisco a um Cisco IP Phone. A primeira mensagem é girar sobre a lâmpada no Cisco IP Phone da chamada originada.

16:05:41.625 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn 
tcpHandle=0x4fbbc30

O mensagem stationOutputCallState é usado pelo CallManager da Cisco para notificar a estação de determinada informação atendimento-relacionada.

16:05:41.625 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30

O mensagem de status stationOutputDisplayPrompt é usado pelo CallManager da Cisco para fazer com que um mensagem imediata atendimento-relacionado seja indicado no Cisco IP Phone.

16:05:41.625 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

O mensagem stationOutputSelectSoftKey é usado pelo CallManager da Cisco para fazer com que a estação mirrada selecione um grupo específico de chaves macias.

16:05:41.625 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30

A mensagem seguinte é usada pelo CallManager da Cisco para instruir a estação mirrada a respeito da linha correta contexto para o indicador.

16:05:41.625 CCM|StationD - stationOutputActivateCallPlane tcpHandle=0x4fbbc30

No seguinte mensagem, o processo da análise de dígitos está pronto para identificar dígitos recebidos e verificá-los para ver se há fósforos potenciais de roteamento no base de dados. A entrada, cn=1001, representa o número do chamador. o "" do dd= representa o dígito discado, que mostraria o part number chamado. Note que mensagens de Init de Estação estão enviados pelo telefone, as mensagens de StationD são enviadas pelo CallManager da Cisco, e a análise de dígitos é executada pelo CallManager da Cisco.

16:05:41.625 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:41.625 CCM|Digit analysis: potentialMatches=PotentialMatchesExist

Os seguintes debugam a mensagem mostram que o CallManager da Cisco está fornecendo o tom de discagem interno ao Cisco IP Phone da chamada originada.

16:05:41.625 CCM|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x4fbbc30

Uma vez que o CallManager da Cisco detecta um mensagem recebida e reconhece o botão 1 do teclado numérico foi pressionado no Cisco IP Phone, para imediatamente o tom da saída.

16:05:42.890 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 1 
tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:42.890 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1")
16:05:42.890 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.203 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.203 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="10")
16:05:43.203 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.406 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.406 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="100")
16:05:43.406 CCM|Digit analysis: potentialMatches=PotentialMatchesExist|
16:05:43.562 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.562 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1000")

Uma vez que o CallManager da Cisco recebeu bastante dígitos para combinar, fornece os resultados da análise de dígitos em um formato da tabela. Alguns dígitos extra pressionados no telefone depois que este ponto será ignorado pelo CallManager da Cisco, desde que um fósforo tem sido encontrado já.

16:05:43.562 CCM|Digit analysis: analysis results
16:05:43.562 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=1000
|DialingRoutePatternRegularExpression=(1000)
|PotentialMatches=PotentialMatchesExist
|DialingSdlProcessId=(1,38,2)
|PretransformDigitString=1000
|PretransformPositionalMatchList=1000
|CollectedDigits=1000
|PositionalMatchList=1000
|RouteBlockFlag=RouteThisPattern

O traço seguinte mostra que o CallManager da Cisco está mandando esta informação a um telefone do número chamado (o telefone é identificado pelo número do tcpHandle).

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbb150

O traço seguinte indica que o CallManager da Cisco está pedindo a lâmpada piscar para a indicação da chamada recebida no Cisco IP Phone do número chamado.

16:05:43.578 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampBlink tcpHandle=0x4fbb150

Nos seguintes traços, o CallManager da Cisco está fornecendo a campainha, a notificação de exibição, e a outra informação atendimento-relacionada ao Cisco IP Phone do número chamado. Além disso, você pode ver que todas as mensagens estão dirigidas ao mesmo Cisco IP Phone porque o mesmo tcpHandle é usado durante todo os traços.

16:05:43.578 CCM|StationD - stationOutputSetRinger: 2=InsideRing tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayNotify tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbb150

Observe que o CallManager da Cisco igualmente está fornecendo a informação similar ao Cisco IP Phone da chamada originada. Além disso, o tcpHandle é usado para diferenciar-se entre Telefones IP de Cisco.

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=1000, tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbbc30

No traço seguinte, o CallManager da Cisco fornece uma alerta ou um tom de toque ao Cisco IP Phone da chamada originada, notificando que a conexão esteve estabelecida.

16:05:43.578 CCM|StationD - stationOutputStartTone: 36=AlertingTone tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

Neste momento, o Cisco IP Phone do número chamado vai fora-gancho. Consequentemente, o CallManager da Cisco para de gerar o tom da campainha à chamada originada.

16:05:45.140 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30

Nos seguintes mensagens, o CallManager da Cisco faz com que a estação mirrada comece a receber um córrego do unicast RTP. Para fazer assim, o CallManager da Cisco fornece o endereço IP de Um ou Mais Servidores Cisco ICM NT da informação do número chamado assim como do codec, e do tamanho do pacote no milissegundo (milissegundos). PacketSize é um inteiro que contém o tempo da amostra nos milissegundos usados para criar os pacotes RTP.

Nota: Este valor é ajustado normalmente a 30msec. Neste caso, é ajustado a 20msec.

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbbc30 
myIP: e74610ac (172.16.70.231)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

Similarmente, o CallManager da Cisco fornece a informação ao número chamado (1000).

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbb150 
myIP: e64610ac (172.16.70.230)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

O CallManager da Cisco recebeu o mensagem de reconhecimento do número chamado para estabelecer o canal aberto para o córrego RTP, assim como o endereço IP de Um ou Mais Servidores Cisco ICM NT do número chamado. Esta mensagem é informar o CallManager da Cisco de duas partes de informação sobre a estação mirrada. Primeiramente, contém o estado da ação aberta. Em segundo, contém o endereço de porta e o número da recepção para a transmissão à extremidade remota. O endereço IP de Um ou Mais Servidores Cisco ICM NT do transmissor (que chama a parte) do córrego RTP é ipAddr, e PortNumber é o número de porta IP do transmissor de fluxo de RTP (chamada originada).

16:05:45.265 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID 
tcpHandle=0x4fbb150, Status=0, 
IpAddr=0xe64610ac, Port=17054, PartyID=2

Os seguintes mensagens são usados pelo CallManager da Cisco para pedir a estação para começar a transmitir o fluxo de áudio ao endereço IP de Um ou Mais Servidores Cisco ICM NT e ao número de porta do telefone IP remoto indicado de Cisco.

16:05:45.265 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbbc30 
myIP: e74610ac 
(172.16.70.231)
16:05:45.265 CCM|StationD - RemoteIpAddr: e64610ac (172.16.70.230) RemoteRtpPortNumber: 
17054 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

Nos seguintes traços, as mensagens previamente explicadas são enviadas ao número chamado. Estas mensagens são seguidas pelas mensagens que indicam que o fluxo de mídia RTP começou entre a parte chamada e chamadora.

16:05:45.312 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbb150 
myIP: e64610ac 
(172.16.70.230)
16:05:45.328 CCM|StationD - RemoteIpAddr: e74610ac (172.16.70.231) RemoteRtpPortNumber: 
18448 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

O Cisco IP Phone da chamada originada vai finalmente o em-gancho, que termina todas as mensagens do controle entre a estação mirrada e o CallManager da Cisco, assim como o córrego RTP entre estações mirrada.

16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Casos Práticos II: Chamadas de gateway do Cisco IP Phone para o Cisco IOS

Nos Casos Práticos precedentes, o fluxo de chamadas e as técnicas de Troubleshooting de uma chamada de intra-grânulo foram discutidos em detalhe. Estes Casos Práticos examinam um Cisco IP Phone que chama através de um Cisco IOS gateway a um telefone conectado com um PBX local ou em algum lugar no PSTN. Conceptualmente, quando o atendimento alcança o Cisco IOS gateway, o gateway enviará o atendimento a um telefone que pendura fora de sua porta da estação de câmbio internacional (FXO), ou ao PBX. Se o atendimento é enviado ao PBX, poderia terminar a um telefone que pendura fora de um PBX local ou o PBX enviá-lo-á sobre o PSTN e o atendimento terminará em algum lugar no PSTN.

Topologia de exemplo

O seguinte diagrama mostra o exemplo de topologia para estes Casos Práticos. Os atendimentos são distribuídos através dos Cisco IOS gateway e da relação ao PSTN, ou o PBX é T1/CAS ou T1/PRI. Os gateways podem ser os modelos 26XX, 36XX, 53XX ou 6K.

/image/gif/paws/30266/ios_gatekeeper2.gif

Rastreamentos de fluxo de chamada

Esta seção discute o atendimento corre através de exemplos do arquivo CCM000000000 de Trace do CallManager da Cisco (refira a seção anterior para o lugar do arquivo). Os traços estudam neste caso o foco somente no fluxo de chamadas próprio, porque a informação de rastreamento mais detalhada tem sido explicada já nos Casos Práticos precedentes (iniciação, registro, mecanismo keepalive, e assim por diante).

Neste fluxo de chamadas, um Cisco IP Phone (número de diretório 1001) situado no conjunto 2 está chamando um telefone (número de diretório 3333) ficado situado em algum lugar no PSTN. Recorde que você pode seguir um dispositivo através do traço olhando o valor, o selo de tempo, ou o nome do punho TCP do dispositivo. O valor do punho TCP para o dispositivo permanece o mesmo até que o dispositivo esteja recarregado ou vai off line.

Nos seguintes traços, o Cisco IP Phone (1001) tem o fora-gancho ido. O traço mostra os mensagens exclusiva, o punho TCP, e o número chamado, que é indicado no Cisco IP Phone. Não há nenhum número chamado neste momento porque o usuário não tentou discar nenhuns dígitos.

16:05:46.37515:20:18.390 CCM|StationInit - InboundStim ? OffHookMessageID tcpHandle=0x5138d98
15:20:18.390 CCM|StationD - stationOutputDisplayText tcpHandle=0x5138d98, Display=1001 

Nos seguintes traços, o usuário está discando os 3333, um dígito de cada vez. O número 3333 é o número de destino do telefone, que é ficado situado em algum lugar na rede PSTN. O processo da análise de dígitos do CallManager da Cisco é atualmente ativo e está analisando os dígitos para descobrir onde o atendimento precisa de ser distribuído. Mais explicação detalhada da análise de dígitos foi fornecida nos Casos Práticos precedentes.

15:20:18.390 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
15:20:19.703 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3")
15:20:20.078 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="33")
15:20:20.718 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="333")
15:20:21.421 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3333")
15:20:21.421 CCM|Digit analysis: analysis results

Nos seguintes traços, a análise de dígitos foi terminada, a chamada e o número chamado foram combinados, e a informação foi analisada gramaticalmente.

|CallingPartyNumber=1001
|DialingPattern=3333
|DialingRoutePatternRegularExpression=(3333)
|PretransformDigitString=3333
|PretransformPositionalMatchList=3333
|CollectedDigits=3333
|PositionalMatchList=3333

Nos seguintes traços, o número 0 indica o lugar de origem, e o número 1 indica o local de destino. A largura de banda do lugar de origem é determinada por BW = 1. O valor 1 implica que a largura de banda é infinita. A largura de banda é infinita porque o atendimento foi originado de um Cisco IP Phone situado em um ambiente de LAN. A largura de banda do local de destino é determinada por BW = 64. O destino da chamada é a um telefone situado em um PSTN, e o tipo de codec é usado é G.711 (64Kbps).

15:20:21.421 CCM|Locations:Orig=0 BW=-1 Dest=1 BW=64 (-1 implies infinite bw available)

Os seguintes traços mostram a informação da chamada e do número chamado. Neste exemplo, o nome e o número da chamada originada são o mesmo porque o administrador não configurou um nome do indicador, tal como “John Smith.”

15:20:21.421 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98

Antes de rever os seguintes traços, é importante compreender o significado do termo H.323. Por uma explicação resumida, há diversos protocolos que são usados ao estabelecer uma sessão de H.323. Um protocolo é o H.225, que é usado primeiramente para a sinalização de chamada e é um subconjunto do Q.931. Um outro protocolo é o H.245, que é usado para o intercâmbio de potencialidade. Uma das funções mais importantes do H.245 é o tipo negociação do compressor/descompressor (codec), tal como G.711, G.729, e assim por diante, entre a chamada e o lado chamado. Uma vez que o intercâmbio de potencialidade está completo, a função importante seguinte do H.245 está executando uma negociação de porta UDP entre a chamada e os lados chamados.

O seguinte traço mostra que o código de H.323 esteve inicializado e está enviando um mensagem setup H.225. Você pode igualmente ver os mensagens sapi tradicionais HDLC, o endereço IP de Um ou Mais Servidores Cisco ICM NT do lado chamado encanta dentro, e os números de porta.

15:20:21.421 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol
15:20:21.421 CCM|MMan_Id= 1. (iep= 0 dsl= 0 sapi= 0 ces= 0 IpAddr=e24610ac IpPort=47110)

O seguinte traço mostra a informação da chamada e do número chamado, assim como a mensagem de alerta H.225. Igualmente é mostrado o mapeamento do valor de HEX de um telefone IP de Cisco ao endereço IP de Um ou Mais Servidores Cisco ICM NT. 172.16.70.231 é o endereço IP de Um ou Mais Servidores Cisco ICM NT do Cisco IP Phone (1001).

15:20:21.437 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98
15:20:21.453 CCM|In Message -- H225AlertMsg -- Protocol= H225Protocol
15:20:21.953 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)

O seguinte traço mostra o tipo de compactação usado para este atendimento (½ do ¿  de G.711 ï - lei).

15:20:21.953 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

Uma vez que o mensagem de alerta H.225 foi enviado, parte de H.323 seguinte é inicializa: H.245. O seguinte traço mostra a informação da chamada e do número chamado e as mensagens H.245. Observe que o valor do punho TCP é o mesmo que antes, indicar isto é a continuação da mesma chamada.

15:20:22.062 CCM|H245Interface(3) paths established ip = e74610ac, port = 23752
15:20:22.062 CCM|H245Interface(3) OLC outgoing confirm ip = e24610ac, port = 16758
15:20:22.062 CCM|MediaManager - wait_AuConnectInfo - received response, forwarding

O seguinte traço mostra o mensagem CONNECT H.225, assim como a outra informação que foi explicada mais cedo. Quando o mensagem CONNECT H.225 é recebido, o atendimento esteve conectado.

15:20:22.968 CCM|In Message -- H225ConnectMsg -- Protocol= H225Protocol
15:20:22.968 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:22.062 CCM|MediaCoordinator - wait_AuConnectInfoInd
15:20:22.062 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x5138d98 
myIP: e74610ac 
(172.16.70.231)
15:20:22.062 CCM|StationD - RemoteIpAddr: e24610ac (172.16.70.226) RemoteRtpPortNumber: 
16758 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
15:20:22.062 CCM|Locations:Orig=0 BW=-1Dest=1 BW=6(-1 implies infinite bw available)

O seguinte mensagem mostra que uma mensagem do em-gancho do Cisco IP Phone (1001) está sendo recebida. Assim que uma mensagem do em-gancho for recebida, o H.225 e as mensagens magros da disconexão estão enviados e a mensagem H.225 inteira é considerada. Este mensagem final indica que o atendimento esteve terminado.

15:20:27.296 CCM|StationInit - InboundStim ? OnHookMessageID tcpHandle=0x5138d98
15:20:27.296 CCM|ConnectionManager -wait_AuDisconnectRequest (16777247,16777248): STOP SESSION
15:20:27.296 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending 
disconnect to (64,5) and remove 
connection from list
15:20:27.296 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
15:20:27.296 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x5138d98 myIP:
 e74610ac (172.16.70.231)
15:20:27.296 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)
15:20:28.328 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol

Mensagens debug e comandos show no Cisco IOS Gatekeeper

Na seção anterior, o traço do CallManager da Cisco SDI foi discutido em detalhe. Na topologia para estes Casos Práticos, debugar ras foi girado sobre no Gatekeeper.

Os seguintes debugam mensagens mostram que o Gatekeeper está recebendo o pedido de admissão (ARQ) para o CallManager da Cisco (172.16.70.228), seguido por outros mensagens bem-sucedida de RAS. Finalmente, o Gatekeeper envia uma mensagem do Admission Confirmed (ACF) ao CallManager da Cisco.

*Mar 12 04:03:57.181: RASLibRASRecvData ARQ (seq# 3365) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
*Mar 12 04:03:57.181: RASlibras_sendto msg length 16 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendACF ACF (seq# 3365) sent to 172.16.70.228

Os seguintes debugam mensagens mostram que o atendimento é em andamento.

*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 
55 from 172.16.70.228883

Os seguintes debugam mensagens mostram que o Gatekeeper receberam um pedido desacoplado (DRQ) do CallManager da Cisco (172.16.70.228), e o Gatekeeper enviou um desencargo confirmado (DCF) ao CallManager da Cisco.

*Mar 12 04:03:57.181: RASLibRASRecvData DRQ (seq# 3366) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASlibras_sendto msg length 3 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendDCF DCF (seq# 3366) sent to 172.16.70.228
*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 124 
from 172.16.70.228883

O comando show gatekeeper endpoints no Gatekeeper mostra que todos os quatro CallManagers de Cisco estão registrados com o Gatekeeper. Recorde que na topologia para estes Casos Práticos, há quatro CallManagers de Cisco, dois em cada conjunto. Este Gatekeeper tem duas zonas e cada zona tem dois CallManagers de Cisco.

R2514-1#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
===================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type
--------------- ----- --------------- ----- --------- ---- --
172.16.70.228 2 172.16.70.228 1493 gka.cisco.com VOIP-GW
H323-ID: ac1046e4->ac1046f5
172.16.70.229 2 172.16.70.229 3923 gka.cisco.com VOIP-GW
H323-ID: ac1046e5->ac1046f5
172.16.70.245 1 172.16.70.245 1041 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
172.16.70.243 1 172.16.70.243 2043 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
Total number of active registrations = 4

Mensagens de depuração e comandos show no gateway do Cisco IOS

Na seção anterior, os comandos show e os resultados do debug do Gatekeeper foram discutidos em detalhe. Esta seção centra-se sobre o resultado do debug e os comandos show no Cisco IOS gateway. Na topologia para estes Casos Práticos, os atendimentos estão atravessando os Cisco IOS gateway. O Cisco IOS gateway conecta ao PSTN ou ao PBX com as relações T1/CAS ou T1/PRI. O resultado do debug dos comandos como debuga o inout do ccapi do voip, debuga os eventos h225, e debuga o asn1 h225 é mostrado abaixo.

No seguinte resultado do debug, o Cisco IOS gateway está aceitando o pedido de conexão de TCP do CallManager da Cisco (172.16.70.228) na porta 2328 para o H.225.

*Mar 12 04:03:57.169: H225Lib::h225TAccept: TCP connection accepted from 
172.16.70.228:2328 on socket [1]
*Mar 12 04:03:57.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
*Mar 12 04:03:57.177: Hex representation of the received TPKT03000065080000100

O seguinte resultado do debug mostra que os dados H.225 estão vindo do CallManager da Cisco nesta sessão de TCP. Neste resultado do debug é importante observar o protocolIdentifier, que indica a versão de H.323 que está sendo usada. Os seguintes debugam mostram que a versão 2 de H.323 está sendo usada. Os números da parte chamando e chamada são mostrados igualmente.

- Source Address H323-ID
- Destination Address e164
*Mar 12 04:03:57.177: H225Lib::h225RecvData: Q.931 SETUP received from socket 
[1]value H323-UserInformation ::=
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-uu-pdu
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-message-body setup :
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.181: sourceAddress
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-ID : "1001"
*Mar 12 04:03:57.181: },
*Mar 12 04:03:57.185: destinationAddress
*Mar 12 04:03:57.185: {
*Mar 12 04:03:57.185: e164 : "3333"
*Mar 12 04:03:57.185: },
*Mar 12 04:03:57.189: H225Lib::h225RecvData: State changed to [Call Present].

O seguinte é resultado do debug para a interface de programação de aplicativo do Controle de chamadas (CCAPi). CCAPi está indicando uma chamada recebida. A informação da parte chamando e chamada pode igualmente ser considerada na seguinte saída. CCAPi combina o dial peer 0, que é o dial peer padrão. Está combinando o dial peer 0 porque o CCAPi não poderia encontrar nenhum outro dial peer para o número chamado, assim que está usando o dial peer padrão.

*Mar 12 04:03:57.189: cc_api_call_setup_ind (vdbPtr=0x616C9F54, callInfo={called=3333, 
calling=1001, fdest=1 
peer_tag=0}, callID=0x616C4838)
*Mar 12 04:03:57.193: cc_process_call_setup_ind (event=0x617A2B18) handed call to app "SESSION"
*Mar 12 04:03:57.193: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(17), disp(0)
*Mar 12 04:03:57.193: ccCallSetContext (callID=0x11, context=0x61782BBC)
Mar 12 04:03:57.193: ssaCallSetupInd finalDest cllng(1001), clled(3333)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17) peer list: tag(1)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17), destPat(3333), matched(4), prefix(), peer(6179E63C)
*Mar 12 04:03:57.193: ccCallSetupRequest (peer=0x6179E63C, dest=, params=0x61782BD0 mode=0, 
*callID=0x617A87C0)
*Mar 12 04:03:57.193: callingNumber=1001, calledNumber=3333, redirectNumber=
*Mar 12 04:03:57.193: accountNumber=,finalDestFlag=1, 
guid=0098.89c8.9233.511d.0300.cddd.ac10.46e6

O CCAPi combina o dial-peer 1 com o padrão de destino, que é o número chamado 3333. Recorde que o peer_tag significa o dial peer. Observe a chamada e o número da parte chamada no pacote de requisição.

*Mar 12 04:03:57.193: peer_tag=1
*Mar 12 04:03:57.197: ccIFCallSetupRequest: (vdbPtr=0x617BE064, dest=, 
callParams={called=3333, calling=1001, 
fdest=1, voice_peer_tag=1}, mode=0x0)

O seguinte resultado do debug mostra que as mensagens de alerta H.225 estão retornando ao CallManager da Cisco.

*Mar 12 04:03:57.197: ccCallSetContext (callID=0x12, context=0x61466B30)
*Mar 12 04:03:57.197: ccCallProceeding (callID=0x11, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_proceeding(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_alert(vdbPtr=0x617BE064, callID=0x12,
 prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: sess_appl: ev(17=CC_EV_CALL_PROCEEDING), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)
-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaIgnore cid(18), st(1),oldst(1), ev(17)
*Mar 12 04:03:57.201: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(1)cfid(-1)csize(0)in(0)fDest(0
)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaFlushPeerTagQueue cid(17) peer list: (empty)
*Mar 12 04:03:57.201: ccCallAlert (callID=0x11, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: ccConferenceCreate (confID=0x617A8808, callID1=0x11, callID2=0x12, tag=0x0)
*Mar 12 04:03:57.201: cc_api_bridge_done (confID=0x7, srcIF=0x616C9F54, srcCallID=0x11, 
dstCallID=0x12, 
disposition=0, tag=0x0)value H323-UserInformation
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-uu-pdu
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-message-body alerting :
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.205: destinationInfo
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: mc FALSE,
*Mar 12 04:03:57.205: undefinedNode FALSE
*Mar 12 04:03:57.205: },

Observação neste pacote que o Cisco IOS igualmente está enviando o endereço H.245 e o número de porta ao CallManager da Cisco. Às vezes o Cisco IOS gateway enviará o endereço inacessível, que poderia causar não audio ou o áudio de sentido único.

*Mar 12 04:03:57.205: h245Address ipAddress :
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: ip 'AC1046E2'H,
*Mar 12 04:03:57.205: port 011008
*Mar 12 04:03:57.205: },
*Mar 12 04:03:57.213: Hex representation of the ALERTING TPKT to send.0300003D0100
*Mar 12 04:03:57.213:
*Mar 12 04:03:57.213: H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [1]. 
Call state changed to [Call 
Received].
*Mar 12 04:03:57.213: cc_api_bridge_done (confID=0x7, srcIF=0x617BE064, srcCallID=0x12,
 dstCallID=0x11, 
disposition=0, tag=0x0)

O seguinte resultado do debug mostra que a sessão H.245 está vindo acima. Você pode ver a indicação de recurso para a negociação codec, assim como quantos bytes querem estam presente em cada pacote de voz.

*Mar 12 04:03:57.217: cc_api_caps_ind (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12,
 caps={codec=0xEBFB, 
fax_rate=0x7F, vad=0x3, modem=0x617C5720 codec_bytes=0, signal_type=3})
*Mar 12 04:03:57.217: sess_appl: ev(23=CC_EV_CONF_CREATE_DONE), cid(17), disp(0)
*Mar 12 04:03:57.217: ssa: cid(17)st(3)oldst(0)cfid(7)csize(0)in(1)fDest(1)
-cid2(18)st2(3)oldst2(1)
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

O seguinte resultado do debug mostra que ambos os partidos negociaram corretamente e concordaram com o codec de G.711 com os 160 bytes de dados.

*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, 
srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

H.323 conecta e as mensagens da disconexão podem ser consideradas abaixo.

*Mar 12 04:03:59.373: cc_api_call_connected(vdbPtr=0x617BE064, callID=0x12)
*Mar 12 04:03:59.373: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(18), disp(0)
*Mar 12 04:03:59.373: ssa: cid(18)st(4)oldst(1)cfid(7)csize(0)in(0)fDest(0)
-cid2(17)st2(4)oldst2(3)
*Mar 12 04:03:59.373: ccCallConnect (callID=0x11)
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-uu-pdu
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-message-body connect :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:59.373: h245Address ipAddress :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.377: ip 'AC1046E2'H,
*Mar 12 04:03:59.377: port 011008
*Mar 12 04:03:59.377: },
*Mar 12 04:03:59.389: Hex representation of the CONNECT TPKT to send.03000052080
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [1]
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
*Mar 12 04:04:08.769: cc_api_call_disconnected(vdbPtr=0x617BE064, callID=0x12, cause=0x10)
*Mar 12 04:04:08.769: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(18), disp(0)

Gateway do Cisco IOS com interface T1/PRI

Como explicado mais cedo, há dois tipos de atendimentos que atravessam os Cisco IOS gateway: o Cisco IOS gateway conecta ao PSTN ou ao PBX, com as relações T1/CAS ou T1/PRI. Os seguintes são os resultados do debug quando os Cisco IOS gateway usam a relação T1/PRI.

O comando debug isdn q931 no Cisco IOS gateway foi girado sobre. Isto permite o Q.931, um protocolo de sinalização da camada três para o canal D no ambiente ISDN. Cada vez que um atendimento é colocado fora da relação T1/PRI, um pacote da instalação deve ser enviado. O pacote da instalação tem sempre (descritor de protocolo) paládio = 8, e gerencie um valor de HEX aleatório para o callref. O callref é usado para seguir o atendimento. Por exemplo, se dois atendimentos são colocados, o valor do callref pode determinar o atendimento para que a mensagem RX (recebido) é pretendida. A capacidade do portador 0x8890 significa uma chamada de dados 64kb/s. Se era um 0x8890218F, seria uma chamada de dados 56kb/s. Seria 0x8090A3 se era uma chamada de voz. No resultado do debug abaixo, a capacidade do portador é 0x8090A3, que é para a Voz. Os números da parte chamando e chamada são mostrados igualmente.

O callref usa um valor diferente para o primeiro dígito (para se diferenciar entre TX e RX) e o segundo valor é o mesmo (a INSTALAÇÃO teve um 0 para o dígito último, e o CONNECT_ACK igualmente tem um 0). O roteador é completamente dependente do PSTN ou do PBX atribuir um canal do portador (canal B). Se o PSTN ou o PBX não atribuem um canal ao roteador, o atendimento não estará distribuído. Em nosso caso, um mensagem CONNECT é recebido do interruptor com o mesmo número de referência que foi recebido ALERTANDO (0x800B). Finalmente, você pode ver a troca do mensagem DISCONNECT seguido pelas mensagens da LIBERAÇÃO e RELEASE_COMP enquanto o atendimento está sendo desligado. As mensagens RELEASE_COMP são seguidas por uma causa ID para a recusa de chamada. A causa ID é um valor de HEX. O significado da causa pode ser encontrado descodificando o valor de HEX e continuando com seu fornecedor.

*Mar 1 225209.694 ISDN Se115 TX -> SETUP pd = 8 callref = 0x000B
*Mar 1 225209.694 Bearer Capability i = 0x8090A3
*Mar 1 225209.694 Channel ID i = 0xA98381
*Mar 1 225209.694 Calling Party Number i = 0x2183, ?1001'
*Mar 1 225209.694 Called Party Number i = 0x80, ?3333'
*Mar 1 225209.982 ISDN Se115 RX <- ALERTING pd = 8 callref = 0x800B
*Mar 1 225209.982 Channel ID i = 0xA98381
*Mar 1 225210.674 ISDN Se115 RX <- CONNECT pd = 8 callref = 0x800B
*Mar 1 225210.678 ISDN Se115 TX -> CONNECT_ACK pd = 8 callref = 0x000B
*Mar 1 225215.058 ISDN Se115 RX <- DISCONNECT pd = 8 callref = 0x800B
*Mar 1 225215.058 Cause i = 0x8090 - Normal call clearing 225217 %ISDN-6
DISCONNECT Int S10 disconnected from unknown , call lasted 4 sec
*Mar 1 225215.058 ISDN Se115 TX -> RELEASE pd = 8 callref = 0x000B
*Mar 1 225215.082 ISDN Se115 RX <- RELEASE_COMP pd = 8 callref = 0x800B
*Mar 1 225215.082 Cause i = 0x829F - Normal, unspecified or Special intercept,
 call blocked group restriction 

Gateway de Cisco IOS com interface T1/CAS

Como explicado mais cedo, há dois tipos de atendimentos que atravessam os Cisco IOS gateway: a relação do Cisco IOS gateway ao PSTN ou ao PBX, com relações T1/CAS ou T1/PRI. Os seguintes são os resultados do debug quando os Cisco IOS gateway têm a relação T1/CAS. Debugar cas no Cisco IOS gateway foi girado sobre.

Os seguintes debugam a mensagem mostram que o Cisco IOS gateway está enviando um sinal fora do gancho ao interruptor.

Apr 5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111) 

Os seguintes debugam a mensagem indicam que o interruptor está enviando a piscadela após ter recebido o sinal do fechamento de loop do Cisco IOS gateway.

Apr 5 17:58:21.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)
Apr 5 17:58:22.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)

Os seguintes debugam a mensagem indicam que o Cisco IOS gateway é fora-gancho indo.

Apr 5 17:58:23.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

O seguinte é a saída show call ative voice brief sobre do Cisco IOS gateway quando o atendimento é em andamento. O número da parte chamando e chamada e a outra informação util são mostrados igualmente.

R5300-5#show call active voice brief
<ID>: <start>hs.<index> +<connect> pid: <peer_id> <dir> <addr> <state> tx: <packets>/<bytes>
 rx:<packets>/<bytes>
<state>
IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late> 
delay:<last>/<min>/<max>ms <codec>
FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> sig:<on/off> <codec> (payload size)
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> (payload size) 
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
511D : 156043737hs.1 +645 pid:0 Answer 1001 active
tx:1752/280320 rx:988/158080
IP172.16.70.228:18888 rtt:0ms pl:15750/80ms lost:0/0/0 delay:25/25/65ms g711ulaw
511D : 156043738hs.1 +644 pid:1 Originate 3333 active
tx:988/136972 rx:1759/302548 
Tele 1/0/0 (30): tx:39090/35195/0ms g711ulaw noise:-43 acom:0 i/0:-36/-42 dBm

Obtendo um sinal de ocupado após discar para números internacionais

Problema

O usuário tem CM 2.4.4 com um teste padrão da rota apropriada atribuído a seu gateway DT-24+. Pode discar o local e os números interurbanos E.U. sem problemas. Contudo quando perfura os dígitos para um número internacional, ouve uma pausa, e então um busy signal (sinal ocupado).

Solução

Isto foi visto no passado onde o switch CO não sabe tratar corretamente o atendimento IE (elemento de informação). Isto pode ser fixado ajustando a chamada originada do gerenciador de chamada o tipo IE que “ajustou a chamada e o tipo chamado DN ao desconhecido” sob os parâmetros do período DT24+.

Casos Práticos III: Chamadas de Telefone IP Cisco para Telefone IP Cisco inter-grânulos

Nos Casos Práticos precedentes, o fluxo de chamadas e as técnicas de Troubleshooting de uma chamada de intra-grânulo e de um atendimento do Cisco IP Phone através de um Cisco IOS gateway a um telefone que pendura fora de um PBX local ou no PSTN foram discutidos em algum lugar em detalhe. Estes Casos Práticos examinam um Cisco IP Phone que chama um outro Cisco IP Phone ficado situado em um cluster diferente. Este tipo de atendimento é sabido igualmente como um atendimento do Cisco IP Phone do inter-conjunto.

Topologia de exemplo

O seguinte é o exemplo de topologia usado neste caso estuda. Esta topologia tem dois conjuntos, cada um que tem dois CallManagers de Cisco. Há igualmente Cisco IOS gateway e um Gatekeeper no lugar.

/image/gif/paws/30266/ios_gatekeeper3.gif

Comunicação entre clusters H.323

Como você pode ver na topologia, o Cisco IP Phone no conjunto 1 está fazendo um atendimento ao Cisco IP Phone em uma comunicação do CallManager da Cisco do Inter-conjunto do conjunto 2. ocorre usando o protocolo da versão 2 de H.323. Há igualmente um Gatekeeper para o controle de admissão. A explicação detalhada do resultado do debug e os comandos show, e a interação entre o Gatekeeper e o Cisco IOS gateway e os dispositivos do CallManager da Cisco, podem ser revistas nas seções anterior.

O processo de fluxo de chamadas é mostrado no diagrama abaixo. O Cisco IP Phone pode falar ao CallManager da Cisco através do protocolo de estação mirrada, e o CallManager da Cisco pode falar com o Gatekeeper que usa o protocolo RAS de H.323. A mensagem do pedido de admissão (ARQ) é enviada ao Gatekeeper, que envia a mensagem do Admission Confirmed (ACF) após se ter certificado de que a chamada inter-grânulo pode ser feita usando o protocolo da versão 2 de H.323. Uma vez que feito, o caminho de áudio é feito usando o protocolo de RTP entre Telefones IP de Cisco nos clusteres diferentes.

/image/gif/paws/30266/gatekeeper_flow.gif

Rastreamentos de fluxo de chamada

Esta seção discute o fluxo de chamadas usando os exemplos de rastreamento SDI capturados no arquivo CCM000000000. O lugar deste arquivo pode ser encontrado na seção anterior. Os traços discutidos neste caso estudam o foco somente no fluxo de chamadas próprio, porque a informação de rastreamento mais detalhada tem sido explicada já nos Casos Práticos precedentes (iniciação, registro, o mecanismo keepalive, e assim por diante.)

Neste fluxo de chamadas, um Cisco IP Phone (2002) situado no conjunto 2 está chamando um Cisco IP Phone (1001) ficado situado no conjunto 1. recorda que você pode seguir um dispositivo através do traço olhando o valor, o selo de tempo, ou o nome do punho TCP do dispositivo. O valor do punho TCP para o dispositivo permanece o mesmo até que o dispositivo esteja recarregado ou vai off line.

Nos seguintes traços, o Cisco IP Phone (2002) tem o fora-gancho ido. O traço mostra os mensagens exclusiva, o punho TCP, e o número chamado, que é indicado no Cisco IP Phone. O número chamado (1001), H.225 conecta, e o H.245 confirma mensagens pode ser visto no seguinte resultado do debug. O tipo de codec é ½ do ¿  de G.711 ï - lei.

16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, 
CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x1c64310,
 Status=0, 
IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626

A chamada e o número da parte chamada, que é associado com um endereço IP de Um ou Mais Servidores Cisco ICM NT e um valor de HEX, podem ser considerados nos seguintes traços.

16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310
 myIP: e74610ac 
(172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252) 

Os seguintes traços mostram os tamanhos do pacote e o MAC address do Cisco IP Phone (2002). Estes traços são seguidos pela disconexão, a seguir pelas mensagens do em-gancho.

RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06
16:06:16.531 CCM|Locations:Orig=1 BW=64 Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to 
(64,2) and remove 
connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies, 
forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2)
 from connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310

Falha no fluxo de chamada

A seguinte seção descreve um fluxo mal sucedido da chamada inter-grânulo, como visto no traço SDI. Nos traços abaixo, o Cisco IP Phone (1001) tem o fora-gancho ido. Um punho TCP é atribuído ao Cisco IP Phone.

16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampOn tcpHandle=0x4fbbc30

Nos seguintes traços o usuário está discando o número chamado (2000) do Cisco IP Phone, e o processo de análise de dígitos está tentando combinar o número.

16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:33.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:36.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:36.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")

A análise de dígitos tem sido terminada agora e os resultados são mostrados nos seguintes traços. É importante notar que a referência de PotentialMatches=NoPotentialMatchesExist abaixo indica que o CallManager da Cisco é incapaz de combinar este número de diretório. Finalmente, uma reordenar tom é enviada à chamada originada (1001), que é seguida por uma mensagem do em-gancho.

16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=, 
CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Registros de detalhes da chamada

Esta seção fornece a informação detalhada sobre os registros dos destalhes da chamada (CDR) e o Call Management Records (CMR, igualmente conhecidos como CDR diagnósticos).

Os registros de CDR são redigidos a um base de dados para o uso em atividades deprocessamento. Estas atividades incluem muitas funções, mas primeiramente estarão faturando-as e análises de rede.

O base de dados é um base de dados do Microsoft SQL server 7.0. O acesso ao base de dados pode ser feito através da conectividade de bases de dados aberto (ODBC).

O acesso é fornecido a todas as tabelas no base de dados em uma forma de leitura apenas e às tabelas CDR e CMR em uma forma de leitura/gravação.

Para usar dados do registro de CDR, você pode querer ler outras tabelas no base de dados em um esforço para obter a informação sobre o tipo de dispositivo que o CDR está aproximadamente. Esta correlação entre dispositivos na tabela de dispositivo e o endereço IP de Um ou Mais Servidores Cisco ICM NT alistado no registro de CDR não é direta e é alistada como um problema conhecido mais tarde nesta seção.

Gravando registros

O CallManager da Cisco redige registros de CDR ao base de dados SQL como os atendimentos são feitos de um modo consistentes com a configuração de cada CallManager da Cisco individual. Esta configuração é feita através da tela dos parâmetros de serviço na administração do CallManager da Cisco.

Todos os registros são redigidos ao base de dados principal para um conjunto. Se o base de dados principal não está disponível, os registros estarão redigidos a alguns dos outros backup de base de dados. Uma vez que o base de dados principal se torna disponível, a seguir os novos registros da escrita continuarão no base de dados principal e os registros local-escritos serão movidos para o preliminar.

Lendo registros

A maneira a mais fácil de ler dados do base de dados SQL pode ser usar o ODBC. Uma corda da boa conexão olharia como:

DRIVER= {SQL Server};SERVER=machineX;DATABASE=CCM0300

Seja certo usar o nome do base de dados correto. Se uma versão da revisão do CallManager da Cisco 3.0(1) do software é instalada sobre uma instalação existente, o base de dados pôde ser migrado se chamado para pela instalação nova. Neste caso o base de dados velho ainda existirá, e o base de dados novo igualmente existirá. Os nomes diferirão adicionando um ao número do nome. Por exemplo, o nome original é CCM0300. Após uma migração, o nome do base de dados mais novo será CCM0301. O base de dados do número o mais alto deve ser usado.

O base de dados principal (máquina e nome) atualmente em uso pelo conjunto pode ser encontrado clicando sobre o botão Details Button da administração do CallManager da Cisco (ajuda do clique para alcançar a tela de boas vindas onde o botão Details Button é encontrado). O registro nas máquinas que hospedam um base de dados pode igualmente ser verificado. Olhe a chave de registro: \ \ HKEY_LOCAL_MACHINE \ software \ Cisco Systems Inc. \ DBL para o artigo chamou DBConnection0. Este artigo da corda contém um string de conexão similar àquele mostrado acima com o nome de máquina e o nome do base de dados do base de dados principal.

O acesso é controlado por meio dos usuários SQL. A tabela a seguir especifica o ID e senha de usuário que deve ser usado ao alcançar a base de dados do CallManager da Cisco.

Tabelas SQl UserID Senha Capacidade
CallDetailRecord, CallDetailRecordDiagnostic CiscoCCMCDR dipsy De leitura/gravação
(Outro) CiscoCCMReader vaqueiros Read only

Removendo registros

Desde que o CallManager da Cisco está confiando no cargo-processo dos aplicativos de terceiros os dados CDR, você deve remover os dados CDR quando todos os aplicativos são terminados com os dados. Desde que isto envolve alterar o base de dados, o usuário do CiscoCCMCDR deve ser usado.

Se os registros de CDR acumulam a uma máxima configurada (10,000,000 registros de CDR), os registros de CDR os mais velhos estarão removidos junto com registros relacionados CMR uma vez pelo dia.

Ao remover os dados CDR após a análise, seja certo remover todos os registros relacionados CMR, também.

Esquema de tabela

A informação detalhada sobre o formato e o uso de cada campo no CDR é fornecida mais tarde nesta seção.

As tabelas preliminares usadas são a tabela do CallDetailRecord (que guarda registros de CDR) e a tabela Diagnóstico de Registro de Detalhes de Chamada (que guarda registros CMR). A tabela do CallDetailRecord é relacionada à tabela Diagnóstico de Registro de Detalhes de Chamada através das dois colunas, GlobalCallID_callManagerId, e GlobalCallID_callId de GlobalCallID. Pode haver mais de um CMR pelo CDR.

A tabela CallDetailRecord contém informação sobre os valores-limite do atendimento e de outros aspectos do Controle de chamadas/roteamento do atendimento. A tabela Diagnóstico de Registro de Detalhes de Chamada guarda a informação sobre a qualidade do áudio fluído do atendimento.

Problemas conhecidos

A revisão do CallManager da Cisco 3.0(1) tem diversos problemas conhecidos com os dados CDR. Alguma destes está listada abaixo.

IP à tradução do nome de dispositivo

A tabela CDR alista endereços IP de Um ou Mais Servidores Cisco ICM NT para os valores-limite de um atendimento. Estes endereços IP de Um ou Mais Servidores Cisco ICM NT não são convertidos facilmente aos nomes de dispositivo de modo que o tipo de dispositivo possa ser determinado.

OnNet contra o OffNet

É difícil saber se o atendimento ficou completamente na rede IP, ou pelo menos interno ao sistema local. Um indício é verificar o tipo de dispositivo de ambas as extremidades do atendimento. Se ambos são telefones, a seguir você pode supor que ficou OnNet. Contudo, se um é um gateway, mais suposições devem ser feitas. Se o gateway é um tipo do acesso analógico de dispositivo com POTENCIÔMETROS ou porta da estação, o atendimento pôde apenas ter ido a um telefone analógico local, ou pôde ter saído ao PSTN. Olhe o número discado e correlacione isto ao Plano de discagem conhecido calcular se o atendimento foi OffNet. Se não, o atendimento foi provavelmente OnNet.

Discador dos dígitos OffNet

Se um atendimento é colocado para fora um gateway, os dígitos discados para obter ao gateway não podem ser os dígitos enviados ao PSTN. O gateway pode ser inteligente e alterar o número de diretório mais. Se este é o caso, o CallManager da Cisco não sabe, e o CDR não refletirá os dígitos reais enviados OffNet.

Campos em um registro de detalhes da chamada

Esta seção define todos os campos nos registros atual. Os tipos de campo são aqueles usados pelo CallManager da Cisco, e não necessariamente aqueles definidos no registro de CDR no base de dados. As definições de campo do base de dados são adequadas armazenar os dados, mas a interpretação dos dados deve levar em consideração os tipos de campo definidos aqui.

Todos os inteiros não assinados são os inteiros não assinados 32bit.

Conversões de dados de campo

Há alguns campos que exigem a conversão do formato decimal a um outro formato para indicadores. Esta seção define seus valores, e como convertê-los ou onde obter a informação em como convertê-los.

Valores do tempo

Todos os valores do tempo são representados como 32 inteiros sem assinatura do bit. Este valor de inteiro não assinado é indicado do base de dados como um integer assinado.

Este campo é um valor do time_t que seja obtido das 2000) rotinas de sistema do Windows NT (. O valor é um valor do tempo universal coordenado (UTC) e representa o número de segundos desde o 1º de janeiro da meia-noite (de 00:00:00), 1970.

Decifrando o selo de tempo

Usando Microsoft Excel, você pode escrever uma fórmula para facilitar convertendo este selo de tempo um pouco de. Se o valor está no A1 da pilha, você pode fazer uma outra pilha:

=A1/86400+DATE(1970,1,1)

Há 86400 segundos em um dia.

Então, formate a pilha resultante como um campo da data/hora em Excel.

Endereços IP

Todos os endereços IP de Um ou Mais Servidores Cisco ICM NT são armazenados no sistema como inteiros não assinados. O base de dados indica-os como integers assinados. Para converter o valor decimal assinado a um endereço IP de Um ou Mais Servidores Cisco ICM NT, converta primeiramente o valor a um número encantar (que toma na consideração que é realmente um número não assinado). O valor de HEX 32bit representa quatro bytes. Os quatro bytes estão na ordem reversa (padrão Intel). Para obter o endereço IP de Um ou Mais Servidores Cisco ICM NT, inverta a ordem dos bytes e converta cada byte a um número decimal. Os quatro bytes resultantes representam os campos de quatro-byte do endereço IP de Um ou Mais Servidores Cisco ICM NT na notação pontilhada.

Nota: O base de dados indica-a como um número negativo quando o baixo byte do endereço IP de Um ou Mais Servidores Cisco ICM NT tem o bit mais significativo ajustado.

Convertendo endereços IP de Um ou Mais Servidores Cisco ICM NT

  • Exemplo 1:

    Por exemplo, o endereço IP 192.168.18.188 seria indicado como segue:

    Indicador do base de dados = -1139627840.

    Isto converte a um valor de HEX de 0xBC12A8C0.

    Inverta os bytes encantar = o C0A812BC

    CO A8 12 BC

    Os bytes converteram de encantam ao decimal = 192 168 18 188, que seriam indicados como 192.168.18.188.

  • Exemplo 2:

    Endereço IP 192.168.18.59

    Indicador do base de dados = 991078592

    Isto converte a um valor de HEX de 0x3B12A8C0

    Inverta a ordem do byte = o C0A8123B

    C0A8 12 3B

    Os bytes converteram de encantam ao decimal = 192 168 18 59 que seriam indicados como 192.168.18.59.

Definição de campo CDR

A tabela a seguir fornece definições de campo para CDR.

Definições de campo
Campo Definição
cdrRecordType O tipo deste inteiro não assinado do registro especifica o tipo deste registro específico. Podia ser um atendimento da chamada de início record(0), do fim record(1), ou um CMR record(2).
mais globalCallIdentifier O identificador da chamada global o identificador da chamada global consiste em dois campos que são ambos os inteiros não assinados. Os valores devem ser tratados como inteiros não assinados. Os dois campos são: O inteiro não assinado GlobalCallID_CallManagerID de GlobalCallID_CallID do inteiro não assinado isto é o identificador de chamada que é atribuído ao atendimento inteiro. Tudo grava associado com uma chamada padrão terá o mesmo identificador da chamada global.
mais origLegCallIdentifier O inteiro não assinado do identificador de chamada do trecho de origem isto é um identificador exclusivo que seja usado para seguir o trecho de origem de um atendimento. É original dentro de um conjunto.
dateTimeOrigination O inteiro não assinado das origens da data/tempo de chamada isto representa o tempo que o dispositivo de origem do atendimento foi fora do gancho, ou o tempo que uma chamada externa esteve reconhecida primeiramente pelo sistema (recebeu o mensagem setup). O valor é um valor do tempo universal coordenado (UTC), e representa o número de segundos desde o 1º de janeiro da meia-noite (de 00:00:00), 1970.
origNodeId O inteiro não assinado da identificação de nó do autor este campo representa o nó dentro do Cluster do CallManager daCisco onde o originador de chamada foi registrado na altura deste atendimento.
origSpan O período do autor ou o inteiro não assinado da porta este campo contêm o número da porta ou do período do autor se o atendimento originou através de um gateway. Se não, este campo contém zero (0).
callingPartyNumber O número do chamador até 25 caráteres isto é o número de diretório do dispositivo de que o atendimento originou.
origIpPort O inteiro não assinado da porta IP da chamada originada este campo contém a porta IP do dispositivo de que o atendimento originou.
origIpAddr O inteiro não assinado do endereço IP de Um ou Mais Servidores Cisco ICM NT da chamada originada este campo contém o endereço IP de Um ou Mais Servidores Cisco ICM NT do dispositivo de que o atendimento originou.
originalCallingPartyNumberPartition A separação da chamada originada até caráteres dos 50 pés este campo contém a separação associada com a chamada originada.
origCause_Location O inteiro não assinado do valor de local de ISDN este campo contém o valor de localização do elemento de informação da causa.
origCause_Value A causa da chamada originada do inteiro não assinado da terminação de chamada esta causa representa a razão que o atendimento ao dispositivo de origem foi terminado. No caso de transferências, para a frente, e assim por diante, a causa da terminação de chamada pode ser diferente para o dispositivo de origem e o dispositivo de terminação. Assim, há dois campos da causa associados com cada atendimento. Geralmente serão os mesmos.
origMediaTransportAddress_IP O endereço IP de Um ou Mais Servidores Cisco ICM NT para o inteiro não assinado da conexão de mídia do autor isto é o endereço IP de destino a que o fluxo de mídia do autor foi conectado.
origMediaTransportAddress_Port A porta para o inteiro não assinado da conexão de mídia do autor isto é a porta do destino a que o fluxo de mídia do autor foi conectado.
origMediaCap_payloadCapability O tipo de codec usou-se pelo inteiro não assinado que do autor este campo contém o tipo de codec (compressão ou tipo de payload) que o autor usou no lado de envio durante este atendimento. Pode ser diferente do que o tipo de codec usado em seu lado receptor.
origMediaCap_maxFramesPerPacket O número de milissegundos dos dados pelo inteiro não assinado do pacote este campo contém o número de milissegundos dos dados pelo pacote enviado ao destino, pelo autor deste atendimento. O tamanho de dados real depende do tipo de codec que está sendo usado para gerar os dados.
origMediaCap_g723BitRate A taxa de bits a ser usada pelo inteiro não assinado de G.723 define a taxa de bits a ser usada por G.723. Há dois valores da taxa de bits: 1 taxa de bits e 2 =5.3K = taxa de bits 6.3K.
lastRedirectDn Número de diretório do partido que reorientado por último este atendimento até 25 caráteres este é o número de diretório do último dispositivo que reorientou este atendimento. Este campo aplica-se somente aos atendimentos que foram reorientados, como teleconferências, chamadas encaminhadas do atendimento, e assim por diante.
lastRedirectDnPartition Separação do telefone que reorientado por último este atendimento até caráteres dos 50 pés esta é a separação do último dispositivo que reorientou este atendimento. Este campo aplica-se somente aos atendimentos que foram reorientados como teleconferências, chamadas encaminhadas do atendimento, e assim por diante.
mais destLegIdentifier O identificador de chamada para o trecho de destino do inteiro não assinado do atendimento isto é um identificador exclusivo que seja usado para seguir o trecho de destino deste atendimento. É original dentro de um conjunto.
destNodeId O identificador de nó para o nó onde o destino do atendimento era inteiro não assinado registrado o nó dentro do Cluster do CallManager daCisco onde o dispositivo de destino foi registrado na altura deste atendimento.
período dest O inteiro não assinado do período ou da porta do destino este campo contém o número da porta do destino ou do período se o atendimento foi terminado através de um gateway. Se não, este campo contém a (0) zero.
destIpAddr O endereço IP de Um ou Mais Servidores Cisco ICM NT a que o atendimento era inteiro não assinado entregado este campo contém o endereço IP de Um ou Mais Servidores Cisco ICM NT da conexão da sinalização no dispositivo que terminou o atendimento.
destIpPort A porta IP a que o atendimento era inteiro não assinado entregado este campo contém a porta IP da conexão da sinalização no dispositivo que terminou o atendimento.
originalCalledPartyNumber O destino recebeu do originador de chamada até 25 caráteres que este campo contém o número de diretório a que o atendimento era originalmente prolongado com base nos dígitos discou pelo autor do atendimento. Se o atendimento termina normalmente (o significar não esteve enviado), este número de diretório deve sempre ser o mesmo que o “finalCalledPartyNumber”. Se o atendimento foi enviado, este campo conteve o destino original do atendimento antes que esteve enviado.
originalCalledPartyNumberPartition A separação do número chamado até caráteres dos 50 pés este campo contém a separação associada com o número chamado.
finalCalledPartyNumber O destino a que o atendimento foi entregado até 25 caráteres este campo contém o número de diretório a que o atendimento era realmente prolongado. Se o atendimento termina normalmente (o significar não esteve enviado), este número de diretório deve sempre ser o mesmo que o “originalCalledPartyNumber”. Se o atendimento foi enviado, este campo contém o número de diretório do destino final do atendimento foi terminado afinal para a frente.
finalCalledPartyNumberPartition A separação associou com o destino final do atendimento. até caráteres dos 50 pés este campo contém a separação associada com o destino a que o atendimento era realmente prolongado. Em uma chamada normal, este campo deve ser o mesmo como o “originalCalledPartyNumberPartition”. Se o atendimento foi enviado, este campo contém a separação do destino final do atendimento foi terminado afinal para a frente.
destCause_location O inteiro não assinado do lugar da causa do número chamado isto é o valor de local de ISDN do elemento de informação da causa.
destCause_value A causa do número chamado do inteiro não assinado da terminação de chamada esta causa representa porque o atendimento ao dispositivo de terminação foi terminado. No caso de transferências, para a frente, e assim por diante, a causa da terminação de chamada pode ser diferente para o receptor do atendimento e do autor do atendimento. Assim, há dois campos da causa associados com cada atendimento. Geralmente serão os mesmos. Quando uma tentativa é feita para estender um atendimento a um dispositivo ocupado que esteja enviado, o código de causa refletirá “ocupado” mesmo que o atendimento seja conectado a um destino dianteiro.
destMediaTransportAddress_IP O endereço IP de Um ou Mais Servidores Cisco ICM NT para o inteiro não assinado da conexão de mídia de saída de destino isto é o endereço IP de Um ou Mais Servidores Cisco ICM NT das origens de que o fluxo de mídia do destino foi conectado.
destMediaTransportAddress_Port A porta para o inteiro não assinado da conexão de mídia de saída de destino isto é a porta do autor de que o fluxo de mídia do destino foi conectado.
destMediaCap_payloadCapability O tipo de codec usou-se pelo destino no inteiro não assinado que do lado de envio este campo contém o tipo de codec (compressão ou tipo de payload) que o destino usou em seu lado de envio durante este atendimento. Pode ser diferente do que o tipo de codec usado em seu lado receptor.
destMediaCap_maxFramesPerPacket O número de milissegundos dos dados pelo inteiro não assinado do pacote este campo contém o número de milissegundos dos dados pelo pacote enviado ao autor pelo destino deste atendimento. O tamanho de dados real depende do tipo de codec que está sendo usado para gerar os dados.
destMediaCap_g723BitRate A taxa de bits a ser usada pelo inteiro não assinado de G.723 define a taxa de bits a ser usada por G.723. Há dois valores da taxa de bits: 1 taxa de bits e 2 =5.3K = taxa de bits 6.3K.
dateTimeConnect A data/hora de conecta o inteiro não assinado que esta é a data e hora que o atendimento esteve conectado entre os dispositivos de origem e terminação. O valor é um valor do tempo universal coordenado (UTC), e representa o número de segundos desde o 1º de janeiro da meia-noite (de 00:00:00), 1970.
dateTimeDisconnect Data/hora do inteiro não assinado da disconexão este é o tempo que o atendimento esteve desligado entre os dispositivos de origem e terminação, ou em que o atendimento foi rasgado para baixo mesmo se foi conectado nunca. O valor é um valor do tempo universal coordenado (UTC), e representa o número de segundos desde o 1º de janeiro da meia-noite (de 00:00:00), 1970.
duração Duração da chamada este é o número de segundos que o atendimento foi conectado. É a diferença entre a data/hora de conecta e a data/hora da disconexão.

Definições de campo CMR

A tabela a seguir fornece definições de campo para CMR (CDR diagnósticos).

Definições de campo
Campo Definição
cdrRecordType O tipo deste inteiro não assinado do registro especifica o tipo deste registro específico. Será ajustado ao registro CMR.
mais globalCallIdentifier O identificador da chamada global para este atendimento o identificador da chamada global consiste em dois campos que são ambos os inteiros não assinados. Os valores devem ser tratados como inteiros não assinados. Os dois campos são: O inteiro não assinado GlobalCallID_CallManagerID de GlobalCallID_CallID do inteiro não assinado isto é o identificador de chamada que é atribuído ao atendimento inteiro. Tudo grava associado com uma chamada padrão terá o mesmo identificador da chamada global.
nodeID O identificador de nó do CallManager da Cisco o nó dentro do Cluster do CallManager daCisco onde este registro foi gerado.
mais callIdentifier O inteiro não assinado do identificador de chamada isto é um identificador do trecho de chamada que identifique a que trecho de chamada este registro pertence.
directoryNum O número de diretório usado neste atendimento isto é o número de diretório do dispositivo de que estes diagnósticos foram recolhidos.
directoryNumPartition A separação associada com o número de diretório isto é a separação do número de diretório neste registro.
dateTimeStamp A terminação da data/tempo de chamada isto representa o tempo aproximado que o dispositivo foi no gancho. O tempo está posto no registro quando o telefone responde a um pedido para a informação de diagnóstico. Este é um valor do time_t.
numberPacketsSent O número de pacotes enviou o número total de pacotes de dados RTP transmitidos pelo dispositivo desde começar a transmissão nesta conexão. O valor é zero se a conexão foi ajustada no modo " somente recebimento ".
numberOctetsSent O número de octetos (bytes) dos dados enviados aos outro party o número total de octetos de carga úteis (isto é, não incluindo o encabeçamento ou acolchoando) transmitidos em uns pacotes de dados RTP pelo dispositivo desde começar a transmissão nesta conexão. O valor é zero se a conexão foi ajustada no modo " somente recebimento ".
numberPacketsReceived O número de pacotes de dados recebidos durante este atendimento que o número total de pacotes de dados RTP recebeu pelo dispositivo desde começar a recepção nesta conexão. A contagem inclui os pacotes recebidos das fontes diferentes se esta é uma chamada de transmissão múltipla. O valor é zero se a conexão foi ajustada no modo " somente envio ".
numberOctetsReceived O número de octetos (bytes) dos dados recebidos durante este atendimento o número total de octetos de carga úteis (isto é, não incluindo o encabeçamento ou acolchoando) recebeu em uns pacotes de dados RTP pelo dispositivo desde começar a recepção nesta conexão. A contagem inclui os pacotes recebidos das fontes diferentes, se esta é uma chamada de transmissão múltipla. O valor é zero se a conexão foi ajustada no modo " somente envio ".
numberPacketsLost Pacotes RTP perdidos durante esta conexão o número total de pacotes de dados RTP que foram perdidos desde o início da recepção. Este número é definido como o número de pacotes esperados, menos o número de pacotes recebidos realmente, onde o número de pacotes recebidos inclui alguns que estiverem atrasados ou os duplica. Assim, os pacotes que chegam tarde não estão contados como perdidos, e a perda podem ser negativos se há duplicatas. O número de pacotes esperados é definido para ser o último número de sequência prolongado recebido, como definido em seguida, menos o número de sequência inicial recebido. O valor é zero se a conexão foi ajustada no modo " somente envio ". (Para detalhes, veja o RFC 1889)
tremor A variação de sinal inter-chegada durante esta conexão uma avaliação da variância estatística do tempo de chegada interna do pacote de dados RTP, medida nos milissegundos e expressada como um inteiro não assinado. A variação de sinal inter-chegada J é definida para ser o desvio médio (valor absoluto alisado) da diferença D no afastamento do pacote no receptor comparado ao remetente para um par de pacotes. Os algoritmos detalhados da computação são encontrados no RFC 1889. O valor é zero se a conexão foi ajustada no modo " somente envio ".
latência A latência experimentou durante esta conexão que o valor é uma avaliação da latência da rede, expressada nos milissegundos. Este é o valor médio da diferença entre o timestamp do Network Time Protocol (NTP) indicado pelos remetentes das mensagens do Protocolo de Controle RTP (RTCP) e o rótulo de tempo do NTP dos receptores, medido quando estas mensagens são recebidas. A média é obtida somando todas as avaliações, a seguir dividindo-se pelo número de mensagens RTCP que foram recebidas. (Para detalhes veja a solicitação para comentários (RFC) 1889)

Registros de chamada registrados pelo tipo de chamada

Cada chamada normal entre dois partidos registra um registro de encerramento de chamada CDR. Cada registro de encerramento de chamada contém todos os campos identificados acima, mas alguns campos não podem ser usados. Se um campo não é usado, será vazio se é um campo do string ascii, ou "0" se é um campo numérico. Quando os serviços suplementares são envolvidos em um atendimento, mais registros de encerramento de chamada podem ser redigidos.

Além do que o registro de encerramento de chamada CDR, pode haver até um registro CMR por ponto final envolvido em um atendimento. Em uma chamada normal entre dois partidos cada um que usa um Cisco IP Phone, haverá dois registros CMR redigidos: um para o autor e um para o destino do atendimento.

Esta seção descreve os registros redigidos para tipos de chamada diferentes no sistema.

Chamadas normal (telefone IP IP Telefone-à-Cisco de Cisco)

As chamadas normal registram três registros pelo atendimento. São EndCall mais dois registros de diagnóstico, um para cada valor-limite. No registro de EndCall, todos os campos podem conter a informação válida. A duração será sempre diferente de zero a menos que a bandeira do “CdrLogCallsWithZeroDurationFlag” for permitida (ajuste para retificar). O campo " número de parte de chamada original " conterá o mesmo número de diretório que o campo " número de parte chamada original ".

Chamadas abandonadas

O registro dos atendimentos com duração zero é opcional. Normalmente, estes registros não serão registrados. Se registrar atendimentos com duração zero é permitido, as seguintes coisas devem ser notadas.

  • Se o atendimento esteve abandonado (como quando um telefone for gancho descolado e colocado para trás no gancho), os vários campos não conterão dados. Neste caso, o “originalCalledPartyNumber,” “finalCalledPartyNumber,” as separações associadas com eles, o “destIpAddr,” e os campos do dateTimeConnect estará vazio. Todos os atendimentos que não foram conectados terão uma “duração” dos segundos zeros. Quando um atendimento é abandonado, o código de causa é "0".

  • Se o usuário discou um número de diretório e abandonou então o atendimento antes que esteve conectado, “os campos primeiro Dest” e “Dest final” e suas separações associadas contiveram o número de diretório e a separação a que o atendimento seria estendido. “O campo IP Dest” estará vazio, e a duração será zero.

Atendimentos enviados ou reorientados

Os registros de chamada para chamadas encaminhadas serão os mesmos que aqueles para chamadas normal à exceção do campo " número de parte de chamada original " e dos campos do “originalCalledPartyNumberPartition”. Estes campos conterão o número de diretório e a separação para o destino que foi discado originalmente pelo autor do atendimento. Se o atendimento foi enviado, os campos do “finalCalledPartyNumber” e do “finalCalledpartyNumberPartition” serão diferentes e conterão o número de diretório e a separação do destino final do atendimento. Também, quando um atendimento é enviado, os campos do “lastRedirectDn” e do “lastRedirectDnPartition” conterão o número de diretório e a separação do último telefone que enviou ou reorientou este atendimento.

Atendimentos com os destinos ocupados ou ruins

Estes atendimentos serão registrados como uma chamada normal com todos os campos relevantes que contêm dados. O campo da causa do número chamado conterá um código de causa que indica porque o atendimento não foi conectado, e o IP do número chamado e a data/hora conectam campos estarão vazios. Se o autor abandonou o atendimento, a causa será “NO_ERROR” (0). A duração será sempre segundos zeros. Estes atendimentos não serão registrados a menos que o “CdrLogCallsWithZeroDurationFlag” for permitido.

Registros de gerenciamento de chamadas feitos por tipo de chamada

Cada chamada normal entre dois logs dos Telefones IP de Cisco exatamente dois registros CMR. Cada registro do atendimento CMR contém todos os campos identificados acima. Quando os serviços suplementares são envolvidos em um atendimento, mais de um registro pode ser redigido. Esta seção descreve quando os registros de diagnóstico são redigidos para tipos de chamada diferentes no sistema.

Chamadas normal

As chamadas normal registram exatamente dois registros CMR pelo atendimento, um para cada telefone envolvido no atendimento. Atualmente, somente os Telefones IP de Cisco e os gateways MGCP são capazes da resposta ao pedido da informação de diagnóstico. Todos os campos conterão a informação válida.

Chamadas abandonadas

Se o atendimento esteve abandonado (como quando um telefone for tomado o fora-gancho e colocado para trás no gancho), tudo coloca relacionado a fluir dados será a placa (zero). Isto é porque nenhuma conexão de fluência foi estabelecida, e consequentemente nenhum dados foi transferido. Nenhum registro com campos em branco será registrado se o “CdrLogCallsWithZeroDurationFlag” é desabilitado.

Chamadas encaminhadas

Os registros de chamada para chamadas encaminhadas serão os mesmos que aqueles para chamadas normal.

Atendimentos com os destinos ocupados ou ruins

No caso normal, somente os registros que representam os atendimentos que foram conectados realmente serão registrados. A fim registrar atendimentos com destinos ruins, você deve permitir o “CdrLogCallsWithZeroDurationFlag.” Se é permitido, a seguir todos os atendimentos estarão registrados que incluem o caso aonde o usuário vai fora-gancho e então em-gancho outra vez.

Se os atendimentos são registrados, estarão registrados como chamadas normal com todos os campos relevantes que contêm dados. Haverá somente um registro pelo atendimento desde que os atendimentos foram conectados nunca a um destino. O registro será para o autor do atendimento.

Tipos de codec (tipos de compressão/payload)

A tabela a seguir fornece valores e descrições para tipos de codec.

Descrição do codec
Codec Descrição
1 Não padronizado
2 G711A-law 64k
3 56K G711A-law
4 ½ do ¿  G711ï - lei 64k
5 ½ do ¿  G711ï - 56K da lei
6 G722 64k
7 56K G722
8 G722 48k
9 G7231
10 G728
11 G729
12 G729AnnexA
13 Is11172AudioCap
14 Is13818AudioCap
15 G729AnnexB
32 Dados 64k
33 56K dos dados
80 GS
81 ActiveVoice
82 G726_32K
83 G726_24K
84 G726_16K

Códigos da causa

A tabela a seguir fornece uma lista de códigos de causa que podem aparecer nos campos da causa.

Descrições do código de causa
Código de causa Descrição
0 Nenhum erro
1 Número (unassigned) Unallocated
2 Nenhuma rota ao transit network especificado (uso nacional)
3 Sem rota para o destino
4 Enviar tom de informação especial
5 Prefixo de tronco Misdialed (uso nacional)
6 Canal não aceitável
7 Atendimento concedido e que está sendo entregado em um canal estabelecido
8 Preempção
9 Preempção - circuito reservado para a reutilização
16 Limpeza normal de chamada
17 Usuário ocupado
18 Nenhum usuário está respondendo
19 Sem resposta do usuário (usuário alertado)
20 Assinante ausente
21 Chamada rejeitada
22 Número alterado
26 Limpeza de usuário não selecionada
27 O destino não está funcionando
28 Formato de número inválido (endereço incompleto)
29 Facilidade recusada
30 Resposta ao QUESTIONAMENTO DE STATUS
31 Normal, não especificado
34 Nenhuns circuito/canal disponível
38 A rede não está funcionando
39 Conexão de modo de estrutura permanente fora de serviço
40 Conexão do modo de estrutura permanente operacional
41 Falha temporária
42 Congestionamento do equipamento de switching
43 Informação de acesso descartada
44 Circuitos /canal solicitado não disponíveis
46 Atendimento da precedência obstruído
47 Recurso não disponível, não especificado
49 Qualidade de Serviço não disponível
50 Recurso solicitado não inscrito
53 Operação de serviço violada
54 Chamadas recebidas barradas
55 Chamadas recebidas barradas dentro do grupo de usuários fechado (CUG)
57 Capacidade do portador não autorizada
58 Capacidade do portador não está disponível presentemente
62 Inconsistência na classe que parte designada da informação de acesso e do subscritor
63 Serviço ou opção não disponível, não especificado
65 Capacidade do portador não implementada
66 Tipo de canal não implementado
69 Recurso solicitado, não implementado
70 Somente a capacidade do portador restrita da informação digitais está disponível (o uso nacional)
79 Serviço ou opção não executado, não especificado
81 Valor de referência de chamada inválido
82 O canal identificado não existe
83 Uma chamada suspensa existe, mas esta identidade de chamada não faz
84 Identidade de chamada no uso
85 Nenhuma chamada suspensa
86 O atendimento que tem a identidade de chamada pedida foi cancelado
87 Membro do usuário não do grupo de usuários fechado (CUG)
88 Destino incompatível
90 Desaparecidos do número de destino e DC não subscritos
91 Seleção inválida do transit network (uso nacional)
95 Mensagem inválida, não especificada
96 O elemento de informação obrigatório falta
97 Tipo de mensagem inexistente ou não executado
98 A mensagem não é compatível com o estado da chamada, ou o tipo de mensagem é inexistente ou não executado
99 Um elemento de informação ou um parâmetro não existem nem não são executados
100 Conteúdos inválidos do elemento de informação
101 A mensagem não é compatível com o estado da chamada
102 O atendimento foi terminado quando um temporizador expirou e uma rotina de recuperação foi executada para recuperar do erro
103 Parâmetro inexistente ou não executado - passado em (uso nacional)
110 Mensagem com parâmetro não reconhecido rejeitada
111 Erro de protocolo, não especificado
126 Separação do atendimento. Este é um código específico da Cisco. É usado quando um atendimento é terminado durante uma operação de transferência porque esteve rachado fora e terminado (não era parte da chamada transferida final). Isto pode ajudar a determinar que atendimentos foram terminados como parte de uma operação de transferência.
127 Entrelaçamento, não especificado

Alarmes

Um alarme é emitido quando o CDR ou os dados de diagnóstico são permitidos, e o sistema é incapaz de redigir os dados no base de dados.

Incapaz de redigir dados CDR. (Alarme # 1711 - Alarme principal)

O sistema tentado abrir o base de dados, e era mal sucedido. As causas prováveis incluem:

  • O CallManager da Cisco não tem privilégios suficientes abrir o arquivo para escrever ao base de dados. Certifique-se que o CallManager da Cisco tem os privilégios que permitirão escrevem operações.

  • O trajeto não se estabelece, ou o servidor de base de dados está para baixo.

Ligando para o Centro de Assistência Técnica da Cisco (TAC)

Se você tem um problema que não possa ser resolved com seu próprio Troubleshooting, chame por favor o TAC para o auxílio. Antes de chamar o TAC, tenha a informação seguinte disponível:

  • Detalhes do CallManager da Cisco

  • Topologia

  • Os logs e seguem-no foram executado durante o Troubleshooting, incluindo traços SDI e SDL

  • Stackwalk.txt arquiva do diretório WINNT\system32 e do sub-diretório de Trace do CallManager da Cisco

  • sh-tecnologia em Cisco IOS gateway, se aplicável

  • sh-tecnologia no CallManager da Cisco

  • Se o problema é com atendimentos através de um Cisco IOS gateway, por favor igualmente forneça:

    • debugar o inout do ccapi da Voz

    • debug isdn q931

    • somente] xboard sh do vfc [AS5300

    • [AS5300 somente] dspware de versão sh do vfc x

    • [AS5300 somente] vcware de versão sh do vfc x


Informações Relacionadas


Document ID: 30266