QueueMetrics > Running QueueMetrics

Calls in queue are not shown to be answered in correct order

(1/2) > >>

gb_delti:
Hello,

on our realtime reporting page we see calls that enter the queue later than other calls but are handled earlier. The seems to be contrary to the "first come, first served" principle of queues. Has anybody else had this problem? Is this just a display issue? Or is something wrong with our Asterisk? Before I dig myself deep into Asterisk debugging, I just wanted to ask if this is just a QueueMetrics thing.

Here is a screenshot:

QueueMetrics:
QM shows all calls by the time they enter the queue - so earlier calls should be answered earlier, as long as:
- they are on the same queue
- they don't have different priorities set

If you have multiple queues, any queue in unaware of what the others are doing.

mudslide567:
there are in fact other reasons where this can occur.  in a situation where there are multiple calls backed up and using an autofill type ring strategy, calls can in fact "overtake" each other in the hunt process.  you can minimize this by making sure that you get accurate reading on device state and make sure that you set your queue up to skip busy devices.  Otherwise, while call #1 is wasting time ringing some busy device, call #2 goes directly to another device that happens to be available and jumps queue position.

QueueMetrics:
Interesting! One other thing I was thinking about is that it can happen if you have clock syncing done while Asterisk is running.

mudslide567:
I think the device state problem is one that is underestimated in its role in causing a lot of these problems.  I have had two recenter installations that were using softphones where the asterisk [1.4.x] server was properly configured but the queue was ringing extensions that were already handling a queue call...so the agent would see the second line ring on e.g. Zoiper.  This was despite the fact that the server was correctly set up with "skip busy agents" etc...

The problem was that the phones were never presenting themselves as busy to the queue distribution service.  The cure for this is [gulp] to reinsert AgentCallBackLogin() onto the plan!!!  This deprecated function seems to be one of the few functions that will easily and accurately control  dev_state! 

Navigation

[0] Message Index

[#] Next page