Document ID: 116230
Updated: Jun 24, 2013
Contributed by Kristof Van Coillie, Cisco TAC Engineer.
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).
Cisco recommends that you have knowledge of these topics:
- Call Queuing feature
- Media Resources
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.
Refer to Cisco Technical Tips Conventions for information on document conventions.
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.
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.
In order to confirm the issue, you need to verify:
- Send progress indicator = 8 to the provider.
- 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
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.