CUCM Hunt Pilot Initial Announcement Not Heard by External Callers

Introduction

This document describes how to identify the faulty part when external callers do not hear the initial announcement (when they call a hunt pilot with call queueing enabled available) from Cisco Unified Communications Manager Release 9.0(1).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Call Queuing feature
• Media Resources

Components Used

This document is not restricted to specific hardware versions. For software it is applicable to Cisco Unified Communications Manager Release 9.0(1) and higher.

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

Refer to Cisco Technical Tips Conventions for information on document conventions.

Background Information

Cisco Unified Communications Manager Release 9.0(1) provides call queuing to users so that callers can be held in a queue until hunt members are available to answer the calls. Callers in a queue receive an initial greeting announcement, followed by music or a tone on hold.

Problem

When a call is placed to the hunt pilot, and the initial announcement is not heard by external callers (but it is heard when calling the hunt pilot is called from an internal IP phone), this is typically caused by the service provider not cutting through the media before the call is connected.

Solution

In order to confirm the issue, you need to verify:

1. Send progress indicator = 8 to the provider.
2. The initial announcement is being streamed. Take a Pulse Code Modulation (PCM) capture.

In order to verify the progress indicator = 8 to the provider, enabe the isdn q931 debug on the gateway. When you have a busy system, follow the best practices to collect the debugs as described in this document: How to properly and safely collect debugs on an IOS router .

You should see the progress indicator as follows:

*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

In the example above, you see the initial announcement is being played for approximately five seconds. Next, the call rings on the agent phone (ALERTING) and finally you see the CONNECT message when the agent answers the call.

In order to verify that you are streaming the announcement, you must take a PCM capture, documented in: Cisco IOS, Phone, UCM and CUC Packet, and PCM Captures Command Reference. Consider the use of a longer announcement if you face challenges to collect the pcm capture in time.

If both have been verified successfully, the issue is caused by the service provider and not by cutting through the media before the call is connected. This problem must be fixed by the service provider. If either of the above items are missing, the situation must be investigated more in depth on the Cisco Unified Communications Manager or the gateway side.

Related Caveats :

Cisco bug ID CSCuh15872 CUCM9 Native Call Queuing should connect call on announcment

Cisco bug ID CSCug87543 CUCM Native Call Queuing Does Not Work if Ingress is H323 Fast Start

Related Information

• Call Queuing
• Cisco IOS, Phone, UCM and CUC Packet, and PCM Captures Command Reference
• How to properly and safely collect debugs on an IOS router
• Technical Support & Documentation - Cisco Systems

Revision History