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,
although the underlying causes will be different. As loads increase, the system will haveincreasing 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 |
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 |