[asterisk-dev] Queue Gate Concept

[Richard Mudgett]

On Fri, Oct 21, 2016 at 6:09 PM, Troy Bowman <troy at lump.net> wrote:

> 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.
>

This sounds like a good idea.  Reducing the number of queues an agent is a
member of
certainly simplifies the lock contention involved since each caller thread
competes for
available agents.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161021/151aba73/attachment-0001.html>