When large amounts of people need to be notified about a particular event, the “telephone chain” was used to distribute messages in a uniform manner. I call three people, they each call three people, and so on, and so on.
This worked well, as each individual received a single call, and then had to make three calls themselves. Very quickly a large group of people would be notified, however there was the possibility that the message integrity not be retained as it was passed along from person to person.
As technology came into play, Intelligent Voice Response or IVR units were reversed, and instead of receiving calls, they would make calls. It wasn’t long before this technology was used for mass call notification events by large corporations, school districts as well as government and public safety agencies.
Although these are widely available, there has always been a question on their effectiveness. It seems that there was a common thread coming from those customers who started to investigate deployment, but then quickly stopped.
It all comes down to throughput. Let’s take a common example, and look at the numbers to see where the problem lies.
I have a 45 second long message to deliver to 10,000 people.
I would like this done in a matter of 15 minutes.
Sounds like a reasonable request, right?
To do the math, we need all of the variables. One that is most commonly forgotten his call setup time. Although this is usually only 1 or 2 seconds, multiplying that by 10,000 makes this a significant number. So significant, that it adds up to almost 5.5 HOURS of trunk usage by itself!
Even MORE alarming is the ‘ring cycle’ factor. Each ring-cycle in the United States is a total of 6 seconds. 2 seconds of ringing followed by 4 seconds of silence. Based on this, and assuming that the average call pickup time is 2 1/2 rings, then in addition to the two seconds of setup time, you have an average of 17 seconds of call setup time on each one of the call attempts. We will use this as an average, as while some people may pick up after the first ring, other calls will go to voicemail or answering machines and be much, much longer. This also doesn’t take into consideration busy signals, and disconnected numbers that are on the list erroneously.
17 seconds of call setup time over 10,000 call attempts to subscribers equates to 47.22 hours of trunk usage, and we haven’t even gotten to the message yet.
A 45 second message now becomes a one minute message, and although that doesn’t seem like a big increase, when you calculate that out over 10,000 subscriber call attempts, it becomes a very significant number.
But we’re not done with the calculator. The other part of the equation, that most people forget, is “how fast must this task be accomplished?”. Let’s do the math to see what this will take:
10,000 1 minute phone calls (600,000 seconds of content) that needs to be delivered in 900 seconds (15 minutes)
Using normal Erlang tables used to calculate trunking capacities, each individual trunk can carry 3600 seconds of content each hour.
600,000 seconds of content divided by 900 seconds of available trunk ‘bandwidth’ will require 667 individual trunks to accomplish the delivery of these messages in the allotted time. That works out to nearly 30 digital PRI T1 circuits, or a little more than what 1 DS-3 High Speed MUX can deliver.
You can quickly see that, in addition to the cost of the system, the monthly trunking requirements are financially not feasible. Despite this fact, this kind of call volume into a single central office could cause severe congestion. Delivering this content over SIP trunks, may alleviate the problem at the local central office, but that is still a massive call event that has to eventually egress into the public switched telephone network.
Some will argue that sharing this type of service or going to a service bureau may be an effective way to handle communications surges like this. The only problem there, is what if the service Bureau needs to deal with multiple customer emergencies at the same time.
To me, it seems like this is a continuous battle that is not easily won. For those reasons, mass call notification makes more sense when the notification is packetized and then transmitted via the ethernet.