It is very rare to find businesses these days that do not have to reinvent themselves every few years. It is equally rare to find a business that can afford to replace its communi- cations infrastructure each time it goes in a new direction. Today’s businesses need extreme flexibility in all of their technology, including telecom.
In his book Crossing the Chasm (HarperBusiness), Geoffrey Moore opines, “The idea that the value of the system will be discovered rather than known at the time of instal- lation implies, in turn, that product flexibility and adaptability, as well as ongoing account service, should be critical components of any buyer’s evaluation checklist.” ‡More than 30 percent, at last count.
§The #asterisk-dev channel is for the discussion of changes to the underlying code base of Asterisk and is also
not second-tier support. Discussions related to programming external applications that interface with Asterisk via AGI or AMI are meant to be in #asterisk.
What this means, in part, is that the true value of a technology is often not known until it has been deployed.
How compelling, then, to have a system that holds at its very heart the concept of openness and the value of continuous innovation.
This Book
So where to begin? Well, when it comes to Asterisk, there is far more to talk about than we can fit into one book. For now, we’re not going to take you down all the roads that the über-geeks follow—we’re just going to give you the basics.
In Chapter 2, we cover some of the engineering considerations you should keep in mind when designing a telecommunications system. You can skip much of this material if you want to get right to installing, but these are important concepts to understand, should you ever plan on putting an Asterisk system into production.
Chapter 3 covers obtaining, compiling, and installing Asterisk, and Chapter 4 deals with the initial configuration of Asterisk. Here we cover the important configuration files that must exist to define the channels and features available to your system. This will prepare you for Chapter 5, where we introduce the heart of Asterisk—the dialplan. Chapter 6 will introduce some more advanced dialplan concepts.
We will take a break from Asterisk in Chapter 7 and discuss some of the more important technologies in use in the PSTN. Naturally, following the discussion of legacy telephony, Chapter 8 discusses Voice over IP.
Chapter 9 introduces one of the more amazing components, the Asterisk Gateway Interface (AGI). Using Perl, PHP, and Python, we demonstrate how external programs can be used to add nearly limitless functionality to your PBX. In Chapter 14, we briefly cover what is, in fact, a rich and varied cornucopia of incredible features and functions, all of which are part of the Asterisk phenomenon. To conclude, Chapter 15 looks for- ward, predicting a future where open source telephony completely transforms an industry desperately in need of a revolution. You’ll also find a wealth of reference in- formation in the book’s five appendixes.
This book can only lay down the basics, but from this foundation you will be able to come to an understanding of the concept of Asterisk—and from that, who knows what you will build?
CHAPTER 2
Preparing a System for Asterisk
Very early on, I knew that someday in some “perfect” future out there over the horizon, it would be common- place for computers to handle all of the necessary pro- cessing 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. If you are building a hobby system, you can probably jump right to the next chapter and begin the installation. 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.* However, to arm you with an understanding of the type of operating environment
Asterisk will really thrive in, this chapter 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 em- bedded, 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 pri- ority, 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, * 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.)
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 con- sideration during the platform selection process.
Table 2-1 lists some very basic guidelines that you’ll want to keep in mind when plan- ning your system. The next section takes a close look at the various design and implementation issues that will affect its performance.
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 2-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 distrib- uted 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 data- base 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 ex- tremely 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.
If you are sure that you need to set up a distributed Asterisk system, you will want to study the DUNDi protocol, Asterisk Realtime Architecture (ARA), func_odbc, and the various other database tools at your dispos- al. This will help you to abstract the data your system requires from the dialplan logic your Asterisk systems will utilize, allowing a generic set of dialplan logic that can be used across multiple boxes, thereby allow- ing 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 12.