I just installed another Cisco phone system at one our remote sites and once again was asked why a call that is transferred from UCCX does not show the CLID of the caller, but instead shows the UCCX CTI port number and name when ringing. I searched the threads once again and came across a thread about this same issue with Unity Connection transfers and found out that there is a service parameter to fix this issue for Unity Connection. Hmm, why can't this be done for UCCX transfers too? Below is what I have sent to my Cisco Rep. for a feature request.
Note to Cisco Rep:
We use UCCX for IVR scripts for our company stores. I have been asked every time I put in a new system in a store why the UCCX CTI port number is seen instead of the original caller's caller-id while the phone is ringing. The original caller's caller-id displays after the call is answered however. I could only tell them this is the way it works. I've tried many times to find a solution for this and read many Cisco forum posts about this same issue and can't find a way to make the original caller's caller-id show up on the phone during ringing.
The setup is that a call script on UCCX answers an inbound call and plays a message "Please hold for the next available representative". The script then attempts to transfer (consult transfer) the call to a hunt-group configured with the appropriate phones for that group (Not Agents in UCCX). If no one is available to take the call the caller gets queued on UCCX while UCCX continues to attempt to reach an available group member. The problem is that when UCCX is attempting the transfer and ringing the group member phones the phone only displays the CTI port number and not the original caller's caller-id. I understood the user's concern about this, but didn't think it was that big a deal until a user showed me that missed calls from the UCCX script were also only displaying the CTI port of UCCX. This in my mind is a much bigger issue than just not seeing the original caller's caller-id while the phone is ringing. There is no way to return a missed call or even know who was calling because of this.
I just read a similar issue in the Cisco forums except that Unity Connection's AA was being used instead of a UCCX script. Some one replied that there was a service parameter that you could set to show the original caller's caller-id instead of the Unity Connection port during call transfers. This was new in 7.1 I believe. I would like to submit a feature request to have this same service parameter included for the same function with UCCX call forwards. The Unity Connection service parameter is Display Original Calling Number on Transfer from Cisco Unity.
This feature request is to have the service parameter Display Original Calling Number on Transfers from Cisco UCCX added to CUCM. I don't know if there is a technical reason this can't be done, but I would like to put it on the table for the developers to consider.
This is the single biggest complaint we have from our users. From the Cisco forum posts I've read, it appears to be an issue to others as well.
An engineer replies that it is because UCCX is using a consult-transfer. I agreed with him. I had already stated this in my original message. So, I sent the below assuming Unity Connection also performs a consult-transfer, but can now show the CLID of the caller with a service parameter setting.
1. a phone to phone consult transfer shows the transferring number during the transfer and shows the original caller's number after the transfer completes.
2. UCCX to phone consult transfer shows the transferring number during the transfer and shows the original caller's number after the transfer completes.
3. Unity Connection to phone (assumed) consult transfer used to show the transferring number during the transfer and the original caller's number after the transfer completes
4. Now, at a recent version level, Unity Connection to phone (assumed) consult transfers can be configured with a service parameter to show the original caller's number during the transfer and after the transfer completes.
So, if they all worked the same before, then I would think the process is the same. If the process is same for all scenarios, wouldn't a service parameter like the one available for Unity Connection be possible for all?
The Cisco engineer replies that he thinks Unity Connection does a blind transfer. I wasn't convinced that this was the case since Unity connection has the ability to queue a call attempt multiple transfers if a phone user is not available.
I replied with this:
I got the below from the Unity Connection admin guide. Wouldn't Unity Connection's ability to bring a call back into a queue and attempt multiple transfers be a consult transfer? I wouldn't think it would be possible to bring a call back into queue with blind transfer.
Call Waiting Hold Time
With call holding, when the phone is busy, Cisco Unity Connection can ask callers to hold. Connection manages each caller in the queue according to the settings that you configure.
You can change the setting for the wait time between call transfer attempts (the default value is 5 seconds), and for the maximum number of call transfer attempts that are allowed (the default value is 5 attempts). To obtain the call holding queue wait time for the first caller in the queue, Connection multiplies the values of the two settings. For example, if both keys were set to a value of 10, the call holding queue wait time would be 100 seconds (a wait time of 10 seconds x 10 call transfer attempts).
I know this is wordy, but I think it is a big issue and could possibly be solved with a service parameter the same way the Unity Connections issue was.
Have you tried setting "Display CTI Route Point Name or DN" CCM service parameter to "False" ?
Display CTI Route Point Name or DN is for redirected calls not transferred calls. It is also already set to false.
I received a reply from my Cisco sales engineer about my thinking on this issue. He says that Unity Connection can do a consult transfer or a blind transfer. He says that the parameter for Unity Connection only works with the blind transfer option. That didn't seem right to me. For one thing blind transfers already show the original caller's CLID, so why would there be a need for a service parameter in this case.
I set this up in my lab and tested consult transfers from Unity Connection for calls with and without the Display Original Calling Number on Transfer from Cisco Unity set to true.
Display Original Calling Number on Transfer from Cisco Unity = false
Transfer target displays Unity Connection port and "From Voicemail"
Display Original Calling Number on Transfer from Cisco Unity = true
Transfer target displays original caller's CLID and "name of caller"
So, if a service parameter can make this work for Unity Connection consult transferred calls, then wouldn't it seem plausible that it could be done for UCCX too?
I would really like Cisco to look into adding this same feature for UCCX consult transferred calls. It is a huge concern for our users and I understand their concern completely.
I received a call from Cisco today. They will be implementing this request in a future release. The engineer that called me to inform me of it's pending inclusion did not know when this would be implemented, but assured me that it will be coming.
Thank you Cisco for looking into this and moving it further along the feature addition process. I can't wait until the time I can inform our users of it's release.
Have you found any type of workaround for this issue since your last post? We are facing the same problem. From what I understand, in CME, accomplishing this is as easy as adding the command 'calling-number initiator' after entering into 'telephony-service'. We run CUCM 7 with a number of H.323 gateways and thought about configuring that command on them, but I'm thinking once you're in 'telephony-service', you're essentially configuring CME and the command would have no effect on the H.323 gateway. Am I right? Either way, this is something they need to get corrected sooner rather than later.
I think you are correct in that the gateway telephony-service config would have no affect on the calls routed through the UCCX server. I don't think I will hear back from Cisco on this until it is actually added as a feature. I am hoping sooner than later as well. Until then I just let our users know that it's coming.
Your detailed post is over two years old now! I am lookin for this same functionality with the Call Consult Transfer in UCCX 8.5.1. I have not fould this functionality yet, have you?!
I haven't heard anything on this since I was told it would be an added feature in a future release of callmanager. This will be a service parameter on CUCM when implemented. There is currently a service parameter for this same issue with Unity Connection. I was told it may be a few releases before it was available.
Great write-up Mark. I've been searching for a workaround for a couple days and apparently one doesn't exist. Someone had recommended I try the parameter "Display Original Calling Number on Transfer from Cisco Unity" but see you have already done so and it had no effect on UCCX transfers. It is a shame that Cisco hasn't been able to rectify this issue as it is an inconvenience for those of us that need to capture the CLID prior to the call being completed. We were going to use a 3rd party application in order to pull up the customers account prior to the call being completed.
It has been a long time since I was told this feature would be coming. I just checked the latest release notes and haven't seen it mentioned yet. I think 9.x should be out this year, but not certain. I hope it contains this feature.
Has anyone discovered the fix for this? I am running into the exact same issue. I have CUCM 9.01 and CCX 9.01, so hoping there was a parameter added somewhere??
I was at a CIPTUG meeting a few months ago and was told that this feature did not make it into 9.0. It is hopeful to be in the 9.5 version. I'll believe it when I see it though.