At 11:44 AM 5/16/2008, you wrote: >Yes, you could probably add 2 or 3 or 10 or 15 to the number of calls >that a particular machine could handle, but from a support perspective, it >doesn't matter how many the machine could theoretically handle, it matters >how many it could handle in the particular installation in a supportable >configuration (those are all those pesky variables we've been talking about).
Absolutely! Right On! Tell it like it is! And many other cryptic encouragements. With very large scale deployments, I have a set of numbers available in my head that work well to predict how many machines will be needed for a particular application but I wind up being surprised by non-predictable "rate of arrival" issues. Since most of my deployments are tied with Television and other promotional support, a single reference by the on-screen (or on-radio) commentator, and the phones are instantly flooded with thousands of new call setup requests. Indeed, one such incident in a NASCAR race with 13M viewers, produced 18,000 new calls within two minutes. The rate of arrival of new calls was dispersed to a farm of 60 Asterisk in three widely separated regions of the US. However, approximately 15,000 calls were actually dropped on the PSTN / SS7 network before ever reaching three dispersed Asterisk farms. Those farms were being "fed" inbound calls by a network of 250+ Nortel switches with millions of subscribers. However, the Los Angeles area PSTN network access facility had only 900 spare channels available in that two minute period. Meanwhile, every asterisk answered every call and joint the callers into appropriate conference groups until every single available port was fully occupied. This illustrates that such issues of call capacity exist completely apart from the Asterisk or whatever machine is used for implementation. So everyone should not be surprised by "it depends" kinds of answers to the question of concurrent call counts. This application was so far off the typical product specifications that nothing published by Digium or anyone else could anticipate those surprises that come when you least expect. ..mike.. _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
