I had a problem with my UCCX 8.5, that i was told by a TAC is a "enhancement defect" of the UCCX. So what we could call a "feature" of UCCX.
When a call is being presented to an agent in the CAD, and the calling party disconnect the call, then call will continue to be presented in the CAD for about 5 seconds, before the agent goes into ready state again and the "offered" call is removed.
So in about 5 seconds the agent will think they have a call, and they can also try to answer it with "Ctrl+A" but nothing will happen.
The actually call isn't anymore on the agent's deskphone, so no ringing from that one.
But that the a call is still being "offered" in CAD for 5 seconds
is a major defect from my perspective.
So how do you tackle this? Do you tell the agents that this is just the way it is, or do you have any loopholes that one could use to avoid this?
If i'm to roll out an UCCX with this, then I'll have a hard time being pushed by the customer regarding this.
I have tried to put an "On Exception (ContactInactiveException)" in the script, and the script catches the exception fine. But I can't find anything that would help me with that call stays presented in the CAD for those 5 seconds. I can end the script when I catches it, but the timelimit in the CAD still persists.
The only thing I really can do, is to make sure that the least amount of calls is being abonded, while being presented to an agent.
So what I'm doing now is puting ind prompts in every script (queue), so that everyone that don't want to talk with an agent, is given time enough to discontinue the call before they reach an agent. Something like "You are now entering the internal Copenhagen Queue."
But still... It's not an pretty solution, to something that in my pespective shouldn't work like this in the first place.
It should be a problem for all running an UCCX 8.5.
I understand your concern and 5 seconds does seem like a long time however, how often do you think this happens? I'm going to guess, depending on volume, a few calls out of every few hundred calls. The reason I say that is because the majority of people who sit in queue have enough time to think about whether they really want to talk to someone or not. The ringing event happens so far down in the natural call center call flow that by that time callers should be committed to either talking or hanging up way before that ring begins.
Please let me know if this is not the case in the industry you're in.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...