QueueMetrics > MySQL storage and Qloaderd/Uniloader

QM and Asterisk Realtime Agents

(1/1)

moa:
I'm in the process of upgrading and completely reworking our phone network.  In the process I've ran into a small problem that I need some more input on.  I apologize for the long winded post but more information is better, right?

Here's the setup to help everyone understand:
Asterisk 1.6, logging the queue log directly to mysql.
QM 1.6.0.1 setup to watch the asterisk mysql queue_log rather than qloaderd.
In house built web front end for agents to login/logout and add/remove themselves from queues.

It is my understanding that by using asterisk realtime, you eliminate the need for agents to login and logout.  You only need to add/remove queue members via mysql.  With asterisk queue members setup to use the realtime engine the queues are parsed only when needed (i.e., call comes into queue).  If there have been any changes to the queue members since the last time it was parsed, that is when the sql queue_log is written.  I was thinking to get the correct payroll information, queue availability stats, and current agent extension, I could add a fake AGENTCALLBACKLOGIN row in asterisk mysql table.

I've got all of this up and running in my test environment and I would like some clarification on how QM would handle the following situation:

>Agent logs in (fake agentcallbacklogin row)
>Agent becomes member of 5 queues (added into queue member mysql table)
>Agent takes calls on all 5 queues (placing the queueaddmember line in asterisk queue_log)
>Agent removes himself as member of 5 queues(removed from mysql table)
>Agent logs out (fake agentcallbacklogin row)
>Queues stay dormant for several hours before receiving calls parsing the queue member table and updating the queue_log

So now there is a queue remove member after the agent has already logged out and gone home for the day.


We have roughly 50 queues, and the activity ranges from several thousand calls a day to one or two a week.  There is a high possibility that an agent will stay a member of the queue over night until he comes back the next day.  How would a situation like this affect the QM stats?


Hopes this makes sense!

QueueMetrics:
If you fake AGENTLOGINs, everything should work as expected. Or you could fake ADDMEMBERs.
The only big problem is if agents stay logged in over the realtime visibility window - but you can either change that or replicate AGENTLOGIN records every 24 hrs or so....

moa:
So having a removemember show up after the agentlogoff has been faked wont affect any stats?

We don't have any agents that will be logged in for the full realtime visibility window. However, there is a possibility that they will be associated with queues according to QM and the asterisk queue_log. Due to the way asterisk handles it's queue log with realtime agents.

QueueMetrics:
You should use either AGENTCALLBACK or ADDMEMBER.

Navigation

[0] Message Index