Appendix C. Preparing a System for Asterisk

Table of Contents

Server Hardware Selection
Performance Issues
Choosing a Processor
Small systems
Medium systems
Large systems
Choosing a Motherboard
Power Supply Requirements
Computer power supplies
Redundant power supplies
Environment
Power Conditioning and Uninterruptible Power Supplies
Power-conditioned UPSs
Grounding
Electrical Circuits
The Equipment Room
Humidity
Temperature
Dust
Security
Telephony Hardware
Connecting to the PSTN
Analog interface cards
Digital interface cards
Channel banks
Other types of PSTN interfaces
Connecting Exclusively to a Packet-Based Telephone Network
Echo Cancellation
Types of Phones
Physical Telephones
Analog telephones
Proprietary digital telephones
ISDN telephones
IP telephones
Softphones
Telephony Adaptors
Communications Terminals
Linux Considerations
Conclusion

Very early on, I knew that someday in some “perfect” future out there over the horizon, it would be commonplace for computers to handle all of the necessary processing functionality internally, making the necessary external hardware to connect up to telecom interfaces very inexpensive and, in some cases, trivial.

Jim Dixon, “The History of Zapata Telephony and How It Relates to the Asterisk PBX”

By this point, you must be anxious to get your Asterisk system up and running. For a mission-critical deployment, however, some thought must be given to the environment in which the Asterisk system will run. Make no mistake: Asterisk, being a very flexible piece of software, will happily and successfully install on nearly any Linux platform you can conceive of, and several non-Linux platforms as well.[218] However, to arm you with an understanding of the type of operating environment Asterisk will really thrive in, this appendix will discuss issues you need to be aware of in order to deliver a reliable, well-designed system.

In terms of its resource requirements, Asterisk’s needs are similar to those of an embedded, real-time application. This is due in large part to its need to have priority access to the processor and system buses. It is, therefore, imperative that any functions on the system not directly related to the call-processing tasks of Asterisk be run at a low priority, if at all. On smaller systems and hobby systems, this might not be as much of an issue. However, on high-capacity systems, performance shortcomings will manifest as audio quality problems for users, often experienced as echo, static, and the like. The symptoms will resemble those experienced on a cell phone when going out of range, although the underlying causes will be different. As loads increase, the system will have increasing difficulty maintaining connections. For a PBX, such a situation is nothing short of disastrous, so careful attention to performance requirements is a critical consideration during the platform selection process.

Table C.1, “System requirement guidelines” lists some very basic guidelines that you’ll want to keep in mind when planning your system. The next section takes a close look at the various design and implementation issues that will affect its performance. Keep in mind that no guide can tell you exactly how many calls a server can handle. There are an incredibly high number of variables that can affect the answer to the question of how many calls Asterisk can handle. The only way to figure out how many calls a server can handle is to test it yourself in your own environment.

Note

The size of an Asterisk system is actually not dictated by the number of users or sets, but rather by the number of simultaneous calls it will be expected to support. These numbers are very conservative, so feel free to experiment and see what works for you.

Table C.1. System requirement guidelines

Purpose

Number of channels

Minimum recommended

Hobby system

No more than 5

400-MHz x86, 256 MB RAM

SOHO system (small office/home office—less than three lines and five sets)

5 to 10

1-GHz x86, 512 MB RAM

Small business system

Up to 25

3-GHz x86, 1 GB RAM

Medium to large system

More than 25

Dual CPUs, possibly also multiple servers in a distributed architecture


With large Asterisk installations, it is common to deploy functionality across several servers. One or more central units will be dedicated to call processing; these will be complemented by one or more ancillary servers handling peripherals (such as a database system, a voicemail system, a conferencing system, a management system, a web interface, a firewall, and so on). As is true in most Linux environments, Asterisk is well suited to growing with your needs: a small system that used to be able to handle all your call-processing and peripheral tasks can be distributed among several servers when increased demands exceed its abilities. Flexibility is a key reason why Asterisk is extremely cost-effective for rapidly growing businesses; there is no effective maximum or minimum size to consider when budgeting the initial purchase. While some scalability is possible with most telephone systems, we have yet to hear of one that can scale as flexibly as Asterisk. Having said that, distributed Asterisk systems are not simple to design—this is not a task for someone new to Asterisk.

Note

If you are sure that you need to set up a distributed Asterisk system, you will want to study the DUNDi protocol, the Asterisk Realtime Architecture (ARA), func_odbc, and the various other database tools at your disposal. This will help you to abstract the data your system requires from the dialplan logic your Asterisk systems will utilize, creating a generic set of dialplan logic that can be used across multiple boxes. This in turn will enable you to scale more simply by adding additional boxes to the system. However, this is far beyond the scope of this book and will be left as an exercise for the reader. If you want a teaser of some tools you can use for scaling, see Chapter 22, Clustering.



[218] People have successfully compiled and run Asterisk on WRAP boards, Linksys WRT54G routers, Soekris systems, Pentium 100s, PDAs, Apple Macs, Sun SPARCs, laptops, and more. Of course, whether you would want to put such a system into production is another matter entirely. (Actually, the AstLinux distribution, by Kristian Kielhofner, runs very well indeed on the Soekris 4801 board. Once you’ve grasped the basics of Asterisk, this is something worth looking into further. Check out http://www.astlinux.org.)