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.
