<div dir="ltr"><div>Hi Greg,<br></div><div>I am aware of a couple of solutions that come prepackaged and offer distributed queues for Asterisk. One of them, that seems to work well and reliably, is the one from Raynet. I am sure there are more. On the other side, I have seen a number of in-house solutions where you basically have a daemon polling queues statuses and redirecting calls based on the relative wait times. Rough but effective, and can be deployed easily.</div>
<div><br></div><div>About recordings, my suggestion would be to use something to offload them right from the servers, like Oreka. Have a number of large clients using it and they are quite happy (plus, the guys supporting it are superb).</div>
<div><br></div><div>Just my two cents,</div><div>l.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/27 Gregory Malsack <span dir="ltr"><<a href="mailto:gmalsack@coastalacq.com" target="_blank">gmalsack@coastalacq.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div>
<p>Hey All,<br>
<br>
Growing call center. Currently at about 200 call center staff,
running about 1000 calls per hour. Gearing up to double that.
Not too sure that a single server will support that growth.
So, I'm trying to come up with ways to scale the system and
still maintain a simplistic design. So I'd like to bounce some
ideas around.<br>
<br>
Currently I am running on a Dell 1950, dual quad core 2.33ghz
xeons, with 16gb ram, and 2 tce400p cards. This server is
managing the full load of the company. We are recording all
calls, running ivr, queues, cdr, cel, and web for reporting. I
currently have another 1950 of the exact same specifications
as a cold spare.<br>
<br>
Here's where you can see drawings of my current connectivity
and an optional connectivity I'm contemplating...<br>
<br>
<a href="http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Epaydaysupportcenter%2Ecom%2Fcurrent%2Epdf&urlhash=qLsB&_t=tracking_anet" rel="nofollow" target="_blank">http://www.paydaysupportcenter.com/current.pdf</a><a href="http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Epaydaysupportcenter%2Ecom%2Foption%2Epdf&urlhash=CJG1&_t=tracking_anet" rel="nofollow" target="_blank">http://www.paydaysupportcenter.com/option.pdf</a><br>
<br>
As you can see I currently have a separate sql server and a
separate storage server for the call recordings. This is all
working fine.<br>
<br>
However, I'm thinking for scalability I should be looking to
migrate to a configuration similar to the one in option.pdf.
Where I have a VOIP gateway server that simply relays traffic
and possibly can do some load balancing or intellegent
routing. But nothing more then that, and possibly a second one
of these online as a hot failover.<br>
<br>
Then have separate sql, storage, (i forgot it in the pic) web,
and asterisk servers behind that on separate dedicated
network. Here's my dilemma though, how do I balance the load
across multiple machines for scalability...<br>
<br>
Since 95% of our calls come into queues, I need to be able to
maintain queue stats and presence across all of the servers.
Thus far, I've got everything except the extensions.conf file
into the mysql database. I thought about setting up 2 servers,
1 for sales, and 1 for customer service, then possibly break
out each call queue to it's own server as things grow. Just
not sure if that's the right way to go.<br>
<br>
Then regarding extensions.conf, I've read that it too can be
placed in the sql database and accessed via switch. however
it's resource intense, so now I'm thinking of maybe putting
that file on the nfs server for all of the boxes to read from.<br>
<br>
As for the design of that file, I was kind of thinking of a
modular design within the file using various goto's and
gosubs. Our business model is based on affiliates and
corporate marketing, so we have a ton of did's that follow the
same call flow with minor modifications in some variables, as
well as variations in call flow, and hours of operation. Thus
the modular design of the call flow. Then the primary inbound
context would simply be a list of did's pointing to a goto
with a list of the variations and variables for the did.<br>
<br>
Ok, now that I've melted your brains.... thoughts?<br>
<br>
Thanks all in advance for the discussion...<br>
Greg</p><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
<pre cols="72">--
Greg</pre>
</font></span></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Loway - home of QueueMetrics - <a href="http://queuemetrics.com" target="_blank">http://queuemetrics.com</a><br>
</div><div>Try the WombatDialer auto-dialer @ <a href="http://wombatdialer.com" target="_blank">http://wombatdialer.com</a>
</div></div>
</div>