A Brief History of UC&C, Part Two: The IP PBX

We'll continue today with our brief historical review on factors that have contributed to the evolution of unified communications and collaboration, picking up where we left off last time when we discussed how carriers first chose to use Voice over IP in the PSTN -- focusing on how the IP PBX came into being.

We'll continue today with our brief historical review on factors that have contributed to the evolution of unified communications and collaboration, picking up where we left off last time when we discussed how carriers first chose to use Voice over IP in the PSTN -- focusing on how the IP PBX came into being. 

The IP PBX was a third generation of automated private branch exchanges, following "cord-boards" and human operators, replacing people first with on-premise circuit switching on premise and then by adding a whole other generation of ISDN features. The PBX allowed for shared incoming and outgoing trunk lines and essentially bypassed the PSTN for internal, on-campus calls, thus promoting savings for many businesses. ISDN added to the feature set with services like caller ID.

ISDN: Where did it go wrong?

As was the case with the PSTN that faced increasing usage of the Internet, so too was an evolution taking place in the enterprise as businesses started to install local area networks (LANs) to move data traffic between employees, connecting these campus LANs to wide area networks (WANs) with services like frame relay (FR)and ATM. Although the battle for the winning WAN protocol was begin fought between FR and ATM, IP was already the clear winner as the preferred LAN protocol, typically being run over an Ethernet LAN. Enterprises were faced with a growing need to fund and support internal IP data networks, and they looked to converged voice and data networks as a way to increase efficiency and save money.

Circuit-switched PBXs and ISDN PBXs were not, however, well suited to run on IP data networks for several reasons, so engineers needed to come up with a few fixes. First, traditional PBXs used time division multiplexing (TDM) to guarantee a high quality of voice service, something a statistically multiplexed protocol like IP could not easily manage -- something that proper LAN engineering and use of IP control protocols eventually were built to overcome. Second, even if internal voice traffic could be routed between callers, off-net calls still had to connect to the PSTN, so H.323 gateways had to be put in place to translate between PSTN and IP PBX protocols. And third, legacy desktop phones didn't connect to an Ethernet/IP network, so users who wanted to use VoIP had to either install VoIP-compatible phones or gateways that would allow traditional phones to connect across the data network.

A BRIEF HISTORY OF UC: Part One | Part Two | Part Three | Part Four | Part Five

Several other outside factors contributed to the appeal of an IP PBX. For example, the introduction of servers in the LAN also established an infrastructure that allowed the IP PBX to be largely a software-driven system that could work on readily available hardware, lowering the cost and speeding up the feature development cycles when compared to legacy PBX infrastructures. IP-based protocols like XML, VXML and HTTP helped make more advanced features like call center integration a standards-based development effort, again improving costs and feature design efforts.

In summary, it was a "perfect storm" of factors that helped to create the need for and the technology basis for today's IP PBX, including the growing use of IP protocols, advances in computing and the ongoing business need for network efficiency.

Next time, we'll look at the importance of unified messaging and SIP. Read Part 3 of this series.

Learn more about this topic

A Brief History of UC&C, Part One: VoIP and the Softswitch

How dead is the PBX really?

Moves afoot in US, elsewhere to end PSTN copper lifeline

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT