Matt,
I am sure this is a RTFM and I am pretty sure you are using meetme
rooms. Just not too sure how you do the magic.
28 T1s with NFAS so 95 channels per trunk group, seven trunk groups =
665 lines. My client's call volume has shot from 5,000 to about 10,000
calls a day. Due to recent product offerings/advertising, I expect to
be eating up 6 T1 (peak) by the end of October. They will eventually
have every channel in use during peaks, whether that is in November or
December, I am not sure. I just know it can't break at that point due
the the sheer expense of revenue lost for downtime.
Thanks,
Steve
Matt Florell wrote:
> How many lines and agents are you looking at?
>
> What kind of call volume?
>
> Average expected hold time?
>
> VICIDIAL could be an option for you since it does not use Asterisk
> Queues and can already easily scale across many servers.
>
> MATT---
>
>
> On 9/15/06, Steve Totaro <[EMAIL PROTECTED]> wrote:
>> I have been tossing around some ideas about scaling a call center
with
>> load balancing and redundancy and would like the comunities input,
>> thoughts, criticism and anything anyone wants to toss in.
>>
>> The most evident thing is to start with beefy servers and only run
procs
>> that are required. All of the TDM boxes run stripped down
versions of
>> Linux and Asterisk, they just take the call from the PRIs and convert
>> them to SIP, everything stays ulaw end to end.
>>
>> *Shared queues across multiple servers would be ideal*. I don't
think
>> it is possible in asterisk, as is. Maybe DUNDI could be useful
but I am
>> not up to speed on it enough to really know.
>>
>> I was toying with a concept of a DB server tracking the number of
calls
>> to queue(s), number of agents logged into the queue(s). Some agents
>> will be logged into multiple queues and providing the logic to a
series
>> of Asterisk servers. Calls could be made to the db to determine
which
>> queue/server to route the call to. In this situation, duplicate
queues
>> would exist on several servers, so balancing would work somewhat
if the
>> DB made the selection on which box to route the call to and which
box an
>> agent should log into. FastAGI and the manager interface will
provide
>> the routing and DB updates.
>>
>> Another thought was to have one central server with all of the queues
>> and agents, then somehow the central server would cause a
"recording/CDR
>> server" to send re-invites to the two SIP endpoints so that the
call/RTP
>> stream is moved to another asterisk server which would record the
call
>> and keep the CDR info. Again, this would be done with a DB to decide
>> which asterisk (recording/CDR) box has the lightest load. It
would take
>> the burden of maintaining the call from the "Queue" server. I/O
is the
>> first bottleneck in scaling when you record each and every call.
>>
>> Would it be difficult to have asterisk send two SIP endpoints
re-invites
>> and then bridge the call? Then it is just a matter of the "Queue"
>> server checking the DB which recording/CDR server the call should
go to
>> and send it a message to re-invite and bridge the endpoints. A
transfer
>> to a meetme is another possiblility but I want the "Queue" server
out of
>> the stream.
>>
>> Has anybody else thought through the best way to scale something like
>> this. I have a DS3 and will be using all of the channels in the
>> semi-near future. I need to come up with a workable plan before
then.
>>
>> Thanks,
>> Steve
