06-29-2005 11:08 AM - edited 03-13-2019 11:00 PM
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.
07-05-2005 03:14 AM
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.
07-05-2005 08:48 AM
Looks like you are running into a bug here. The bug-Id is: CSCsa89635
07-05-2005 10:48 AM
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.
07-05-2005 12:19 PM
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.
07-05-2005 12:56 PM
I see this in the Webview and also in the Supervisor Desktop.
07-05-2005 02:54 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide