topic CUBAC -- Caller ID on External Call Transfer in Unified Communications Infrastructure

CUBAC -- Caller ID on External Call Transfer

cooperben — Tue, 19 Mar 2019 10:38:00 GMT

I am receiving complaints that external, transferred calls from the Operator using CUBAC are not showing the original Caller ID/Number on the users' phones. After testing, I see that the Console Service Port directory number is what is displayed, e.g. an internal extension as designated in the CUBAC server, (I did label these service lines as 'Operator Transfer.') However, the desired behavior would be for the person receiving the call to see the original, external number of the call on their phones, even if after a brief display of the 'Operator Transfer' number.

I have already changed the Call Manager service's clusterwide paramteter, 'Always Display Original Calling Number on Transfer from Cisco Unity.' This works for transfers out of VM, but what about Operator transfer using CUBAC? We want the users to see the Caller ID of who originally called into the queue. Is there another parameter here that I need to change? I've scanned them all, but nothing jumped out. There are a lot though, so I may have missed something. Thanks in advance.

CMBE 5000 v8.5.1

CUBAC 8.6.1.9

7940/7960 IP Phones

C3825 IOS (12.4) Gateway

CUBAC -- Caller ID on External Call Transfer

sean Riley — Wed, 21 Sep 2011 13:27:37 GMT

This is from the Arc Forums. We implemented this here and it works fine. Just need to adjust after upgrades as well.

This is how the system works – you essentially see the caller ID of the CTI Port (“Service Device”) until the transfer is complete. This is because Arc puts the call through this CTI Port, to allow the system to perform the advanced call control features such as recall, camp-on, etc etc

There is a way to disable this process, and therefore the call bypasses these CTI Ports. Try the following:

1) Close down the CUEAC Console
2) Open regedit
3) Browse to HKLM>Software>Arc Solutions>Call Connect>Operator>Defaults>Direct transfers
4) Set this to ALL
5) Close the registry editor and try again

Doing this means that you may lose the transfer recall functionality, however we find that a lot of users do not necessarily need transfer recall nowadays, as the phone users have Forward_No_Answers to Voicemail anyway

Re: CUBAC -- Caller ID on External Call Transfer

cooperben — Wed, 21 Sep 2011 15:21:27 GMT

Thanks Sean, that was it! I wasn't aware of the Arc Forums, but will definitely be looking there for CUBAC-related problems first from here on.

CUBAC -- Caller ID on External Call Transfer

bcorbet2004 — Wed, 14 Dec 2011 17:38:53 GMT

When looking that the registry location referenced in the other thread it does not appear to be available in CUBAC. Is this only a CUEAC? Or is it version specific thing? We are running 8.6.2.11.

Do we need to manually add the Key and value, being Operator and Direct Transfer does not appear under HKLM. Does it require a reset of services to enable it?

Thanks,

Brian Corbet

CUBAC -- Caller ID on External Call Transfer

sean Riley — Mon, 19 Dec 2011 20:37:56 GMT

We are using CUBAC version 8.6.1.9. Are you looking on the Attendant Console users computer and not the server. The Reg key should already be there.

CUBAC -- Caller ID on External Call Transfer

jamgale — Tue, 14 Feb 2012 21:32:00 GMT

This is availabele on all edtions.

Make sure you log out and close the console first.

CUBAC -- Caller ID on External Call Transfer

SCOTT TURNER — Fri, 22 Jun 2012 17:40:49 GMT

I had the same issue, and changing the registry setting worked fine until another Windows user logged into the PC. When the 2nd user logs in, the problem comes back. The registry setting still shows Direct Transfer = "All". We've checked registry key permissions, but still can't figure out why this doesn't work for the 2nd Windows user. Any ideas?

CUBAC -- Caller ID on External Call Transfer

BrianRoberson — Fri, 26 Oct 2012 19:08:52 GMT

Scott / ALL:

What Scott describes is exactly what I am seeing. Everything worked fine until a second person (a different operator) signed into the same machine. Now direct transfer is broken again (No caller ID passing through)

Any ideas?

Skip

CUBAC -- Caller ID on External Call Transfer

cooperben — Fri, 26 Oct 2012 19:17:08 GMT

Because these settings are changed in the HKCU Registry hive, the settings are per-user. So, if a different user logs in, CUBAC doesn't know about the settings that were already changed for another user.

It's unwieldy, but what it means is that you have to make these reg changes for each user who logs into the machine. Sucks, I know.

As stated before in the thread, make sure that the application is logged out and closed before making the changes.

Re: CUBAC -- Caller ID on External Call Transfer

BrianRoberson — Fri, 26 Oct 2012 19:21:58 GMT

So I dont know if it matters but we are running CUEAC.

The registry keys in question are in HKLM which are generic for every user that logs in. I couldnt understand if it were the case that the registry entries were housed in HKCU.

Maybe I am mistaken, but it seems like HKLM will not change no matter how many people create profiles on the machine, yet we are observing the same behavior.

**EDIT ** i want to point out that in addition to the new operator profile, the original is also broken. Both are not working which really doesn't make sense.

Re: CUBAC -- Caller ID on External Call Transfer

jamgale — Fri, 26 Oct 2012 20:11:00 GMT

As already stated, the settings are stored in HKLM, therefore it does not matter which operator logs into the console, the same settings will be used.

If you have checked the registry and the value is set correctly but it is not working, this is liekly a permissions issue. I would guess that the operator account does not have the correct permissions over the registry and cannot therefore read the settings, in this case the default settings of the application are used.

If you add "EVERYONE" to the permissons of the Arc Solutions registry key (and all child objects) and give that group Full Access, then anybody logging onto that PC should have the correct access to read the settings.

As a side note, the settings will soon be moving to the database instead of being local. When this happens all the settings will be done on a per operator basis and be done based on there login account and not the PC they are using.

As another side note, that registry setting was added to the Options --> Preferences menu in version 9, this means you do not have to go into the registry to make this change.

Hope this helps.

CUBAC -- Caller ID on External Call Transfer

mulkeyinc — Tue, 05 Mar 2013 16:41:37 GMT

I have changed the Direct Transfer registry setting to All and still getting the CID of the CTI port rather than the Calling Party on transfers. Is there anything else that needs to be modified to get to this work?

Thanks,

Aaron

CUBAC -- Caller ID on External Call Transfer

agonza07 — Tue, 07 May 2013 22:59:45 GMT

Thanks Jamie!

Just wanted to let everyone know that the setting in Version 9 is under the advanced tab/button. Works like a charm.

CUBAC -- Caller ID on External Call Transfer

Joshua Warcop — Tue, 10 Sep 2013 19:43:03 GMT

It would be good if the documentation was kept up to date. It still references the non-existant registry key to make this functional.

I cannot find the registry on

Chi Fai Leung — Fri, 13 Jun 2014 03:20:47 GMT

I cannot find the registry on the AC 10.5 client. How can I show the original caller ID when the reception press the transfer to the others user?

Just to add a followup. It

BrianRoberson — Fri, 13 Jun 2014 11:41:36 GMT

Just to add a followup. It is best to open up the registry in question on the client machine and do a blanket search for Direct Transfers. Usually you will find the additional keys set incorrectly in the CU hive as a poster listed in the thread. Also make sure you are logged out the console when doing this as the setting will revert if you are logged in.

Dear Sriley,I'm working your

Chi Fai Leung — Fri, 13 Jun 2014 12:10:43 GMT

Dear Sriley,

I'm working your registry on the AC 9.1 enterprise client, but it is fail on the AC 10.5 advanced client.

I still hv this problem at the AC 1.5 advanced version. The transfer call will show the CTI port numbers. How can I enable the Direct Transfer ALL at the AC advanced client?

Computer\HKEY_LOCAL_MACHINE

Joshua Learn — Thu, 12 Mar 2015 16:50:17 GMT

If the Attendant Console is on a 64-bit OS use the following;

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Arc Solutions\Call Connect\Operator\Preferences\Defaults

Direct Transfers = All

Re: Just to add a followup. It

Chris Gardner — Wed, 04 Oct 2017 20:17:56 GMT

This is what you can do if you want to get the external caller id

On the console > go to options > preferences > advanced > select "No Calls"

this is will allow the call to bypass the CTI route point and allows the external call to directly hit the called number. I did the change and I was able to get it resolved. But the catch here is if the external call is not handled by the called party the external call will drop and there is no way the call will automatically connect back to Operator. Hope it make sense.

This information can be found also in the User Guide for the CUAC 11, page 41/82:

>> https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucmac/cuaca/11_0_2/user_guide/eng/CUACA110201CUG_eng.pdf