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
_______________________________________________
--Bandwidth and Colocation sponsored by Easynews.com --
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
