The PBX Is Dead; Long Live VoIP

The private branch exchange (PBX) has been the reference standard for business telephone systems for decades, but of late, its age has been showing. While the computer industry has changed vastly, telephone systems until relatively recently have changed only superficially. They are expensive, proprietary, and often so arcane that only factory-authorized dealers have the remotest clue how to manage them. This, coupled with the emergence of open source Voice over IP (VoIP) technology, leaves PBX on the verge of obsolescence. In this article I'll look at Asterisk, a Linux-based open source softswitch, and why it heralds the end of PBX.

Introduction

In the mid-1990s, vendors began to introduce PC-based telephone systems, mostly based on Windows NT, although one vendor, NexPath, made a Unix-based small-business phone system. These systems were a great improvement over completely closed systems, offering more features for a more reasonable price, but fundamentally they were based on the same circuit-switched architecture as their predecessors. These vendors, AltiGen and Artisoft--two leaders in this space--have since reengineered their systems around VoIP, but they still depend heavily on proprietary switching hardware to handle basic telephony functions.

Enter Asterisk. It threatens to turn the business telephone system industry on its head, and in my mind, that is a very good thing. For years, I've been listening to clients complain about how overpriced telephone equipment is compared with other networking hardware, how difficult their systems are to manage, and how once they select a vendor they are locked in for life. Some systems are more open than others, but for the most part telephone equipment vendors really don't want customers to have the freedom to mix and match equipment from different vendors.

A Quick History Lesson

Telephone systems have been slowly evolving from their circuit-switched origins (a PBX is essentially a miniature version of the telephone company's central office) to completely packet-switched systems such as Asterisk.

Monolithic Circuit-Switched Systems

Until not long ago, business telephone systems were monolithic systems, with every telephone wired to a central box. That made sense in the days when telephone systems did little more than electrical switching. In these systems, every outside telephone line and every internal device was typically wired to a central switching unit.

There were two types of switches: blocking switches, which could make only a limited number of connections between terminal devices at any given time, and nonblocking switches, which could connect any number of terminal devices to any number of other devices or telephone lines.

Both types of switches can be represented as a matrix, in which terminal devices (telephones) are connected to one or more circuits (see diagram). In the oldest telephone switches, operators did this manually by making connections on peg boards. Although switches have long since been automated and digitized, this legacy from the "number please?" days lives on.

Distributed Circuit-Switched Systems

Distributed switches replace a single central switch with a small number of switches that are interconnected, either via an interchassis bus (for example, H.100) or circuit-switched trunk lines (such as a leased T1 line between offices). These systems have become more common in the past ten or so years as the need to support decentralized facilities and telecommuters has grown. However, even recently these systems were little more than a confederation of smaller, relatively dumb switches.

Hybrid Circuit-Switched/VoIP Systems

In the late 1990s, VoIP began to make major headway in the business telecom equipment industry, initially as a trunking technology to interconnect physically distant switches. The main motivation for doing this was to reduce long-distance tolls by routing interoffice voice traffic over a company WAN. PBX vendors began to support VoIP directly but did not fundamentally change their hardware architecture. They just made VoIP interface cards that made a TCP/IP network look like a channelized T1 line.

Some companies, such as ShoreTel, made fundamental changes to the PBX architecture. They've been making hublike devices that primarily use VoIP for interswitch communication and support any combination of VoIP or conventional telephone handsets hanging off each hub. Their system is more analogous to an Ethernet switch than the mainframelike design of a conventional PBX. This approach works great for small and medium-size shops, and until recently this was my favorite approach.

Diagram of a typical hybrid circuit-/packet-switched telephone system

Softswitches

Newer systems--Asterisk is an excellent example of this trend--eliminate the need for dedicated telecom hardware altogether. With Asterisk, all of the basic telephony services are implemented as software running on the host CPU and a SIP protocol stack. (Asterisk supports other VoIP protocols, as well as conventional circuit-switched telephone lines and devices via expansion cards.)

With a VoIP carrier such as Broadvoice, it is now possible to build a pure software-based PBX. The VoIP carrier provides the interconnection to the public telephone network, external telephone numbers, and so on. With a Linux server, off-the-shelf LAN/WAN hardware, a broadband connection, and SIP-compatible telephone handsets, one can now build a fully functional telephone system, complete with high-end features.

While companies such as Cisco were offering pure VoIP-based systems several years ago, those were fundamentally closed systems that targeted the high-end corporate market. Asterisk, by contrast, allows users to improvise solutions and cobble together components from many different vendors. If you doubt that softswitches will replace specialized telecom hardware, it's worth noting that two of the major telecom component vendors, Dialogic (now part of Intel) and Natural Microsystems, have both introduced software-only versions of their computer telephony and switching products. These SIP-based tools eliminate the need to install custom DSP/interface boards in servers. Now one can download their host media processing tools and run them on standard-issue hardware.

The importance of this shift is that telephony is no longer the province of exotic and overpriced hardware. It is just another service that runs on standard-issue server hardware. Of course, specialized knowledge is required to configure and manage these systems. However, we've seen many times where once exotic services, email for example, have become commonplace. The same will happen with telephony as IT professionals become acquainted with systems like Asterisk.

Close, but Not Quite There

Related Reading Switching to VoIP By Theodore Wallingford Table of Contents Index Sample Chapter Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

I initially was very skeptical of Asterisk, and still have some reservations about using it in a production environment. Telecom applications demand a high degree of reliability, and the best way to guarantee this, especially on PC-based servers, is to run basic telephony and switching services on dedicated hardware. Computer telephony hardware, such as NMS's Fusion cards, are essentially self-contained computers that reside within a server. Their onboard DSPs offload busywork from the host server's CPU (calculations used in compression algorithms, echo cancellation, and so on). The application on the host server does little more than send high-level commands (for example, connect port 1 to port 16) to the telephony interface. Thus you have great confidence that an interface rated to handle 120 calls will perform well in real-world conditions.

Computers have gotten a lot faster and cheaper since PC-based telephony cards were introduced in the late 1980s--so much so that it is now possible to run many once overtaxing services on standard-issue hardware. This is the approach taken by Asterisk, as well as by well-known speech recognition vendors such as Nuance.

I am still reluctant to use Asterisk for production systems, for reasons I'll get into shortly, but in the long run I think it is a matter of time before this approach obsoletes dedicated hardware. I am currently using it for some pilot projects and am impressed with the results so far. But for now, I am inclined to go with a known evil while I gain experience with these new tools.

Asterisk's main weakness (which applies to all softswitches) is the uncertainty about how much host CPU is available at any given instant. PC operating systems don't do a good job of guaranteeing that a specific amount of CPU or memory will be available at any moment. You can be reasonably sure of average performance, but when you're running a live service like telephony, it's no good if 50 calls arrive just as your PC decides to launch a CPU-intensive cron job. There are workarounds that make this less of a problem, but it isn't fully solved. The general solution is to throw lots of hardware at the problem to disable all unnecessary services.

This is analogous to the QoS (quality of service) problem in Voice over IP services, where voice packets need to receive higher priority and hopefully faster routing. Best-effort routing works reasonably well on uncongested networks, and "best effort plus" protocols such as diffserv and 802.1p improve on this further. However, it is very difficult to guarantee 100 percent reliability on a decentralized packet-switched network.

This issue was highlighted at the Asterisk Europe conference in June. Many people asked questions about scalability. Unfortunately nobody was able to provide clear guidance or even a cocktail-napkin estimate of how many users a typical Asterisk box can support. There are simply too many factors to consider. For example, if you are running the same compression algorithm throughout the system, especially a low overhead codec like g.711, the system can scale much better than if it has to translate between different codecs (such as g.711 to/from g.719 or gsm). The only way to find out how many users a box can handle before it breaks is to test it, and even then you still don't know for sure where the redline is.

That said, I don't think this will remain a major problem for too much longer. With improvements such as automatic load balancing (an especially important item), builds that take advantage of new dual-core CPUs, and general improvements in server performance, it should be possible to build softswitches whose performance and reliability are close enough to those of dedicated hardware. The main obstacle at the moment is not technology but rather the relative immaturity of system administration tools.

Asterisk is still in release 1.0, so this is not a critique. The system is quite impressive for version 1.0. It's not an easy system to configure; in fact, it's pretty much a nightmare to install and manage, but that's not much of an insult, because just about every phone system I've seen has been. It's easy to break things in Asterisk's present incarnation, so it is definitely for early adopters.

That said, it's not hard to imagine what versions 2.0 and 3.0 might look like. For example, the unknown performance issue can be solved by modifying the system so that each instance of Asterisk redirects users to redundant nodes when the CPU utilization exceeds a specified threshold. In a pure VoIP environment, it doesn't matter which box processes a given call, so in principle it should be possible to build a fully distributed system that does this fairly automatically. Once you reach that point, the scalability issue goes away, and you just add more boxes to the rack when you notice utilization climbing above a threshold.

My Asterisk Wish List

Overall, Asterisk is an impressive platform. But like many young open source projects, it has some rough edges. So here's my wish list for version 2.0 and beyond.

• Automatic load balancing--In a pure VoIP installation, it shouldn't matter which box processes a call. Asterisk boxes would communicate with each other and would start redirecting calls to peers when CPU utilization climbed above a threshold. Ideally this would be a line item in the system configuration, and for small systems it would be fairly automatic. If this is done right, it should be possible to build systems that scale to handle several thousand concurrent sessions, large enough for all but carrier-grade installations. Asterisk already has some very useful peer-to-peer services such as TDM over Ethernet, so this should not be very difficult to do.

• MRCP --This newly developed protocol enables telephony servers to engage speech synthesis and automatic speech recognition servers such as Nuance via a platform-neutral interface.

• Native Win32 support--I know this is heresy for some people, but the reality is that Windows is a known evil, and while most smaller companies have a resident Windows expert, Linux users are harder to come by in a small-business environment. The option of running Asterisk directly on Windows would encourage people to use the system and hopefully switch to Linux later on.

• VoiceXML--VoiceXML is a de facto standard for scripting IVR and speech recognition applications. It would be nice if Asterisk had an embedded VoiceXML parser. That would allow IVR developers to port their applications to Asterisk more easily.

If I were a PBX manufacturer, I wouldn't take this mild critique as good news. Software evolves much more quickly than hardware. I think it's safe to assume that version 2.x will be here sometime later this year (disclaimer: I have no inside knowledge), and that subsequent versions will continue to come along at a rapid pace (a blinding pace, by the standards of telecom hardware vendors). All of Asterisk's problems are fixable, and work is actively under way to resolve them.

Overall, I'd say the news for PBX vendors is pretty bad. My guess is that within two or three years, there will be a well-developed ecosystem of vendors shipping Asterisk-based systems in a wide variety of form factors for a range of applications including low-cost VoIP gateways, small-office intercom systems, and enterprise systems. Sure, the traditional switch vendors will be able to hang on to their existing customers, but it is hard to see in a few years why anybody would pour tens of thousands of dollars into a closed system when they'll have a wide choice of inexpensive, open systems derived from what I predict will become the reference standard for many telephone systems.

PBX vendors and their advocates are usually quick to point out that VoIP has been relatively slow to take off. People have been predicting the death of the PBX for nearly ten years now, and they are still around. The difference this time is that it is possible to build open systems using cheap general-purpose computing and networking hardware. Combine that with an open source framework that people are free to extend and build upon, and you have something fundamentally new. This freedom to reuse and extend upon open systems has never existed in the telecom hardware industry. So in my view, this is not a debate about whether Voice over IP is better than circuit-switched telephony, but about open software versus locked-down hardware environments.

I certainly don't feel sorry for many of these companies, as they've been bilking customers for many years. Case in point: one well-known telecom hardware vendor has been selling T1 interface cards at more or less the same price point for more than ten years! Compared with the price/performance curve in the computing and networking business, that's pretty much unthinkable. The only reason they've been able to hold their prices has been that it is more expensive to port to another hardware platform than to pay a tithe to the vendor.

The news isn't all bad for these vendors. For some of them it could be an opportunity to shed their legacy hardware and embrace open source and become more competitive in the process. If I were the CEO of a telephone system manufacturer, I would seriously consider abandoning old product lines in favor of developing an open system. Doing so would allow a company to shed an expensive hardware R&D and manufacturing division and focus almost exclusively on software and functional system upgrades, which are much more visible to customers and therefore more valuable than an upgrade to a DSP buried somewhere in an expansion board.

So should you run off and replace your existing phone system with Asterisk? Not today--but in a couple of years, and probably sooner rather than later, you'll be able to choose from a variety of phone systems that are derived from it. And that's what's so interesting to me about Asterisk: it's not that it does anything fundamentally new that no other phone system does, but the fact that it is built upon an open platform. This will make it possible for companies to develop telephone systems that are customized for different types of uses, and do so without reinventing the basic platform.

On the other hand, if you're a propeller-head type and want to experiment with building your own phone system, you should definitely give Asterisk a whirl (you can build a decent test bed for a couple thousand dollars). Watch my blog for some posts about getting started with different Asterisk configurations.

Brian McConnell is an inventor, author, and serial telecom entrepreneur. He has founded three telecom startups since moving to California. The most recent, Open Communication Systems, designs cutting-edge telecom applications based on open standards telephony technology.

Return to ONLamp.com.