Cisco Unified Attendant Console Advanced is an application for the Unified Communication Solutions which simplifies the ability of an operator to make/receive calls in a busy business environment with large call volume. It also simplifies various call functioning such as conference/transfer/call park. Operator has control over the client application and has access to the entire directory which simplies searching and transferring calls to users. Cisco Unified Attendant Console Advanced is widely deployed with the Cisco Unified Call Manager. This session will provide an opportunity to learn and ask questions about the Cisco Unified Attendant console Advanced and it's position in the Unified Communication solutions.
Ask questions from Monday, August 24th to Friday, September 4th, 2015
Antara Sargam is a Customer Support Engineer in Cisco TAC based out in Bangalore, India. She has total 2 years of experience and her area of expertise covers Cisco Unified Communications Manager, Cisco Unified Attendant Console and Cisco Unity Connection. She has delivered multiple training sessions on understanding the architecture and functioning of the Attendant console (CUAC). She graduated with a Bachelor of Electronics and Communication Engineering from Manipal Institute of Technology, Manipal University. She has achieved certifications for CCNA, CCNP - R&S and is pursuing RHC.
Alok Singh is a Customer Support Engineer in Cisco TAC based out in Bangalore, India. He has been working with TAC from past 4 years and 10 months in multiple domains - CUCM, Unity, Attendant Console. Alok has delivered trainings on CUCM, SIP and CUAC and Attendant Console. He worked closely with the development team identifying bugs in the testing phase and working towards resolutions for enhancing the quality of products. Alok holds a Bachelor's degree in Information Technology College – D.A.V. College of Engineering and Technology from Maharishi Dayanand University, Rohtak. He also holds CCIE Collaboration and RHCE Certifications(CCIE Collab # 45575).
** Ratings Encourage Participation! **
Please be sure to rate the Answers to Questions
Cisco Unified Attendant Console Advanced Edition (CUACA) is an application that runs on Windows server. You should not use DHCP on CUACA server and provide a static IP address. All IP addressing is done on Widows server.
As the query is routing and switching specific, i would request you to post the query on the following link:
and someone from routing and switching team would respond to your query. Alternatively, you can open up a TAC case as well.
Report for operator's availability (which keeps a track of operator's login and logout time) was not a feature on CUEAC. This feature was added on CUAC Advanced Edition version 10.5.2. Hence i would suggest an upgrade to get this feature. Following are the reports that can be generated on version 10.5.2:
Link for Webadmin - CUAC Advanced Edition: http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucmac/cuaca/10_5_2/install_admin_guide/CUACA1052WAG.pdf
You can get reports on CUAC under 'Cisco Unified Reporting' (Go to Webadmin page > Select 'Cisco Unified Reporting' from the Navigation drop-down list).
I just installed AC Advanced 10.5.2 and to my surprise noticed that +e164 number cannot be defined, is there a plan to allow +e164 to be used for the CTI ports and route points? In true +e164 deployment as recorded by industry and Cisco it's disappointing to see applications lacking behind.
Also, in related topic, in +e164 CUCM dial plan where all user DNs are +e164 how would one configure AC direct to voicemail feature to work?
CUAC Advanced version 11.0.1 will include the ability to use E.164 formatted numbers for configuring CTI devices (CTI route points and CTI ports). This version should be available for download before mid September '15. You can download it from http://www.cisco.com/go/ac.
Regarding second query about direct transfer to voicemail, following are the steps:
Yes, this is a tested procedure and works well.
Following are the snippets from CallManager traces (after 'Transfer to Voicemail' on console):
01192975.000 |09:57:08.695 |SdlSig-I |CtiLineCallInitiateReq |restart0 |StationD(2,100,63,6690) |CTIDeviceLineMgr(2,200,25,1) |2,200,13,28.702^10.100.4.14^SBD7AEB34100102 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] AsyncResponse=10130 LH=2|1929 GCH=1|2032 CalledPartyInfo=#+1234567890 MediaDeviceName = MediaDevicePid = (0,0,0,0) resource ID=0 FetaurePriority=1
01193027.006 |09:57:08.697 |AppInfo |Digit analysis: match(pi="2",fqcn="111111",cn="111111", plv="5", pss="device:CUAC",TodFilteredPss="device:CUAC", dd="#+1234567890",dac="0")
I used CUAC Advanced version 10.5.2 with CUCM version 10.5.2 and # as voicemail prefix. 'Maximum internal device digit length' was configured as 13.
Dialed digits are #+1234567890. CUAC didn't strip + and prefixed the number with #.
As Chris has said, this fails before it ever gets to Call Manager. There is no work around unless something can be applied to the client.
I have a +E164 dialplan at a client I recently deployed and they are running into this very issue.
Below are CUAC Debugs from two different VOICEMAIL PREFIX settings within the client itself.
First is *XXXXXXXXXXX You can see the failed result.
The second is just a *.
Notice in both cases, the + never makes it CUCM, requests never leave the client.
RTMT shows no CUCM activity from the CUAC DN during these attempts.
The problem is with the client and it is difficult to believe it has not been addressed until 11, considering SRND has been pushing E164 so hard.
TAC has not been helpful and asked me to do the same thing. It makes me wonder if you or anyone else at Cisco has tried it considering I've seen the same canned response from two separate Cisco resources.
Can you please comment and thank you for your time.
//CUAC LOGS (NOT RTMT TRACE THERE ARE NO TRACES FOR THIS TIME PERIOD INDICATING THE REQUEST NEVER HITS CUCM.)
*XXXXXXXXXXXX 2015-07-27 11:35:21,433  DEBUG Repository - DialRuleWrapperRepository.ApplyRules. Initial Number :*XXXXXXXXXXXX+12245553234
2015-07-27 11:35:21,434  DEBUG Repository - DialRuleWrapperRepository.StripNonValidDialChar - Before:*XXXXXXXXXXXX+12245553234, After:*12245553234 //Failed Result
2015-07-27 11:38:26,473  DEBUG Repository - DialRuleWrapperRepository.ApplyRules. Initial Number :*+12245553234
2015-07-27 11:38:26,473  DEBUG Repository - DialRuleWrapperRepository.StripNonValidDialChar - Before:*+12245553234, After:*12245553234 //Failed Result
If you're using Cisco Unified Attendant Console Advance (server based), then it should be working for you. I have tried and tested it in my lab for transferring calls directly to the VoiceMail using the console client and it worked successfully. The operator was not stripping off the + from the DN.
Make sure you're using CUAC Advanced and not Standard (server less). From the logs that you've mentioned above, it looks like you're using CUAC Standard.
If you're using CUAC Advanced and it is still not working for you, i would suggest you to go ahead and open a TAC case.
I also checked for CUAC Standard in my lab and it looks like at the moment CUAC Standard application will strip off the + from the number before sending it to the CUCM, which is happening in your case.
Below are the logs from my lab server :
2015-08-28 07:12:09,612  DEBUG Repository - DialRuleWrapperRepository.ApplyRules. Initial Number :*\+987654
2015-08-28 07:12:09,612  DEBUG Repository - DialRuleWrapperRepository.StripNonValidDialChar - Before:*\+987654, After:*987654
2015-08-28 07:12:09,612  DEBUG Repository - DialRuleWrapperRepository.ApplyRules():Aborting... no rule is Found
To reiterate, CUAC Standard is just an application for the Cisco IP Phone. As of now, this functionality is not available on CUAC Standard but can be configured on CUAC Advanced.
As a workaround, you can do the following :
1. Configure the Voicemail prefix as * on the CUAC Standard client. CUAC Standard will send digits *XXXXXX to the CUCM
2. Create a Translation pattern : *.XXXXXX (x depending on the DN length)
3. Configure this translation pattern to discard digit preDot and prefix +
4. Create a Directory Number as \+XXXXXX with Call Forward All to Voicemail.
5. Configure CSS and partition in such a way so that the DN \+XXXXXX is accessible only to the translation pattern created in step 2.
I am not sure if I am making this complicated but hope to hear from you.
In my setup, my CUAC is Centralize in Location "A".
CTI Template's User Hold and Network Hold is Configured as Stream 10. (Music which the Caller would hear when they are placed in a queue)
I have a 2 x Remote Site (Location "B" and Location "C"), where the phones are using Multicast MOH, Stream from the Gateway. Phones's user and Network Hold is configured as Stream 1 (Cisco Default).
Would Queue Music or Silece be hear, if the Calls come in via the Location "B" Voice Gateway, and place the Call in the Queue?
Would Queue Music or Silece be hear, if the Calls come in via the Location "C" Phone, and place the Call in the Queue?
Would Queue Music or Silece be hear, the Operator had pickup the call, and is transfering the call?
My understanding of MOH is, it would use the Holdee's MRGL and Search for the Holder's Stream (in this Case, Stream 10). But due to it streaming from the Voice Gateway, it might not work.
Am I correct?
If i am, how should I design it? (Not stated in the Design Guide)
If I am wrong,
What is the behaviour for the above scenario?
Hope to hear from you, the expert.
CUAC does not play MOH. It completely relies on config of CTI ports on CUCM for music on hold. It sends the hold request to CUCM (via CTI) and CUCM takes care of MOH part. In your case, CTI device (used for CUAC) on CUCM is the holder and phone at location B or C is the holdee. All rules for MOH on CUCM applies here.
CTI devices on CUCM do not support multicast MOH:
Therefore, i assume location A or audio source 10 is configured for unicast MOH. As you mentioned, MOH resource will be selected from holdee's MRGL and audio source will be selected from holder's config.
Link for SRND for MOH selection on CUCM:
Multicast MOH server will continuously send out a MOH stream. Phone will listen to it only when CUCM will ask it to join the multicast group. MOH server where multicast MOH is enabled can still send out unicast streams whenever needed.
In your case, whenever a phone in location B or C would call in CUAC (CTI devices), audio source 10 will be selected (which is not configured for multicast), hence it would be a unicast stream to both the locations from CUCM. It should work fine and multicast MOH for location B and C shouldn't impact MOH on calls to CUAC from both the locations.
Hi Alok & Anantra,
I have a customer who were on the Arc system and have since migrated to the CUACA 10 version. Their main pain point currently is that they are unable to assign user roles on the CUACA because of which the administrator has to provide his user credentials to the supervisor in order to review the reports.
Will we be able to assign user privileges with the 11 version?
Cisco Unified Attendant Console Advanced Administration is accessible only to administrators. The
default user name is ADMIN and the default password is CISCO.
The latest release of CUAC Advanced version 11 is also out. There is no enhancement to include users to be able to access the CUAC webadmin page. Since this is a server-client model, the server is supposed to be accessed only by the Administrator and the client console can be accessed by the operators.
Since there are no per-user based configuration (as opposed to other Unified Communication applications) on the CUAC Administrator page, there are no user roles defined as well. Users are imported on the CUAC which are visible on the Admin page as well as the client console. The operator can make changes manually to the users visible to them on the console. We cannot manually make any changes to the users on the web admin page.
The Cisco Unified Reporting page is also accessible only to the administrators where they can generate the following system reports.