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.
My thinking:
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.
Any thoughts,
Mark
