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.
We have CUCM 10.5 and UCCX 10.6. I applied the necessary configurations you mentioned(enabling CLID feature and restarting the engine), but it didn't work. Should I do any thing else?
I have another question. Where will the calling number be displayed? If this feature works,can I see the Calling Number while ringing?
I think you are talking about UCCX scenarios that use Call Consult Transfer in order to connect the calls to CIPC, not agents. Am I right?
I tested this scenario but it did not work.
Well, me to. I guess it works for Agents, not for regular Subscribers.
If you try to register UCCX Agent and to produce a call using script with queue, it will show whether it work or not.
Call Consult Trunsfer calls on behalf or CTI Ports, that is why it don't use CallerID of Calling Party, because for this Call leg CTI Port is the Calling Party.
Yes, you are right. It just works for the calls that connect via select resource to the UCCX agents. But it was important for us to show both selected Resource and Call Consult Transfer calls.
Is there any solution to convert CTI Port to Calling Number?
This is generally discuss question.
The step Call Consult Trunsfer won't show CallerID untill Connected state of a call.
Right now I don't how to workaround it.
What may help is The step Redirect (but UCCX release the call on this step),
or maybe use CTL script on GW instead of UCCX ivr.
We've implemented this and in our environment the overlay on the phone stays until the user presses exit. Is there a way for this to disappear when the call is complete?
We tried implementing it for a customer and the results sound exactly like what you're getting. I had to back out the change at the end of the first day as they were even less happy with it than they were with the internal number being displayed.
Does anyone know if this is fixed in the latest version or if it's been committed to in a future release?
this feature “utils uccx icd clid enable”. is not helping in a way, where you have to contact people on there cellphone in PSTN.
If you simple send a call from an internal phone to a script, which only transfer the call to PSTN, it is only working for blind-transfer not for full consult-transfer.
The diffrence between them is, that on blind-transfer the call is no longer in control of UCCX. If Cellphone is busy or not reachable a failover by busy or no answer is not possible in script.
Cisco should configure a switch, which allow to send the original number on full-consult in first place, like in a blind transfer.
I have the same problem, but this problem appears if we reboot CUCM or CCX!!! BUT..... After some time after 24 or 48 hours it disappear automatically!!!!!
But last week we chanage CCX script for incoming calls for incoming calls and this problem don't want disapear automatically and I trying to fond some solution, because before it is working. Now shows CLID as CTI port number.
Cisco where are you?