Anuncio inicial de CUCM Hunt Pilot que no oyeron las personas que llaman externas

Introducción

Este documento describe cómo identificar la pieza defectuosa cuando los llamantes externos no escuchan el anuncio inicial (cuando llaman a un piloto de búsqueda con cola de llamadas habilitada) de Cisco Unified Communications Manager versión 9.0(1).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Función de Call Queue Server
• Recursos de medios

Componentes Utilizados

Este documento no se limita a versiones de hardware específicas. Para el software, es aplicable a Cisco Unified Communications Manager versión 9.0(1) y posteriores.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Convenciones

Consulte Convenciones de Consejos Técnicos de Cisco para obtener información sobre las convenciones sobre documentos.

Antecedentes

Cisco Unified Communications Manager versión 9.0(1) proporciona cola de llamadas a los usuarios para que las personas que llaman puedan permanecer en cola hasta que los miembros del grupo de salto estén disponibles para contestar las llamadas. Las personas que llaman en una cola reciben un anuncio de saludo inicial, seguido de música o un tono en espera.

Problema

Cuando se realiza una llamada al piloto de búsqueda y las personas que llaman externas no oyen el anuncio inicial (pero se escucha cuando se llama al piloto de búsqueda desde un teléfono IP interno), esto suele deberse a que el proveedor de servicios no corta los medios antes de que se conecte la llamada.

Solución

Para confirmar el problema, debe verificar:

1. Enviar indicador de progreso = 8 al proveedor.
2. El anuncio inicial está siendo transmitido. Tome una captura de modulación de código de pulso (PCM).

Para verificar el indicador de progreso = 8 al proveedor, habilite el debug isdn q931 en el gateway. Cuando tenga un sistema ocupado, siga las prácticas recomendadas para recopilar las depuraciones tal y como se describe en este documento: Cómo recolectar debugs de manera adecuada y segura en un router IOS .

Debería ver el indicador de progreso de la siguiente manera:

*May 18 08:25:22.169: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8  callref = 0x00BF
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Progress Ind i = 0x8183 - Origination address is non-ISDN
        Calling Party Number i = 0x0180, '6611112'
                Plan:ISDN, Type:Unknown
        Called Party Number i = 0x81, '2000'
                Plan:ISDN, Type:Unknown
*May 18 08:25:22.197: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x80BF
        Channel ID i = 0xA98381
                Exclusive, Channel 1
*May 18 08:25:22.197: ISDN Se0/1/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0x80BF
        Progress Ind i = 0x8188 - In-band info or appropriate now available

## Initial announcement being played ##

*May 18 08:25:27.941: ISDN Se0/1/0:15 Q931: TX -> ALERTING pd = 8  callref = 0x80BF
        Progress Ind i = 0x8088 - In-band info or appropriate now available

## The call is ringing at agent phone ##

*May 18 08:25:30.309: ISDN Se0/1/0:15 Q931: TX -> CONNECT pd = 8  callref = 0x80BF

## The call is connected with the agent ##

*May 18 08:25:30.313: ISDN Se0/1/0:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x00BF

## Call is ended by calling party ##

*May 18 08:25:34.101: ISDN Se0/1/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x00BF
        Cause i = 0x8290 - Normal call clearing
*May 18 08:25:34.289: ISDN Se0/1/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x80BF
*May 18 08:25:34.293: ISDN Se0/1/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x00BF

En el ejemplo anterior, verá que el anuncio inicial se está reproduciendo durante aproximadamente cinco segundos. A continuación, la llamada suena en el teléfono del agente (ALERTA) y, por último, verá el mensaje CONNECT cuando el agente conteste la llamada.

Para verificar que está transmitiendo el anuncio, debe tomar una captura PCM, documentada en: Cisco IOS, Phone, UCM y CUC Packet, y PCM Captures Referencia de Comandos. Considere el uso de un anuncio más largo si se enfrenta a retos para recopilar la captura de pcm en el tiempo.

Si ambos se han verificado correctamente, el problema es causado por el proveedor de servicios y no por el corte de los medios antes de que se conecte la llamada. El proveedor de servicios debe solucionar este problema. Si falta alguno de los elementos anteriores, la situación debe investigarse más a fondo en Cisco Unified Communications Manager o en el lado de la puerta de enlace.

Advertencias relacionadas:

El Id. de error de Cisco CSCuh15872 CUCM9 Native Call Queue debe conectar la llamada en el anuncio

El Id. de bug Cisco CSCug87543 CUCM Native Call Queue no funciona si el Ingreso es H323 Fast Start

Información Relacionada

• Envío a cola de llamada
• Referencia de Comandos de Cisco IOS, Phone, UCM y CUC Packet y PCM Capturas
• Cómo recopilar de forma correcta y segura las depuraciones en un router IOS
• Soporte Técnico y Documentación - Cisco Systems