Troubleshooting do ISDN BRI Layer 3 usando o Comando debug isdn q931

Introduction

Ao Troubleshoot problemas de falhas de chamadas ISDN, é importante ter em mente que a chamada pode estar falhando devido a algum dos seguintes itens:

• Dial-on-Demand Routing (DDR)

• Camadas ISDN 1, 2 e 3

• Protocolo ponto-a-ponto (PPP) incluindo problemas relacionados ao protocolo de controle de link (LCP), à autenticação e ao protocolo de controle de IP (IPCP).

Este documento especificamente discute problemas relacionados a ISDN que causam falhas de chamadas. Este documento também assume que você verificou se as camadas 1 e 2 da ISDN estão funcionando em ambas as extremidades do circuito. Consulte Using the show isdn status Command for BRI Troubleshooting para obter mais informações sobre a verificação de status da camada 1 e 2 de ISDN.

Prerequisites

Requirements

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

Componentes Utilizados

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

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Conventions

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

Pré-requisitos para Troubleshooting: Ativando depurações da camada 3 do ISDN

Use o comando debug isdn q931 em ambas as extremidades para ativar a debugação da camada 3 de ISDN. Você também deve ter marcações de horário em milissegundos para depurações habilitadas em ambos os roteadores. Os timbres de hora são necessários para fornecer entrada relativa ao processo de Troubleshooting.

Observação: ative os timestamps de milissegundos para depurações usando os seguintes comandos:

maui-soho-01(config)#service timestamps debug datetime msec
maui-soho-01(config)#service timestamps log datetime msec

Para obter mais informações sobre os comandos de debugação, consulte Important Information on Debug Commands.

Iniciar a chamada de ISDN

Gere um ping ICMP para o endereço IP do roteador remoto. Isso deve iniciar uma chamada ISDN para esse roteador. Ambos os roteadores gerarão mensagens q931 do isdn de depuração.

Pode haver muitas variações nas trocas do Q.931 devido às exigências específicas para tipos de switch ISDN ou nos casos onde os parâmetros adicionais são exigidos. O seguinte diagrama ilustra as transações comuns de Q.931 durante uma configuração de chamada de ISDN bem-sucedida.

Observação: algumas das seguintes linhas de saída de depuração são divididas em várias linhas para fins de impressão.

maui-soho-01#
18:39:29.425: ISDN BR0: TX -> SETUP
    pd = 8  callref = 0x10

!-- The Calling Router Transmits !-- (indicated by TX) the SETUP message

18:39:29.433:
         Bearer Capability i = 0x8890
18:39:29.441: Channel ID i = 0x83
18:39:29.449:
         Keypad Facility i = '5558888'
18:39:29.822: ISDN BR0: RX <- CALL_PROC
    pd = 8  callref = 0x90

!-- The telco switch responds with a !-- Call Proceeding. This indicates the !-- network is processing the call.

18:39:29.830:
         Channel ID i = 0x89
.
.
.

!-- Nothing has been omitted here. The !-- dots were put in place to align !-- the Called and Calling Routers.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18:39:30.000: ISDN BR0: RX <- CONNECT
    pd = 8  callref = 0x90

!-- Received a CONNECT from the remote !-- router. The ISDN connection has been !-- established. Any failures of the call !-- past this point are due to higher !-- level issues such as DDR, PPP, !-- Authentication, IPCP/IP Addressing

18:39:30.036: ISDN BR0: TX -> CONNECT_ACK
    pd = 8  callref = 0x10

!--- The Router responds with a Connect !--- Acknowledgment (CONNECT_ACK) !--- to the telco.

maui-nas-08#
18:39:29.647: ISDN BR2/0: RX <- SETUP
    pd = 8  callref = 0x08

!-- The Called Router receives !-- (indicated by RX) a SETUP message !-- from the switch

18:39:29.647:
    Bearer Capability i = 0x8890

!-- The incoming call is 64k Digital. 

18:39:29.647: Channel ID i = 0x89
18:39:29.647:
    Signal i = 0x40 - Alerting on -
    pattern 0 
18:39:29.647:
    Called Party Number i = 0xC1,'5558888',
    Plan:ISDN, Type:Subscriber(local)
18:39:29.647:
    Locking Shift to Codeset 5
18:39:29.647:
    Codeset 5 IE 0x2A  
    i = 0x808001038001118001, '<'
18:39:29.651:
    ISDN BR2/0: Event: Received a DATA 
    call from  on B1 at 64 Kb/s
18:39:29.651: ISDN BR2/0: TX -> CALL_PROC
    pd = 8  callref = 0x88

!--- Router transmits a Call Proceeding
 
18:39:29.655:
         Channel ID i = 0x89
18:39:29.655: %LINK-3-UPDOWN:
 Interface BRI2/0:1, changed state to up
18:39:29.955: ISDN BR2/0: TX -> CONNECT
    pd = 8  callref = 0x88

!--- Call is accepted and the routers sends !--- a CONNECT message to the remote end

18:39:29.955:  Channel ID i = 0x89
18:39:29.995: ISDN BR2/0: RX <- CONNECT_ACK
    pd = 8  callref = 0x08

!--- Called device receives a CONNECT_ACK !--- from the switch

18:39:29.995:
         Channel ID i = 0x89
18:39:29.995:
         Signal i = 0x4F - Alerting off 
18:39:35.655: %ISDN-6-CONNECT:
 Interface BRI2/0:1 is now
 connected to unknown 

Ao avaliar a saída debug isdn q931 na chamada e nas extremidades chamadas, mantenha os seguintes pontos na mente:

• Preste atenção à direção das mensagens. As depurações indicam se as mensagens foram geradas pelo roteador (indicado por TX ->) ou se foram recebidas pelo roteador (indicado por RX <—). No exemplo abaixo, a primeira mensagem (CONNECT) é recebida pelo roteador do Switch ISDN, enquanto a segunda mensagem (CONNECT_ACK) é enviada pelo roteador:

  18:39:30.000: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x90
  18:39:30.036: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x10
  
  

  É possível identificar a fonte do problema seguindo a direção de uma mensagem específica e a resposta. Por exemplo, se o roteador recebe inesperadamente uma mensagem RELEASE do switch telco ISDN; isso redefinirá o fim da conexão também. Isso indica que o problema encontra-se no switch telco ISDN ou o roteador remoto

• Verifique se a mensagem recebida ou enviada é a prevista. Por exemplo, se a parte chamada receber uma mensagem SETUP, mas enviar uma mensagem DISCONNECT em vez de CONNECT, faça Troubleshooting no Roteador Chamado e não na rede ISDN. A tabela a seguir possui uma lista de possíveis mensagens Q.931 vistas durante o estabelecimento e a destruição de chamadas:

Visão geral de Troubleshooting: Sintoma e procedimento de resolução

Analise a saída de debug isdn q931 conforme descrito nas seções anteriores e prossiga para o sintoma apropriado discutido abaixo.

Observação: neste documento, o roteador que inicia a chamada é chamado de roteador chamador, enquanto o roteador que aceita a chamada é conhecido como roteador chamado.

Troubleshooting: Sintoma e procedimento detalhado para resolução

O roteador de chamada não envia uma mensagem SETUP

Se o roteador chamador não enviar uma mensagem SETUP para a rede ISDN, provavelmente o problema está relacionado com problemas nas camadas ISDN 1, 2 ou no Dial-On-Demand Routing (DDR), e não está relacionado ao Layer 3.

Execute as seguintes tarefas no roteador de chamada:

• Verifique se o tipo de switch ISDN está configurado corretamente:

  O tipo de switch ISDN pode ser verificado usando o comando show isdn status. A Telco deve indicar explicitamente o tipo de switch que precisa ser configurado. Às vezes, (especialmente na América do Norte), a Telco pode indicar que o tipo de switch é "personalizado" ou "nacional". Nesses casos, use as seguintes diretrizes para determinar a configuração do tipo de switch:

  • Personalizado: Se a Telco indicar um switch do tipo personalizado, configure o switchtype no roteador como basic-5ess (para BRI com switch 5ess), primary-5ess (para PRI com 5ess), basic-dms (para BRI com switch DMS) ou primary-dms (para PRI com DMS).

  • Nacional: Tipo de Switch de acordo com o padrão NI-1 para BRI e com o padrão NI-2 para PRI (não há padrão NI-1 para PRIs). Caso a Telco o informe que o tipo de switch é Nacional, a configuração do Cisco Router deve ser basic-ni (para BRI) ou primary-ni (para PRI).

  Para configurar o Switchtype, utilize o comando isdn switch-type switch-type no modo de configuração da interface BRI. Para ver um exemplo, consulte Troubleshooting de ISDN BRI Layer 1

• Verifique se as Camadas 1 e 2 ISDN do Roteador de chamada estão funcionando:

  Você pode verificar se as camadas de ISDN 1 e 2 estão prontas para utilizar o comando show isdn status. Use o procedimento descrito para solucionar problemas relacionados a ISDN de Camada 1 e 2.

• Use o comando show ip route para verificar se o roteador tem uma rota para o destino.

  O comando da show ip routeindicará se há uma rota para a rede do roteador remoto. Se a rota não existir, use o comando da ip route para adicionar uma rota estática para a rede remota. Assegure-se de que a rota se dirige para a interface correta no roteador de chamada.

  Em um ambiente de Legacy DDR (por exemplo, mapas de discador), o Next Hop deve ser a rede de interface física (interface BRI x) ou o IP Address do roteador remoto (que também deve ter sido configurado na instrução de mapa de discador).

  Com os perfis de discagem, o salto seguinte geralmente é a interface Dialer x utilizada para o dialout. Por exemplo,

  maui-soho-01#show ip route
  ...
  ...
  !-- Output omitted
  
  ...
  
       10.0.0.0/24 is subnetted, 1 subnets
  C       10.0.0.0 is directly connected, Ethernet0
  S*   0.0.0.0/0 is directly connected, Dialer1
  

  No exemplo acima, observe que a nó seguinte da rota padrão é a interface Discador 1 (a interface lógica de discador dessa conexão).

• Verifique se o tráfego interessante está identificado corretamente.

  O roteador verifica se um pacote recebido é tráfego interessante antes de iniciar a discagem. Portanto, o roteador não pode discar se o tráfego interessante está definido incorretamente, ou se o número de lista de discador (a definição de tráfego interessante) não está aplicado ao exame ou à interface do discador (que usam o comando dialer-group number). Por exemplo, se utilizar um ping ICMP para iniciar a conexão DDR, verifique se o ICMP está permitido na definição de tráfego interessante.

  Consulte Configurando o dialup BRI-to-BRI com os mapas de discadores DDR para obter mais informações.

• Verifique se a string apropriada do discador (ou mapa do discador) inclui o número ISDN do dispositivo remoto.

  A string de discador (ou mapa de discador) deve incluir o número de ISDN do roteador remoto. Por exemplo,

  dialer string 5551111
  or
  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
  

• Verifique a configuração de DDR e use o discador de debugação para verificar se o roteador está iniciando a chamada:

  Verifique se a configuração de DDR está correta. Use a tecnologia de discagem do documento: Visões gerais e explicações para assistência adicional na configuração correta do DDR.

  É possível também utilizar o comando debug dialer para verificar se o roteador recebe tráfego de interesse e se possui mapa ou seqüência apropriados de discagem, para iniciar este processo. Consulte o documento acima além de tecnologia dial-up: Técnicas de Troubleshooting para obter mais informações.

  Consulte a seguinte configuração como exemplo de configuração adequada do DDR:

  Perfis do discador: Configurando ISDN DDR com DDR de perfis de discagem herdados (mapas de discadores): Configurando o Dialup BRI-to-BRI com os mapas de discadores DDR

  Dica: para fins de teste, você pode eliminar o DDR usando o comando isdn call (explicado na próxima seção) para gerar uma chamada ISDN para o dispositivo remoto. Se essa chamada tiver sucesso, você poderá estar razoavelmente certo que os circuitos de ISDN estão funcionando. Continue a Troubleshoot o DDR.

• Executar uma chamada de teste de loopback

  Em uma chamada de circuito de retorno, o roteador disca o número ISDN de seu próprio BRI. A chamada prossegue para a nuvem da empresa de telecomunicações, onde a empresa de telecomunicações a encaminha para o segundo canal de BRI. Essa chamada agora é vista pelo roteador como uma chamada de entrada no segundo canal. Portanto, o roteador envia e recebe a chamada ISDN.

  Uma chamada de circuito de retorno testa a capacidade de o roteador iniciar e encerrar uma chamada ISDN. Uma chamada de loopback bem-sucedida fornece uma indicação forte de que os circuitos de ISDN para a nuvem Telco estão funcionando corretamente.

  A seguir há um exemplo anotado de chamada de loopback de bem-sucedida. O comando isdn call (introduzido no software Cisco IOS® 12.0(3)T) permite chamadas isdn de saída sem exigir os requisitos de DDR tais como o tráfego interessante e as rotas. Este comando só pode ser usado para teste do circuito ISDN e não pode ser usado para passar tráfego ou como substituição de uma configuração DDR adequada. Este comando permite verificar se o circuito ISDN, especialmente na Camada 3, está funcionando.

maui-soho-04#isdn call interface bri 0 5551111

!--- the router will dial 5551111 (the ISDN number of the router's own BRI)

maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch. !--- The switch is now processing the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the !--- incoming call. Remember that the router sent a Setup message (for the !--- outgoing call) and now receives a SETUP message for the same call

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: 
Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect for the outgoing call

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: 
Interface BRI0:1 is now connected to 5551111 

! --- Call is now connected. Loopback call is successful

Notas:

• Durante uma chamada de loopback, o roteador atua tanto como o roteador chamador quanto como o chamado (embora em diferentes canais B). É importante que você controle essas "funções duplas" ao interpretar a saída de debug isdn q931. Por exemplo, o roteador transmite uma mensagem de configuração (TX -> SETUP) e também recebe uma (RX <- SETUP). A mensagem SETUP (CONFIGURAÇÃO) transmitida deve estar associada à chamada de saída, enquanto a mensagem SETUP recebida deve estar associada à chamada de entrada.

• No exemplo acima, discamos o número para o primeiro canal B. Entretanto, a empresa de telecomunicações reconhecendo que o primeiro canal B estava ocupado (uma vez que estava fazendo a ligação), comutou a chamada para o segundo canal B e a conexão foi concluída com sucesso. Contudo, um erro de configuração no switch telco pode resultar em uma falha da chamada de loopback, devido à tentativa do switch de atribuir a chamada ao primeiro canal (que está ocupado fazendo a chamada). O telco deve corrigir esse problema. Contudo, como uma solução alternativa, especifique o segundo número de canal B no comando isdn call.

• Se a chamada de loopback for bem-sucedida e a chamada à extremidade remota continuar a falhar, entre em contato com a empresa de telecomunicações para obter mais assistência de Troubleshooting para seu circuito BRI.

O roteador chamado não recebe uma mensagem SETUP

Se você determinar que o Roteador Chamador deve enviar uma mensagem ISDN Layer 3 SETUP (CONFIGURAÇÃO de Camada 3 de ISDN), mas o Roteador Chamado não a receber, então o problema poderá estar relacionado às camadas 1 e 2 do ISND no Roteador Chamado ou na nuvem ISDN da empresa de telecomunicações.

Execute as seguintes tarefas no roteador chamado:

• Verifique se o tipo de switch ISDN está configurado corretamente:

  O tipo de switch ISDN pode ser verificado usando o comando show isdn status. A Telco deve indicar explicitamente o tipo de switch que precisa ser configurado. Às vezes, (especialmente na América do Norte), a Telco pode indicar que o tipo de switch é "personalizado" ou "nacional". Nesses casos, use as seguintes diretrizes para determinar a configuração do tipo de switch:

  • Personalizado: Se a Telco indicar seu Switch é do tipo personalizado, configure o switchtype no roteador como basic-5ess (para BRI com 5ess Switch), primary-5ess (para PRI com 5ess), basic-dms (para BRI com DMS Switch) ou primary-dms (para PRI com DMS).

  • Nacional: Tipo de Switch de acordo com o padrão NI-1 para BRI e com o padrão NI-2 para PRI (não há padrão NI-1 para PRIs). Caso a Telco o informe que o tipo de switch é Nacional, a configuração do Cisco Router deve ser basic-ni (para BRI) ou primary-ni (para PRI).

  Para configurar o tipo de switch, utilize o comando isdn switch-type switch type no modo de configuração da interface BRI. Para ver um exemplo, consulte Troubleshooting de ISDN BRI Layer 1

• Verifique se as Camadas 1 e 2 ISDN do Roteador de chamada estão funcionando:

  Você pode verificar se as camadas de ISDN 1 e 2 estão prontas para utilizar o comando show isdn status. Utilize o procedimento descrito em Using the show isdn status Command for BRI Troubleshooting (Utilizando o comando show isdn status para solucionar problemas de BRI) para solucionar problemas relacionados às Camadas 1 e 2 de ISDN.

• Verifique se o número de diretório local SPID (LDN) está configurado corretamente

  Determinados tipos de comutação exigem que o spid e o ldn estejam corretamente configurados para que seja possível aceitar chamadas de entrada. Consulte Troubleshooting ISDN BRI SPIDs para obtermais informação.

Execute as seguintes tarefas no roteador de chamada:

• Use um telefone análogo regular para fazer uma chamada de teste para o roteador remoto.

  Usando um telefone analógico regular, disque o número de ISDN do Roteador chamado exatamente como foi configurado no Roteador chamador. O Roteador Chamado deve receber uma mensagem de configuração (SETUP) (apesar de a chamada falhar posteriormente, já que não se trata de uma chamada ISDN). Se o roteador chamado receber a mensagem de SETUP, então pode-se presumir que a rede do ISDN do lado chamado está funcionando. A questão seria com a rede ISDN da estação local, o número ISDN de destino, o serviço de longa distância, entre outros. Continue usando as etapas abaixo.

• Tenha certeza de que o número de destino da ISDN está corretamente configurado.

  Verifique a configuração do Roteador Chamador e se o número ISDN configurado para o roteador remoto está correto. Muito frequentemente os circuitos de ISDN atrás de um PBX exigem um 9 que precede o número ISDN. Além disso, se a chamada é de longa distância (nos EUA), você deve incluir o dígito 1 antes do número ISDN do local remoto (similar à discagem de longa distância normal do telefone). Por exemplo, considere uma situação em que a instalação local está atrás de um PBX e a chamada para o local remoto precisa ser uma chamada de longa distância. O número ISDN da extremidade remota é 5551111 dentro do código de área 512. Nesse caso, incluindo os dígitos apropriados para o PBX e a longa distância, o número discado é 915125551111.

  O motivo de desconexão do debug isdn q931 também pode ser usado para determinar se a falha de chamada deve-se a um número ISDN remoto incorreto ou a um número formatado inadequadamente. Consulte o documento Understanding debug isdn q931 Disconnect Cause Codes para obter mais informações sobre interpretação de códigos da causa da desconexão do ISDN q931.

  Uma desconexão devido a um número de ISDN incorreto pode ser indicada por:

  Aug 13 18:20:01.100: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x85
  Aug 13 18:20:01.112: Cause i = 0x81D8 - Incompatible destination
  

  Ao consultarmos o documento de códigos de causas de desconexão mencionado anteriormente, podemos determinar que o código de desconexão foi provocado por uma tentativa de se conectar a um equipamento não-ISDN. (Por exemplo, uma linha analógica.).

  Uma desconexão devido a um número formatado incorretamente pode ser indicada por:

  Aug 13 18:23:14.734: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x86
  Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format 
  (incomplete number)
  

  Consultando o documento Noções Básicas Sobre Códigos de Causa de Desconexão debug isdn q931, podemos determinar se o código de desconexão foi causado por um formato inválido para o número ISDN remoto. Há falha na conexão porque o endereço de destino é apresentado (ao switch) em um formato irreconhecível, ou o endereço de destino está incompleto.

• Se aplicável, determine se o serviço a longa distância está ativo:

  Você deve contatar sua companhia telefônica local e de longa distância para verificar se o serviço está ativado. Geralmente, a Telco local tem o circuito ISDN configurado inadequadamente, de maneira que as chamadas ISDN externas de longa distância não são comutadas para a rede correta do provedor de longa distância. Você também deve verificar se a rede de provedores de longa distância está funcionando.

  Nos EUA e em situações em que a telco/provedor de chamadas a longa distância não consegue retificar o problema, pode ser necessário usar uma companhia telefônica "de longa distância pré-assinada" (PIC). Códigos PIC são prefixos de 7 dígitos que identificam companhias de longa distância de longa distância dos Estados Unidos para as portadoras de intercâmbio locais (LEC). Isso permite aos clientes usar portadoras de chamadas interurbanas diferentes para chamadas separadas. O código PIC está configurado como um prefixo para o número discado. A maioria dos PICs apresenta formato 1010xxx. Para obter uma listagem numérica de PICs, consulte US PIC codes, Numerically

• Configurar dois mapas de discadores ou duas instruções de string de discador; um por cada número de ISDN de canal B remoto.

  Configurar um mapa de discadores (ou uma string do dialer, se estiver usando perfis do discador) para cada canal B remoto permite que a conexão continue mesmo se companhia telefônica não é capaz de comutar a segunda chamada para o segundo canal B de ISDN.

  Observação: esta solução alternativa é necessária se apenas um canal B estiver aceitando chamadas em uma BRI específica. Esse problema ocorre com freqüência em conexões multilink.

  Uma amostra de configuração (que usa mapas de discagem) é fornecida:

  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
  dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551112
  
  !--- dialer map statements for the remote router !--- The two different phone numbers correspond !--- to the b-channels of the remote side. The multiple statements allow !--- the router to dial the second number if the first number is busy. 
  
  

O roteador chamado não envia uma mensagem CONNECT

Se o Roteador chamado receber uma mensagem SETUP e não responder com uma mensagem CONNECT, isso pode indicar que o roteador (devido a um motivo desconhecido) escolheu não aceitar a chamada.

Execute as seguintes tarefas no roteador chamado:

• Verifique se a chamada é rejeitada devido à seleção baseada em ID/DNIS do chamador:

  O ID de chamador ou a seleção baseada em DNIS permite que o roteador aceite ou negue seletivamente chamadas específicas sem incorrer cobranças de tarifa. Com a exibição baseada em identificador de chamada, o roteador chamado recebe (na mensagem de INICIALIZAÇÃO) o número da parte que está chamando. Com isso, o roteador pode permitir chamadas de certos números, fornecendo alguma segurança. Com a triagem baseada em DNIS o Roteador Chamado discrimina chamadas recebidas com base no número discado.

  Há dois pontos importantes a serem lembrados em relação à filtragem baseada em CLID/DNIS:

  1) O telco deve fornecer informações CLID/DNIS apropriadas na mensagem SETUP. Se você permite a seleção do ID do chamador no roteador, mas não tem os dígitos de ID de chamador que estão sendo passados ao roteador, todas as chamadas será selecionadas e nenhuma chamada será aceita.

  2) Verifique o formato dos dígitos CLID/DNIS entregues pela companhia telefônica (na saída debug isdn q931 ). Por exemplo, algumas companhias telefônicas incluem o código de área nos dígitos CLID/DNIS entregues, quando outros não fizerem. Corrija qualquer configuração CLID/DNIS da forma apropriada.

  Segue abaixo um exemplo de uma chamada falha. O roteador tem habilitada a triagem baseada no CLID, porém, como a empresa de telecomunicações não fornece os dígitos do CLID, o roteador recusa as chamadas.

  maui-nas-08#
  05:46:33: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x4E
  
  ! --- The router receives (RX) a SETUP message
  
  05:46:33:         Bearer Capability i = 0x8890
  05:46:33:         Channel ID i = 0x89
  05:46:33:         Signal i = 0x40 - Alerting on - pattern 0 
  05:46:33:         Called Party Number i = 0xC1, '5558888', Plan:ISDN,
    Type:Subscriber(local)
  
  ! --- The Called Number (DNIS) is delivered to the router ! --- Note that CLID information is not delivered
  
  05:46:33:         Locking Shift to Codeset 5
  05:46:33:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
  05:46:33: ISDN BR2/0: TX ->  RELEASE_COMP pd = 8  callref = 0xCE
  05:46:33:         Cause i = 0x8095 - Call rejected
  
  ! --- Calls is Rejected due to screening
  
  

  Para obter mais informações sobre o ID de chamada, consulte a autenticação e o retorno de chamada para ISDN com ID de chamada

• Verifique se os SPIDs estão corretos:

  Use o comando show isdn status para verificar se os SPIDs no Roteador chamado estão corretos. Consulte Using the show isdn status Command for BRI Troubleshooting para obter informações adicionais sobre a soluções de problemas relacionados a Spid.

• Certifique-se de que existam canais B disponíveis no circuito que foi discado:

  Use o comando exibir status isdn para verificar se há canais disponíveis no circuito discado. Se não houver canais disponíveis, use o comando clear para liberar alguns.

• Se diversas BRIs estiverem disponíveis, faça a empresa de telecomunicações configurá-las em um grupo de busca:

  Ter vários BRIs em um grupo de perseguição permite ao telco comutar a chamada para qualquer cirtuito BRI livre nesse roteador. Contate Telco sobre este recurso.

• Verifique se você está tendo problemas relacionados à recursos do portador:

  A capacidade do portador (ou bearer cap) é a indicação de serviço de camada 3 que define as características de determinada chamada. A Cobertura do Portador de uma chamada é indicada pelo telco nas mensagens SETUP Q.931. A cobertura do portador é freqüentemente usada para diferenciar chamadas de voz de 64k (analógicas), chamadas de dados de 56k e chamadas de dados de 64k. As mensagens de cobertura do portador vistas mais comumente e suas descrições são fornecidos abaixo:

  Cobertura do portador	Descrição
  0x8890	Chamada ISDN de 64K
  0x8890218F	Chamada ISDN de 56K
  0x8090A2	Chamada de voz/discurso (u-law)
  0x9090A2	Voice/Speech call (u-law) - 3.1 kHz Audio
  0x8090A3	Chamada de voz/fala (A-law)
  0x9090A3	Voice/Speech call (A-law) - 3.1 kHz Audio

  A seguir está um exemplo de uma chamada ISDN de 64 K:

  Aug  8 18:49:48.246: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x6F
  
  !-- Incoming SETUP messages
  
  Aug  8 18:49:48.246:         Bearer Capability i = 0x8890
  
  !-- The bearer cap indicates the incoming call is ISDN 64k
  
  Aug  8 18:49:48.246:         Channel ID i = 0x89......
  

  Execute as etapas abaixo, dependendo da capacidade do portador da chamada:

  A capacidade do portador é 0x8890218F: A chamada é ISDN digital de 56 K:

  • Verifique se o tipo de switch ISDN está configurado corretamente:

    O tipo de switch ISDN pode ser verificado usando o comando show isdn status. A Telco deve indicar explicitamente o tipo de switch que precisa ser configurado. Às vezes, (especialmente na América do Norte), a Telco pode indicar que o tipo de switch é "personalizado" ou "nacional". Nesses casos, use as seguintes diretrizes para determinar a configuração do tipo de switch:

    • Personalizado: Se a Telco indicar seu Switch é do tipo personalizado, configure o switchtype no roteador como basic-5ess (para BRI com 5ess Switch), primary-5ess (para PRI com 5ess), basic-dms (para BRI com DMS Switch) ou primary-dms (para PRI com DMS).

    • Nacional: Tipo de Switch de acordo com o padrão NI-1 para BRI e com o padrão NI-2 para PRI (não há padrão NI-1 para PRIs). Caso a Telco o informe que o tipo de switch é Nacional, a configuração do Cisco Router deve ser basic-ni (para BRI) ou primary-ni (para PRI).

    Para configurar o tipo de switch, utilize o comando isdn switch-type switch type no modo de configuração da interface BRI. Para ver um exemplo, consulte Troubleshooting de ISDN BRI Layer 1

  • No lado de discagem, verifique que a velocidade/taxa da chamada é de 56k. Isso é necessário porque alguns switches ISDN legados não podem estar passando um canal claro e podem forçar a fazer sua chamada em 56K para atravessar.

    Use o parâmetro de velocidade no comando dialer map configuration para efetuar chamadas de saída em 56 Kbps, como no exemplo seguinte:

    maui-soho-01(config)#interface bri 0
    maui-soho-01(config-if)#dialer map ip 10.1.1.1 name 
    Maui-NAS-08 speed 56 5551111
    
    !-- The keyword speed 56 sets the outgoing call rate at 56k
    
    

    O exemplo a seguir mostra como configurar um perfil de discador do Cisco IOS para fazer chamadas de saída a 56 Kbps:

    maui-soho-01(config)#interface dialer 1
    maui-soho-01(config-if)#dialer string 5558888 class 56k     
    
    !-- Use the map-class named "56k" when dialing number 5558888 
               
    maui-soho-01(config-if)#exit
    maui-soho-01(config)#map-class dialer 56k
    
    !-- map-class named "56k" that was used with the dialer string above
    
    maui-soho-01(config-map-clas)#dialer isdn speed 56
    
    !-- Set the speed of the call to be 56k (default is 64k)
    
    

  • No lado do receptor, configure o comando isdn not-end-to-end 56 na interface BRI.

    Maui-NAS-08(config)#interface bri 2/0
    Maui-NAS-08(config-if)#isdn not-end-to-end 56
    

    A capacidade do portador ISDN Q.931 e outros IEs são usados para determinar a velocidade da chamada de entrada e, na maioria das circunstâncias, operarão corretamente. Contudo, em algumas aplicações de país para país (ou devido a alguns switches legados), a mensagem de configuração de chamada de entrada será entregue com uma capacidade do portador que não atende à chamada de origem. Se uma mensagem que indica que o isdn 'not end-to-end' é recebida, o roteador pode cancelar a capacidade do portador recebida usando o comando de configuração do Cisco IOS isdn not end-to-end.

    A capacidade do portador é 0x8090A2 ou 0x9090A2: Chamada de voz/discurso (u-law)

    A capacidade do portador é 0x8090A3 ou 0x9090A3: Chamada de voz/fala (A-law)

    A chamada recebida é uma chamada analógica de 64 K. Com relação a aplicativos de modem, a chamada será enviada para os modems internos, enquanto, para aplicativos de voz, a chamada pode ser enviada para o módulo de voz adequado. Execute as seguintes etapas:

    1. No lado receptor, verifique se a interface física de ISDN (por exemplo, interface bri 0) possui o isd incoming-voice modem configurado.

    2. Verifique se as linhas do modem têm o comando modem inout.

    Para obter um exemplo de configuração, consulte o documento Configurando a conectividade do modem com um Cisco 3640 BRI

  • Interprete o código da causa da desconexão enviado (do Roteador chamado ao roteador de chamada) na mensagemDISCONNECT ou RELEASE

    Se o Roteador chamado não enviar um mensagem CONNECT ao Roteador de chamada, deverá enviar de volta uma mensagem DISCONNECT ou RELEASE. Essa mensagem DISCONNECT ou RELEASE também deve ser incluída em um Código da causa da desconexão. No exemplo abaixo, o código de causa da Desconexão é 0x8090. Consulte o documento Understanding debug isdn q931 Disconnect Cause Codes para interpretar o código de desconexão.

    Aug 22 19:25:24.290: ISDN BR0: TX ->  DISCONNECT pd = 8  
    callref = 0x06
    Aug 22 19:25:24.298:         Cause i = 0x8090 - Normal call clearing
    

O roteador de chamada não recebe uma mensagem CONNECT (Conectar)

Se o roteador chamado enviar uma mensagem CONNECT, mas esta mensagem não for recebida pelo roteador chamador, então é muito provável que o problema seja com a empresa de telecomunicações.

• Determine se o roteador recebe CONNECT_ACK a partir do Switch ISDN local:

  Isso indica que o switch telco perto do Roteador chamado aceitou o mensagem CONNECT e está passando a mensagem CONNECT ao Roteador de chamada. Uma falha da chamada é provavelmente um problema da companhia telefônica.

• Entre em contato com a companhia telefônica para Troubleshooting.

O roteador de chamada recebe um CONNECT, mas ainda assim a chamada falha

Se o Roteador de chamada recebe um mensagem CONNECT, isso indica que a conexão ISDN está ativa e funcionando corretamente. Entre em contato com a empresa de telecomunicações para determinar se há um problema com o B-Channel que não está sendo mapeado adequadamente nos dados. Toda a falha da chamada, após esta fase, deve-se a um problema da camada superior, como com PPP, autenticação ou negociação de endereço IPCP/IP. Use a negociação de ppp de debugação para solução de problemas de ppp.

Você também deve consultar o documento Dialup Technology: Troubleshooting Techniques para obter técnicas de solução de problemas de PPP.

Informações Relacionadas

• Acesse a página de suporte de tecnologia
• Suporte Técnico - Cisco Systems

Histórico de revisões