PBX Evolution: Where It Was, Where It Is, & Where It’s GoingPBX Evolution: Where It Was, Where It Is, & Where It’s Going

“The PBX is dead” has been heard throughout the industry for longer than most telecommunications managers can remember. The phrase first popped up more than a quarter century ago with the widespread adoption of Ethernet LANs. It made another appearance in the early 1990s when Computer Telephony Integration (CTI) standards were introduced, and yet again a few years later with the announcement of the first IP telephony system from Selsius Systems. More recently the phrase made major headlines following last year’s big Microsoft kickoff for Office Communications Server (OCS) 2007 with embedded voice call control features. Has the PBX finally come face to face with the Grim Reaper, or will it receive yet another reprieve from the big CIO in the sky?

Before we write the PBX’s obituary (again) it is important to be sure we know what we are talking about. First things first: What is a PBX? PBX is an abbreviation for Private Branch Exchange, a privately owned communications system that is physically located on a customer’s premises, provides dial tone and telephony features to subcribers, and is linked to a central office (CO) communications system (the “central exchange”) via trunk circuits for access to and egress from the Public Switched Telephone Network (PSTN). For simplicity’s sake we will consider all customer premises communications systems to be classified as PBXs, even those marketed as a Key Telephone System (KTS) or Hybrid system, because the core capabilities and functions are similar, if not identical, across the category offerings.

Until a few years ago, all voice communications traffic was handled over the circuit switched PSTN, but an increasing amount is now bypassing the traditional network in favor of the packet switched Internet. It must be noted, however, that most Voice Over Internet Protocol (VoIP) traffic across the Internet still originates/terminates at a non-IP voice terminal connected to the PSTN or a customer premises communications system. The number of pure VoIP calls will someday eclipse circuit switched-only calls, but that may not happen for awhile. Circuit switched COs are expected to remain in place, connected to customer premises PBXs, for many more years. When the circuit switched CO does fade from the scene, only then can we truly write off the PBX as we have known it.

Based on the above definition, whatever customer premises solution is used to provide dial tone, traditional telephony features, and connectivity to local/long distance exchange carrier services should continue to be known as a PBX regardless of the underlying technology. The final days of the standalone voice-centric PBX system may be on the horizon, but as long as there is demand for real time voice communications, it will continue to march on a little farther. PBXs have evolved dramatically during the past several decades, and are guaranteed to do so into future. Before analyzing the future evolution of the PBX, it may be beneficial to review the three most significant architecture and design developments of the past 40 years: computer-based call processing; digital switching fabric; and IP-based packet switched connections.

STORED PROGRAM CONTROL

The ancestor of today’s highly intelligent and feature rich software-based PBX systems was the Northern Telecom (ne Nortel) SG-1 PBX. Also known as the “Pulse,” it was first introduced in 1972. Prior to bringing the new technology to the customer premises, computer-based call control technology was first available at a large scale with the #1 Electronic Switching System (ESS) central office system. First introduced in 1965, it was designed and developed by AT&T’s Bell Laboratories. It should be noted that the first deployment of the technology on a smaller scale was available with AT&T’s 101 ESS.

Stored Program Control (SPC) system is the technical name used for telephony communications systems controlled by a computer program stored in the system memory. Earlier generations of central office exchange technologies, such as Panel, Rotary and Crossbar were classified as electromechanical switching systems without software control. SPC allowed and provided new and sophisticated calling features untenable with electromechanical technology. Computer technology was still evolving in the 1960s and early 1970s when mainframes ruled, so incorporation of microprocessors into PBXs was a major breakthrough for enterprise communications systems. By the late 1970s, SPC-based PBXs dominated the landscape, quickly replacing electromechanical systems in a few short years.

DIGITAL SWITCHING

Shortly following the arrival of SPC technology was the development of digital switching technology in the mid-1970s. Until the development of digital communications, analog switching and transmission techniques were used to establish connections between calling and called parties. The first digital PBXs, such as Rolm’s CBX, converted analog wave signals into a digital format for internal transmission and switching purposes. Voice audio signals from the desktop analog telephone to the PBX common equipment hardware were transmitted over a 4-Kilohertz (KHz) communications channel, at which point a coder/decoder (codec) embedded on the port circuit card converted the analog signal into a digital signal for transmission across the internal circuit switched network. When digital telephones were first introduced in 1980 behind the Intecom IBX S/40, the codec function was embedded in the desktop instrument itself, and transmission to the PBX common equipment was in digital format, ready for transmission across the internal circuit switched network. Digital switching, as compared to analog switching, provided improved sound quality and more reliable transmission at a lower cost. It was also ideal for supporting data communications requirements in the days of expensive, low-speed modems.

In the early days of digital PBXs, there was no official standard for digital transmission and coding followed by all system manufacturers, because transmission schemes, bit word sizes, and sampling rates varied. By the mid-1980s, however, a Time Division Multiplexing/Pulse Code Modulation (TDM/PCM) format using an 8-bit word and 8 KHz sampling rate emerged as the de facto standard. An 8-bit word and 8 KHz sampling rate translated to a 64 Kbps transmission rate now commonly referred to as the ITU-T G.711 audio standard.

PACKET SWITCHING

Lucent Technologies introduced its Multimedia Communications Exchange (MMCX) solution to work behind its Definity PBX system in 1995. MMCX was the first enterprise voice communications system option to support Ethernet-connected H.323 softphone clients with an integrated media gateway for connection to the circuit switched Definity via a PRI link. The first Ethernet-based PBX system to support Ethernet-connected desktop telephone instruments was introduced two years later by Selsius Systems (then a subsidiary of Intecom). Both the MMCX and Selsius Systems deployed packet switching technology over the Ethernet for control and communications transmission signaling. The beginning of the end of the circuit switched communications era was in sight.

There are two major differences between circuit and packet switching pertinent to to real time voice communications: encoding of communications signals and routing between endpoints. Packet switching is a communications scheme in which packets of digitized data in size-defined blocks are routed between nodes over shared transmission links. Packets are queued or buffered at each node and are usually delayed for a variable amount of time. In contrast, circuit switching is designed for a limited number of constant bit rate and constant delay connections between nodes, and provides for exclusive use of a transmission link for the duration of the communication. Packet switched networks are characterized by delay and congestion parameters; circuit switched networks by network access and blocking issues.

Computer control, digitization, and packet switching slowly transformed voice-centric communications systems over the course of three decades, causing the PBX and its telephone endpoints to eventually appear as just a another server and workstations, respectively, on the larger enterprise LAN/WAN. When voice is digitized and packetized it becomes virtually indistinguishable from other modes of communications transported and switched across the network, such as data or email-based text. When voice communications is handled like non-voice communications, it becomes relatively simple to treat all communications modes similarly for unification purposes in support of software-based applications.

PBX TODAY AS A UNIFIED COMMUNICATIONS SYSTEM (UCS)

Today’s real time enterprise communications system, whether referred to as a PBX, IP telephony system or Unified Communications System (UCS), is the culmination of more than 30 years of computer and digital design evolution. Computer control, digital encoding of analog voice signals, and packet switched routing are where we now stand. The key point to be made about today’s communications system solution is that the underlying technology and system design is ideal for supporting unified communications features and functions beyond basic voice-centric telephony operations.

If one was to identify the beginning of the evolution of unified communications, it would have to be with the introduction of Computer-Telephony Integration (CTI)-centric PBXs in the late 1990s from system suppliers such as Altigen, Shoreline Communications (now ShoreTel), and Vertical Networks (ne Vertical Communications). The product offerings initially did not support IP telephones, but desktop analog telephones with desktop-associated PC soft clients without the need for a peripheral CTI server. The generic software included support of traditional telephony features and a CTI-like soft client to simplify and facilitate standard and advanced feature/function access and implementation. Desktop client capabilities included all of the usual 1990s CTI attributes, such as directories, dial-by-name, screen-pops, and a variety of call control commands for screening and routing of incoming calls. System-level integration of basic CTI capabilities was the first step towards a full-featured unified communications offering.

Within a few years, almost all PBX systems supported a PC client option, including full feature IP softphone that could stand by itself without an associated telephone instrument. Although customer take rate of IP softphones has yet to reach the magical 10% adoption level, it was an important evolutionary step in voice terminal design. The introduction of GUI-based soft clients for wireless PDAs and cellular telephone extensions soon followed, affording system subscribers a new degree of mobility while still being connected, if not tethered, to their premises communications system. Several of the most popular cellular smartphones are supported behind most currently available IP telephony systems, including select models from Nokia and RIM (Blackberry). There is little doubt that Apple’s iPhone will become a widely used cellular extension in the next few years, as will models using Google’s Android platform.

Softphones and mobile soft client options generally do not require a peripheral applications server, unlike the early unified communications solutions that first appeared about five years ago. At that time, the new system option typically required at least one dedicated applications server working behind the core communications system. Those server(s) also interfaced to a variety of other servers, such as Microsoft Live Communications Server (LCS) if integration to Microsoft applications was desirable.

Today’s unified communications server usually interfaces to Microsoft’s Office Communications Server (OCS) or IBM’s Sametime server for a variety of non-voice desktop applications. The first major unified communications offering was Siemens’ OpenScape, originally developed in close cooperation with Microsoft. The first version of OpenScape included bundled desktop CTI elements from the 1990s with more advanced 21st century capabilities such as presence management, multimedia conferencing and Web-based screen collaboration.

Today’s unified communications system market is crowded with offerings, although there are major design and functional differences between specific solutions. Not all are based on a single server design, like OpenScape, nor are all of today’s identifiable unified communications features and functions supported. In fact many solutions, such as those from market leaders Avaya and Cisco, require multiple servers to support the full range of unified communications capabilities. Microsoft’s OCS 2007 requires up to seven additional servers (some application-specific and some operational) to provide telephony and unified communications functionality.

Although the upfront cost of a single server is relatively inexpensive, a few thousand dollars at most, maintenance and operational costs for multiple servers will add up over time. The need to interface and synchronize multiple servers, including the core telephony server, also incurs expenses for a well-trained and available IT staff should problems occur (as they usually do). Reducing the number of servers to support telephony and unified communications requirements has several financial (capital and expenses) and operational advantages, not the least being power savings at a time when being “Green” is a high priority for almost every business or institutional entity. Space and cooling savings can also be gained through a single configuration. A single-server solution may not be viable for a large enterprise configuration consisting of thousands or tens of thousands of system subscribers, but it is certainly doable for customers with small or medium line-size requirements.

Several single-server solutions currently support both telephony and unified communications. For example, Mitel and 3Com implement the integrated solution by deploying a multiple-“instances” server configuration. The Mitel Communications Suite (MCS) runs on the Sun Fire X4150 server to support a mix of communications applications, including: fundamental Mitel 3300-based telephony operations; Mitel NuPoint Messenger IP; Mitel Live Business Gateway; Mitel Teleworker Solution; Mitel Mobile Extension; and Mitel Audio and Web Conferencing. The available 3Com solution is based on an IBM System i 5xx series server running the 3Com VCX Convergence Applications Suite (including the optional Enterprise Management Suite) and the System i IP Telephony Integrated Collaboration Suite that supports integration between IBM’s Lotus Domino and Lotus Sametime applications and the 3Com VCX Convergence Applications Suite of telephony applications. The IBM and Sun servers can be programmed to simultaneously run multiple software application programs, owing to a software virtualization process that provides a complete simulation of underlying hardware requirements. Virtualization also allows a single server to concurrently support multiple operating system platforms as required for the applications software.

Although a multiple-“instances” server solution reduces hardware requirements and simplifies monitoring and maintenance operations, there remains the need to load and run multiple software programs and to support a high level of integration for seamless telephony and unified communications processes. Physical interface problems may be minimized, but logical software interface issues remain. To simplify the configuration even further, the ideal solution is to fully integrate all fundamental telephony and advanced unified communications software into a single generic program.

Siemens, who helped pioneer the market for unified communications with OpenScape, recently pioneered the market for a single server/software program solution with the announcement of its OpenScape Unified Communications (UC) Server. The new native SIP software platform is both comprehensive and modular. The three fundamental modules include OpenScape HiPath 8000 Voice, OpenScape UC, and OpenScape Video. The Medium Edition (ME) runs on a single server for customers with up to 1,000 subscribers; the Large Edition (LE) is a multi-server configuration that can support up to 100,000 voice subscribers and 20,000 UC subscribers.

In addition to providing true telephony/unified communications integration, OpenScape UC Server is based on an OpenSOA platform that will facilitate development of third-party applications software and better enable Business Process Integration (BPI) solutions. BPI is being promoted by many system suppliers and analysts as the next evolutionary step in the deployment and use of a customer’s total IT infrastructure to streamline operations, reduce costs, and create new applications that involve communications of some sort, such as outbound dialing, messaging, or conferencing.

The concept of a single server with unified software should not be surprising to those tracking the PBX market for the past few decades. Consolidating multiple products and software packages into a single system solution has been common. In the late 1970s there were standalone call detail recording (CDR) and least-cost routing (LCR) products designed to work behind PBXs that lacked these capabilities. CDR and LCR were considered advanced PBX features at the time, and not the standard features they are today. Similarly, digital trunk interfaces were not integrated into most PBXs until the mid-1980s, several years before T1-services became commonly available. Of more recent vintage, outboard VoIP media gateways were used by a variety of system suppliers before integrated circuit boards were standard IP telephony system components. Once a hardware element or feature becomes an inherent component of the core communications system, it becomes more widely used and in greater demand by customers. The availability of fully integrated software offerings may stimulate the market for unified communications, because if the application is available for the using, people will use it.

In summary, then, the evolution of the enterprise communications system looks like the timeline below. The far right-hand side shows where the evolution has been heading: the Federated Communications Server (FCS), which we will discuss in the next section.

Source: TEQConsult Group

THE NEXT STEP: FEDERATED COMMUNICATIONS SYSTEM (FCS)

What is the next step in the PBX evolutionary path? Discounting the likelihood that system designers will incorporate teleportation a la Star Trek into the communications system, presence federation is on track to be the next Big Thing. According to a recent IETF draft memo, presence federation refers to the sharing of presence information across multiple presence systems. This interconnection involves passing of subscriptions from one system to another, and then the passing of notifications in the opposite direction. Presence federation is considered in the context of interconnection between different domains, and may also be known as inter-domain presence federation.

Presence federation will facilitate and enhance the use of unified communications across multiple customer enterprises deploying different presence and messaging platforms that were previously incompatible. It is a concept similar to Q-signaling (Qsig), the ISDN-based Q.931 connection communications protocol for signaling between dissimilar PBXs in a private network. Presence federation will bring a higher level of communications across corporate boundaries, especially among members of a supply chain, and will bring a new dimension to unified communications capabilities. It will also greatly enhance the benefits that can be derived from business process integration. Real-time communications will be more efficient, because there will be fewer missed calls and piling up of messages. Shared resources can be leveraged across a greater universe of subscribers to drive down upfront capital costs on a per capita basis while encouraging a new level of employee cooperation for both planning and operational processes.

With federation, today’s UCS will evolve into a Federated Communications System. The introduction of a workable FCS is on the foreseeable horizon, only a few years away. It will require the leading system suppliers to work closely together in software design and development. Companies such as Microsoft and IBM will play very key roles, as they dominate the current desktop application market for intra-domain presence and messaging solutions. This PBX evolutionary step can particularly benefit Microsoft, because its OCS solution also incorporates traditional voice communications capabilities and may be viewed as a fully-featured PBX replacement in a few years.

The traditional PBX system suppliers must be cautious not to be shunted to the side in an FCS era with strong Microsoft presence (pardon the pun). Even Cisco must tread carefully, despite its dominant networking position, because software solutions, not hardware, will dictate the direction of the market and the lineup of market leaders. Customers may be forced to decide between a single vendor or multi-vendor solution. Each offers its own unique set of advantages and disadvantages, therefore marketing and promotion will play an important role in influencing customer buying decisions. Size and control of an installed customer base will also be important, and the installed base category will not necessarily be limited to voice-centric systems--as Cisco proved.

A follow-up article will appear prior to VoiceCon San Francisco to further illuminate the concept and workings of the emerging FCS.

Allan Sulkin is founder and president of TEQConsult Group, and is recognized as the guru of PBX market analysts and consultants. He will again be on the agenda of the upcoming Interop New York and VoiceCon San Francisco conferences, and is already preparing an updated version of his annual IP Telephony System RFP used at VoiceCon Orlando.