CUBAC -- Caller ID on External Call Transfer

[cooperben]

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

[sean Riley · Accepted solution]

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

[cooperben]

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.

[bcorbet2004]

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

[sean Riley]

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.

[jamgale]

This is availabele on all edtions.

Make sure you log out and close the console first.

[Joshua Learn]

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

[Chi Fai Leung]

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?

[SCOTT TURNER]

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?

[BrianRoberson]

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

[cooperben]

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.

[BrianRoberson]

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.

[jamgale]

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.

[mulkeyinc]

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

[Joshua Warcop]

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