Resolución de problemas de la Capa 3 de ISDN BRI mediante el comando debug isdn q931

Introducción

Durante la resolución de problemas de falla de llamada ISDN, es importante tener en cuenta que la llamada podría estar fallando debido a cualquiera de los siguientes:

• Dial-on-Demand Routing (DDR)

• Capas ISDN 1, 2 y 3

• Point-to-Point Protocol (PPP): incluyendo problemas relacionados con el Link Control Protocol (LCP) y el Authentication o IP Control Protocol (IPCP).

Este documento se centra específicamente en los problemas de ISDN que causan fallas de llamada. Este documento también da por sentado que ha verificado que las capas 1 y 2 de ISDN en ambos extremos del circuito están funcionando. Refiérase a Utilización del Comando show isdn status para el Troubleshooting de BRI para obtener más información sobre la verificación del estado de la capa ISDN 1 y 2.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Requisitos previos de la solución de problemas: Activación de depuración de la capa 3 de ISDN

Utilice el comando debug isdn q931 en ambos extremos para activar los debugs de la capa ISDN 3. También debe tener sellos de hora en milisegundos para las depuraciones habilitadas en ambos routers. Las marcas de fecha y hora son necesarias a fin de brindar una entrada relativa para el proceso de solución de problemas.

Nota: Active las marcas de tiempo en milisegundos para las depuraciones utilizando los siguientes comandos:

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

Para obtener más información sobre los comandos debug, refiérase a Información Importante sobre los Comandos Debug.

Inicie la llamada ISDN

Genere un ping ICMP a la dirección IP del router remoto. Esto debería iniciar una llamada ISDN a ese router. Ambos routers generarán mensajes debug isdn q931.

Puede haber muchas variaciones en los intercambios Q.931 debido a requerimientos específicos para tipos de switches ISDN o en los casos en los que se requieren parámetros adicionales. El siguiente diagrama ilustra transacciones Q.931 comunes durante una configuración de llamada ISDN correcta.

Nota: Algunas de las siguientes líneas de salida de depuración se dividen en varias líneas con fines de impresión.

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 

Cuando evalúe la salida del comando debug isdn q931 en los extremos de llamada y llamado, tenga presentes los puntos siguientes:

• Preste atención a la dirección de los mensajes. Las depuraciones indican si los mensajes fueron generados por el router (indicado por TX ->) o si fueron recibidos por el router (indicado por RX <—). En el ejemplo que se encuentra abajo, el router recibe el primer mensaje (CONECTAR) desde el switch ISDN, mientras que el router envía el segundo (CONECTAR_ACUSE DE RECIBO):

  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
  
  

  Puede identificar el origen del problema siguiendo la dirección de un mensaje en particular y la respuesta. Por ejemplo, si el router inesperadamente recibe un mensaje RELEASE desde el switch telco ISDN, también reestablecerá su extremo de la conexión. Esto indica que el problema se encuentra en el switch ISDN de la compañía telefónica o en el router remoto.

• Verifique que el mensaje recibido o enviado sea el previsto. Por ejemplo, si la parte que recibe la llamada recibe un mensaje SETUP (Configurar) pero envía un mensaje DISCONNECT (Desconectar) en lugar de uno CONNECT (Conectar), entonces solucione el problema en el router marcado y no en la red ISDN. La siguiente tabla tiene una lista de mensajes Q.931 posibles vistos durante el establecimiento y el desmembramiento de las llamadas.

Descripción general de la resolución de problemas: Síntomas y procedimiento de solución

Analice la salida del debug isdn q931 tal como se describió en las secciones anteriores y continúe con el síntoma apropiado que se analiza a continuación.

Nota: En este documento, el router que inicia la llamada se denomina Router llamante, mientras que el router que acepta la llamada se denomina Router llamado.

Resolución de problemas: Síntomas y procedimiento detallado para la resolución

El router llamador no envía un mensaje de CONFIGURAR

Si el Router llamador no envía un mensaje SETUP a la red ISDN, es muy probable que el conflicto esté relacionado con problemas de capas ISDN 1, 2 o de Dial-on-demand Routing (DDR), y no con una capa 3.

Realice las siguientes tareas en el router llamador:

• ‘Verifique que la configuración del tipo de switch para ISDN sea correcta.’

  Es posible verificar el tipo del switch de ISDN con el comando show isdn status. La compañía telefónica debería indicar explícitamente el tipo de switch que debe configurarse. Ocasionalmente, especialmente en América del Norte, la compañía telefónica puede indicar si el tipo de switch es "personalizado" o "nacional". En tales casos, utilice las siguientes pautas para determinar la configuración del tipo de switch:

  • Local': Si la compañía telefónica indica que su tipo de switch es personalizado, configure el tipo de switch en el router como basic-5ess (para BRI con switches 5ess), primary-5ess (para PRI con 5ess), basic-dms (para BRI con DMS switch) o primary-dms (para PRI con DMS).

  • Nacional El tipo de switch cumple con los estándares NI-1 para BRI y NI-2 para PRI (no hay estándar NI-1 para PRI). Si la compañía telefónica le informa que el tipo de switch es National, entonces la configuración del router Cisco debe ser basic-ni (para BRI) o primary-ni (para PRI).

  Para configurar el tipo de switch, utilice el comando isdn switch-type en el modo de configuración de interfaz BRI. Para ver un ejemplo, consulte la sección Resolución de problemas de ISDN BRI Capa 1

• Verificar que las capas ISDN 1 y 2 en el router de llamada estén funcionando:

  Puede verificar que las capas 1 y 2 de ISDN estén en funcionamiento utilizando el comando show isdn status. Utilice el procedimiento descrito para resolver los problemas relacionados con la Capa 1 y 2 de ISDN.

• Utilice el comando show ip route para verificar que el router posee una ruta al destino.

  El comando show ip route indicará si hay una ruta a la red del router remoto. Si no existe la ruta, utilice el comando ip route para añadir una ruta estática para la red remota. Asegúrese de que la ruta apunte a la interfaz correcta en el router de llamada.

  En un entorno DDR de legado (por ejemplo, correspondencias de marcador) el salto siguiente debería ser la red de interfaz física (interfaz BRI x) o la dirección IP del router remoto (que también debería haber sido configurado en la sentencia de correspondencia de marcador)

  Con los Perfiles de marcado, el próximo salto es generalmente la interfaz del Marcador x que se utiliza para el marcado de salida. Por ejemplo,

  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
  

  En el ejemplo anterior, observe que el salto siguiente de la ruta predeterminada es la interfaz del Marcador 1 (la interfaz del marcador lógico para esta conexión).

• Verifique que el tráfico interesante está debidamente identificado.

  Antes de iniciar el marcado, el router verifica que un paquete entrante contenga tráfico interesante. Por lo tanto, es posible que el router no pueda marcar si dialer-list number (la definición de tráfico interesante) no se aplica a la interfaz física o de marcador (usando el comando dialer-group number). Por ejemplo, si está utilizando un ping ICMP para iniciar la conexión DDR, verifique que el ICMP esté permitido en la definición de tráfico interesante.

  Para más información, consulte la sección Configuración del marcado manual BRI a BRI con correspondencias de marcador de DDR.

• Controlar si la cadena de marcador adecuada (o correspondencia de marcador) incluye el número ISDN de dispositivo remoto.

  La cadena del marcador (o mapa del marcador) debe incluir el número ISDN del router remoto. Por ejemplo,

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

• Compruebe la configuración DDR y utilice debug dialer para verificar que el router está iniciando la llamada:

  Verificar que la configuración DDR es correcta. Utilice el documento Tecnología de Marcación Manual: Descripciones y explicaciones para obtener asistencia sobre la configuración correcta de DDR.

  También debe usar el comando debug dialer para verificar que el router recibe tráfico interesante y que tiene el dialer map or dialer string adecuado para iniciar el marcado. Consulte el documento anterior y también, la Tecnología de marcado: Técnicas de resolución de problemas para obtener más información.

  Consulte el siguiente ejemplo de configuración para ver ejemplos de configuraciones DDR adecuadas:

  Perfiles del marcador: Configuración de ISDN DDR con perfiles del marcador heredados del DDR (correspondencias del marcador): Configuración del marcado manual BRI a BRI con correspondencias de marcador de DDR

  Sugerencia: Para realizar pruebas, puede eliminar DDR mediante el comando isdn call (explicado en la siguiente sección) para generar una llamada ISDN al dispositivo remoto. Si esa llamada tiene éxito, entonces puede estar razonablemente seguro de que el circuito ISDN está funcionando. Continúe solucionando los problemas de DDR.

• Realice una llamada de prueba de loopback

  En una llamada de loop retorno, el router marca el número de ISDN de su propio BRI. La llamada prosigue hacia la nube de la compañía telefónica en donde la llamada se conmuta hasta el segundo canal BRI. Esta llamada ahora es detectada por el router como una llamada entrante en el segundo canal. Por lo tanto, el router envía y recibe la llamada ISDN.

  Una llamada de loopback comprueba la capacidad del router para iniciar y finalizar una llamada ISDN. Una llamada de loopback exitosa le da un indicio sólido de que el circuito ISDN a la nube de la compañía telefónica está funcionando correctamente.

  El siguiente es un ejemplo comentado de una llamada de loopback exitosa. El comando isdn call (introducido en Cisco IOS® Software 12.0(3)T) habilita las llamadas isdn salientes sin necesidad de requisitos DDR como tráfico interesante y rutas. Este comando puede usarse sólo para probar el circuito ISDN y no para pasar tráfico ni como reemplazo de una configuración adecuada de DDR. Este comando nos permite verificar que el circuito ISDN, especialmente el de Capa 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 la llamada de loopback, el router funciona tanto como Router llamado como Router que llama (aunque en canales B diferentes). Es importante realizar un seguimiento de estos “roles dobles” al interpretar el resultado debug isdn q931. Por ejemplo, el router transmite un mensaje de inicio (TX -> SETUP) y a la vez recibe uno (RX <- SETUP). El mensaje SETUP transmitido debe estar asociado con la llamada saliente mientras que el mensaje SETUP recibido se asocia con la llamada entrante.

• En el ejemplo anterior, marcamos el número para el primer canal B. Sin embargo, la compañía telefónica se dio cuenta de que el primer canal B estaba ocupado (ya que estaba realizando la llamada) y conmutó la llamada al segundo canal B y la conexión se completó exitosamente. Sin embargo, una configuración incorrecta en el switch de la compañía telefónica puede dar lugar a una falla de la llamada de loopback, debido al switch que intenta asignar la llamada al primer canal (que está ocupado haciendo la llamada). La compañía telefónica debería corregir este problema. Sin embargo, como solución temporal, especifique el segundo número de canal B en el comando isdn call.

• Si la llamada de loopback es exitosa y la llamada al extremo remoto continúa fallando, comuníquese con la compañía telefónica para obtener asistencia adicional para la resolución de problemas para su circuito BRI.

El router llamado no recibe un mensaje de CONFIGURAR

Si determina que el Router llamador envía un mensaje de CONFIGURACIÓN de Capa 3 de ISDN, pero el Router llamado no lo recibe, entonces el problema podría estar en las capas 1 y 2 de la ISDN del Router llamado o podría tratarse de un problema con la nube ISDN de la compañía telefónica.

Realice las siguientes tareas en el router llamado:

• ‘Verifique que la configuración del tipo de switch para ISDN sea correcta.’

  Es posible verificar el tipo del switch de ISDN con el comando show isdn status. La compañía telefónica debería indicar explícitamente el tipo de switch que debe configurarse. Ocasionalmente, especialmente en América del Norte, la compañía telefónica puede indicar si el tipo de switch es "personalizado" o "nacional". En tales casos, utilice las siguientes pautas para determinar la configuración del tipo de switch:

  • Local': Si la compañía telefónica indica que su tipo de switch es personalizado, configure el tipo de switch en el router como basic-5ess (para BRI con switches 5ess), primary-5ess (para PRI con 5ess), basic-dms (para BRI con DMS switch) o primary-dms (para PRI con DMS).

  • Nacional El tipo de switch cumple con los estándares NI-1 para BRI y NI-2 para PRI (no hay estándar NI-1 para PRI). Si la compañía telefónica le informa que el tipo de switch es National, entonces la configuración del router Cisco debe ser basic-ni (para BRI) o primary-ni (para PRI).

  Para configurar el tipo de switch, utilice el comando isdn switch-type tipo de switch en el modo de configuración de interfaz BRI. Para ver un ejemplo, consulte la sección Resolución de problemas de ISDN BRI Capa 1

• Verificar que las capas ISDN 1 y 2 en el router de llamada estén funcionando:

  Puede verificar que las capas 1 y 2 de ISDN estén en funcionamiento utilizando el comando show isdn status. Utilice el procedimiento descrito en la utilización del comando show isdn status para la solución de problemas de BRI, para resolver los problemas relacionados con la capa 1 y 2 de ISDN.

• Verifique que el número de directorio local (LDN) SPID está configurado correctamente

  Ciertos tipos de switch requieren que el spid y el ldn estén configurados correctamente para aceptar las llamadas entrantes. Refiérase a Troubleshooting de los SPIDs BRI ISDN para obtener más información.

Realice las siguientes tareas en el router llamador:

• Utilice un teléfono analógico regular para realizar una llamada de prueba al router remoto.

  Con un teléfono analógico común, marque el número ISDN del router llamado exactamente como está configurado en el router llamador. El Router llamado debe recibir un mensaje SETUP (aunque la llamada fallará debido a que no es una llamada ISDN). Si el router llamado recibe el mensaje SETUP, podemos asumir que la red ISDN de la parte llamada está funcionando. El problema podría estar en la red ISDN del lado local, en el número ISDN de destino, en el servicio de larga distancia y así sucesivamente. Proceda a realizar los pasos siguientes.

• Asegúrese de que el número de destino de ISDN esté configurado correctamente.

  Verifique la configuración del Router que realiza la llamada y compruebe que el número ISDN configurado para el router remoto sea correcto. Muy a menudo, los circuitos ISDN que hay detrás de un PBX requieren un 9 delante del número ISDN. También, si la llamada es de larga distancia (en EE.UU.), debería incluir el dígito 1 antes del número ISDN del sitio remoto (similar a la marcación de larga distancia de un teléfono normal). Por ejemplo, consideremos una situación en la que el sitio local está por detrás de un PBX y la llamada a un sitio remoto tiene que ser de larga distancia. El número ISDN del extremo remoto es 5551111 dentro del código de área 512. En este caso, incluyendo los dígitos apropiados para el PBX y la larga distancia, el número marcado es 915125551111.

  El motivo de desconexión debug isdn q931 se puede utilizar también para determinar si la falla de llamada se debe a un número ISDN remoto incorrecto o a un número con formato inadecuado. Refiérase al documento Comprensión de los Códigos de Causa de Desconexión debug isdn q931 para obtener más información sobre la interpretación de los códigos de causa de desconexión ISDN q931.

  Una desconexión a causa de un número ISDN incorrecto puede ser indicada por medio de:

  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
  

  Con relación al documento de los códigos de la causa de desconexión al que se hizo referencia anteriormente, podemos determinar que el código de desconexión fue provocado por un intento de conexión a un equipo que no era ISDN. (Por ejemplo, una línea analógica.)

  Una desconexión a causa de un número con formato incorrecto puede ser indicada por medio de:

  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)
  

  Refiriéndonos al documento Comprensión de los Códigos de Causa de Desconexión debug isdn q931 podemos determinar que el código de desconexión fue causado por un formato no válido para el número ISDN remoto. La conexión falla debido a que la dirección de destino se presenta (hacia el switch) en un formato irreconocible o la dirección de destino está incompleta.

• Si corresponde, determine si el servicio de larga distancia está activo:

  Debe ponerse en contacto con su compañía telefónica y proveedor de larga distancia local para verificar que el servicio está activado. Frecuentemente, la compañía telefónica local tiene el circuito ISDN mal configurado de manera tal que las llamadas de larga distancia ISDN salientes no se transfieren a la red correcta del proveedor de larga distancia. También debe verificar que la red del proveedor de larga distancia esté funcionando.

  En EE.UU. y en situaciones en las que el proveedor de larga distancia/telco no es capaz de solucionar el problema, podrá utilizar una Portadora entre centrales de suscripción previa (PIC). Los códigos PIC son prefijos de 7 dígitos que identifican a las portadoras de larga distancia de EE.UU., a diferencia de las portadoras de intercambio local (LEC). Esto permite que los clientes puedan utilizar diferentes portadoras de larga distancia para llamadas separadas. El código PIC está configurado como un prefijo al número marcado. La mayoría de las PIC tienen el formato 1010xxx. Para ver un listado numérico de PICs, refiérase a Códigos PIC en EE.UU., Numéricamente

• Configure dos sentencias de mapa de marcador o de cadena de marcador; una por cada número ISDN del canal B remoto:

  La configuración de un mapa de marcador (o cadena de marcador, si se utilizan perfiles de marcador) para cada canal B remoto permite que la conexión continúe incluso si la compañía telefónica no puede conmutar la segunda llamada al segundo canal B ISDN.

  Nota: Esta solución temporal es necesaria si sólo 1 canal B acepta llamadas en un BRI determinado. Este problema es frecuente con conexiones de links múltiples.

  Se proporciona un ejemplo de configuración (usando mapas de marcador):

  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. 
  
  

El router llamado no envía un mensaje de CONECTAR

Si el Router llamado recibe un mensaje SETUP (Configurar) pero no responde con un mensaje CONNECT (Conectar), esto puede indicar que el router (por alguna razón indeterminada) ha elegido no aceptar la llamada.

Realice las siguientes tareas en el router llamado:

• Compruebe si la llamada es rechazada debido al filtrado basado en ID/DNIS de llamada:

  El filtrado basado en ID o DNIS de llamada permite al router aceptar o negar selectivamente una llamada particular sin incurrir en gastos telefónicos. Con el monitoreo basado en el identificador de llamadas, el router invocado recibe (en el mensaje de configuración) el número de la parte que realiza la llamada. Esto permite que el router acepte llamadas de determinados números; de este modo, brinda cierta seguridad. Con el monitoreo basado en DNIS, el Router al que se llama discrimina las llamadas entrantes según el número marcado.

  Existe un par de puntos principales para recordar con relación a la revisión sobre la base de CLID/DNIS:

  La compañía telefónica debe proveer la información de CLID/DNIS apropiada en el mensaje de CONFIGURACIÓN. Si habilita el filtrado de ID de llamada en el router, pero no tiene dígitos de ID de llamada transmitiéndose al router, todas las llamadas al router se "filtrarán" y no se aceptará ninguna llamada.

  2) Compruebe el formato de los dígitos CLID/DNIS suministrados por la compañía telefónica (en la salida debug isdn q931). Por ejemplo, algunas compañías telefónicas incluyen el código de área en los dígitos CLID/DNIS suministrados, mientras que otras no lo hacen. Corrija toda configuración de CLID/DNIS según sea necesario.

  El siguiente es un ejemplo de una llamada fallida. El router tiene el monitoreo basado en CLID habilitado, sin embargo, debido a que la compañía telefónica no entrega los dígitos CLID el router rechaza la llamada.

  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
  
  

  Si desea más información sobre Id. de la parte llamadora, consulte el documento Autenticación ISDN y devolución de llamada con Id. de la parte llamadora.

• Verifique que los SPID sean correctos:

  Utilice el comando show isdn status para verificar que los SPIDs del router llamado sean correctos. Refiérase a Utilización del Comando show isdn status para el Troubleshooting de BRI para obtener más información sobre el troubleshooting de los problemas relacionados con Spid.

• Asegúrese de que haya canales B disponibles en el circuito que se marcó:

  Utilice el comando show isdn status para verificar si existe algún canal disponible en el circuito que fue marcado. Si no hay canales disponibles, utilice el comando clear para liberar algunos canales.

• Si existen varias BRI disponibles, la compañía telefónica debe configurarlas en un grupo de búsqueda:

  Tener BRI múltiples en un grupo de búsqueda permite que la compañía telefónica conmute la llamada a cualquier circuito BRI de ese router. Contáctese con la compañía telefónica por esta función.

• Verifique si está encontrando problemas relacionados con la capacidad de transporte.

  La capacidad portadora (o cap. portadora) es la indicación del servicio de la capa 3 que define las características de una determinada llamada. La compañía telefónica indica la capacidad portadora de una llamada en mensajes de CONFIGURACIÓN Q.931. Generalmente se utiliza el límite Bearer para distinguir entre llamadas de datos de 56k, de voz de 64k (analógica) y llamadas de datos de 64k. Los mensajes de capacidad portadora más habituales y su descripción se proporcionan a continuación:

  Capacidad portadora	Descripción
  0x8890	Llamada ISDN de 64K
  0x8890218F	Llamada ISDN de 56 K
  0x8090A2	Llamada de voz/discurso (u-law)
  0x9090A2	Llamada de voz/discurso (u-law) - audio de 3,1 kHz
  0x8090A3	Llamada vocal/de voz (ley A)
  0x9090A3	Llamada de voz/discurso (A-law) - audio de 3,1 kHz

  Lo que sigue es un ejemplo de una llamada 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......
  

  Siga los siguientes pasos, según la capacidad portadora de la llamada:

  La capacidad portadora es 0x8890218F: La llamada es digital ISDN de 56 K:

  • ‘Verifique que la configuración del tipo de switch para ISDN sea correcta.’

    Es posible verificar el tipo del switch de ISDN con el comando show isdn status. La compañía telefónica debería indicar explícitamente el tipo de switch que debe configurarse. Ocasionalmente, especialmente en América del Norte, la compañía telefónica puede indicar si el tipo de switch es "personalizado" o "nacional". En tales casos, utilice las siguientes pautas para determinar la configuración del tipo de switch:

    • Local': Si la compañía telefónica indica que su tipo de switch es personalizado, configure el tipo de switch en el router como basic-5ess (para BRI con switches 5ess), primary-5ess (para PRI con 5ess), basic-dms (para BRI con DMS switch) o primary-dms (para PRI con DMS).

    • Nacional El tipo de switch cumple con los estándares NI-1 para BRI y NI-2 para PRI (no hay estándar NI-1 para PRI). Si la compañía telefónica le informa que el tipo de switch es National, entonces la configuración del router Cisco debe ser basic-ni (para BRI) o primary-ni (para PRI).

    Para configurar el tipo de switch, utilice el comando isdn switch-type tipo de switch en el modo de configuración de interfaz BRI. Para ver un ejemplo, consulte la sección Resolución de problemas de ISDN BRI Capa 1

  • En el lado de origen de la llamada, verifique que la velocidad de transferencia de la llamada sea de 56k. Esto es necesario porque es probable que algunos switches ISDN heredados no estén transmitiendo un canal despejado y lo obliguen a realizar su llamada a 56K para comunicarse.

    Utilice el parámetro de velocidad en el comando dialer map configuration para efectuar llamadas salientes a 56 kbps tal como se muestra en el siguiente ejemplo:

    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
    
    

    El siguiente ejemplo muestra cómo configurar un perfil del marcador del IOS de Cisco para realizar llamadas salientes 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)
    
    

  • En el lado de recepción, configure el comando isdn not-end-to-end 56 bajo la interfaz BRI.

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

    Se utiliza la capacidad de portador de ISDN Q.931 y otro elemento de información (IE) para determinar la velocidad de la llamada entrante y, en la mayoría de las circunstancias, funcionará correctamente. Sin embargo, en algunas aplicaciones de un país a otro (o a causa de algunos switches heredados), el mensaje de configuración de llamada entrante será enviado con una capacidad portadora que no coincide con la llamada de origen. Si se recibe un mensaje que indica isdn "not end-to-end", el router puede invalidar la capacidad portadora recibida usando el comando de configuración de Cisco IOS isdn not end-to-end.

    La capacidad portadora es 0x8090A2 o 0x9090A2: Llamada de voz/discurso (u-law)

    La capacidad portadora es 0x8090A3 o 0x9090A3: Llamada vocal/de voz (ley A)

    La llamada entrante es una llamada analógica de 64 k. En el caso de aplicaciones de módem, la llamada será enviada a los módems internos, mientras que en aplicaciones de voz la llamada puede ser enviada al módulo de voz apropiado. Siga los pasos descriptos a continuación:

    1. En el lado receptor, verifique que la interfaz física de ISDN (por ejemplo, interfaz bri 0) tenga configurado el isdn incoming-voice modem.

    2. Verifique que las líneas del módem tengan el comando modem inout.

    Para obtener un ejemplo de configuración, diríjase al documento Configuración de la conectividad del módem con un Cisco 3640 BRI.

  • Interprete el código de causa de desconexión enviado (del router llamado al router de llamada) en el mensaje DISCONNECT o RELEASE.

    Si el router llamado no envía un mensaje CONNECT al router de llamada, debe devolver un mensaje DISCONNECT o RELEASE. Este mensaje DISCONNECT o RELEASE debe incluir también un código de causa de desconexión. En el siguiente ejemplo, el código de la causa de desconexión es 0x8090. Refiérase al documento Comprensión de los Códigos de Causa de Desconexión debug isdn q931 para interpretar el código de desconexión.

    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
    

El router llamador no recibe un mensaje de CONECTAR

Si el Router llamado envía un mensaje CONNECT (Conectar), pero el mensaje no es recibido por el Router llamador, entonces es muy probable que el problema provenga de la compañía telefónica.

• Compruebe si el router recibe un mensaje CONECTAR_ACK del switch ISDN local:

  Esto indica que el switch de la compañía telefónica cercano al router llamado ha aceptado el mensaje de CONEXIÓN y lo está pasando al router llamado. Una falla de la llamada es probable que sea problema de la compañía telefónica.

• Comuníquese con la compañía telefónica para obtener más información acerca de la solución de problemas.

El router que realiza la llamada recibe un mensaje CONNECT pero aún así la llamada fracasa

Si el router de llamada recibe un mensaje CONNECT, eso indica que la conexión ISDN está activa y funciona correctamente. Contacte a la compañía telefónica para determinar si el problema es que el canal B no está correlacionado de forma correcta para los datos. Cualquier falla de la llamada, pasada esta etapa, es debida a un problema de capa superior, por ejemplo, de negociación PPP, de autenticación o de dirección IPCP/IP. Utilice debug ppp negotiation para el troubleshooting de PPP adicional.

También debe consultar el documento Tecnología de Marcación Manual: Técnicas de Troubleshooting para ver más técnicas de troubleshooting de PPP.

Información Relacionada

• Página de soporte de la tecnología de acceso
• Soporte Técnico - Cisco Systems

Historial de revisiones