B-ACD is a topic that is relevant to those pursuing the CCIE-V 2.0 and also the CCIE-V 3.0 version of the Voice Lab exam. If you know how to use the resources available to you and have sufficient practice, B-ACD can become a very strong topic for all candidates since the “points earned:time taken” ratio could potentially be greater than other tested applications such as, say, IPCC-X.
Accessing the Documentation
The first thing to mention is that use of the documentation is a must during the lab exam. How you access the documentation is from the Cisco Support page > Voice and Unified Communications > Call Control > Cisco Unified Communications Manager Express. Navigate to Configure > Configuration Guides and you will see a link for Cisco Unified CME B-ACD and Tcl Call-Handling Applications. Within this PDF document go to the chapter entitled “Cisco Unified CME Basic Automatic Call Distribution and Auto-Attendant Service (B-ACD)” and you will have struck gold.
An alternative method of reaching B-ACD documentation is via the ReadMe file which comes as part of the tar file that is extracted to the flash of the CME router. You can view this using the following command:
CME-RTR#more app-b-acd-2.1.0.0.ReadMe
I personally prefer the PDF document since I find this easier to use and the examples are better laid out when compared with the ReadMe document on the router.
Base Setup
To get your base setup configured I suggest you use notepad and copy/paste from the PDF. A common mistake will be to use the example given at the bottom of the PDF document- all examples are always at the end of the document right? Well in this case you want to use an example that is embedded in the middle of the document- click on the link for Call-Queue and AA Tcl Scripts in Flash Memory: Example and you will find a neat example that you can use as your starting point.
B-ACD contains two TCL scripts. The first script which is invoked from the dial-peer is the auto-attendant script which is called app-b-acd-aa-2.1.0.0.tcl (note- the other script has a very similar name except it does not contain the “-aa”). This is responsible primarily for two things- playing prompts and digit collection. The second TCL script is responsible for routing the call to the respective huntgroup and also call queuing when members of the huntgroup are all busy.
Once the DTMF entry has been collected the “AA” script “hands-off” to the “ACD” script and the call is routed from there.
I suggest that in notepad you go through the parameters one by one and modify them accordingly. Note the following parameters:
paramspace english language en param welcome-prompt _bacd_welcome.au
Upon further inspection of the files contained on the flash of the CME router you will see the following:
Pod11-BR2-RTR#sh flash | i .au … 70 48058 Dec 25 2008 03:51:48 +00:00 en_bacd_welcome.au
The name of the prompt that the TCL script will search for when playing the welcome prompt is actually the paramspace prefix (en) + welcome-prompt.
The welcome prompt is not to be mistaken for the menu prompt. The welcome message by default is literally a lady say “Thank you for calling”. The menu (press 1 for blah, press 2 for blah, etc…) is actually hardcoded to be played after the welcome prompt. This menu prompt is called en_bacd_options_menu.au.
Timers
The two timers to be most concerned with are the following:
param call-retry-timer 15 param max-time-call-retry 600
These timers affect the behavior of call placed into the queue when all huntgroup members listed with the huntgroup (defined using ephone-hunt) are busy. The first timer defines that the script will only ever poll the status of members of the huntgroup every 15 seconds. (That’s why it’s called Basic AA and ACD- when a huntgroup member is back in the idle state there could be a potential delay of up to 15 seconds before a caller is taken out of the queue).
The second of these timers specifies the maximum length of time a caller can be held in the queue. After this second timer expires the caller is sent to the number defined in the following parameter:
param voice-mail 5000
The voice-mail parameter is a mandatory parameter that must always be included in your base configuration for B-ACD. It does not necessarily have to be a voicemail pilot number. It could equally be a failover huntgroup number or even another B-ACD pilot number.
The voice-mail pilot number will never be used if the final number is set within the ephone-hunt configuration since in the final number will most likely be invoked before the max-time-call-retry timer expires. For this reason I suggest that the final number within the huntgroup not be used unless there is a specific reason to use it.
If the number configured for the voice-mail parameter is not responding, then the TCL script will retry every 15 seconds (or whatever the call-retry-timer has been set to). The script will only retry a certain number of times configurable using the following parameter:
param max-time-vm-retry 2
Call routing
Enough about the AA TCL script although there are other parameters that have not been covered here- although I’ve focused on some of the less understood ones. In general you should not delete parameters if you don’t think there are to be used- simply leave them to the default values.
The ACD TCL script in effect maps a DTMF entry to a huntgroup (or phone) number. In the example below a caller pressing “3″ will be routed to the huntgroup or telephone with extension “1111″ and somebody pressing “4″ will be routed to “2222″. The call routing component is entirely dependent on dial-peer matching so it is feasible that an external number (such as a PSTN number) can be used.
param aa-hunt3 1111 param aa-hunt4 2222
There are other parameters in the BACD script (such as maximum number of callers in the queue) but the only other one I’m about to mention here is the one below:
param number-of-hunt-grps 2
It is imperative that this be set to the total number of DTMF-Extension mappings created otherwise you will have major problems with your script.
The DTMF entry “0″ is reserved for routing calls to the operator and by default the highest “aa-hunt” option provisioned will be used as the operator extension. So in the example above “2222″ is the operator number.
If the highest “aa-hunt” option should not be used as the operator number “aa-hunt10″ can be used to in effect hardcode the operator to a particular number since this is the highest aa-hunt option allowed. Don’t forget that you will have to increment the number-of-hunt-grps parameter if you go down this path.
Invoking the TCL script
The good news about the example used in the PDF document is that the dial-peer required to invoke the TCL script is given to you. The example shows the following dial-peer:
dial-peer voice 222 voip service aa destination-pattern 8005550123 session target ipv4:192.168.1.1 incoming called-number 8005550123 dtmf-relay h245-alphanumeric codec g711ulaw no vad
This single dial-peer is required to invoke the TCL script. It is important to remember that the TCL script can only ever be called on an inbound call leg. The dial-peer shown above works for both calling from the PSTN and the CME phone.
The IP Address specified in the session target is a Loopback Address defined on the router. Both the “destination-pattern” and “incoming called-number” are set to the aa-pilot number defined in the AA TCL script.
When a call is made to the pilot number you will see that dial-peer 222 (in this example) is an outbound call leg. The call is routed to the Loopback interface and is returned to the CME gateway. At this point you will see that dial-peer 222 will be used on the inbound call leg at which point the call is “handed off ” to an application called “aa”.
If you have copy/pasted accurately you should have the following application already created:
service aa flash:app-b-acd-aa-2.1.0.0.tcl
No other dial-peer is required to invoke the TCL scipt- and the good news is all you have to remember is to change the IP Address and Telephone number defined.
Drop-Through
If you scroll back to the top of the PDF document you will see a link entitled Cisco Unified CME B-ACD with Drop-Through Option: Example.
It is possible to create a secondary (or how ever many you need) AA applications. One variation you could add is drop-through. All this means is that the caller does not hear any prompt and is not required to enter a DTMF option. Instead the caller, having dialed the drop-through pilot number, is routed to a pre-defined huntgroup number without any user intervention. Lets take a look at an example:
service queue flash:app-b-acd-2.1.0.0.tcl … param aa-hunt1 5071 … ! service aa-drop-through flash:app-b-acd-aa-2.1.0.0.tcl … param aa-pilot 5000 param number-of-hunt-grps 1 param drop-through-option 1 param drop-through-prompt _dt_prompt.au ! dial-peer voice 223 voip service aa-drop-through destination-pattern 5000 session target ipv4:<Loopback0 IP Address> incoming called-number 5000 dtmf-relay h245-alphanumeric codec g711ulaw no vad
In this example a person calling extension “5000″ will invoke the service “aa-drop-through” since dial-peer 223 will be the closest match dial-peer and within this dial-peer the drop-through application is invoked..
Since the aa-drop-through TCL application has param drop-through-option set to “1″ the call will immediately be sent to the “queue” application and routed to extension “5071″ since this is what “aa-hunt1″ points to. The caller will hear no prompt unless the param drop-through-prompt has been set to a valid .au file. It is imperative that the number-of-hunt-grps is set to “1″ when the drop-through option is used otherwise you will run into major problems.
You may be asked yourself why bother with the drop-through option at all? Why not just make change extension “5071″ to be “5000″ and save yourself a lot of hassle. Well the answer is that by huntgroups do not have any queueing functionality. With the drop-through option you may not be using the auto-attendant behavior of B-ACD but you are very much able to take advantage of the call queuing functionality inherent within the ACD TCL script.
There are a whole host of other tidbits related to B-ACD that have not been mentioned here but hopefully this gives you the general theme behind configuring B-ACD. Read through the entire PDF before your lab and practice configuration 5 times beforehand and you should be adequately prepared for anything they throw at you in the lab. Happy labbing!
Tags: aa, aa-pilot, b-acd, bacd, ccie voice, cme, drop-through, Mark Snow, tcl, vik malhi








Great job Vik.
After reading this post this, I went ahead to configure B-ACD.
Guess what? It works like a chram!!
Many thanks matey.
Great job Vik.
After reading this post this, I went ahead to configure B-ACD.
Guess what? It works like a chram!!
Many thanks matey.
Agreed. Great Job Vik! When I was first introduced to B-ACD earlier in my studies, I have to admit I was intimidated by the number of commands and the “mystery” behind it. For those just beginning to learn this topic, your post is a Godsend :-)
James Key
Agreed. Great Job Vik! When I was first introduced to B-ACD earlier in my studies, I have to admit I was intimidated by the number of commands and the “mystery” behind it. For those just beginning to learn this topic, your post is a Godsend :-)
James Key
Nice Article.However, if call is sent to voicemail number i.e 5000 , whose Voice-Mail box will be played to User.Is it Pilot Point OR HuntGroup# ? Does that mean we Must have Voice-Mailbox for either Pilot Point or HuntGroup# in order for user to successfully leave a message there.
Nice Article.However, if call is sent to voicemail number i.e 5000 , whose Voice-Mail box will be played to User.Is it Pilot Point OR HuntGroup# ? Does that mean we Must have Voice-Mailbox for either Pilot Point or HuntGroup# in order for user to successfully leave a message there.
Vik- This was a great job explaining B-ACD configs I am just curious if we need to be concerned about configs on CUE especially if we are adding voice mailbox for each HuntGroup? If so do you have a CUE in a NutShell? Or QOS in a Nutshell? :-)
Vik- This was a great job explaining B-ACD configs I am just curious if we need to be concerned about configs on CUE especially if we are adding voice mailbox for each HuntGroup? If so do you have a CUE in a NutShell? Or QOS in a Nutshell? :-)
The redirect # would be the HUNTGROUP # and not the B-ACD PILOT #. So if you wanted to route it to a specific mailbox that is NOT the huntgroup # you would set the voicemail parameter to a dummy ephone-dn number which forwards all to CUE.
Greg- I’ll do QoS in a nutshell if you like- there is some good material out there already but I can add my own 2cents. Watch this space.
The redirect # would be the HUNTGROUP # and not the B-ACD PILOT #. So if you wanted to route it to a specific mailbox that is NOT the huntgroup # you would set the voicemail parameter to a dummy ephone-dn number which forwards all to CUE.
Greg- I’ll do QoS in a nutshell if you like- there is some good material out there already but I can add my own 2cents. Watch this space.
Oh and BTW- don’t forget that you need the following command if you need to call CUE from B-ACD:
voice service voip
allow-connections h323 to sip
Oh and BTW- don’t forget that you need the following command if you need to call CUE from B-ACD:
voice service voip
allow-connections h323 to sip
Great info, Vik. After your comments tonight, I went to the lab and got it working. This site helped to supplement your tips about B-ACD.
I also posted a PDF on my website that shows necessary edits to the Cisco example for use in the lab. For me, it helped me visualize where I need to make changes in the configs.
Here’s the link: http://ciscovoiceguru.com/327/b-acd-tips-and-explanation/