Annonce initiale du pilote de recherche CUCM non entendue par des appelants externes

Introduction

Ce document décrit comment identifier la partie défectueuse lorsque les appelants externes n'entendent pas l'annonce initiale (lorsqu'ils appellent un pilote de recherche avec mise en file d'attente des appels activée disponible) à partir de Cisco Unified Communications Manager version 9.0(1).

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Fonction de mise en file d'attente des appels
• Ressources multimédia

Components Used

Ce document n'est pas limité à des versions matérielles spécifiques. Pour les logiciels, il s'applique à Cisco Unified Communications Manager version 9.0(1) et ultérieure.

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.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

Cisco Unified Communications Manager version 9.0(1) fournit la mise en file d'attente des appels aux utilisateurs afin que les appelants puissent être mis en file d'attente jusqu'à ce que les membres de recherche soient disponibles pour répondre aux appels. Les appelants d'une file d'attente reçoivent une annonce de message d'accueil initiale, suivie d'une musique ou d'une tonalité d'attente.

Problème

Lorsqu'un appel est passé au pilote de recherche et que l'annonce initiale n'est pas entendue par des appelants externes (mais elle est entendue lors de l'appel du pilote de recherche est appelé à partir d'un téléphone IP interne), cela est généralement dû au fait que le fournisseur de services ne coupe pas le support avant que l'appel ne soit connecté.

Solution

Pour confirmer le problème, vous devez vérifier :

1. Envoyer l'indicateur de progression = 8 au fournisseur.
2. L'annonce initiale est diffusée en continu. Prenez une capture PCM (Pulse Code Modulation).

Afin de vérifier l'indicateur de progression = 8 au fournisseur, activez le débogage isdn q931 sur la passerelle. Lorsque vous avez un système occupé, suivez les meilleures pratiques pour collecter les débogages comme décrit dans ce document : Comment collecter correctement et en toute sécurité les débogages sur un routeur IOS .

L'indicateur de progression doit s'afficher comme suit :

*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

Dans l'exemple ci-dessus, vous voyez que l'annonce initiale est diffusée pendant environ cinq secondes. Ensuite, l'appel sonne sur le téléphone de l'agent (ALERTE) et, enfin, vous voyez le message CONNECT lorsque l'agent répond à l'appel.

Afin de vérifier que vous diffusez l'annonce en continu, vous devez prendre une capture PCM, documentée dans : Guide de référence des commandes de Cisco IOS, Phone, UCM et CUC Packet, et PCM Captures. Considérez l'utilisation d'une annonce plus longue si vous rencontrez des difficultés pour collecter la capture pcm à temps.

Si les deux ont été vérifiées avec succès, le problème est causé par le fournisseur de services et non par une coupure du support avant la connexion de l'appel. Ce problème doit être résolu par le fournisseur de services. Si l'un ou l'autre des éléments ci-dessus est manquant, la situation doit être examinée plus en profondeur du côté de Cisco Unified Communications Manager ou de la passerelle.

Cavaliers associés :

ID de bogue Cisco CSCuh15872 CUCM9 Mise en file d'attente d'appels natifs devrait connecter l'appel à l'annonce

ID de bogue Cisco CSCug87543 La mise en file d'attente des appels natifs CUCM ne fonctionne pas si l'entrée est H323 Fast Start

Informations connexes

• Mise en file d'attente des appels
• Guide de référence des commandes de Cisco IOS, Phone, UCM et CUC Packet, et PCM Captures
• Comment collecter correctement et en toute sécurité les débogages sur un routeur IOS
• Support et documentation techniques - Cisco Systems