[asterisk-users] Scaling/Loadbalancing a Call Center and Redundancy

[Steve Totaro]

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 <stotaro at asteriskhelpdesk.com> 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
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>