[asterisk-dev] Queue Gate Concept

[Troy Bowman]

Where I work, we're running a call center on Asterisk, using app_queue.

For a long while, we were using multiple queues for each speciality (or
"skill"), placing agents in several queues, and using the "announce"
queue.conf configuration option to whisper to the agent the role they
should perform for the incoming call, and reporting statistics for each
queue.  For example, Sales needs to be able to answer the call differently
for different products, and we need to report on how many calls we are
receiving for each product, how they are handled, and what type of support
calls we're getting, and so on.

We had what I thought were issues with n! (O^n) mutex locking possibilities
as multiple queues had more and more calls queued up, and as those multiple
queues had to check all of the agent states over and over.  At the time, we
also had the issue that if the queue priority is the same, there was a race
condition and multiple calls would be fed to the same agent at the same
time.  This has since been fixed (commit c345e53), but the issue of
balancing incoming call priority for multiple queues remains.  And with
queue priorities, one queue would have to empty entirely before the other
queue would start to empty.

The idea came from our operations leadership that another phone system they
used in the past had the concept of multiple "gates" to the same queue.
Gates could provide these advantages:

- Keep each team (support, sales, etc) in their own single queue.  Simple!
- Reduce the n! (O^n) possibilities to just n (O*n) for queue distribution,
and mutex locking cpu load.
- Aggregate an entire teams' statistics, but keep the ability to break
statistics out by gate, too.
- Keep all incoming calls from multiple gates prioritized by their age in
the single queue.

The point of a gate is to be able to dynamically define an entry name to
the queue in the dialplan, depending on menu options or DIDs that whatever
route the caller took to arrive at the queue.  The queue "announceoverride"
parameter, which is played to the agent as they answer the call, is the
perfect opportunity to double as a definition of a gate name.  We would
just need reporting for the different announceoverrides in the queue log.

I modified app_queue.c, and we've been running with my changes for about 6
months.  So far, so good.  Here is a summary of the changes I made:

To me, the name "announce" in the queues.conf and "announceoverride"
app_queue argument is ambiguous.  While those names should reflect what is
whispered to the agent when they accept a queue call, there are many other
"announce" queue configuration parameters that reflect what is played to
the caller while they are waiting in the queue.  I renamed "announce" to
"gate_whisper" and "announceoverride" to "override_gate_whisper."

The big piece of the puzzle was reporting gate statistics.  I did not want
to change the schema of the queue_log, but I wanted to be able to tell if a
queue_log entry went through a special gate.  So I added another
queues.conf option, "log_gate_in_queuename", which if true would append the
gate name (defined by the whisper/announce) after the queue name, delimited
by a forward slash for easy parsing.  Appending the gate name would be
skipped if the gate name is undefined or if the gate name is the the same
name as the queue name.

My reason for posting this is to ask if this is something you all want
upstream.  I know many people run multiple queues simply for reporting
statistics like I was, when we only really need one queue for each team of
agents.  Of course, reporting packages out there would still need to take
advantage of the queue gate in the queuename field of the queue_log, if
they want to turn it on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161021/cad6a86b/attachment.html>