Greetings,
I've seen multiple posts on the topic none of which appear to have a Correct Answer identified (see
https://supportforums.cisco.com/thread/2079191
https://supportforums.cisco.com/thread/2058072
)
The request is to be able to display the original calling party ID on UCCX agent phone while the call is being presented to the agent rather than the CTI port. We understand this is expected behavior as UCCX is performing a consultative transfer from the CTI port until the call is answered and we also understand that the calling party information is made available via CAD. Here is what I received from TAC confiming my understanding that this is expected behavior:
This is the way how it works and the reason why it does.
1. Call arives at CTI RP of UCCX and rediectred to a CTI port.
2. CTI port provided media processing for the call.
3. Agent is selected and a consult transfer is done to the agent.
4. CTI port puts caller on Hold and caller hears MOH.
5. CTI port kicks off transfer process and makes a call to Agent IP phone.
6. Agent IP phone see the call from CTI port and picks it up.
7. CTI port recognizes the agent has taken the call and again kicks off trnasfer process.
8. Agent gets the call and CUCM updates the calling party address on agent phone.
At every step, UCCX has no role to play but just tell CUCM where to route the call.
CUCM is the one who is responsible for updating calling party info on the phone.
This is known as MID-Call update.
If you are looking for an answer in UCCX documentation, you won’t get it.
UCCX Developers wont provided this information as this is out of their scope.
UCCX is not a Call Agent like CUCM.
Here's a clarification from CUCM guide:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/9_0_1/ccmfeat/CUCM_BK_CEF0C471_00_cucm-features-and-services-guide_chapter_01001.html#CUCM_TP_G2219403_00
We have received this request from multiple customers and so we just need to know if there is a workaround or if there is something on the roadmap. If there are no roadmaps to change this behavior and if there are no other documents that address this perceived issue, can I ask that Cisco just mark this as a Correct Answer so that we have somewhere to direct customers questioning why this is working as it does?
