<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 21, 2016 at 6:09 PM, Troy Bowman <span dir="ltr"><<a href="mailto:troy@lump.net" target="_blank">troy@lump.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Where I work, we're running a call center on Asterisk, using app_queue.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>- Keep each team (support, sales, etc) in their own single queue.  Simple!</div><div>- Reduce the n! (O^n) possibilities to just n (O*n) for queue distribution, and mutex locking cpu load.</div><div>- Aggregate an entire teams' statistics, but keep the ability to break statistics out by gate, too.</div><div>- Keep all incoming calls from multiple gates prioritized by their age in the single queue.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>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."</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>This sounds like a good idea.  Reducing the number of queues an agent is a member of<br></div><div>certainly simplifies the lock contention involved since each caller thread competes for<br></div><div>available agents.<br><br></div><div>Richard<br></div></div><br></div></div>