Asterisk: The Future of Telephony

Content preview·Buy reprint rights for this chapter

It does not require a majority to prevail,
but rather an irate, tireless minority
keen to set brush fires in people's minds.

—Samuel Adams

An incredible revolution is under way. It has been a long time in coming, but now that it has started, there will be no stopping it. It is taking place in an area of technology that has lapsed embarrassingly far behind every other industry that calls itself high-tech. The industry is telecommunications, and the revolution is being fueled by an open source Private Branch eXchange (PBX) called Asterisk ^TM.

Telecommunications is arguably the last major electronics industry that has (until now) remained untouched by the open source revolution. Major telecommunications manufacturers still build ridiculously expensive, incompatible systems, running complicated, ancient code on impressively engineered yet obsolete hardware.

As an example, Nortel's Business Communications Manager kludges together a Windows NT 4.0 server, a 15-year-old VXWorks-based Key Telephone Switch, and a 700-MHz PC. All this can be yours for between 5 and 15 thousand dollars, not including telephones. If you want it to actually do anything interesting, you'll have to pay extra licensing fees for closed, limited-functionality, shrink-wrapped applications. Customization? Forget it—it's not in the plan. Future technology and standards compliance? Give them a year or two—they're working on it.

All of the major telecommunications manufacturers offer similar-minded products. They don't want you to have flexibility or choice; they want you to be locked in to their product cycles.

Asterisk changes all that. With Asterisk, no one is telling you how your phone system works, or what technology you are limited to. If you want it, you can have it. Asterisk lovingly embraces the concept of standards compliance, while also enjoying the freedom to develop its own innovations. What you choose to implement is up to you-Asterisk imposes no limits.

Naturally, this incredible flexibility comes with a price: Asterisk is not a simple system to configure. This is not because it's illogical, confusing, or cryptic; to the contrary, it is very sensible and practical. People's eyes light up when they first see an Asterisk dialplan and begin to contemplate the possibilities. But when there are literally thousands of ways to achieve a result, the process naturally requires extra effort. Perhaps it can be compared to building a house: the components are relatively easy to understand, but a person contemplating such a task must either a) enlist competent help or b) develop the required skills through instruction, practice, and a good book on the subject.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

While Voice over IP (VoIP) is often thought of as little more than a method of obtaining free long-distance calling, the real value (and—let's be honest—challenge as well) of VoIP is that it allows voice to become nothing more than another application in the data network.

It sometimes seems that we've forgotten that the purpose of the telephone is to allow people to communicate. It is a simple goal, really, and it should be possible for us to make it happen in far more flexible and creative ways than are currently available to us. Since the industry has demonstrated an unwillingness to pursue this goal, a large community of passionate people have taken on the task.

The challenge comes from the fact that an industry that has changed very little in the last century shows little interest in starting now.

The Zapata Telephony Project was conceived of by Jim Dixon, a telecommunications consulting engineer who was inspired by the incredible advances in CPU speeds that the computer industry has now come to take for granted. Dixon's belief was that far more economical telephony systems could be created if a card existed that had nothing more on it than the basic electronic components required to interface with a telephone circuit. Rather than having expensive components on the card, Digital Signal Processing (DSP) would be handled in the CPU by software. While this would impose a tremendous load on the CPU, Dixon was certain that the low cost of CPUs relative to their performance made them far more attractive than expensive DSPs, and, more importantly, that this price/performance ratio would continue to improve as CPUs continued to increase in power.

Like so many visionaries, Dixon believed that many others would see this opportunity, and that he merely had to wait for someone else to create what to him was an obvious improvement. After a few years, he noticed that not only had no one created these cards, but it seemed unlikely that anyone was ever going to. At that point it was clear that if he wanted a revolution, he was going to have to start it himself. And so the Zapata Telephony Project was born.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The most successful key telephone system in the world has a design limitation that has survived 15 years of users begging for what appears to be a simple change: when you determine the number of times your phone will ring before it forwards to voicemail, you can choose from 2, 3, 4, 6, or 10 ring cycles. Have you any idea how many times people ask for five rings? Yet the manufacturers absolutely cannot get their heads around the idea that this is a problem. That's the way it works, they say, and users need to get over it.

That's just one example—the industry is rife with them.

Another example from the same system is that the name you program on your set can only be seven characters in length. Back in the late 1980s, when this particular system was built, RAM was pretty dear, and storing those seven characters for dozens of sets represented a huge hardware expense. So what's the excuse today? None. Are there any plans to change it? Hardly—the issue is not even officially acknowledged as a problem.

Now, it's all very well and good to pick on one system, but the reality is that every PBX in existence suffers shortcomings. No matter how fully featured it is, something will always be left out, because even the most feature-rich PBX will always fail to anticipate the creativity of the customer. A small group of users will desire an odd little feature that the design team either did not think of or could not justify the cost of building, and, since the system is closed, the users will not be able to build it themselves.

If the Internet had been thusly hampered by regulation and commercial interests, it is doubtful that it would have developed the wide acceptance it currently enjoys. The openness of the Internet meant that anyone could afford to get involved. So, everyone did. The tens of thousands of minds that collaborated on the creation of the Internet delivered something that no corporation ever could have.

As with many other open source projects, such as Linux and the Internet, the explosion of Asterisk was fueled by the dreams of folks who knew that there had to be something more than what the industry was producing. The strength of the community is that it is composed not of employees assigned to specific tasks, but rather of folks from all sorts of industries, with all sorts of experiences, and all sorts of ideas about what flexibility means, and what openness means. These people knew that if one could take the best parts of various PBXs and separate them into interconnecting components—akin to a boxful of LEGO bricks—one could begin to conceive of things that would not survive a traditional corporate risk-analysis process. While no one can seriously claim to have a complete picture of what this thing should look like, there is no shortage of opinions and ideas.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Telecommunications companies who choose to ignore Asterisk do so at their peril. The flexibility it delivers creates possibilities that the best proprietary systems can scarcely dream of. This is because Asterisk is the ultimate hacker's PBX .

If someone asks you not to use the term hacker, refuse. That term does not belong to the mass media. They stole it and corrupted it to mean "malicious cracker." It's time we took it back. Hackers built the networking engine that is the Internet. Hackers built the Apple Macintosh and the Unix operating system. Hackers are also building your next telecom system. Do not fear; these are the good guys, and they'll be able to build a system that's far more secure than anything that exists today, because rather than being constricted by the dubious and easily cracked security of closed systems, they will be able to quickly respond to changing trends in security and fine-tune the telephone system in response to both corporate policy and industry best practices.

Like other open source systems, Asterisk will be able to evolve into a far more secure platform than any proprietary system, not in spite of its hacker roots, but rather because of them.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Never in the history of telecommunications has a system so suited to the needs of business been available, at any price. Asterisk is an enabling technology, and, as with Linux, it will become increasingly rare to find an enterprise that is not running some version of Asterisk, in some capacity, somewhere in the network, solving a problem as only Asterisk can.

This acceptance is likely to happen much faster than it did with Linux, though, for several reasons:

Linux has already blazed the trail that led to open source acceptance, so Asterisk can follow that lead.
The telecom industry is crippled, with no leadership being provided by the giant industry players. Asterisk has a compelling, realistic, and exciting vision.
End users are fed up with incompatible, limited functionality, and horrible support. Asterisk solves the first two problems; the community has shown a passion for the latter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

One of the compelling strengths of Asterisk is the passionate community that developed and supports it. This community, led by Mark Spencer of Digium, is keenly aware of the cultural significance of Asterisk, and they are giddy about the future.

One of the more powerful side effects caused by the energy of the Asterisk community is the cooperation it has spawned among the telecommunications professionals, networking professionals, and information technology professionals who share a love for this phenomenon. While these professions have traditionally been at odds with each other, in the Asterisk community they delight in each other's skills. The significance of this cooperation cannot be underestimated.

Still, if the dream of Asterisk is to be realized, the community must grow—yet one of the key challenges the community currently faces is a rapid influx of new users. The members of the existing community, having birthed this thing called Asterisk, are generally welcoming of new users, but they've grown impatient with being asked the kinds of questions whose answers can often be obtained independently, if one is willing to put forth the time needed to research and experiment.

Obviously, new users do not fit any particular kind of mold. While some will happily spend hours experimenting and reading various blogs describing the trials and tribulations of others, many people who have become enthusiastic about this technology are completely uninterested in such pursuits. They want a simple, straightforward, step-by-step guide that'll get them up and running, followed by some sensible examples describing the best methods of implementing common functionality (such as voicemail, auto attendants, and the like).

To the members of the expert community, who (correctly) perceive that Asterisk is like a programming language, this approach doesn't make any sense. To them, it's clear that you have to immerse yourself in Asterisk to appreciate its subtleties. Would one ask for a step-by-step guide to programming and expect to learn from it all that a language has to offer?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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 communications 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 installation implies, in turn, that product flexibility and adaptability, as well as ongoing account service, should be critical components of any buyer's evaluation checklist." 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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 have 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. Having covered dialplan basics, Chapter 6 introduces 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 10, 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 11 looks forward, 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 information 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?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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. 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 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The selection of a server is both simple and complicated: simple because, really, any x86-based platform will suffice; but complicated because the reliable performance of your system will depend on the care that is put into the platform design. When selecting your hardware, you must carefully consider the overall design of your system and what functionality you need to support. This will help you determine your requirements for the CPU, motherboard, and power supply. If you are simply setting up your first Asterisk system for the purpose of learning, you can safely ignore the information in this section. If, however, you are building a mission-critical system suitable for deployment, these are issues that require some thought.

Among other considerations, when selecting the hardware for an Asterisk installation you must bear in mind this critical question: how powerful must the system be? This is not an easy question to answer, because the manner in which the system is to be used will play a big role in the resources it will consume. There is no such thing as an Asterisk performance-engineering matrix, so you will need to understand how Asterisk uses the system in order to make intelligent decisions about what kinds of resources will be required. You will need to consider several factors, including:

The maximum number of concurrent connections the system will be expected to support: Each connection will increase the workload on the system.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Your system's environment consists of all those factors that are not actually part of the server itself, but nevertheless play a crucial role in the reliability and quality that can be expected from the system. Electrical supplies, room temperature and humidity, sources of interference, and security are all factors that should be contemplated.

When selecting the power sources for your system, consideration should be given not only to the amount of power the system will use, but also to the manner in which that power is delivered.

Power is not as simple as voltage coming from the outlet in the wall, and you should never just plug a production system into whatever electrical source is near at hand. Giving some consideration to the supply of power to your system can provide a far more stable power environment, leading to a far more stable system.

Properly grounded, conditioned power feeding a premium-quality power supply will ensure a clean logic ground (a.k.a. 0-volt) reference for the system and keep electrical noise on the motherboard to a minimum. These are industry-standard best practices for this type of equipment, which should not be neglected. A relatively simple way to achieve this is through the use of a power-conditioned UPS.

Section 2.2.1.1: Power-conditioned UPSs

The UPS is well known for its role as a battery backup, but the power-conditioning benefits that high-end UPS units also provide are less well understood.

Power conditioning can provide a valuable level of protection from the electrical environment by regenerating clean power through an isolation transformer. A quality power conditioner in your UPS will eliminate most electrical noise from the power feed and help to ensure a rock-steady supply of power to your system.

Unfortunately, not all UPS units are created equal; many of the less expensive units do not provide clean power. What's worse, manufacturers of these devices will often promise all kinds of protection from surges, spikes, overvoltages, and transients. While such devices may protect your system from getting fried in an electrical storm, they will not clean up the power being fed to your system, and thus will do nothing to contribute to stability.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you are going to connect Asterisk to any legacy telecommunications equipment, you will need the correct hardware . The hardware you require will be determined by what it is you want to achieve.

Asterisk allows you to seamlessly bridge circuit-switched telecommunications networks with packet-switched data networks. Because of Asterisk's open architecture (and open source code), it is ultimately possible to connect any standards-compliant interface hardware. The selection of open source telephony interface boards is currently limited, but as interest in Asterisk grows, that will rapidly change. At the moment, one of the most popular and cost-effective ways to connect to the PSTN is to use the interface cards that evolved from the work of the Zapata Telephony Project (http://www.zapatatelephony.org).

Section 2.3.1.1: Analog interface cards

Unless you need a lot of channels (or a have lot of money to spend each month on telecommunications facilities), chances are that your PSTN interface will consist of one or more analog circuits, each of which will require a Foreign eXchange Office (FXO) port.

Digium, the company that sponsors Asterisk development, produces the most popular analog interface card for Asterisk , known as the TDM400P. The TDM400P is a four-port base card that allows for the insertion of up to four daughter cards, which deliver either FXO or Foreign eXchange Station (FXS) ports. The TDM400P can be purchased with these cards preinstalled, and Digium has designated part numbers to describe these configurations. The naming convention is TDM x y B, where x and y are numbers representing the quantity of FXS and FXO cards on the board, respectively. Check out Digium's web site (http://www.digium.com) for more information about this card.

An older card produced by Digium was known as the X100P. It is no longer available from Digium, but you may be able to find a clone of this card.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Since the title of this book is Asterisk: The Future of Telephony, we would be remiss if we didn't discuss the devices that all of this technology ultimately has to interconnect: telephones !

We all know what a telephone is—but will it be the same five years from now? Part of the revolution that Asterisk is contributing to is the evolution of the telephone, from a simple audio communications device into a multimedia communications terminal providing all kinds of yet-to-be-imagined functions.

As an introduction to this exciting concept, we will briefly discuss the various kinds of devices we currently call "telephones" (any of which can easily be integrated with Asterisk). We will also discuss some ideas about what these devices may evolve into in the future (devices that will also easily integrate with Asterisk).

Any physical device whose primary purpose is terminating an on-demand audio communications circuit between two points can be classified as a physical telephone. At a minimum, such a device has a handset and a dial pad; it may also have feature keys, a display screen, and various audio interfaces.

This section takes a brief look at the various user (or endpoint) devices you might want to connect to your Asterisk system. We'll delve more deeply into the mechanics of analog and digital telephony in Chapter 7.

Section 2.4.1.1: Analog telephones

Analog phones have been around since the invention of the telephone. Up until about 20 years ago, all telephones were analog. Although analog phones have some technical differences in different countries, they all operate on similar principles.

When a human being speaks, the vocal cords, tongue, teeth, and lips create a complex variety of sounds. The purpose of the telephone is to capture these sounds and convert them into a format suitable for transmission over wires. In an analog telephone, the transmitted signal is

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you ask anyone at the Free Software Foundation, they will tell you that what we know as Linux is in fact GNU/Linux . All etymological arguments aside, there is some valuable truth to this statement. While the kernel of the operating system is indeed Linux, the vast majority of the utilities installed on a Linux system and used regularly are in fact GNU utilities. "Linux" is probably only 5% Linux, possibly 75% GNU, and perhaps 20% everything else.

Why does this matter? Well, the flexibility of Linux is both a blessing and a curse. It is a blessing because with Linux you can truly craft your very own operating system from scratch. Since very few people ever do this, the curse is in large part due to the responsibility you must bear in determining which of the GNU utilities to install, and how to configure the system.

If this seems overwhelming, do not fear. In the next chapter, we will discuss the selection, installation, and configuration of the software environment for your Asterisk system.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In this chapter, we've discussed all manner of issues that can contribute to the stability and quality of an Asterisk installation. Before we scare you off, we should tell you that many people have installed Asterisk on top of a graphical Linux workstation, running a web server, a database, an X-windowing environment, and who knows what else, with no problems whatsoever. How much time and effort you should devote to following the best practices and engineering tips in this chapter all depends on how much work you expect the Asterisk server to perform, and how much quality and reliability your system must provide.

What we have attempted to do in this chapter is give you a feel for the kinds of best practices that will help to ensure that your Asterisk system will be built on a reliable, stable platform. Asterisk is quite willing to operate under far worse conditions, but the amount of effort and consideration you decide to give these matters will play a part in the stability of your PBX. Your decision should depend on how critical your Asterisk system will be.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

I long to accomplish great and noble tasks, but it is my
chief duty to accomplish humble tasks as though they
were great and noble. The world is moved along, not
only by the mighty shoves of its heroes, but also by the
aggregate of the tiny pushes of each honest worker.

—Helen Keller

In the previous chapter, we discussed preparing a system to install Asterisk. Now it's time to obtain, extract, compile, and install the software.

Although a large number of Linux distributions and PC architectures are excellent candidates for Asterisk, we have chosen to focus on a single distribution in order to maintain brevity and clarity throughout the book. The instructions that follow have been made as generic as possible, but you may notice a leaning toward Red Hat structures and utilities. We have chosen to focus on Red Hat because its command set, directory structure, and so forth are likely to be familiar to the majority of users (we have found that most Linux administrators are familiar with Red Hat, even if they don't prefer it). However, this doesn't mean that Red Hat is the only choice, or even the best one for you. A question that often appears on the mailing lists is: "Which distribution of Linux is the best to use with Asterisk?" The multitude of answers generally boils down to "the one you like the best."

Asterisk uses three main packages : the main Asterisk program (asterisk), the Zapata telephony drivers (zaptel), and the PRI libraries (libpri). If you plan on a pure VoIP network, the only real requirement is the asterisk package. The zaptel drivers are required if you are using analog or digital hardware, or if you're using the ztdummy driver (discussed later in this chapter) as a timing interface. The libpri library is technically optional unless you're using ISDN PRI interfaces, and you may save a small amount of RAM if you don't load it, but we recommend that it be installed in conjunction with the zaptel

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Asterisk uses three main packages : the main Asterisk program (asterisk), the Zapata telephony drivers (zaptel), and the PRI libraries (libpri). If you plan on a pure VoIP network, the only real requirement is the asterisk package. The zaptel drivers are required if you are using analog or digital hardware, or if you're using the ztdummy driver (discussed later in this chapter) as a timing interface. The libpri library is technically optional unless you're using ISDN PRI interfaces, and you may save a small amount of RAM if you don't load it, but we recommend that it be installed in conjunction with the zaptel package for completeness.

One other package you may want to install is asterisk-sounds. While Asterisk comes with many sound prompts in the main source distribution, the asterisk-sounds package will give you even more. If you would like to expand the number of professionally recorded prompts for use with your Asterisk system, this package is essential. Some of our examples in the following chapters will make use of files included in this package, so we will assume that you have it installed.

To compile Asterisk, you must install the GCC compiler (Version 3.x or later) and its dependencies. While Version 2.96 of GCC may work for the time being, future versions will not support it. Asterisk also requires bison, a parser generator program that replaces yacc, and ncurses for CLI functionality. The cryptographic library in Asterisk requires OpenSSL and its development packages. If you want to use ztdummy for timing, or any of the hardware drivers provided by Zaptel, you'll need to install the zaptel package as well. If you are installing libpri, be sure to install it before asterisk (see "Compiling libpri").

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Asterisk source code can be obtained either through FTP or CVS. We will show you how to acquire the source with both methods, although you only need to use one of them to retrieve the packages (FTP is the preferred method).

The Asterisk source code can be obtained from the Digium FTP server, located at ftp://ftp.digium.com. The easiest way to obtain the stable release is through the use of the program wget.

Asterisk comes in two different flavors, generally referred to as stable and head. Stable, as the name implies, is the established branch of Asterisk for use in production systems. The head branch is what the developers use to test new features and bug fixes .

Bug fixes (not features) are merged over to the stable branch after a reasonable period of testing. It is entirely possible that the development branch may be broken at certain points during testing; thus, the stable branch is what you will want to run your production system on, and it is what we will be using throughout this book.

You can obtain stable releases via FTP. Both the stable and head branches of Asterisk can also be obtained from CVS, as explained later in this chapter. However, it is important to note the difference between releases and CVS. Releases are snapshots from the stable CVS tree, tagged with a version number and released via the FTP server when a new stable release is deemed ready. Note that the stable CVS branch is not a release—it's a work in a progress, and it may be buggy (i.e., not so stable after all). The FTP tarballs are the actual releases.

To summarize, use only stable releases obtained via the FTP server for production systems.

Note that we will be making use of the /usr/src/ directory to extract and compile the Asterisk source. Also be aware that you will need root access to write files to the /usr/src/ directory and to install Asterisk and its associated packages.

To obtain the latest stable source code via

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Figure 3-1 shows the layers of interaction between Asterisk and the Linux kernel with respect to hardware control. On the Asterisk side is the Zapata channel module, chan_zap. Asterisk uses this interface to communicate with the Linux kernel, where the drivers for the hardware are loaded.

Figure 3-1: Layers of device interaction with Asterisk

The Zaptel interface is a kernel loadable module that presents an abstraction layer between the hardware drivers and the Zapata module in Asterisk. It is this concept that allows the device drivers to be modified without any changes being made to the Asterisk source itself. The device drivers are used to communicate with the hardware directly and to pass the information between Zaptel and the hardware.

While Asterisk itself compiles on a variety of platforms, the Zaptel drivers are Linux-specific—they are written to interface directly with the Linux kernel. There are no official Zaptel drivers for other operating systems, although work has been going on to write drivers for FreeBSD.

We will discuss the Zaptel compile-time options momentarily, in "The zconfig.h File." First, let's take a look at compiling and installing the drivers. (The configuration of Zaptel drivers will be discussed in the next chapter.)

Before compiling the Zaptel drivers on a system running a Linux 2.4 kernel , you should verify that /usr/src/ contains a symbolic link named linux-2.4 pointing to your kernel source. If the symbolic link doesn't exist, you can create it with the following command (assuming you've installed the source in /usr/src/):

    # ln -s /usr/src/'uname -r' /usr/src/linux-2.4

Computers running Linux 2.6 kernel-based distributions do not usually require the use of the symbolic link, as these distributions will search for the kernel build directory automatically. However, if you've placed the build directory in a nonstandard place (i.e., somewhere other than

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Compiling and installing libpri follows the same pattern as described above for zaptel. libpri is used by various makers of Time Division Multiplexing (TDM) hardware , but even if you don't have the hardware installed it is safe to compile and install this library. You must compile and install libpri before Asterisk , as it will be detected and used when Asterisk is compiled. Here are the commands (replace version with your version of libpri):

    # cd /usr/src/libpri-version
            
    # make clean
    # make
    # make install

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Once you've compiled and installed the zaptel and libpri packages (if you need them), you can move on to Asterisk. This section walks you through a standard installation and introduces some of the alternative make arguments that you may find useful. We'll also look at how you can edit the Makefile to optimize the compilation of Asterisk.

Asterisk is compiled with gcc through the use of the GNU make program. Unlike many other programs, there is no need to run a configuration script for Asterisk. To get started compiling Asterisk, simply run the following commands (replace version with your version of Asterisk):

    # cd /usr/src/asterisk-version
               
    # make clean
    # make
    # make install
    # make samples

Be aware that compile times will vary between systems. On a current-generation processor, you shouldn't need to wait more than five minutes. At Astricon, someone reported successfully compiling Asterisk on a 133-MHz Pentium, but it took approximately five hours. You do the math.

Run the make samples command to install the default configuration files. Installing these files (instead of configuring each file manually) will allow you to get your Asterisk system up and running much faster. Many of the default values are fine for Asterisk. Files that require editing will be explained in future chapters.

If you already have configuration files installed in /etc/asterisk/ when you run the make samples command, .old will be appended to the end of each of your current configuration files—for example, extensions.conf will be renamed extensions.conf.old. Be careful, though, because if you run make samples more than once you will overwrite your original configuration files!

The sample configuration files can also be found in the configs/ subdirectory within your Asterisk sources directory.

If you're using a system that makes use of the /etc/rc.d/init.d/ or /etc/init.d/ directories, you may wish to run the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The asterisk-sounds package contains many useful professionally recorded prompts. It is highly recommended that you install it now, as we will be using some of the prompts from this package in later chapters. To do so, run the following commands:

    # cd /usr/src/asterisk-sounds
    # make install

The asterisk-addons package contains code to allow the storage of Call Detail Records (CDRs) to a MySQL database and to natively play MP3s, as well as an interpreter for loading Perl code into memory for the life of an Asterisk process. Programs are placed into asterisk-addons when there are licensing issues preventing them from being implemented directly into the Asterisk source code, or when they are not yet ready for primetime.

The g729/ directory contains the code and registration program for the proprietary G.729 codec . Even if your end devices have the G.729 codec installed, in order to allow the phones to communicate with Asterisk using G.729 (e.g., in voicemail or to allow attended transfers), you must purchase a license. Licenses for the codec can be purchased online from Digium and activated with the registration program contained in the g729/ directory.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Instead of deleting the sources and downloading the entire tree every time you want to update, you can update just the files that have changed since the last revision. To do this, change into the directory containing the files you want to update and run the make update command:


    # cd /usr/src/asterisk/
    # make update
    # make clean
    # make upgrade

Note that this will work only with code obtained via the CVS method (see "make update," earlier in this chapter). The make upgrade command is used only in the Asterisk source directory. In other directories, use make install.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

There are many common compiling issues that users often run into. Here are some of the more common problems, and how to resolve them.

First, let's take a look at some of the errors you may encounter when compiling Asterisk.

Section 3.8.1.1: C compiler cannot create executables

If you receive the following error while attempting to compile Asterisk, you must install the gcc compiler and its dependencies:

    checking whether the C compiler (gcc ) works... no
    configure: error: installation or configuration problem: C compiler cannot
    create executables.
    make: *** [editline/libedit.a] Error 1

The following packages are required for gcc:

gcc
glibc-kernheaders
cpp
binutils
glibc-headers
glibc-devel

These can be installed manually, by copying the files off of your distribution disks, or through the yum package manager, with the command yum install gcc.

Section 3.8.1.2: bison: command not found

The following error may be encountered if the bison parser, which is required for parsing expressions in the extensions.conf file, is not found:

    bison ast_expr.y -name-prefix=ast_yy -o ast_expr.c
    make: bison: Command not found
    make: *** [ast_expr.c] Error 127

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In this section, we'll take a quick look at how to load the zaptel and ztdummy modules. The zaptel module does not require any configuration if it's being used only for the ztdummy module. If you plan on loading the ztdummy module as your timing source (and thus, you will not be running any PCI hardware in your system), now is a good time to load both drivers.

In the early days of Linux, the system's /dev/ directory was populated with a list of devices with which the system could potentially interact. At the time, nearly 18,000 devices were listed. That all changed when devfs was released, allowing dynamic creation of devices that are active within the system. Some of the recently released distributions have incorporated the udev daemon into their systems to dynamically populate /dev/ with device nodes.

To allow Zaptel and other device drivers to access the PCI hardware installed in your system, you must add some rules. Using your favorite text editor, open up your udevd rules file. On Fedora Core 3, for example, this file is located at /etc/udev/rules.d/50-udev.rules. Add the following lines to the end of your rules file:

    # Section for zaptel 
 
 device
    KERNEL="zapctl",     NAME="zap/ctl"
    KERNEL="zaptimer",   NAME="zap/timer"
    KERNEL="zapchannel", NAME="zap/channel"
    KERNEL="zappseudo",  NAME="zap/pseudo"
    KERNEL="zap[0-9]*",  NAME="zap/%n"

Save the file and reboot your system for the settings to take effect.

The zaptel module must be loaded before any of the other modules are loaded and used. Note that if you will be using the zaptel module with PCI hardware, you must configure /etc/zaptel.conf before you load it. (We will discuss how to configure zaptel.conf for use with hardware in Chapter 4.) If you are using zaptel only to access ztdummy , you can load it with the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The libpri libraries do not need to be loaded like modules. Asterisk looks for libpri at compile time and configures itself to use the libraries if they are found.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Asterisk can be loaded in a variety of ways. The easiest way is to start Asterisk by running the binary file directly from the Linux command-line interface. If you are running a system that uses the init.d scripts, you can easily start and restart Asterisk that way as well. However, the preferred way of starting Asterisk is via the safe_asterisk script.

The Asterisk binary is, by default, located at /usr/sbin/asterisk. If you run /usr/sbin/asterisk, it will be loaded as a daemon. There are also a few switches you should be aware of that allow you to (re)connect to the Asterisk CLI, set the verbosity of CLI output, and allow core dumps if Asterisk crashes (for debugging with gdb). To explore the full range of options, run Asterisk with the -h switch:

    # /usr/sbin/asterisk -h

Here is a list of the most commonly used options:

-c: Console. This allows you to connect to the Asterisk CLI.
-v: Verbosity. This is used to set the amount of output for CLI debugging.
-g: Core dump. If Asterisk were to crash unexpectedly, this would cause a core file to be created for later tracing with gdb.
-r: Remote. This is used to reconnect remotely to an already running Asterisk process. (The process is remote from the standpoint of the console connecting to it but is actually a local process on the machine. This has nothing to do with connecting to a remote process over a network using a protocol such as IP, as this is not supported.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Asterisk uses several directories on a Linux system to manage the various aspects of the system, such as voicemail recordings, voice prompts, and configuration files. This section discusses the necessary directories, all of which are created during installation and configured in the asterisk.conf file.

The /etc/asterisk/ directory contains the Asterisk configuration files. One file, however—zaptel.conf—is located in the /etc/ directory. The Zaptel hardware was originally designed by Jim Dixon of the Zapata Telephony Group as a way of bringing reasonable and affordable computer telephony equipment to the world. Asterisk makes use of this hardware, but any other software can also make use of the Zaptel hardware and drivers. Consequently, the zaptel.conf configuration file is not directly located in the /etc/asterisk/ directory.

The /usr/lib/asterisk/modules/ directory contains all the Asterisk loadable modules. Within this directory are the various applications, codecs, formats, and channels used by Asterisk . By default, Asterisk loads all of these modules at startup. You can disable any modules you are not using in the modules.conf file, but be aware that certain modules are required by Asterisk or are dependencies of other modules. Attempting to load Asterisk without these modules will cause an error at startup.

The /var/lib/asterisk/ directory contains the astdb file and a number of subdirectories . The astdb file contains the local Asterisk database information, which is somewhat like the Microsoft Windows Registry. The Asterisk database is a simple implementation based on v1 of the Berkeley database. The db.c

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In this chapter, we have reviewed the procedures for obtaining, compiling, and installing Asterisk and the associated packages. In the following chapter, we will touch on the initial configuration of your system with regard to various communications channels, such as analog devices attached to FXS and FXO ports, SIP channels, and IAX2 endpoints.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter<

Table of Contents

Section 2.2.1.1: Power-conditioned UPSs

Section 2.3.1.1: Analog interface cards

Section 2.4.1.1: Analog telephones

Section 3.8.1.1: C compiler cannot create executables

Section 3.8.1.2: bison: command not found