UCCX Queues showing bogus calls in Queue and they will not clear

Question

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?

Answer 1

Hi Jonathan ,
What is your UCCX version .
Looking at the problem description i am suspecting that your system is hitting BUG:-CSCsu40814
BUG:-CSCsu40814
Symptom:
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)
Conditions:
So far the only condition that exists is that calls are coming into the system.
Workaround:
None
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:
o   http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_8_0/release/notes/uccx_802_rn.pdf
++         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 .