Calls Randomly Stuck in Que

[abaulackey]

Hello, Our system consists of IPCC 4.0(3)_Build080, Call Manager 4.13sr3b, Unity 4.2 Build 4.2(1).

Everything works just fine, but at random times, each Que (we have 3 in total), calls will get stuck in the Que, even though the agent state is ready. I see nothing in the event log to say there is a problem. Any help would be appreciated, thanks

[gene]

I had a customer that had the same problem on 4.0.1 and we upgraded to 4.0.4 and have not had anymore issues. Also we realized one of the primary ways this was happening was when the call started ringing at the agents desk if the agent accidently jiggeled (so basically immediatly answering and hanging up) the speaker button. Instead of hanging up on the caller they would be stuck in que. And there was no way to get them out. Not sure if this scenerio was fixed in 4.0.4 it was mainly fixed by training the agents not to jiggle the speaker button.

[abaulackey]

Hey Gene

Thanks for the post. I checked the release notes for 4.04, and there are about 4 fixes for stuck in que problems. I'll upgrade tonight and keep you posted, thanks

[jones_amy]

I am at release 4.04 and we are still having problems with callers stuck in the que. Any advice

[emorgan]

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,

Eric

[abaulackey]

Thanks Eric

We'll give this a try and see. Much appreciated.

Ash

[Justin Brenton]

Hey Ash,

We have the same problem ;)

I had a case open with Cisco Last week to review the logs that we had from December. They weren't too helpful but they suggest that we remove that particular phone from the Jtapi user in Call Manager, and reinsert it. He seems to think that might reset some hidden issue.

[adignan]

1. Upgrade to CRS 4.0(5) (4.0(3) had lots of issues with calls stuck in queue from what I saw)

2. Add a "Delay" step to the beginning of each script (add it before the Accept step)

3. Ensure after all "Redirect" steps in the successful branch, set each contact to "handled".

4. Follow the link below to ensure your RONA is working correctly:

http://www.cisco.com/en/US/partner/products/sw/custcosw/ps1846/products_tech_note09186a00801c82ea.shtml

please rate helpful posts.

[Justin Brenton]

Hey Adignan,

seems like this is for CCM 3, we are at 4.2(3) right now

The information in this document is based on these software and hardware versions:

Cisco IPCC Express version 3.0(2)

Cisco CallManager 3.2(3) or 3.3(3)

[adignan]

It still applies to crs 4.x and ccm 4.x

[mmelbourne]

What's the reasoning behind the one second delay before the Accept step?

[adignan]

there has been issues in the past with calls that get routed to scripts from Unity or from anothe route point where not having a delay at the beginning of the call caused phantom calls in queue. Call setup happened to quick and cti events were lost.

I have just made it a best practice since and haven't had any issues.

[marks]

If this i a phantom call this is some times caused by the CTI port settings. Check the setting to make sure they are set to max calls 2 busy trigger 1. I have had this issue on 3.5 and 401 and this is how we managed to fix it.

Hope this helps

Mark