Hi, How do you folks handle really large queues (350+ simultaneous callers) in your Asterisk PBXes? We're going to be bringing in around 16 PRIs' worth of inbound callers, doing skills-based routing, and queuing them up for approximately 200 agents. What's the best way to handle all of these callers? We want to record the calls and we'll probably use the ramdisk method that has been discussed on this list. Here's some ideas that I'm considering: Idea #1: Use servers with (2) Digium 4-port PRI cards, running Asterisk, as media gateways. From here, send calls to 2 or more Asterisk queue servers. For each incoming call, run an AGI on the media gateways that determines which queue server is least loaded. Send this incoming call to the queue server over an IAX2 trunk. The problem with this method is that the queues are not unified; if one queue server suddenly has available agents, queued callers on the other queue server cannot be (easily?) transfered to the server with available agents. Also, running an AGI for each incoming call is lame and slow. Idea #2: Use 3com VCX V7122 media gateways to terminate the PRIs and send the calls to a load balanced pair of SER proxies. These proxies will somehow keep track of the state of the Asterisk queue servers and redirect the incoming calls to the least loaded (most available) queue server. The problem with this method is that, by using SIP, we'll probably see higher interrupt load on the Asterisk queue servers. Additionally, I'm not a SER expert yet and I have no idea how to get SER to monitor the state of the Asterisk queue servers. As with Idea #1, the queues are also not unified, which sucks. Idea #3: ??????? (profit!) Do you fine folks have any ideas or suggestions? thanks, Chris
On Tue, 16 Jan 2007, Christopher Snell wrote:> Idea #1: Use servers with (2) Digium 4-port PRI cards, running > Asterisk, as media gateways. From here, send calls to 2 or more > Asterisk queue servers. For each incoming call, run an AGI on the > media gateways that determines which queue server is least loaded. > Send this incoming call to the queue server over an IAX2 trunk. The > problem with this method is that the queues are not unified; if one > queue server suddenly has available agents, queued callers on the > other queue server cannot be (easily?) transfered to the server with > available agents. Also, running an AGI for each incoming call is lame > and slow.This is similar to what I am doing now. I have 3 1u's with a single Digium 4 port PRI card. Each server services 2 T1's. This configuration was based on management's tolerance for in-flight call revenue loss, not CPU capacity. The "telco servers" dial a single application server via IAX. I disagree with "lame and slow." In my system, 3 AGI's are executed on the telco servers before the call is "handed over" to the application server and 1 more when the call is hung up. 8 AGI's are executed on the application server before the caller connects to the product of their choice and 2 more when the call is hung up. All of the boxes are 3 gHz Intel's. This system handles a load of about 15,000 calls a day with about 100 simultaneous callers and based on "top" could handle several times that load -- most of the boxes run about 80%+ idle. Just for grins, I wrote an AGI (in C, like all my AGI's) that just reads the AGI environment from STDIN, parses it, and stuff's the strings into a structure, just like any "real" AGI would and then exits. I find that a 3 gHz non-HT Intel can execute about 300 "noop" AGI's per second. For comparison, this same box can execute the "noop" application about 6,000 times per second. This is not to say that an application executes 20 times faster than an AGI, just that the invocation of an AGI is much more "expensive" than an application because it is a separate process and communicates with Asterisk via STDIN/STDOUT. Once the AGI is started, I believe the execution time of the "meat" of the AGI should be similar to that of an application. AGI's: ) don't crash Asterisk if you make a simple coding error. ) "take effect" as soon as you move them to the agi-bin directory. ) never require a reload or a restart. ) can be coded in a variety of languages by programmers with meager coding skills. ) are less complex because they only have to deal with a single thread of execution. ) are quicker to develop. AGI's rock and are appropriate for many applications. Thanks in advance, ------------------------------------------------------------------------ Steve Edwards sedwards@sedwards.com Voice: +1-760-468-3867 PST Newline Fax: +1-760-731-3000
Hello Chris, we have a number of clients who deployed very large CCs over the 200 agent range. Your idea #1 is pretty sound and I believe that's what most people are doing. I would like to add a couple of points of attention: - having hundreds of agents on a box means a lot of synchronous audio flowing in and out, so you don't want to save on the ethernet hardware :) - think about a passive SIP monitoring for call recording, so that you can have a different box (or set of boxes) to handle that without slowing down the overtaxed ethernet connections of the queueing servers. I hope this helps, l. In data Wed, 17 Jan 2007 02:32:35 +0100, Christopher Snell <chris.snell@gmail.com> ha scritto:> Hi, > > How do you folks handle really large queues (350+ simultaneous > callers) in your Asterisk PBXes? > > We're going to be bringing in around 16 PRIs' worth of inbound > callers, doing skills-based routing, and queuing them up for > approximately 200 agents. > > What's the best way to handle all of these callers? We want to record > the calls and we'll probably use the ramdisk method that has been > discussed on this list. > > Here's some ideas that I'm considering: > > Idea #1: Use servers with (2) Digium 4-port PRI cards, running > Asterisk, as media gateways. From here, send calls to 2 or more > Asterisk queue servers. For each incoming call, run an AGI on the > media gateways that determines which queue server is least loaded. > Send this incoming call to the queue server over an IAX2 trunk. The > problem with this method is that the queues are not unified; if one > queue server suddenly has available agents, queued callers on the > other queue server cannot be (easily?) transfered to the server with > available agents. Also, running an AGI for each incoming call is lame > and slow. > > Idea #2: Use 3com VCX V7122 media gateways to terminate the PRIs and > send the calls to a load balanced pair of SER proxies. These proxies > will somehow keep track of the state of the Asterisk queue servers and > redirect the incoming calls to the least loaded (most available) queue > server. The problem with this method is that, by using SIP, we'll > probably see higher interrupt load on the Asterisk queue servers. > Additionally, I'm not a SER expert yet and I have no idea how to get > SER to monitor the state of the Asterisk queue servers. As with Idea > #1, the queues are also not unified, which sucks. > > Idea #3: ??????? (profit!) > > Do you fine folks have any ideas or suggestions? > > thanks, > > Chris-- Home of QueueMetrics - http://queuemetrics.loway.it