Cisco Unity

Call Holding in Cisco Unity

Document ID: 13919

Updated: Feb 02, 2006



This document describes how call holding and queues work in Cisco Unity, and answers some frequently asked questions. The information in this document is based on all versions of Cisco Unity, and it does not make a difference if it is integrated with Microsoft Exchange or Lotus Notes (Domino) on the back-end.

How Call Holding and Queues Work

Cisco Unity places certain calls on hold, depending on how you have your Subscriber and/or Call Handler set up. For example:

ESubscriber has the extension of 99990. Under the Subscriber configuration in SAWeb, ESubscriber has Call Transfer set to Yes, ring subscriber's extension or Yes, ring subscriber at this number.

A caller dials into the Opening Greeting of Cisco Unity, and wants to be transferred to ESubscriber. They enter the digits 99990#. Cisco Unity then places that call leg on hold and starts to stream the music on hold (MOH) audio file from the switches MOH server (Cisco CallManager or legacy PBX). For Cisco CallManager, this is specified in the device pool that the voicemail ports are a member of. Cisco Unity then initiates a supervised transfer on the same port which the call originally came in on. If that subscriber is on the phone (or busy), you get back a busy status from the switch. At this time, Cisco Unity takes the call off hold and then resumes the call. This cycle repeats until the subscriber is no longer busy and the transfer is successful, or the caller chooses to leave the queue. For subsequent callers in the same queue, they advance in the queue after the caller in front of them disconnects and their MOH audio stream (which is located on the Cisco Unity server) stops playing. See the FAQs in this document on how to tweak these parameters.

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

Q. Can call holding replace an Automatic Call Distribution (ACD)?

A. No. The appropriate Cisco AVVID solution for ACD is Cisco IP Contact Center (IPCC) Express, Cisco Customer Response Solution (CRS), or Cisco Customer Response Applications (CRA). These are more equipped to handle the functionality.

Q. Why do I hear choppy MOH when I am the first person in the queue?

A. If you are able to place a normal phone on hold and are able to hear MOH fine, then the problem is not with the MOH. The choppy MOH is actually due to the design limitations of the TAPI service provider (TSP) Cisco Unity uses to integrate with the switch (Cisco CallManager or the legacy PBX). Silence is heard because after the attempted transfer fails (because the user is busy) the caller sits on the TSP port and waits until the next interval to attempt another transfer to the switch. The MOH audio stops because Cisco Unity needs to resume the call after the attempted transfer fails, and does not stream any audio. The total time for this interaction to take place is approximately five seconds. Therefore, you hear approximately five seconds of MOH, silence for approximately twenty seconds, then approximately five seconds of MOH again, and so forth.

If Cisco Unity is integrated with Cisco CallManager, and the silence is a problem for your environment, you can change the MOH audio file on the Cisco CallManager to say something similar to "Please wait while transferring" and place this on the MOH Server. Then define the audio source on a new device pool which is only used on the voicemail ports. This file needs to be under five seconds since you only hear approximately five seconds of MOH audio before Cisco CallManager responds with a success or busy status on the attempted transfer. This is operating within the design limitations of the TSP, and applies to all versions of Cisco Unity.

Q. Can the length of time between the "press 1 to continue holding" prompts be lengthened?

A. Yes. The length of time between the "press 1 to continue holding" prompts is controlled by the length of the music prompts. There is no prompt editor for Cisco Unity. There are two different situations where the length of time can be modified:

  1. For the first caller in the queue you need to modify this registry entry to extend the time of the prompts. By default, these are set to five each. Therefore, five multiplied by five equals twenty-five seconds to wait for the first caller in the queue before Cisco Unity prompts the caller again if they wish to continue waiting. To increase this value, increase one or both of these values. No services need to be restarted for this to take effect.

    HKEY_LOCAL_MACHINE\SOFTWARE\Active Voice\CallTransfer\1.0\Attempts = 5
    HKEY_LOCAL_MACHINE\SOFTWARE\Active Voice\CallTransfer\1.0\WaitTimeSec = 5 
  2. For the subsequent callers in the queue, you can record your own MOH file and place it in the following location. Cisco Unity streams the MOH files in sequence starting with the file PHHoldMusic000.wav to PHHoldMusic009.wav in the X:\CommServer\Localize\Prompts\ENU\G711\AvPHGreet\ directory, then loops back to the first file. To maintain consistency of the hold music, you can copy the PHHoldMusic000.wav nine times, and rename the copied files to PHHoldMusic001.wav, PHHoldMusic002.wav, and so forth. You cannot delete the extra nine MOH files. This causes the subsequent callers to hear the failsafe message when they press 1 to continue.

    Also be aware that the subsequent callers in the queue do not advance to the next position in the queue until the MOH file has stopped streaming. It is not a good idea to have a three hundred second MOH file. A good hold time is anywhere between sixty to one-hundred twenty seconds. Good practice is to create a MOH file in this range which extends the length of time between the "press 1 to continue holding" prompt to sixty to one-hundred twenty seconds.

Q. Can the "press 1 to continue holding" prompt that is played between the music prompts be removed?

A. No. The Cisco Unity setup does not allow this. Cisco Unity was designed this way because there is not always a good disconnection when a caller hangs up. If the caller was not prompted to "press 1 to continue holding" and eventually hangs up, a port would be stuck in holding.

Q. If the caller does not "press 1 to continue holding," the caller is sent back to the opening greeting. Can the call be sent to a different call handler instead?

A. No. Cisco Unity is hardcoded to pass the call back to the arbiter and reroute it to the entry point (the opening greeting) when the user fails to respond. This cannot be changed, even if an engineer edits the Dynamic Packet Transport (DPT). Instead, the conversation code needs to be changed.

Q. How do I disable the "Wait While I Transfer Your Call" prompt in Cisco Unity?

A. By default, Cisco Unity plays the "Wait While I Transfer Your Call" prompt when it transfers a call to an extension. In order to disable this prompt, perform these steps in the Cisco Unity Administrator:

Note: This option is available in Unity 4.2(1) and later. This feature is not available for the previous versions of Cisco Unity.

  1. In the Cisco Unity Administrator, go to your applicable page:
    • In order to modify the template you will use to create subscriber accounts, go to any Subscribers > Subscriber Template page, and find the template that you want to modify. Then browse to the Call Transfer page.

    • In order to modify an existing subscriber account, go to any Subscribers > Subscribers page and find the applicable subscriber. Then browse to the Call Transfer page.

    • In order to modify an existing call handler, go to any Call Management > Call Handlers page and find the applicable call handler. Then browse to the Call Transfer page.

  2. In the While Transferring Notify Caller section, check the Do Not Play the "Wait While I Transfer Your Call" Prompt check box.
  3. Click the Save icon.

Related Information

Updated: Feb 02, 2006
Document ID: 13919