[asterisk-biz] Outbound Messaging, Voice Broadcasting, Alerts,

BJ Weschke bweschke at gmail.com
Wed Aug 15 10:53:11 CDT 2007


  On 8/7/07, Gerard Hickey <hickey at kinetic-compute.com> wrote:
>
>
> On Aug 7, 2007, at 1:41 AM, Luki wrote:
>
> Does anyone know of a program/code out there for high volume voice
> broadcasting, the applications include high volume political calling,
> outbound surveys, emergency notifications, patient reminders, etc, etc.
> Looking for a program that can handle small volumes of calls, example 50
> to 200 calls for doctors offices to very large call volumes of
> 1,000,0000 calls per hour for mass messaging.
>
>
> For a project like this, a distributed solution would be ideal. You
> know, Google-style: lots of low-end machines, cheaper and redundancy
> included. With Asterisk you probably can't squeeze more than 250 calls
> even on a decent hardware, and for 1,000,000 calls per hour, say 2
> minutes in duration (with call setup), you need about 130 decent
> machines. Or like 300 low-end ones... so like 8 racks full.
>
> The code should be pretty simple (this setup is easily distributable).
> One beefy database server (or a small cluster for redundancy) can
> handle ~500-1000 queries/sec you'd need to sustain for 1,000,000 calls
> per hour.
>
>
> Yes, you definitely need to have a distributed solution to scale up to the
> 1M calls/hour, but the architecture is much more complex than you first
> might think it is.
> First you need to have a set of machines as directors to keep track of
> what machines have outdial capabilities. Using a director approach allows
> one to have better control of the systems and receive up to the minute
> reporting concerning the efficiency of the cluster of asterisk machines.
> Arguably you could reverse the solution and have the individual asteriskboxes query the database when it has capability to place a call, but it is
> easy to have two or more asterisk boxes attempting to dial the same
> number. You also have the problem of not detecting asterisk boxes that are
> not pulling their own weight as easily.
>
> The bigger problem is call scheduling. Your queueing system gets very
> complex very fast when you start servicing multiple clients with different
> requirements and different workloads. Lets take the examples from the first
> email: a doctor's office placing patient reminders and a political campaign.
> Everything is great when the system is processing the patient reminders
> because the system is lightly loaded. Then the political campaign starts and
> the system gets flooded with thousands of calls (seems to me that 1M calls
> is a bit much unless you are doing national political campaigns). As the
> campaign calls take over the system, one will find that without the proper
> queuing algorithms the patient reminders are now being placed 2 days after
> the appointments.
>
> Finally, blacklists and do not call lists need to be incorporated into the
> system. If  I remember correctly there are a number of federal regulations
> concerning automated calling that also need to be addressed in the system
> along with observing time of day restrictions for the destination number.
>
> All in all the solution gets pretty complex pretty fast. Unless you do a
> hack job, just don't care and have not problem treating your customers like
> dirt. Then you have it made.
> --
> Gerard Hickey                             Kinetic Compute Services
> hickey at kinetic-compute.com                694 Allen Ave.
> 207-318-5646                              Portland, ME   04103-3707
>
> Specializing in UNIX/Linux/Mac OSX solutions for business and education.
>      * ACSA certified and member of Apple Consultants Network
>
> Alternative contact methods:
>     Jabber: unixgeek at jabber.kinetic-compute.com
>     AIM:    unixgeek69
>     Skype:  unixgeek69
>
> All email messages are sent digitally signed with a X.509 key for
> authentication purposes. Messages not signed should be considered
> forgeries and discarded.
>


 At BTWTech we've developed such a distributed system originally for a large
telemarketing client, but we also now have some municipal alert and
political reference clients on it as well. It takes into account many of the
features that Gerard has correctly pointed out are challenges in operating
such a platform.

 Contact us at info at btwtech.com for more info.


-- 
Bird's The Word Technologies, Inc.
http://www.btwtech.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-biz/attachments/20070815/1cddeccd/attachment-0001.htm 


More information about the asterisk-biz mailing list