Basic Queuing in CUCM (CallManager) without using UCCX

The feature I am thinking of is the Attendant Console application (or the Unified CM Attendant Console feature in the CUCM appliance models).  When Cisco released Call Manager 4.1, they added a feature which allowed an administrator to enable queuing on an AC Pilot Point so that callers to the pilot point can be queued (with Music On Hold no less) while they wait for a hunt group member to become available.

For those folks still using 4.1, 4.2, or 4.3 you can see what I mean by going to the console of your publisher node (or subscriber, if you prefer) and running the following:

“c:program filesciscoCallManagerAttendantinacconfig.bat”

You’ll get something like the following:

The app will load displaying the “Basic” tab and you can click the “Advanced” tab to configure a pilot point for queuing!  It is kinda clunky since you have to go the console of the server to do this, but it is functional.

In the appliance models, you have the same capability but you can configure it directly on the Pilot Point configuration page.

The Procedure (on CUCM appliance, tested on 6.x and 7.x)

Before you can use the Attendant Console application for call queuing you must configure the following:

1. You must activate the “Cisco CallManager Attendant Console server on the appropriate nodes in your cluster,
2. You must configure an Application user with the user ID ac.  This user should be a member of the “Standard CTI Allow Call Park Monitoring”, “Standard CTI Enabled”, and “Standard CTI Allow Control of All Devices” groups.
3. If you want to limit the devices that the Attendant Console application can control DO NOT associated devices to the “ac” user (this can cause instability).  Instead, create another application user named: ACDeviceAuthenticationUser and assign devices to this user.

NOTE: You don’t have to use the “ac” and “ACDeviceAuthenticationUser” user IDs.  You can modify the actual names of the IDs by configuring the Attendant Console service parameters.

After creating these users the first time, you will need to restart the “Cisco CallManager Attendant Console” service.  (BTW, for those still on 4.x builds, this service is the Cisco Telephony Call Dispatcher service)

Now, to create the Pilot number, go to Application>Cisco Unified CM Attendant Console>Pilot Point.  Click on Add New, you will have something similar to the following:

You will need to configure the following:

• Name of the Pilot:  Any name that follows your standard conventions
• Device Pool:  I like to use a device pool dedicated to media resources/applications and is separate from user apps (for things like Region configs, etc.)
• Route Calls to:  Pick a distribution algorithm (more on this later)
• Location:  For use with Call Admission Control (CAC) mechanisms
• Network Hold MOH and User Hold MOH audio sources (this is important if you want to stream music to those callers in queue
• Queuing Enable:  When selected, calls to the pilot can be queued
• Queue Size:  This is the number of callers that will be put in queue before the queue is considered saturated (more on this later)
• Queue Hold Time:  This is the time (in seconds) that a caller will sit in queue before being re-routed (more on this later) (a setting of zero “0” means that callers never time out of the queue

If you are going to queue calls, then the Queue Size and Queue Hold Time parameters are of particular importance.  When you have reached the max queue size or a particular caller’s queue time exceeds the maximum queue time the calls are “de-queued” and sent to a Hunt Group member that has the “Always Route” option flagged.  Typically, this could be another AC Hunt Pilot number or a voicemail system.

After you specify the parameters for the Pilot, click on Save.  You will now have the options to add a pilot number and assign members to the hunt group.  To add a pilot number, click on “Line [1] – Add a new DN”.  You configure the pilot directory number much like any other line DN.

After configuring the pilot DN, you can add Hunt Group members.  When adding Hunt Group members you can only add specific dial plan objects (such as phone lines, Unity VM ports, or other Pilot points).  You can flag a Hunt Group member as an “Always Route Member”.  This means that calls will always be routed to this member, regardless of the line state of the member.  This option is useful when chaining Hunt Groups together and when sending callers to voicemail if all other Hunt Group members are busy or unavailable.

A sample config:

This is a simple test where calls to the “7777” pilot number are routed to either 1003, 1004, or 1006.  The 8019951 DN is an always route member that sends callers to Voicemail.  If the 1003, 1004, and 1006 lines are all busy (on a call) then the next caller will actually be queued and will hear the “Sample Audio Source” MOH stream while in queue.  After 60 seconds in queue, callers are sent to the voicemail number.

Some considerations:

• This only works (in my testing) if you are using Circular Hunting.  When using Broadcast Hunting, First Available, and Longest Idle you will have calls that “accidently” go to the “always route members”
• You can’t associate a standard Hunt Pilot to an AC Hunt Group (including a Unity VM Pilot), so your method to redirect callers to voicemail may require using a dummy phone with a CFA configuration or some other workaround
• There are some Interactions and Restrictions that you will want to review in the Communications Manager Features and Services guide.

When looking at this option, make sure you keep in mind that this is a CTI application and you want to make sure you take appropriate measures when sizing your cluster design.  While creating hundreds of these queuing applications is not ideal, it may be something you keep in your back pocket “just in case”.