asterisk users - Sep 2006 - Scaling/Loadbalancing a Call Center and Redundancy

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

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@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
>