Source: http://www.cisco.com/cisco/web/support/LA/102/1024/1024241_isdn_q931_ts.html
Timestamp: 2016-10-28 02:55:48+00:00

Document:
Resolución de problemas de la Capa 3 de ISDN BRI mediante el comando debug isdn q931 - Cisco Systems Inicio
Contenido Introducción prerrequisitos Requisitos Componentes Utilizados Convenciones Requisitos previos de la solución de problemas: Activación de depuración de la capa 3 de ISDN Inicie la llamada ISDN Descripción general de la resolución de problemas: Síntomas y procedimiento de solución Resolución de problemas: Síntomas y procedimiento detallado para la resolución El router llamador no envía un mensaje de CONFIGURAR El router llamado no recibe un mensaje de CONFIGURAR El router llamado no envía un mensaje de CONECTAR El router llamador no recibe un mensaje de CONECTAR El router que realiza la llamada recibe un mensaje CONNECT pero aún así la llamada fracasa Discusiones relacionadas de la comunidad de soporte de Cisco
Información Relacionada 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. prerrequisitos Requisitos 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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). 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 indicaciones de fecha y hora en milisegundos para las depuraciones utilizando los siguientes comandos: maui-soho-01(config)#service timestamps debug 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 resultado de depuración se han seccionado en líneas múltiples por motivos de impresión. Router que realiza la llamada Router llamado maui-soho-01#
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. Los debugs 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 &lt;-  CONNECT pd = 8  callref = 0x90
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. Mensaje Descripción CONFIGURACIÓN Configuración -- Indica que un dispositivo desea establecer una llamada de Capa 3. CALL_PROC Llamada en ejecución -- La configuración de la llamada ha sido recibida y está siendo procesada por la red y/o el dispositivo remoto EL ALERTAR El alertar -- Informa a la red que el router final ahora "está alertando" al usuario; éste sería normalmente el caso para un teléfono y la alerta sería el "timbre" en el auricular. Este mensaje se asocia normalmente a equipos con auricular, como un teléfono ISDN o TA, y usualmente no aparece para llamadas de datos. CONNECT(conectar) Conecte -- Se acepta la llamada CONNECT_ACK Reconocimiento de conexión -- El dispositivo ha recibido el mensaje CONNECT. Los protocolos de capa más alta (p.ej., PPP) debería comenzar ahora la negociación DESCONECTAR Desconecte -- Mensaje de desconexión iniciado por el router. Por lo general, este mensaje indica que el circuito ISDN funciona y que la desconexión respondió a algún problema con las capas superiores (DDR, PPP y así sucesivamente). El saludo de desconexión de tres vías irá acompañado por los mensajes RELEASE y RELEASE_COMP. El mensaje DISCONNECT también va acompañado por un código de causa de desconexión. Este código de desconexión puede también ser utilizado para identificar dónde fue desconectada la llamada (por ejemplo, la llamada fue desconectada del router, del switch de la compañía telefónica local, del switch de telecomunicación remoto, etc.). Para obtener más detalles, refiérase a Cómo Comprender los Códigos de Causa de Desconexión debug isdn q931 VERSIÓN Versión -- Reconoce la desconexión y continúa la desconexión del circuito. El mensaje RELEASE se encuentra entre los mensajes DISCONNECT y RELEASE_COMP. Es posible que el mensaje RELEASE vaya acompañado por un código de causa de desconexión. Este código de desconexión puede también ser utilizado identificar dónde fue desconectada la llamada (por ejemplo, la llamada fue desconectada del router, switch telco local, switch telco remoto). Para obtener más detalles, refiérase a Cómo Comprender los Códigos de Causa de Desconexión debug isdn q931 RELEASE_COMP Versión completa -- La desactivación de llamadas está completa. Este mensaje suele aparecer: a) Durante una terminación de la llamada normal iniciada por una del Routers b) en respuesta a un mensaje setup del router de llamada. Esto se debe generalmente a una discordancia en la capacidad portadora entre el switch y el router. UN RELEASE_COMP puede también ser debido a los errores del protocolo si la codificación del mensaje setup no cumple con el q.931 estándar o la configuración del Switch el mensaje del RELEASE_COMP se puede acompañar por un código de la causa de desconexión. Este código de desconexión puede también ser utilizado identificar dónde fue desconectada la llamada (por ejemplo, la llamada fue desconectada del router, switch telco local, switch telco remoto). Para obtener más detalles, refiérase a Cómo Comprender los Códigos de Causa de Desconexión debug isdn q931 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 de llamada, 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 debe indicar explícitamente el switchtype que necesita ser configurada. 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 de encargo, después configure el switchtype en el router como el 5ess básico (para el BRI con el 5ess Switch), el 5ess primario (para el PRI con 5ess), el básico-DMS (para el BRI con el Switch DMS), o primario-DMS (para el PRI con el 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
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
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 Consejo: Para realizar pruebas, puede eliminar el DDR usando el comando isdn call (que se explica 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 (presentado en el software 12.0(3)T del ½ del ¿Â de Cisco IOSÃ¯Â) habilita las llamadas salientes isdn sin requerir los requisitos DDR tales 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
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 debe indicar explícitamente el switchtype que necesita ser configurada. 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 de encargo, después configure el switchtype en el router como el 5ess básico (para el BRI con el 5ess Switch), el 5ess primario (para el PRI con 5ess), el básico-DMS (para el BRI con el Switch DMS), o primario-DMS (para el PRI con el 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 &lt;-  DISCONNECT pd = 8  callref = 0x85
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 &lt;-  RELEASE_COMP pd = 8  callref = 0x86
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. A menudo, la compañía telefónica local tiene el circuito ISDN configuró mal tales que las llamadas de salida de larga distancia isdn no están conmutadas encima a la red de proveedor de larga distancia apropiada. 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: Se requiere esta solución temporal si solamente 1 canal B acepta llamadas en un BRI dado. 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
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: 1) La compañía telefónica debe proporcionar la información apropiada CLID/DNIS en el mensaje setup. 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) Marque el formato de los dígitos CLID/DNIS entregados por la compañía telefónica (en el debug ISDN q931 haga salir). 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#
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 &lt;-  SETUP pd = 8  callref = 0x6F
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 debe indicar explícitamente el switchtype que necesita ser configurada. 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 de encargo, después configure el switchtype en el router como el 5ess básico (para el BRI con el 5ess Switch), el 5ess primario (para el PRI con 5ess), el básico-DMS (para el BRI con el Switch DMS), o primario-DMS (para el PRI con el 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
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
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
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: En el lado receptor, verifique que la interfaz física de ISDN (por ejemplo, interfaz bri 0) tenga configurado el isdn incoming-voice modem. 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 -&gt;  DISCONNECT pd = 8
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 Notas Técnicas de Troubleshooting Document ID: 9495

References: resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 Resolución 
 Resolución