[Asterisk-Users] Large Asterisk System

[BJ Weschke]

On 6/1/06, Charles R. Gomes <charles at invosat.com> wrote:
> Hey Guys
>
> I've been browsing the list looking for more information on asterisk
> behavior for large system.
>
> As for now I've got a project with
>
> 300 SIP Extensions to start, with future growth (scalability)
> Capability of recording all extensions simultaneously during peak time.
> And keeping the call recording for 30 days.
> SIP Calls being terminated over a Cisco 5400 Gateway
> Extra 100(+) FXO channels for incoming calls. (calls are going to be
> routed to the SIP Extensions.
>
>
> As far as I get the Hardware setup that I thought that will handle it is:
>
> Two Asterisk Server -  Quad Dual-Core Opteron Servers running for call
> processing
> One SER Server - Dual Dual-Core Opteron for SIP routing and SIP 2 SIP
> calls (no recording)
> One Serial Over Ethernet Storage for recording the calls (the two
> asterisk servers will commit to that device)
>
> For the setup I was going to put a lot of RAM on the serves something
> like 8GB and make asterisk record the calls to a RAMDRIVE. Another
> process will run with low priority moving the Recordings from the
> RamDrive to the Storage.
>
> If Asterisk One dies, Asterisk two assumes.
> If SER dies, ASTERISK one or TWO will handle without the proxy.
>
> We need to avoid single point of failure as also be able to scale well.
>
> Other possibility that we may look is having instead of a storage, is
> having a Extra Asterisk getting the calls as a conference over IAX and
> saving it.
> As far as I see it will also need to deal with the real time recording
> on RAM. Because seek delay on multiple files being writing as small
> chunks of data (20ms voice data) on the HD will make voice choppy. So
> the solution will have to involve moving from RAM do HardDrive as the
> conversation ends. As I read it will be easy to record a 30megs file
> instead of several small chunks of 100KiloBits. As the other process can
> run in low priority and not realtime. It may not affect asterisk
> recording to RAM.
>
> Do you guys think that the servers will be able to handle that ? Does
> the SIP protocol can handle that redundancy ?
>
>
> Has anyone designed a system similar to this ?
>
> Does anyone wants to add a two cents comment on that design ?
>
> Is any company available for paid consulting ?
>

 Your largest challenge(s) will be recording for that many
agents/channels at the same time and splitting up some of the queue
engine work for redundancy. The memory approach is a proven approach
using Monitor and makes sense as memory is a faster i/o than disk, but
you still will have to deal with the tiny chunks getting written at a
time which is just a function of the way Monitor itself works.
MixMonitor and the technology behind it queues the frames up and then
writes when the queue is full, so that's a slightly better approach as
far as scalability goes.

 We have built call center platforms for clients who have the numbers
you've spoken of and are interested in working with you. Please
respond to the email I sent you offlist for more information.

-- 
Bird's The Word Technologies, Inc.
http://www.btwtech.com/