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

Michael Kaspar mikek at blzwire.com
Wed Aug 15 11:14:09 CDT 2007


www.noblesys.com

 

  _____  

From: asterisk-biz-bounces at lists.digium.com
[mailto:asterisk-biz-bounces at lists.digium.com] On Behalf Of BJ Weschke
Sent: Wednesday, August 15, 2007 8:53 AM
To: Commercial and Business-Oriented Asterisk Discussion
Subject: Re: [asterisk-biz] Outbound Messaging, Voice Broadcasting, Alerts,

 

  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 asterisk boxes 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

 <mailto:hickey at kinetic-compute.com> hickey at kinetic-compute.com
694 Allen Ave.

  <chrome://skype_ff_toolbar_win/content/cb_transparent_l.gif>
<chrome://skype_ff_toolbar_win/content/famfamfam/us.gif>
<chrome://skype_ff_toolbar_win/content/space.gif>
<chrome://skype_ff_toolbar_win/content/space.gif>
<chrome://skype_ff_toolbar_win/content/arrow.gif>
<chrome://skype_ff_toolbar_win/content/space.gif>
<chrome://skype_ff_toolbar_win/content/space.gif>
<chrome://skype_ff_toolbar_win/content/space.gif>
<chrome://skype_ff_toolbar_win/content/space.gif>
<chrome://skype_ff_toolbar_win/content/space.gif>
<chrome://skype_ff_toolbar_win/content/space.gif>
<chrome://skype_ff_toolbar_win/content/space.gif> 207-318-5646
<chrome://skype_ff_toolbar_win/content/cb_transparent_r.gif>
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:  <mailto:unixgeek at jabber.kinetic-compute.com>
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/  <http://www.btwtech.com/> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-biz/attachments/20070815/d847e6b7/attachment.htm 


More information about the asterisk-biz mailing list