[Asterisk-Users] UPDATE - 512 Calls w/ Dig Rec: NFS Setup and Benchmarks

[Matt Roth]

Matt,

> Well, almost all of the reports, database schema and other code is all 
> fully GPL'd and available on the project site for download:
> http://astguiclient.sf.net

I guess I should've realized it was open source.  Thanks for the link, 
we'll download everything and take a look for ourselves.

> We do not use Asterisk Queues or Agents because we found them limiting 
> in terms of functionality and scalability as well as not being as open 
> to call manipulation as the system we built is. Because of this we 
> haven't really used the Queue stat analysis tools out there any more 
> than to look at the kind of stats they generate.

I figured as much, but with your experience I didn't think it would hurt 
to ask.  Your statement concerning scalability being a problem with 
Asterisk Queues and Agents concerns me, because we are planning on using 
both in our large scale (250-500 concurrent calls) call center setup.  
Could you expound on it?  Are they resource intensive at large numbers 
of calls, does the code have hard limits, etc?  We've dealt with the 
scalability issue of the Monitor application and thought that would be 
the last such hurdle.  The Asterisk source code looks to be very well 
written and I was hoping that the other applications that aren't bound 
to disk I/O do not introduce other bottlenecks.

Are there other Asterisk applications that present serious scaling 
issues?  We were hoping that our hardware (four 3.16 GHz Intel Xeon 
processors and 4 GB of RAM) would help us overcome most of them.

> Our reporting is entirely based on database tables where we log 
> everything from asterisk calls to agent actions, that way we can 
> easily generate real-time stats based on whatever we want.

I believe that will be the core of our architecture as well.  Capture 
EVERYTHING in a database and derive all of the reports from it.  I'm 
sure your database schema will be quite helpful in this endeavor.

> The ACQS is still viable because it is more of a streamlined interface 
> that is easier on the Asterisk server than some of the other proxies 
> being developed, and it can be tightly integrated into how our other 
> software like VICIDIAL works. It is also fully backward compatible 
> with all versions of Asterisk from 1.2beta1 all the way back to 
> CVS_2003-10-04

Anything that reduces the load on our Asterisk server is a Very Good 
Thing.  We'll take a look at building ACQS into our architecture.

> If you have the time and a spare machine I would suggest installing 
> astGUIclient/VICIDIAL on a machine. That would give you the best idea 
> of how everything works inside of it.

I'll probably do that when I get a break in my schedule.

> The guys from GnuDialer also have been going through a lot of the 
> figuring-out of how all of this works as well. They started earlier 
> this year building their own GPL'd asterisk dialer and they are 
> already on their third major code rebuilding because of all of the 
> things that they have learned.

Working on Asterisk is definitely a learning experience.

> Could you tell me a little more about what it is exactly that you are 
> trying to build?

Sure.  We are developing a three server system to handle inbound calling 
in a call center environment:

 1) Asterisk Server
 2) Digital Recording Server
 3) Reporting Server

The Asterisk Server itself performs no codec translations and no DSP.  
It will be connected to a Cisco AS5400HPX Universal Gateway that 
terminates the Ts and handles all TDM to VoIP (SIP) processing.  As you 
know it's a pretty beefy box and we've tried to reserve as many 
resources on it as possible for running Asterisk and its applications.  
We won't be doing call conferencing on it, but we are planning on having 
multiple queues with music on hold (our music files are converted to raw 
files and do not require any decoding) and queue announcements.  The 
majority of calls will be digitally recorded as well, but this involves 
no transcoding and no writes to the local disk.  Some calls will also 
involve transfers to outsides lines, three way calling, and unattended 
monitoring via the app_chanspy.so module.  We are looking to scale to 
500 agents spread across multiple queues, but I believe our initial 
numbers will be closer to 200 agents.

Currently, we are running a beta of Asterisk Business Edition with a 
license limit of 1000 simultaneous calls.  We are using Asterisk's 
standard queues, but would like to move to realtime/dynamic queues in 
the future.

The Digital Recording Server receives the leg files at the end of each 
call and is responsible for mixing, indexing, and eventually archiving 
them.  The digital recordings will be available for downloading via FTP 
from this server as well.

The Reporting Server is the biggest unknown at this point.  Currently, 
it has a mySQL database that receives call detail records from Asterisk 
via the cdr_addon_mysql.so module.  AstManProxy also runs on this box 
and may be used to add additional data to the mySQL database.  Any 
real-time or next-day reporting will be created from this database, so 
that Asterisk itself is not affected by the reporting process.

Please let me know if you would like any more specific details.  I would 
be happy to supply them to you.

Thanks,

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer