| Asterisk -- punctuating the path to open source Packet Voice |
by Mack Allison (May 30, 2002)
The Asterisk Private Branch Exchange (PBX) and Interactive Voice Response (IVR) platform offers an exciting look at the power and adaptability of the Linux kernel and GNU system. Asterisk turns a GNU/Linux system to the task of switching calls, and offers a large number of features to support communication in the business environment.
An Asterisk system equipped with some comparatively inexpensive telephony hardware is capable of managing a complex network of traditional analog and digital telephony equipment, by communicating over T1 connections to channel banks or directly with line-side and phone-side interface cards. With the Inter-Asterisk Exchange (IAX) protocol, Asterisk supports a powerful native Packet Voice system for passing calls between servers and to clients. Asterisk also has support for the H.323 protocol for wide inter-operability with other Voice over IP software and devices.
Building a bridge to the future of voice
Most readers are probably familiar with some of the industry buzz over Packet Voice, or Voice over IP (VoIP). What VoIP means to telephony is subject to hot debate, but strong points for it include the ability to share networks with data rather than requiring separate lines and interconnecting hardware. Other strengths include the possibility of handling other forms of data along with a voice call in a structured and timely manner. VoIP has its weaknesses, as well -- primarily the latency introduced by compressing and packetizing, and the reversal thereof. VoIP is also a technology very much up in the air and still divided by competing standards and implementations.
Packet Voice offers new applications and cost reductions, but it's unlikely to displace the widely developed and deployed analog and digital telephone systems of today. The traditional systems offer zero latency conversations, but additional features are very expensive to implement. These systems are widely in place now and few businesses relish losing the investment they've made in telephone hardware any time soon.
Asterisk achieves almost total abstraction between the technologies used to connect the calls and the switching core itself. What this means in practice is that calls can be transparently routed, regardless of whether they are coming in over analog interfaces or connecting via Packet Voice protocols. Once the calls have been brought into the switching core, Asterisk can provide a uniform set of features to all callers. IP and analog calls can share conference bridges, three way calls, and voicemail systems, and calls can be cross connected over whatever span of data or voice network is available.
Early history
Like many open source projects, the Asterisk project began primarily to fill a need the author had. Mark Spencer had founded Linux Support Services, a company whose business model included a lot of telephone support. He needed a good internal solution for handling voicemail, three-way calling, conferencing, and other phone services, and he needed it on a reasonable budget. Surveying the market place, Spencer quickly found that existing PBX systems were prohibitively expensive, even before features such as voice mail had been added to the mix. They were hardware based, and every added feature meant another expensive module.
Building on his experience as a co-op at Adtran, Spencer decided to develop a new PBX system in software. The original Asterisk release ran on a motley collection of hardware -- essentially anything that could be rigged to connect a PC to a channel bank, without buying the very large, complex, and expensive T1 interface cards available on the market at the time.
Hurdles, milestones, and thousands of lines of code
"When I wrote Asterisk originally, I used a Sangoma Frame-Relay card to talk to an Adtran Atlas, and used the Atlas to drive a channel bank. I got all this stuff running but it was a pretty big mess at the time," recalls Spencer. "I faced a number of problems in the development of this. One of the primary problems was that of finding hardware to connect the PC to the phone system. The hardware available was as expensive as a PBX itself. Of course, once I got it working, I could add expensive features in software for practically no cost -- other than time to write the code -- but the hardware issue was definitely a problem."
For the most part, Asterisk development went smoothly. There were some big hurdles to jump. Getting the software echo cancellation working called for some very late nights. Making DTMF detection reliable was a long walk. "The hardest part was -- and still is -- making call features work together smoothly. Some new features would break other features, or attempting to use them together would do very bad things. Working out the inter-relations between these features was not always intuitive or very easily done," adds Spencer.
Those features, combined with the base and the separate application modules, now span almost 90,000 lines of code. As with other open source projects, much of this code has been contributed by users aiding in the development of their systems. Most of the code has been written by Mark Spencer himself, but the project would not be as successful without the aid of the community.
Making it Flexible
"As has been typical of my projects, I basically wrote Asterisk twice," explains Spencer. "I wrote the first version, and made it work. With that, I could see much better how it should be written." Using the original as a reference design, Asterisk-ng was born, with a focus on extending the flexibility of the software. Channels, codecs, and applications were carefully modularized and separated from the switching core, to allow for greater adaptability. The Inter-Asterisk Exchange (IAX) protocol was reworked for the most efficiency possible.
The result of this evolutionary process is Asterisk as we now know it. Modularizing the channels allowed Asterisk to handle all kinds of conversations in the same way. By making IAX a type of channel, just like hardware based telephony calls, a pathway was paved to allow for flexible support of various Packet Voice protocols. Obviously, with the future form of VoIP up in the air, it would be unwise to tie Asterisk to any particular protocol.
One of the real pearls of Asterisk is the extension logic. Every step of a call is defined as an application. Dial a Channel is one application. Answer, Playback, Goto, and Voicemail are other examples of applications. Extensions are detached from channels, and are instead more like scripts which can call any application on any channel. A single extension can be used to ring any mixture of channels, and run any combination of applications. For example, an extension can be set up to ring two channels simultaneously (which can of course be any mix of channel types) before attempting to forward the call to a cell phone, and finally giving up reaching a human and rolling over to voice mail. The extension logic has proven to be so adaptable that entire Interactive Voice Response (IVR) systems can be scripted together within the extensions.conf file.
Features, applications, and more features
A significant number of applications is included with the base Asterisk release. Music on Hold was recently implemented, joining a large suite of features and applications already written. Conference Bridges are available, and scale to virtually unlimited size. Asterisk provides Call Detail Records to foster accountability within the phone network. Pretty much all of the expected telephone features are ready, including such functions as caller ID, call waiting, three way calling, etc. The now-common ADSI telephones are also supported, providing a greater level of functionality and usability at the handset without sacrificing the quality (and investment) of current telephone equipment.
In addition to a powerful extension system and a large collection of applications, Asterisk provides both a well defined API for writing custom C applications, as well as the Asterisk Gateway Interface (AGI, like CGI) for writing complex scripts in any number of languages such as PHP or Perl. The possibilities for custom applications are pretty huge. For example, using the Call Detail Records, an SQL database, and some script-fu offers the possibility of custom billing and tracking applications for service providers.
The IAX protocol offers massive scalability for an Asterisk-based phone network. Remote servers (in other buildings, or other countries) can be tied together to provide a unified dial plan and centralized management of core services. IAX is not just a client-to-server protocol. It was specifically designed to foster inter-server communication. The list of features and applications available in Asterisk is quite extensive. There is too much to list here, but more information can be found at asterisk.org.
Finding the right hardware
Though not exactly typical of 'deeply embedded' systems, Asterisk's requirements are fairly modest for the undertaking. It runs on standard PC hardware, though it has also been ported to other architectures. The tasks involved in switching voice calls are pretty intense. Typical systems range from around 300 MHz to 1 GHz. Harnessing the power and stability of the Linux kernel, Asterisk is able to perform all of the functions of a PBX in software, on commodity hardware.
While initially finding hardware to interface with channel banks and analog phones economically was quite difficult, hardware is now available (with more in the pipeline) that integrates beautifully with Asterisk and offers a greater value than the market offerings from a couple of years ago. Linux Support Services has telephony interface cards available that can drive the cost of a complete solution down dramatically. In addition, Quicknet's family of line interfaces and ISDN4Linux devices are supported.
The Future of Asterisk Telephony
Asterisk is now a richly featured platform for all sorts of voice traffic. It has been carefully designed to adapt to the changes in the telephony industry. As one of the last technologies not entirely driven by computers, it's obvious that big changes in this arena are happening now. The industry stands to change dramatically in the coming years. With evolving Packet Voice technology along and ever-increasing amounts of IP bandwidth, and broadband wireless soon to become a reality, voice's place in a data network (and vice versa) will be subject to hot debate.
The framework of Asterisk is such that new protocols and yet-to-be-dreamed-up technologies will be fairly easy to adapt to. In the future, Asterisk should support just about any method of passing voice calls. In addition, Asterisk is poised to embrace added functionality offered by Voice over IP as that technology matures and stabilizes.
Asterisk provides sort of a middleware between the competing technologies and the functions of the PBX itself. By dividing the switching core and the channel layers, Asterisk unifies the voice networks and brings them together within a flexible application environment. Once Asterisk has the calls, adding functionality such as voicemail and call conferencing becomes quite a bit less expensive.
Asterisk can do just about anything in software that a traditional PBX would do with specialized hardware. It unifies systems to provide tremendous possibilities for information services. Seamless use of Packet Voice allows Asterisk servers to intercommunicate throughout LANS, private WANS, and the Internet. Asterisk provides a sophisticated solution for IVR platforms, wide hardware interoperability, flexible wide area phone networks, and advanced telephony features -- all at reasonable cost.
For further information about The Asterisk open source PBX and it's development, visit asterisk.org
About the author: Mack Allison is a technical writer and web guy. He is employed by Linux Support Services, Inc.
Related stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed