So Who Ya Gonna Call?

How PBX Vendors Finally Got The Message (in 1996, anyway)

Franco Vitaliano

Charging down one end of the cybertracks is a new generation of data constricted devices, like DVD, groaning under overbearing, arbitrary rules and standards, shaped and managed by a handful of consumer electronics/entertainment giants.

And from the other end of these rails, and also coming full bore, is an Internet-style computer tomorrow, with the consumer free of data limitations in time, space, and implementation.

This coming collision between closed, proprietary consumer electronics and 'open' multimedia computers is just one instance of the much larger phenomenon known as technology convergence. A case of convergence that is already well down the road to full realization is the recent techno-marriage between telephony and PCs.

In the beginning, there was the proprietary PBX (private branch exchange). It started out life as a crude device, doing simplistic control chores, like holding and transferring telephone calls. But once it got computerized, PBX vendors realized they could write custom software to add value to their now automated matrix switches. To access these new PBX-style computers, their vendors designed 'terminal' handsets. These key entry handsets spoke their own private protocols to access the unique software services on the PBX.

Smart folks realized that most of the PBX's value add was increasingly in its software. It was also noted that PBX vendors were slow to respond with new applications or software modifications. Finally, it was recognized by everybody that PBX systems were terribly 'closed,' and they locked users into a single (expensive) vendor.

Then came the 'open' PC, and everything changed. Small new companies began springing up to create a new type of PC-based telephony industry. The initial goal was not so much to replace the PBX (which is possible); but rather, to create flexible, software-driven PC-based platforms that use the PBX as a 'pass through' switching hub. This allowed users to slip free of the PBX value add stranglehold. Easy to create and use application software would be the new PC telephony market driver.

Pretty soon, PC telephony hardware companies, like Dialogic, Natural Microsystems, Brooktrout, Pika, Rhetorex, and Spectrum were all over the place. Telephony software companies also sprang up, like Telephone Response Technologies, Parity Software, Stylus Innovations, and Precision Systems.

Then, GUI-driven software development tools arrived, as did numerous easy to use telephony VBXs. These hundreds of small companies helped create a new $3+billion dollar computer telephony industry. Incredibly, all this activity went mostly unnoticed by the mainstream PC media.

But as is customary in the computer industry, a standards war soon broke out between the PC telephony hardware vendors. First came the MVIP (Multi-Vendor Integration Protocol) standard.

In 1990, the MVIP PC card vendors standardized on an internal ribbon bus that ran across and attached to the top of the individual PC cards, linking them together. The cards also have edge connectors that plug into an ISA or EISA PC bus. This high speed ribbon bus is optimized for the low latency, guaranteed response that telephony signaling demands. (There is a good analogy here between this telephony-optimized internal ribbon bus, and the IEEE 1394/FireWire external serial bus which connects together multimedia components, like digital camcorders.)

Via MVIP, you could 'tie the ribbon' around multiple vendors' cards, all of whom spoke the same telephony bus protocol. Each card could do a special telephony function, such as fax, speech recognition, voice mail, etc. However, each vendor's cards still had their own unique software interfaces that the PC application software spoke to. (Note: many of these vendors' multimedia cards also utilize DSPs.)

Moreover, these interfaces were of two different types. One accessed the call control functions, which sets up, manages, and tears down a call; and the other was for telephony media control (e.g., speech, fax, video).

Enter Dialogic, the biggest PC telephony vendor of them all with $127M in 1994 revenues. In 1993, Dialogic introduced SCSA; its own vision of a high speed telephony ribbon bus for these PC cards. Dialogic wanted to make the SCSA bus the new de facto industry standard.

The MVIP players responded. The result is that you can now mix and match MVIP-based PCs with SCSA-based PCs. But Dialogic one upped the MVIP players by introducing SCSA TAO, its Telephony Application Object framework.

The SCSA TAO framework offers two vendor independent APIs (application program interfaces; aka, device drivers) rolled into one. One API is the simple call control interface. The other SCSA TAO API is a server-oriented resources manager for distributed media control, be it over voice, fax, speech recognition, text-to-speech, or video.

Dialogic has placed its public domain SCSA TAO framework in the guiding hands of the ECTF (Enterprise Computing Telephony Forum). The ECTF intends to make the SCSA TAO framework an open API standard that will encompass both MVIP and SCSA devices, or any other switching product fabric.
The SCSA TAO framework will also support PCs running Windows, OS/2, or UNIX. But Microsoft and Novell are very much Johnny Come Latelys to this roaring PC CTI party. However, the ECTF says that SCSA TAO will also support Microsoft's TAPI (Telephony API); as well as Novell's Netware TSAPI, the primary Microsoft competitor at the networked desktop.

But unlike the TAO framework, TAPI is focused only on call control (as is TSAPI), be it on the client, or on the server. Microsoft is instead putting all telephony media control under its general, multimedia Windows APIs. In MS TAPI, telephony media becomes just one more multimedia datatype. (In TSAPI, all media control is handled directly by the applications.)

Apart from splitting off call control from media control, where the SCSA TAO and TAPI (and TSAPI) really part company is that both NT Server and Netware still have no multi-media, services-oriented resource manager. Thus, all the telephony media control can only be handled from the Windows desktop; i.e., no true distributed services telephony is possible, even with NT Server.

In marked contrast, the SCSA TAO framework is structured to be an effective service provider to WOSA (Windows Open System Architecture), as well as to other systems. So SCSA TAO and TAPI can easily co-exist, and help each other.

The above telephony-PC scenario serves as a perfect role model for what can happen in consumer electronics. No doubt, many of the PBX vendors went down kicking and screaming, clutching at their old proprietary ways. But in the end, they realized there was a whole new way to make money, and a new industry, just waiting for them.

It is only a matter of time before the consumer electronics industry must follow (albeit, reluctantly) the PBX example.

Back to main Impact article