On Fri, Oct 21, 2016 at 6:09 PM, Troy Bowman <[email protected]> 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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
