Hello, I'm hoping someone can shed some light on this issue.
We have IPCC Express Enhanced 4.0(3)Build080 and on the Real Time Reporting tool, there seems to be a call stuck in a queue.
On the CSQ IPCC Express Stats report we show 1 Contact Waiting and the Oldest in Queue value is over 3 1/2 hours. If all the agents assigned to this CSQ log out then log back in, this number doesn't change. Even if all agents go Ready to take the call, the call doesn't come through. I called the extension for this line and I got through to the agent, but this ghost call still remains in the report.
Initially this was just showing up on the Supervisor Desktop Team Skill Stats Report but now it's showing up on the Real Time report as well.
Our Supervisor Desktop version is 6.1(3) Enhanced.
If anyone has any ideas on this, I'd greatly appretiate the help.
In each of your "Select Resource" steps, have you populated the "Resource Selected" field with a variable of type "User"? (use the existing "__TempResourceSelected__" user varible when available in the script)
Then upload the script and restart the service engine to clear up the stats.
Thank-you for your suggestion,
I tried this but I'm still getting a call in the queue value in the Supervisor Desktop report for Oldest In Queue column with no running time.
This did clear up this morning when I restarted the engine, but it quickly showed up as soon as the phone lines went live.
Any other suggestions on what I can try to fix this?
do you have a 2 second delay in your scripting (especially the ones that the agent's transfer calls to) between your Start step and your Accept step?
Nope, we definetly do not.
I will add a 2 second delay here, but how does that affect the calls? Does that give the system a chance to set the real time data?
It seemed to have resolved the problem shortly after making your requested changes, but similar to your situation we still experience this on occasion.
We also don't have shared lines; each agent has an IP phone and their Agent Desktop running on their PCs.
I opened a TAC on this and they say that this is a cronic problem that needs a lot of debug traces to determine the root cause, and to refer to the following document for instructions on enabling the debug logging necessary to solve this issue:
Hope this can help others out there with this issue.
Had the same problem with similar versions. IPCC RTR showed stuck calls from time to time.
In my setup Unity call handlers accepted the calls then transfered to IPCC. TAC found a problem with Callmanager transfer timings. They suggested changing the transfer type in Unity from "release to switch" to "Supervised transfer". No new stuck calls since.
Bug ID is CSCsh22389.
Hope this helps,
To get rid of the call ALREADY "stuck" in the queue, you can restart the CRS Engine.
In regard to actually fixing the problem, I ran into this problem today and found that the reason was that I answered the call from a shared line on a device that was NOT associated with the RM JTAPI user. The situation was that I had a shared line between an IP phone and an IP Communicator. The IP Phone was associated with the RM JTAPI user, but the IP Communicator wasn't. When I answered from the IP Phone, the call didn't get "Stuck". When I answered from the IP Communicator, it DID get "Stuck". The problem went away when I associated my IP Communicator with the RM JTAPI user.
Unfortunately there are no shared lines in our environment. One line per agent, each agent has an IP Phone and Cisco Agent Desktop.
Do you have any 2 second delays between your start and accept steps in your script?