UCCX Queues showing bogus calls in Queue and they will not clear
I have many queues and two of them show one call in each of the queues on the supervisor desktop. However there is not any call in the queue. How do I clear theses calls/stats on the supervisor desktop for the end user so it does not show bogus calls on the queue on her clent?
The supervisor desktop realtime reports will show an entry in "Oldest in Queue" that appears to be a call in the queue but has no time associated with it. The issue will show as 1(00:00:00)
So far the only condition that exists is that calls are coming into the system.
Further Problem Description:
The system RealTime Reports does not reflect this call and it is only shown in the Supervisor Desktop display. There is not actually a call in queue as well and it seems to be a reporting error.
The defect can be explained as follows:
++ This happens because of any of the unsupported configurations/actions for UCCX.
++ This will lead the UCCX engine not to clear the entry of the call internally and thus it will send messages to the CSD to display the call.
++ Ideally when you have a legitimate call: "1[00:20:00]", this means that there is 1 call in the queue for 20min. However, 2[00:00:00] means that this call is no longer in the queue, but there is a false entry of the same.
++ Therefore, the restart of the engine will remove these entries
++ This entry will be created in the UCCX engine when an unsupported action is performed such as transfer to a different Route point etc. (not necessarily this).
++ The defect addresses how such a call is handled so that the call entry can be appropriately cleared.
++ It would be difficult to say why the issue started to occur, but we can explain as to why the entries are seen on CSD and how we can clear them.
Please note the following:
++ All unsupported scenarios/configurations mentioned in the guide have to be avoided:
++ All the unsupported configurations can cause this issue to occur. However, the defect-fix has been verified for the following configurations:
1. When an agent on call c1 initiates consult c2 to the RP,cti port, c2 is just in the process of getting queued when agent completes transfer and so c1.iaqstate is set incorrectly to NOT_IN_QUEUE due to a race condition. The defect CSCsu40814 occurs even in regular, supported agent to rp transfer scenarios due to race condition.
2. As soon as the agent went reserved for the primary consult , he answered the primary consult but even before the main call could be fully transferred to the agent, He held the primary consult call and initiated a new call to the RP. This is what caused the main IAQ call to terminate. And he was left only with the new call he initiated. So he again initiates another consult and completes transfer.So the agent wanted to answer the PRIMARY consult and immediately transfer it back to the RP without talking to the caller.In this particular scenario, the call was between 2 CTI ports
Issue can be resolved by restarting the CCX engine(in off hours). This is a temp workaround .
you need to check if agent's are not using any unsupported configuration .
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...