cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
623
Views
0
Helpful
6
Replies
Highlighted
Enthusiast

ICM 6.0 - Calls Stuck in Queue

We are runnig 6.0 lot of times we see few calls sitting in the Queue even though the agents are ready & available.

Has any one seen this problem. Any bugs or solutions.

6 REPLIES 6
Highlighted

What type of IVR are you queuing these calls on?

This may be caused by the VRU scripts you are using not being set to be interruptible, so that once the call is in the Queue, they remain in the queue until the message that is being played has finished.

On your AW, in Config Manager, Network VRU Script Explorer, are the VRU scripts you're using for the Queue set to interruptible?

If you're using IPIVR or similar, also look at your prompt node in the CRA Editor and check that the prompt is also set to interruptible.

Highlighted
Participant

Looks like you are running into a bug here. The bug-Id is: CSCsa89635

Highlighted

The bug is different.

I have made sure all the scripts and the promts are set to interuptable. I have not seen it in a while. I will post if I see it again.

Highlighted

Where are you looking when you see the calls stuck in queue?

Some options are:

1. Webview reporting (skill group or call type reports)

2. Script Editor in data monitor mode

3. CTI Agent or Supervisor desk top.

Highlighted

I see this in the Webview and also in the Supervisor Desktop.

Highlighted

OK, I did some research and I do not have an easy answer. There were some related cases opened, but the issue was not easily reproducible, and customer gave up on trying to collect the data.

If you want to pursue, you should probably open a support case with your primary support provider (i.e. your partner or Cisco if you have a direct contract. )

It is going to be difficult to grab logs that capture the condition when the problem occurs unless you are checking frequently, and logs are set correctly (i.e. logfiles are big enough and set with enough trace enabled). Your support team should be able to help you with that piece.

The RouterLongestCallInQ stat should tell you how long the call has been in queue or what time it was put in queue, so it should not be too bad to figure out when to grab the logs from.

There is also an advanced debug option here.

The router has a tool called "rttest" for process interrogation. CCO has several tips on how to use it if you search on it.

It has a basic command line interface. One of the commands will dump all of the calls in a skill group queue.

dump_queue /group

where SkillTargetID is the internal DB ID for the Skill Group where the call is stuck. You might need help from your support provider to look that number up because it is not readily exposed. If you export your skill group table on the AW, that is one place to get it. It will be a 4 digit number in the 5xxx range.

A word of caution here is that the rttest tool has a lot of capabilities, and it would be real easy to set your system offline for a bit if you stray out side the lines. Would be best to do this after hours or with your support team holding your hand.

With this data in hand, and a description of the scripts where this skill group gets queued to, we should be able to figure out how its getting stuck there.

Hope this helps.

Content for Community-Ad