January 1998

BY BROUGH TURNER

The Private Branch Exchange (PBX) is about to be redefined, but not the way most people expect. Despite years of talk, today’s PBX remains an expensive, proprietary solution with limited customization capability. It’s built on an obsolete architecture — dumb terminals (telephone sets) connected to a proprietary mainframe (the PBX itself) with private wiring. These alone are compelling reasons for change, but to what? The emerging “PC PBX” opens up the central box, but preserves the core architecture. The ultimate solution is: packet-based telephony built on open platforms (i.e., PCs), connecting standard terminals (PCs and telephone sets), over shared wiring (the LAN). Signs of this impending change are now becoming visible.

THE BENEFITS OF RADICAL CHANGE
Moving to an open, packetbased PBX solves many of the problems mentioned above. Businesses leverage their LAN infrastructure, simplify management issues, and reduce costs. No longer is the telephone wiring restricted to a single topology — a star connection of copper twisted pairs. A packetbased PBX leverages LAN infrastructure with its choice of topologies — buses, stars, bridged segments, and so on — and its choice of cable types including twisted pair, coax, and fiber. PBX call control becomes just another software application running on a server, and there’s flexibility in the choice of that server. It can range from a lowend clone PC to an extremely highend, redundant, fault tolerant, industrial PC server. The architecture can be distributed, creating a robust, faulttolerant system. And, there will be a choice of gateways for use between this LANbased PBX and the legacy PSTN.

Of course to build such a system, one needs a new kind of telephone. One approach is to use a PC as the telephone. This enables some very useful applications, but a PC-based telephone is too cumbersome for day-to-day calling. And PCs are too expensive to deploy in the mailroom! The telephone is a simple, relatively inexpensive device that people master at an early age. In fact, the telephone’s simplicity can be turned around to improve the way a PC works.

Today, the only standard telephone set is the simple analog phone used in our homes. All of the fancier telephone sets used with PBXs are proprietary. As the computer industry and the open telecom mindset takes over traditional telephony, open, programmable telephone sets will emerge. Once the telephone is a programmable client on the LAN, all sorts of new applications will appear.

Sound quality is also up for improvement. The sound of today’s telephone is little changed from that of a 1920s telephone. Its 3 kHz audio bandwidth is a holdover from the 1880s. The choice of 64 Kbps channels for digital telephony was made because that’s what it took to represent 1880s bandwidth using 1960s transistors. Meanwhile, from experiments done in the video conferencing community, we know that wider audio bandwidth — 7 kHz, for example — greatly improves the perceived quality of a multiparty conference call. With packet-based telephony and today’s digital signal processors (DSP), we can finally break free from the 3 kHz legacy. With 7 kHz or better audio, you will actually be able to spell your words and have the other party distinguish letters like “s” from “f.” It’s also clear the traditional division between MIS and the telecom department will finally disappear. MIS will gain control. With an open, LANbased telephone system, administration will be simplified and costs will be cut dramatically — not just first costs, but the continuing costs of adds, moves, changes, and on-going support.

WHY NOW?
There are many forces driving change in the telecom industry. Today, time-tomarket for new products is limited by our ability to develop software. Open computers and IP networks provide the richest possible software development environment, so they have a major impact on all new products and applications. In addition, because of modern DSPs, packetbased telephony is significantly more efficient than traditional 64 Kbps telephony.

There are no major obstacles to deployment of packet-based PBXs today. A PBX typically serves only one building or part of a building — the same scale as a LAN. The networking industry is scrambling to provide Quality of Service (QoS) guarantees on IP networks, but this is not a problem on a LAN. LANs can be over-provisioned very inexpensively and LAN segments are easily subdivided using switching hubs or routers. IP telephony has already proven that packet voice can be supported on a WAN. Implementing packet voice on a LAN is much easier, much less expensive, and introduces a lot less latency. Any incremental costs incurred in making a LAN-based telephone set will be made up in savings on PBX line cards.

Today, the incremental cost of manufacturing an Ethernet-connected packet telephone set may range from $3 to over $30 above that of a comparable proprietary digital display phone — over $30 for an H.323-compliant telephone, but much less for a phone that supports only a subset of H.323. While the packet telephone may cost more, these telephones communicate directly with each other — there is no corresponding PBX line card. As a result, the total system costs less. With increased volumes and evolving integrated circuit technology, the cost increment for telephones will continue to shrink.

The technology for building the gateway between LAN-based telephony and the PSTN is also available today from a variety of vendors. Components are also available to easily build gateways between LAN telephones that implement only a subset of H.323 and full H.323 telephony.

The end result will be a PBX replacement consisting of application software running on an NT or UNIX server in the MIS department, a gateway to the PSTN built out of open telecom components, plus individual telephone sets that plug into standard Ethernet wall jacks. There are no major obstacles! But, there are a few issues to resolve.

UNRESOLVED ISSUES
Should the new telephone set be completely standards based? This would be nice, but may be expensive. Also, not all of the necessary standards exist. H.323 defines how a terminal should communicate, but it doesn’t define how to download new applications to run on that terminal. If your communications terminal is a PC, then Windows 95 is the de facto operating environment. And, with a browser loaded, you can also count on a Java execution environment. If the terminal is a telephone, Windows 95 is overkill! Do we sign up for Windows CE? Microsoft would like that. Do we provide a Java execution engine? Sun would like that. Or, do we get by with a something much smaller?

Just to put things in perspective, running Windows CE and a full H.323 protocol stack will require a respectable processor with several megabytes of memory. An echo canceler requires special hardware or 2 to 7 MIPS of DSP power. The G.723.1 vocoder, agreed upon by the VoIP Forum, requires another 20+ MIPS of DSP power. Add in the Ethernet interface and the total is easily $30 or more today, even in moderately large volumes. Of course as integrated circuits improve and volumes increase, this cost will come down.

Another viable, and less-costly, solution is to build phones that support a subset of H.323 and use a gateway to access the public Internet, much like the gateway used to connect to the legacy PSTN. For example, maybe it isn’t necessary to support the full G.723.1 vocoder; maybe uncompressed audio is sufficient within the building. After all, the LAN has plenty of bandwidth. This approach could drop the incremental cost of manufacturing packet telephones to under $10 right now and perhaps near $0 in the future. Another issue that has to be addressed is delivering power to the telephone. In existing PBXs, power is delivered over the private telephone wires. Today’s Ethernet infrastructure supplies no power. The immediate way to solve this problem is to use a local power adapter.

Such adapters are already common with speaker phones, answering machines, and other telephone devices. Another solution is to use an extra pair of wires in the existing LAN cables. Finally, one of the Ethernet standards committees is looking at ways to deliver 24 V or 48 V “phantom power” over standard Ethernet wiring. This could be done without an equipment redesign, but it would require the addition of a simple power adapter in the wiring closet with the Ethernet hubs. Supplying power to the new telephone sets is an open issue, but there are solutions available today and other options being explored. The biggest issue, however, is how we reach an industry or de facto standard for packet telephone sets.

STANDARD VS. OPEN TELEPHONE SETS
Since packet-based telephones do not require central PBX hardware, they will show up in computer distribution channels along with the LAN components. All you’ll need for in-building communications is two or more phones and a diskette. To connect to the PSTN, you’ll need an interface box or a telephone board that plugs into a PC server. As a result, the traditional PBX busi-ness model will change. To guess at the new business model, one should look at the LAN equipment business and, for the phones, at the evolution of devices like Sound Blaster and Palm Pilot. The vendor who establishes the dominant standard for packet telephones will do it with a combination of price-performance and third-party applications.

In addition to an open interface at the Ethernet jack, there also needs to be an open way for third parties to access the telephone to perform initialization, control the display and get notified of button presses. The ultimate telephone will support software updates including download of third-party code. It’s nice to think about a telephone with a Java engine, but it is more important to have an open environment, at an affordable price, than a standard environment at a high price. 3COM (formerly US Robotics) provides a proprietary but very open environment with their Palm Pilot and they have certainly attracted a wide variety of thirdparty applications ( www.palmpilot.com ). A packet-based telephone set as open as 3COM’s Palm Pilot will be sufficient. When this telephone emerges, the packet PBX market will explode.

THE RACE TO MARKET DOMINANCE
So who’s active in this market? So far, it is small, start-up companies. You’d think the traditional PBX vendors would be trying to figure this out, but the computer business may still be too much of a leap for them. A more likely large company would be one that sells LAN infrastructure, such as Cisco, 3COM, or Bay Networks. After all, LAN telephony will increase LAN traffic. But it’s possible that a littleknown start-up will win the race.

Several companies have gone public with products or plans. Selsius Systems in Texas has announced LAN-telephony with Ethernet. NBX in Massachusetts has not announced a product, but has made presentations at investor conferences, saying they are working on such a system. Neither of these companies has mentioned highquality audio (better than 3 kHz). Aplio of France and California has announced an interesting box that allows an ordinary telephone to connect to the Internet, but their focus is dialup access to the public Internet, not LAN telephony. There are ATM-based solutions from Sphere and Mitel, but since ATM-to-the-desktop is not happening, they’re not relevant. And of course, there are a lot of companies implementing packet voice using PCs as telephones — companies such as Phonet, TouchWave, and Wildfire. This is a viable approach, but not a direct threat to the PBX. Compared to a telephone, the PC is too expensive and too complex for general telephony.

So nobody has it completely right yet. But the time is right and the action has begun. In less than three years the major PBX vendors will be under pressure and scrambling to react as the computercentric open telecommunications world encroaches on their core business.

Brough Turner is senior vice president of technology at Natural MicroSystems, a leading provider of hardware and software technologies for developers of highvalue telecommunications solutions. For more information, call Natural MicroSystems at 508-620-9300 or visit the company’s Web site at www.nmss.com . E-mail to the author ([email protected]) is also welcome.