Not Your Father's PBX?
Integrating VoIP into the enterprise could mean the end of telecom business-as-usual.
James E. Coffman, Avaya
Perhaps no piece of office equipment is more taken for granted than the common business telephone. The technology behind this basic communication device, however, is in the midst of a major transformation. Businesses are now converging their voice and data networks in order to simplify their network operations and take advantage of the new functional benefits and capabilities that a converged network delivers—from greater productivity and cost savings to enhanced mobility.
Convergence involves much more than simply sending voice packets over an IP (Internet protocol) network. It involves a significant new architecture that introduces advanced IP applications into the framework of an enterprise, with ramifications for communications that will play out over the years to come.
The discussion that follows describes what’s behind some major changes in communication systems design. New systems are evolving to become much more distributed, open, and made up of common, off-the-shelf components. (For an overview on VoIP, read Phil Sherburne and Cary FitzGerald’s “You Don’t Know Jack About VoIP” on page 30 of this issue).
WHAT IS A PBX?
Most of us are familiar with a PBX (private branch exchange) only as users who pick up the phone at the office to call someone inside or outside our business. In fact, although the most basic function of a PBX is to provide communications (usually voice) to the employees of a business, there is more to it than that. Sitting behind the familiar telephone is a sophisticated system of components that provides the functions necessary for communications.
These functions can be roughly divided into six major groups:
1. Feature operations. These consist of both those functions available to the phone user (placing a call, hold, conference, transfer, etc.) and those functions utilized by the operator of the system to control its use and how it is organized—phone number assignments, etc.
2. Endpoints. These allow users to access the functions of the system. The most common endpoints are telephones, but also included are fax machines, modems, PDAs, telephony applications running on laptop computers, and more. Most of the “non-voice” endpoints send signals to the PBX just as if they were simple analog phones. The media streams they send, however, are not voice-like and often require special handling by the system. For example, modems send special tones that tell the system not to perform echo suppression on the information they transmit. PBXs often have special features to suppress “call waiting” tones, which might be useful to human users but would disrupt data traffic.
3. Gateway interfaces. Gateway interfaces allow users inside the business to talk to the outside world. This requires conversion of both the call signaling (how calls are set up) and the voice stream. If someone in a business wants to call an outside phone, the PBX must signal to the outside system—typically the PSTN (public switched telephone network)—and must convert the voice stream inside the business to a voice stream expected by the PSTN.
4. Switching. Making a call requires that a path be established between the calling and called endpoints. This process is “switching,” and it can be accomplished in a variety of ways. It requires a network to tie the components (endpoints and gateways) together.
5. Media processing. Media processing functions combine and transform the voice streams in a call—to provide conferencing, music on hold, announcements, etc. Media processing is also needed to make sure the connection between two phones results in a path where both users can hear each other.
6. Application interfaces. The PBX also provides a voice network used to deliver voice services beyond simple endpoint-to-endpoint calling, including voice mail, interactive voice response (IVR), and other applications.
Additional Attributes. Several other important attributes of PBXs affect the way they are designed:
• Reliability. Most businesses expect their communication system to be available essentially all of the time. As a result, redundancy of components is built into all large systems.
• Scalability. Most businesses expect to grow over time and don’t want to switch communication systems as they do so. Supporting more users by “adding on” is an aspect of most systems.
• Cost effectiveness at various sizes. To be effective in the marketplace, communication systems must be cost-effective for businesses of all sizes.
• Interoperability. It is important for communications systems to work with systems and devices made by other manufacturers.
YOUR FATHER’S PBX: THE TRADITIONAL ARCHITECTURE
How do you design a system that can provide the capabilities and has the reliability and scalability attributes described in the previous section?
The technology currently available obviously impacts system design. For example, in the early 1980s when PBX systems were developed, computing was an expensive resource. Microprocessors were available but were limited in function and also expensive. Data networking was relatively unknown and often based on circuit-switched models such as X.25.
Most PBXs developed at this time have a common architecture:
1. A control processor to run the software that operates system features. This processor is typically built to support the reliability and scalability expected of PBXs.
2. The communication software that runs on the control processor. This application drives all of the system components and determines the functions that it provides.
3. Endpoints used to access the features and functions of the system. There are two kinds of endpoints: Digital phones provide convenient access to calling functions through buttons that are used to tell the system what the user wants (hold, transfer call, etc.) and through a small display used to show who is calling. These endpoints are usually proprietary to a single manufacturer. All traditional PBX systems also support analog phones that provide basic calling functions. Both digital and analog endpoints connect to interface cards in modules.
4. Modules. Sometimes called shelves, these house the interface cards that provide endpoint or gateway interfaces. An individual interface is generally called a “port.” Ports for digital phones usually provide enough power for the phone to operate even if the power to the office fails, assuming that the module itself has backup power. Interfaces to the PSTN are provided by a variety of interface cards. These interfaces convert from signaling and voice formats expected by the PSTN to those used internally to the PBX.
Modules also provide a certain amount of switching among the interface cards held within. Media processing for conferencing, music sources (for music on hold), and announcements is either built as a card that fits into a module or is built right into the interface cards.
5. Inter-module switching. This allows the interconnection of ports in different modules. Traditional PBX systems accomplish this via circuit switching. In circuit switching a dedicated path is set up between the two ports for the duration of the call. Calls to phones not within the business are switched to an interface in a module that enables connection to the PSTN. Often inter-module switching does not have enough capacity to connect all possible calls simultaneously, and its success depends on the fact that not everyone is on the phone at the same time. When call volume exceeds capability, calls are blocked.
The components of the system must be networked together for two purposes. First, a voice network is needed to create a voice path between devices. The voice network is created from switching elements within and between the modules. This is usually done via layers of TDM (time division multiplexing) switching, which is a technology that transmits multiple signals simultaneously over a single transmission path.
Second, a control network is required so the components can communicate with each other to implement system operations. For example, when a user pushes a button on a digital phone, a message indicating the operation requested is sent from the phone to the module it connects to and then to the communication application software. The control network is implemented in a variety of ways, often by stealing some of the TDM timeslots in each module and dedicating them to the transmission of control messages.
The data representation of voice is a 64-kilobits-per-second (Kbps, or 8K eight-bit samples per second) isochronous stream. The voice sample is generally encoded in one of two formats: Mu-law (used mainly in North America and Japan) and A-law (used almost everywhere else). This format matches the one used in digital interfaces to the PSTN. Using the same voice representation in a PBX as in digital interfaces to the PSTN reduces the work needed for the PBX to interoperate with the PSTN.
A module, along with a control processor (often housed in a special slot in a module) and a few interface cards, can provide service to a small number of users.
Systems grow by adding modules and interconnecting them with inter-module switching. The capacity of the modules and of the inter-module switching determines how small or large a system can be economically designed. This is typically based on the amount of switching capacity in these components (see figure 1).
PBX systems have been present in businesses since the early 1980s with little change and predate data networking and PC technologies. After 15 years of relative stability, however, virtually all PBX vendors are now introducing radical changes to their architecture.
What technologies are enabling this change? Perhaps the most important is the development of packet switching into an IP-based network with the bandwidth, speed (low delay), and reliability to support voice communications. The development of this technology and its use in data networking have both enabled the change and provided a driver for it. Since most business data networks span the breadth of their organization, it became possible and advantageous to offer voice communication throughout an enterprise while using only one network.
Another essential enabler was the creation of inexpensive DSP (digital signal processor) technology. For voice streams to ride an IP network, they must be packetized and perhaps compressed. These operations require digital signal processing. Without the availability of inexpensive DSP technology, IP phones would have been too expensive compared with their traditional counterparts.
Another technology lowering the cost of IP devices was the creation of inexpensive network interface chip sets. Fast and inexpensive microprocessors also allowed more intelligence to be distributed to phone modules and interface boards and enabled the use of IP to distribute these functions.
THE NEW ARCHITECTURE
These technology changes have led to a re-design of PBX components. They are evolving to distribute components farther apart, to incorporate more off-the-shelf components, and to use an IP network to transmit both control information and voice. The common term for a PBX with this new architecture is IP-PBX.
Control Processor and Communication Software
The control processor often is an off-the-shelf server that runs communication application software on a standard operating system (Microsoft, Unix, or Linux). The benefits of moving to commercially available hardware and software are substantial, allowing vendors to lower their development costs.
Digital endpoints become IP phones and connect to the IP network rather than to dedicated interfaces in a module. The phones use the IP network to communicate both control and voice streams.
IP phones put some of the same strain on the data infrastructure as does a PC. Each requires an IP address and generally needs DHCP (dynamic host configuration protocol) service to acquire that address. IP phones often use an FTP server to get a new version of their firmware, and—for security or voice-quality reasons—they may be put into a special VLAN (virtual LAN), etc.
Phones require an IP address so that they can be identified by the communication application. Using standard IP network mechanisms, the phone acquires an IP address and the address of the application server, and “registers” itself. Registration allows the communication application to establish a correspondence between a phone number and the IP address used by the phone. Thus, users still dial familiar phone numbers, and the communication application uses the IP address of the phone to communicate with it.
IP phones use the IP network to carry voice streams directly to each other. Unlike the traditional architecture, when two IP devices are talking directly together, they do not use communication system resources to create the voice path.
Interfaces are still needed to provide access to the PSTN and to analog endpoints such as analog phones and fax machines. These “interfaces” are housed in gateways operating in much the same way as do modules in the traditional architecture, but they convert the signaling and voice streams to IP.
Some manufacturers also provide gateway interface cards allowing customers to continue using existing digital phones, protecting their investment in their existing infrastructure and reducing the cost of migrating to the new system.
Inter-module switching is done over the IP network where bandwidth can be limited in certain circumstances (across the wide area, for example). Without provisions to limit the number of calls across a limited resource, the voice quality will degrade. This is analogous to “blocking” in circuit-switched networks, but all calls degrade in quality instead of some being blocked. Some systems enforce “call admission control” so that only a limited number of calls are allowed across the limited links, allowing those calls that do get through to maintain optimum voice quality.
Gateways may also provide the media processing found in traditional modules. Logically, however, this is a separate function, and specialized media processors may be used for this purpose.
Collectively the endpoints, modules, media processors, control processor, and communication software use the IP network to provide the same realtime voice communication functions as provided by a traditional PBX. The new architecture is a client-server approach: the clients are gateways and endpoints, and the server provides the communication application that operates the features. This approach is similar to the way e-mail or Web services are implemented, with a central server providing service to a set of client PCs.
It is important that the IP-PBX be “well-behaved” from a network administration point of view, with common tools and protocols for operation and management.
The other voice applications found in a traditional voice network—voice-mail and IVR—are also migrating to the IP network used for communications (see figure 2).
CHALLENGES TO THE NEW ARCHITECTURE
As customers migrate to this new converged network architecture, they generally expect to keep all the positive functions and attributes of their traditional PBX while gaining new advantages. The IP-PBX has some challenges in this regard.
Traditional PBXs are highly reliable systems (many manufacturers claim 99.999 percent reliability—about five minutes of outage per year). The traditional PBX architecture achieves this with highly reliable components and with redundancy built in by the manufacturer.
A major question is how to provide reliability for the control processor of an IP network. It is a key component because if it fails, all the users of the system (who may number into the tens of thousands) will be without service. One approach to this problem is to rely on the fact that gateways and phones can register to multiple servers. If the server to which they are registered fails, they can register to a backup. Depending on how this is done and the intelligence of the gateway and the phone, the re-registration may or may not affect the active connection (voice path between the devices).
If the main processor and the backup share call control information, then after re-registration the callers can continue their conversation and conference additional parties, etc. This call continuity can be particularly critical in contact center operations where it is important not to disconnect callers “in queue” who are waiting to be answered.
Keep in mind that IP networks can be designed to be highly reliable—with multiple paths from device to device. In many real-world environments, however, there is a single IP link between the control processor and a gateway. If this link fails, then the area served by the gateway will no longer have service. This problem can be addressed by building intelligence into the gateway or into a separate processor so that control functions continue in the event that a primary link is lost.
Voice is more demanding than traditional data communications (such as e-mail, Web pages, etc.) because of its realtime nature. To ensure voice quality, the following attributes of the IP network must be managed for all possible voice paths:
• Bandwidth. For the expected number of simultaneous IP voice calls
• Round-trip delay. The time it takes a packet to go from one IP device to another and back again
• Jitter. Variability in delay
• Packet loss. The number of packets lost (usually expressed as a percent)
Techniques for establishing an IP network suitable for voice must be addressed before the new architecture can be adopted. This usually requires incorporating various quality-of-service capabilities into the IP network, as well as additional bandwidth.
The traditional PBX architecture implements echo suppression mechanisms that assume a circuit-switched network. Within an IP network, the delay increases, requiring changes in echo-suppression capabilities. These considerations affect IP endpoints and gateways.
Traditional PBXs carry much more than voice over their “voice” networks. For example, modem traffic, fax, and multiple 64-Kbps channels for video are all found in a large enterprise. The equipment using these streams may not work well if the streams are transformed into packets and back into a continuous stream. The delay and possible packet loss introduced by the data network make it impossible for endpoints to maintain the synchronization they expect from a circuit-switched network. These limitations are being addressed as vendors create encoding and error-collecting techniques suitable for non-voice traffic.
IP Telephone Operations
Traditional PBX interface cards provide power to analog and digital phones. This job now goes to the IP network. There are several ways to deliver power to the endpoints, but the most convenient is to have the data switch in the closet provide “inline” power over the IP network. Standards for doing so have recently been ratified so that data-switching equipment from one vendor can power phones from another vendor. If communication is to be preserved through a power outage, the data switches need to be on uninterruptible power supplies.
One advantage of IP telephones is they can be easily moved from one office to another. One difficulty with moving phones is that 911 services require information on the location of the phone placing an emergency call. Again, standards are emerging that allow the IP-PBX placing the emergency call to query the data network for the identity of the data port to which the phone is connected. That port can be associated with a physical location for emergency responders.
As PBX components “disaggregate” and become attached to an IP network, they also become potential targets for intrusion, denial of service, and other hacking threats. These voice communication system components must be hardened against attacks, like other parts of the network infrastructure. Some vendors offer encryption of voice packets to prevent eavesdropping via tools commonly found on the Internet.
WHY: BUSINESS DRIVERS
Moving to IP telephony over a converged network offers several important advantages over the traditional PBX approach, leading vendors to insist that IP telephony is the future and that virtually all PBX systems sold in coming years will use this new architecture.
Using the IP network to link IP-PBX components together gives an enterprise substantial flexibility in how a system can be configured. Remote locations can be incorporated into a single enterprise-wide communication system. Remote workers can have the same communications capabilities as those working in a headquarters facility. This can improve the communication capabilities within an enterprise, while lowering the total cost of system implementation and operation.
Software packages such as databases, SNMP (simple network management protocol) development environments, and Web servers are available on standard platforms. Thus, the communication system vendor can more easily integrate these components with the telephony application in an IP environment. This allows operators of the IP-PBX to use familiar tools (Web browsers, SNMP management interfaces, etc.) to operate the system, resulting in lower administrative costs.
Open servers and IP network bandwidth also enable organizations to scale their communication systems to larger sizes. This can increase efficiency, particularly in contact-center implementations. Businesses can link employees in distributed locations to deliver “follow-the-sun” customer service and to take advantage of lower labor costs available in some parts of the world.
It is also possible to use the resiliency of the data network to increase the availability of voice communications. Businesses are moving their critical data and voice communication components to hardened, geographically dispersed “bunkers.” This makes the business more resilient in the face of fires, floods, and other disasters. The architecture of the IP-PBX lends itself naturally to this structure as the control processor can be located at a distance from the endpoints and modules.
Perhaps more important than these network-based advantages is that the communication system is an application on the data network just like the other applications used in business. Thus, this application can be integrated with other business services such as directories, e-mail services, etc. Many systems allow dialing from corporate directories or personal information managers and integration of voice and e-mail.
Now that the market has begun to evolve toward a new PBX architecture, what changes can we expect to see?
First, the difficulties and limits of the new architecture will be overcome. Enterprises expect the new systems to be as reliable and accomplish all the functions of traditional PBX systems. Thus, modem and other nonvoice TDM traffic will move over the IP network as it has moved over traditional voice networks. Standards are being defined and the increasing capacity of DSPs will bring this about in a cost-effective way.
The expectations of reliability for IP-PBXs will drive developments in the reliability and availability of the new architecture. Since an essential component of the new architecture is the IP network, improved diagnostic and network analysis tools will enable the quick diagnosis and repair of network problems impairing voice communications. Since security breaches will be able to disable both voice and data applications, techniques to protect critical business networks from denial-of-service and other attacks will be deployed. IP networks will become more resilient for all applications, not just communications.
Communication systems will take advantage of the new IP-based architecture by scaling larger and reaching farther. Even large enterprises will likely be able to implement a single communication system that ties all their employees together around the world.
Rich collaboration and video communication applications will merge with voice applications—becoming as easy to use and ubiquitous as traditional voice communications. Voice quality will no longer be tied to traditional network bandwidths; video room systems will provide stereo sound so listeners can locate talkers by position, improving audibility and “liveness.”
Audio capabilities will merge into PCs and into other mobile devices. No longer will mobile workers have to carry a “tool belt” of different communication devices.
We can expect such new capabilities to continue to drive the evolution from traditional PBX solutions to new, full-featured IP PBX models that will change the way businesses communicate—delivering greater productivity, cost savings, and mobility.
Definitions and Acronyms
Isochronous. A communication link characterized by both ends using a common clock source to send a constant bit stream.
IVR (interactive voice response). An automated system that can understand human speech and provided prerecorded information to the caller.
PSTN (public switched telephone network). The worldwide telephone network. The standards for PSTN interfaces are specified by the CCITT (now ITU, International Telecommunication Union).
TDM (time division multiplexing). A multiplexing technique by which a communication medium is divided into discrete time slots. Each time slot can be used as a communication channel between two devices. If multiple devices attach to a TDM medium, then the medium can be used as a switch.
LOVE IT, HATE IT? LET US KNOW
email@example.com or www.acmqueue.com/forums
JAMES E. COFFMAN has been with Avaya Labs for more than 20 years, working in a variety of areas in telecommunications such as multimedia communications, VoIP systems development, VoIP standards, Web access to call centers, CTI (computer telephony integration) systems development, and operating systems. He currently is a director in the vertical markets development group responsible for vertical market technology. Previously, he directed MultiVantage (now called Avaya Communication Manager) technical architecture and planning at Avaya Labs. Before that, Coffman was responsible for planning and architecture in bringing IP telephony to the Definity communication platform. Coffman has a B.A. in mathematics from Reed College and an M.S.E.E. and Ph.D. in computer science from the University of Pennsylvania. He holds several patents in the telecommunications area.
© 2004 ACM 1542-7730/04/0900 $5.00
Originally published in Queue vol. 2, no. 6—
see this item in the ACM Digital Library