Voz : CCS Digital

Resolución de problemas para mensajes de no hay tono de ocupado y no hay mensajes de anuncio en llamadas ISDN-VoIP (H.323)

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

En este documento se abordan los problemas relacionados con el progreso de llamadas dentro de banda durante la interconexión de ISDN y la señalización H.323 entre VoIP y una Red de Telefonía Pública Conmutada (PSTN). Cuando routers/gateways VoIP de Cisco intercambian capacidades de señalización con el switch de la compañía telefónica, aparecen desafíos. Esta lista describe escenarios/síntomas comunes del problema:

  • Ningunos dígitos DTMF o audio pasajeros en las llamadas VoIP al PSTN/PBX — usuario de teléfono IP hace una llamada, puede oír los mensajes de anuncio, por ejemplo “ingresan su número de cuenta…”, pero no pueden pasar los dígitos del Multifrecuencia de tono dual (DTMF). Este síntoma solicita las llamadas de elusión de cargos de larga distancia y el Cisco IP Phone VoIP a las llamadas PSTN/PBX.

  • Ningún tono de ocupado o mensaje de anuncio recibido al poner las llamadas de salida VoIP — un teléfono del Cisco IP Phone (escenario de CallManager) o del Servicio telefónico sencillo antiguo (POTS) (escenario de desvío-cargo de VoIP) no oye un tono de ocupado o un mensaje de anuncio de la red PSTN. Este síntoma solicita las llamadas de elusión de cargos de larga distancia y el teléfono del IP VoIP a las llamadas PSTN/PBX.

Refiera al Sin tono de recepción del troubleshooting en las llamadas ISDN-VoIP (H.323) para más información sobre el ISDN - los problema relacionado dentro de la banda de progreso de la llamada VoIP (H.323).

Cisco recomienda leer la sección de Información de Referencia antes de leer la sección Soluciones.

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.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Antecedentes

Interconexión ISDN-VoIP

El interfuncionamiento se define como la correspondencia de mensajes de señalización de llamadas entre dos conjuntos de protocolos diferentes. En el contexto de este documento, el foco está en los problemas de interconexión ISDN y de H.323 (VoIP). Este diagrama visualiza los mensajes de señalización de llamada en el tramo de llamada ISDN (Q.931) y VoIP (H.225).

Nota: H.225 es un protocolo especificado por H.323 para la señalización de llamada y la configuración de la llamada. H.225 especifica el uso y la compatibilidad de Q.931. Refiérase al Tutorial de H.323 para obtener más información sobre H.323.leavingcisco.com

/image/gif/paws/14066/isdnsetup.gif

Tonos de progreso e indicadores de progreso

Los tonos de progreso en banda (por ejemplo, tonos de recepción de llamada y de ocupado) y los anuncios (por ejemplo, los que indican que el número marcado ya no se encuentra en servicio) son obligatorios para la correcta señalización de llamadas de voz. Los tonos de progreso se pueden generar por originar, terminar o los dispositivos intermedios.

La indicación de tonos en banda y anuncios es controlada por el elemento de información (IE) del indicador de progreso (PI) en las redes ISDN y H.323. El PI señala esas situaciones de interconexión en donde los tonos y los avisos de la en-banda deben ser utilizados. En el contexto de este documento, éstos son los valores del q.931 PI ITU del interés:

  • PI = 1 — La llamada no es extremo-extremo ISDN. La información del progreso de la llamada adicional pudo ser en-banda disponible.

  • PI = 2 — La dirección destino es no ISDN.

  • PI=3 — La dirección de origen es no ISDN.

  • PI=8 — Información dentro de la banda o un modelo apropiado está disponible ahora.

La indicación que entona y los avisos están disponibles son señalados por alertar, procedimiento de la llamada, progreso, conecta, puso el Ack o desconecta el mensaje que contiene PI = 1 o 8.

Cuando un mensaje setup llega al gateway de origen con un PI=3, significa que el Switch informa al gateway que los mensajes de la en-banda están esperados.

Nota: Una falta de un PI en un mensaje asume que el dispositivo de origen proporciona la señal apropiada del tono a la parte llamadora.

Nota: Los circuitos PSTN analógicos y digitales con Señalización asociada al canal (CAS) generalmente transportan la información como información dentro de banda.

Atajo de ruta de voz

El atajo del trayecto de voz es la finalización del trayecto de transmisión del portador de una llamada de voz. En una llamada de voz, el atajo se produce en dos etapas:

  • Atajo en la dirección descendente significa que sólo el trayecto de voz de la parte llamada a la parte llamadora está completo.

  • El atajo en ambas direcciones significa que el trayecto de la voz entre la parte que recibe la llamada y la parte que realiza la llamada, está completo.

Los tonos y los avisos se pueden generar en el switch de origen o el switch de destino. Si el switch de destino genera los tonos y los anuncios, el trayecto de transmisión de voz (descendente) desde el switch de destino hacia la parte que llama debe convertirse en un atajo antes de que se generen los tonos y los anuncios. Temprano corte-por del trayecto del portador posterior (antes del mensaje CONNECT) es necesario transportar los tonos y los avisos de la en-banda de la Parte llamada a la parte llamadora y evitar el recorte de voz.

La llamada que termina el router/gateway de Cisco corta a través el trayecto de audio en la dirección inversa para transmitir información dentro de la banda cuando el switch ISDN terminal envía estos mensajes:

  • Mensaje de alerta con PI = 1 o PI = 8

  • Mensaje de progreso con PI = 1 ó PI = 8

  • Mensaje de procedimiento de la llamada con PI = 1 o PI=8

  • Mensaje de Configuración Ack con PI = 1 o PI=8

  • Mensaje de desconexión con PI = 1 o PI = 8

Al terminar las interfaces CAS, el router/el gateway Cisco corta el audio en dirección descendente una vez enviados todos los dígitos de los números marcados.

El router/gateway Cisco de terminación corta la trayectoria de audio en ambos sentidos en los siguientes casos:

  • El mensaje de conexión se recibe en una interfaz ISDN.

  • La supervisión de las respuestas (descolgada) se recibe en una interfaz CAS.

Corte-por en las ambas direcciones se puede fijar en los gatewayes con el uso del comando de configuración global del Cisco IOS, el enviar-recv del rtp de la Voz.

Soluciones

En los Software Release 12.1(3)XI1 y 12.1(5)T del ½ del ¿Â de Cisco IOSïÂ, el Progress Indication se cambia para proporcionar mejor intertrabajar entre los CRISOLES y las interfaces de VoIP. Esto se alcanza principalmente a través del fin-fin habilitado y de la propagación del valor PI que define la generación del tono del Progress Indication.

El uso de estos comandos asume que usted ejecuta por lo menos el Cisco IOS Software Releases 12.1(3a)XI5 o 12.2(1)or más adelante.

Refiérase a Mejoras de Señalización de Interconexión para H.323 y VoIP y Referencia de Comandos de Voz, Vídeo y Fax de Cisco IOS para obtener más información.

No hay dígitos DTMF o audio en las llamadas VoIP a PSTN/PBX’

Síntoma

El usuario hace una llamada, oye los mensajes de anuncio, por ejemplo “ingresa su número de cuenta…”, pero no puede pasar los dígitos DTMF. Este síntoma solicita las llamadas del Toll Bypass y de teléfono del IP VoIP a las llamadas PSTN/PBX.

Descripción de problemas

Un Cisco IP Phone (escenario de CallManager) o los CRISOLES llama por teléfono a las hojas de la llamada (del escenario de desvío-cargo de VoIP) con un Cisco IOS Gateway, donde número al que se llamó está generalmente un sistema de la respuesta de voz interactiva (IVR) que devuelve un mensaje de progreso ISDN, pero no conecta hasta que se ingrese una cierta información de la cuenta. Por abandono, el trayecto de audio está corte-por en la dirección inversa (hacia el teléfono del IP o el gateway de origen), pero no en la dirección delantera, hasta que el gateway de terminación reciba un mensaje CONNECT. Por lo tanto, no hay trayecto de la voz para transmitir los tonos o el discurso DTMF hacia el switch de terminación.

Solución

Configure el comando de configuración global del Cisco IOS, enviar-recv del rtp de la Voz, para establecer (corte-por) el trayecto de audio en las ambas direcciones antes de recibir un mensaje CONNECT ISDN del PSTN. Refiérase a Referencia de Comandos de Fax, Video y Voz de Cisco IOS, Versión 12.2 para obtener más información sobre este comando.

No se recibe tono de ocupado o mensaje de anuncio al colocar llamadas salientes de VoIP

Síntoma

Un Cisco IP phone (escenario del CallManager) o POTS phone (escenario de elusión de cargos por larga distancia del VoIP ) no recepta un tono de ocupado o el mensaje de anuncio desde la red PSTN.

Solución

Configure el comando global configuration del Cisco IOS Software, llamada de voz convertido-discpi-a-prog. Esto se utiliza con el Cisco IOS Software Release 12.2(1) y Posterior. Este comando convierte un mensaje de desconexión ISDN entrante con un PI en un mensaje de progreso H.255 con el mismo valor PI. Este comando puede ayudar cuando un aviso se juega en el lado terminal PSTN, pero la parte llamadora no oye la respuesta.

En el escenario de desvío-cargo de VoIP, la mayor parte de estos problemas se resuelven con una actualización del router/de los gatewayes a una versión de Cisco IOS Software de 12.1(3a)XI5 o 12.2(1) y posterior. Sin embargo, si el dispositivo de origen o el switch ISDN el originar no guarda el active de la llamada cuando se recibe un mensaje de la desconexión H.225/ISDN, después publicar el comando voice call convert-discpi-to-prog.

Esto puede subir cuando la en-banda del aviso es un tono de ocupado, también. Más allá de ello, la señal de ocupado debería ser provista por el dispositivo final o el dispositivo de origen, o la red. Algunos aspectos de esto pueden ser controlados.

No hay tono de ocupado en la llamada entrante desde Telephony (ISDN) al teléfono IP Cisco CallManager, al gateway IOS o a un dispositivo H323 de terceros.

Síntoma

Una llamada del PSTN a través del gateway a un teléfono del IP del Cisco CallManager, al Cisco IOS Gateway, o al dispositivo de H.323 del otro vendedor no pudo oír un tono de ocupado cuando ejecuta una aplicación o el discado en dos etapas en el gateway de origen.

Solución

Éste es un caso menos común que puede ocurrir cuando el gateway de origen ejecuta una aplicación de voz tal como placa de débito, o es discado en dos etapas corriente. Este último refiere a la parte llamadora que marca el número al gateway primero, recibe el tono de discado, entonces marca a la Parte llamada. En cualquier caso, la llamada ha conectado en términos de red PSTN una vez que termine en el puerto de enlace de origen. Si tramo de llamada de IP regresa con una versión de la causa user-busy, esto no se puede indicar a la sesión de telefonía que está en estado conectado.

Esto se ha solucionado al hacer que la gateway de origen genere un tono de ocupado cuando se recibe la desconexión del tramo de llamada IP con un código de causa de usuario ocupado. El tramo de telefonía es liberado por la parte llamadora o por el gateway después de varios minutos con el código de la causa de la Verificación normal de llamadas.

Esta característica es disponible desde la versión de Cisco IOS Software 12.2(8)/12.2(8)T y posterior.

Nota: Para iniciar una transferencia de la FULL-consulta de un teléfono del IP que se registre al Cisco CallManager expreso, el teléfono del IP necesita tener más de una línea disponible. Usted necesita configurar y publicar la dual-línea comando del ephone abajo [number]. Esto permite que el teléfono del IP tenga dos líneas o canales asociados al un número de directorio. El comportamiento normal con la dual-línea configurada es que si una llamada es ya activa en el primer canal, y otra llamada se hace a esa extensión, el llamador oye el tono alerta (sonido) en el segundo canal en vez de un tono de ocupado. Si usted quisiera que un tono de ocupado fuera recibido por el llamador cuando una extensión está ocupada en el primer canal, usted necesita configurar y publicar el comando channel del huntstop bajo ephone abajo, tal y como se muestra en de este ejemplo:

CMECUE(config)#ephone-dn 1
CMECUE(config-ephone-dn)#huntstop channel

!--- Stops hunting on the second channel of a dual-line dn.


Información Relacionada


Document ID: 14066