System information
Another thing to consider when performing an upgrade is whether you really need to
perform the upgrade in the first place. If you’re using a long-term support (LTS)
#
ver-
sion of Asterisk and that version is happily working along for you, perhaps there is no
reason to upgrade your existing production system. An alternative to upgrading the
entire system is simply to add functionality to your system by running two versions
simultaneously on separate systems. By running separate boxes, you can access the
functionality added to a later version of Asterisk without having to disrupt your existing
production system. You can then perform the migration more gradually, rather than
doing a complete system upgrade instantly.
Two parts of Asterisk should be thoroughly tested when performing an upgrade be-
tween major versions: the Asterisk Manager Interface (AMI) and the Asterisk Gateway
Interface (AGI).
These two parts of Asterisk rely on testing your code to make sure any cleanup of syntax
changes in either the AMI or the AGI, or added functionality, does not interfere with
your existing code. By performing a code audit on what your program is expecting to
send or receive against what actually happens, you can save yourself a headache down
the road.
The testing of call detail records (CDRs) is also quite important, especially if they are
relied upon for billing. The entire CDR structure is really designed for simple call flows,
but it is often employed in complex call flows, and when someone reports an issue to
the tracker and it is fixed, it can sometimes have an effect on others who are relying on
the same functionality for different purposes. Asterisk 1.8 now includes channel event
logging (CEL), which is a system designed to get around some of the limitations of CDR
in more complex call flows (such as those that involve transfers, etc.). More information
about CEL is available in “CEL (Channel Event Logging)” on page 537.
Upgrading Asterisk can be a successful endeavor as long as sufficient planning and
testing are carried out prior to the full rollout. In some cases migrating to a separate
physical machine on which you’ve performed testing is preferred, as it can give you a
system to roll back to in case of some failure that can’t be resolved immediately. It’s
the planning, and particularly having a backup plan, that is the most important aspect
of an Asterisk upgrade.
Conclusion
In this chapter we looked at how to install an operating system (one of Ubuntu or
CentOS) and Asterisk itself. We did this securely by installing via sudo and running
Asterisk as the non-root user asteriskpbx. We are well on our way to building a func-
tional Asterisk system that will serve us well. In the following chapters we will explore
#More information about Asterisk releases and their support schedule is available at https://wiki.asterisk.org/
wiki/display/AST/Asterisk+Versions.
Conclusion | 69