Volume 11 Number 8
March 6, 1995

Busy Signals

The integration of computers and telephones, after a slow start,
is starting to yield some interesting new products and companies

Do you want your telephone to live inside your computer, or the other way around? Probably most of us are so accustomed to the specialized roles of these devices that we would just as soon avoid such brain teasers and keep them separate. Fortunately or unfortunately, that doesn't seem to be an option. The onward rush of technology has decreed that computing and telephony are to converge, resulting in a hybrid that has already acquired its own acronym - CTI, for computer-telephony integration. Trying to understand how to leverage this integration into opportunities for new products and companies is not an easy assignment. Many bits and pieces of the technology are hard to identify, harder to understand, and harder still to turn into real applications that will sell. It may well be that CTI calls for the most demanding aspects of two worlds: the deep pockets required to run a successful phone vendor service along with the deep engineering and marketing talents required for the computing side of the equation.

We all have some intuitive understanding that CTI will benefit the people who run call centers, dispatch service technicians, or telemarketing operations administrators. But for the vast majority of office workers, the compelling applications aren't here yet. So far, CTI has a ratio of actual shipping products to announced interfaces, partnerships, and intentions that is far too low for our taste. However, as our consultant friend David Strom tells us, there is plenty of activity going on behind the curtain in two different areas - on the desktop and at the network server/PBX level.

To maximize possible confusion, both Microsoft and Novell have come up with a multitude of proposed architectures and interfaces, all covering different parts of the CTI map in various incompatible ways. It's not possible to choose one camp and ignore the other because both have gained strong industry support; Microsoft has Intel and most of the Wintel hardware makers on its side, while Novell has joined Apple Computer, AT&T, IBM, and Siemens in a standard-setting consortium called Versit. All this turmoil has had one certain result: developer paralysis. Only now, some two years after the first CTI interfaces and architectures were promulgated, are serious numbers of applications starting to appear.

Easy for us to say

On the desktop side of things, the components needed seem simple enough: A combination of a fax/data modem, a voice card, and a sound card should give any personal computer the ability to place and receive calls. There has to be a phone connection, which can either be a standard analog line or a digital PBX line. And, of course, software is needed to enable communications back to the phone switch and to link a contact manager or communications software with the telephony gear.

Here's where that brain teaser pops up: Should the computer - that is, the primary call-processing software - be inside the phone equipment, or vice-versa? Microsoft, interestingly enough, is trying to play both sides. It promotes an application programming interface that puts the phone inside the computer, called Telephony API (or TAPI), and also a software design that puts the computer inside the phone and other office appliances, called Microsoft at Work. To make matters more confusing, TAPI is actually part of the At Work architecture. There are a variety of hardware products available now that include a TAPI service provider driver, and the Windows-based applications needed to make them useful are just beginning to make an appearance.

Reluctant debutante

TAPI has been a slow starter for a variety of reasons. For one thing, hardware support has often been flawed. For example, some products don't provide power to a phone headset; if your PC is turned off, your phone is dead. More importantly, the interface was caught in never-never land between Microsoft's delays on Windows 95 and hardware vendors' reluctance to keep up with changes in the API. TAPI was originally focused on call control (forwarding, answering, and transferring calls) rather than on what the telephone industry calls media access - the ability to actually understand the voice stream in any call and incorporate it into applications. Finally, support for a variety of PBXs was slow in coming.
Many of these issues now seem to be resolved. Microsoft has expanded the interface to include media access mechanisms. And at the last TAPI "bakeoff," a product event sponsored by Intel to demonstrate the interoperability of applications, over 50 vendors showed off their wares. As might be expected with a market opportunity that is just emerging, a flock of new or young companies is taking the lead. These include Answersoft, with integrated contact-management software for call centers; Octus, Clearwave Communications, and Softtalk International, with call-management applications; and Latitude Communications, with a TAPI-based voiceconferencing system. In the area of development tools, Stylus Innovation is marketing a graphical toolkit for more specialized TAPI applications. And a product called T-Server from Genesys runs over a Windows NT or Unix network to handle call control, voice response, and other applications.

Holding pattern

Now the big problem for all these companies is that TAPI is part of Windows 95, meaning that the nascent CTI industry will be on hold until the new operating system ships. (It's possible to develop TAPI applications for Windows 3.1, but the software tools required are still in beta form and subject to change.) There are some impressive elements of TAPI in the latest beta version of Windows 95. For example, there are features that allow the user to specify the location for all applications, including the area code, dialing access code, and time zone. Another Windows 95 feature is called "unimodem" drivers, which amounts to built-in support for most modems. Think about what Windows did for printer drivers, and rejoice if you are tired of having to track down a driver every time you get a new modem. We don't, however, plan to start celebrating until Windows 95 enters the real world.
As for Microsoft's mirror-image initiative, the At Work interface can be found as a part of the presently available Windows for Workgroups. The idea here is to have a Windows interface (and potentially an Intel processor) inside fax machines, laser printers, and, yes, even telephones, allowing a user to monitor and control these office appliances from a desk. This has lots of intuitive appeal. However, so far At Work hasn't, well, worked. Out of the numerous initial supporters, few have shipped anything. Part of the problem may be Microsoft's licensing strategy for At Work, which is reported to be onerous in the extreme. Another issue is that the market for a smart fax machine or printer is limited by the cut-throat margins on these products. Finally, it seems clear that office-machine vendors, like everyone else, are waiting to see what havoc Windows 95 will bring to the desktop marketplace.

Nesting instinct

Meanwhile, Novell has taken a page from Microsoft's playbook and is trying to put NetWare inside the office appliance. The strategy is called NetWare Embedded Systems Technology or NEST; it was announced in late 1993 and a NEST software developer's kit began shipping in February. NEST is similar to Microsoft's At Work in concept: take ordinary office devices and add intelligence. But NEST encompasses more than telephony-related applications, and it is more network protocol-related than At Work. As a result, most of those who have gotten involved with NEST are printer vendors and others traditionally in the network computing camp.

But NEST is attracting CTI adherents. One PBX vendor, Securicor Telecoms of Eynsham, U.K., used NEST technology to build an Ethernet interface to a NetWare server, which is used to provide media access for PBX calls through the NetWare network. Securicor could have built its own Ethernet driver but it took less time and effort using NEST. NEST seems to provide an opportunity for the major telephony vendors to combine the media access and call control layers into a solid application, and we look for more examples to arrive in the next few months.

Sunday driver

On the server side of the CTI revolution, Novell's Telephony Services API (TSAPI), introduced in late 1993 for NetWare, is the early leader. Just about every major PBX vendor has either announced support or shipped drivers for the first version of TSAPI, which has been out for nine months, and a new version of the interface is expected shortly. Still, TSAPI-based applications have been slow to arrive. One reason is that Novell's Telephony Services for NetWare, a kind of construction kit used to incorporate TSAPI in third-party applications, carries a steep price tag of $100 to $250 per user. Add to this the $10,000 or so required for adding voice processing to a PBX, or junking this costly equipment altogether, and you are talking about real money. The fact that TSAPI supported just a few PBXs until recently and that media access still isn't part of the TSAPI specification makes it difficult for vendors that want to include this capability in their products.

Despite these handicaps, it is possible to develop and ship a moderately priced CTI application based on TSAPI, as a new product from CallWare Technologies demonstrates. Formed by a combination of old-line telephony engineers and Novell marketing executives, CallWare is aiming squarely at replacing proprietary voice-messaging systems with off-the-shelf PC components and software that uses a NetWare server to store messages and voice prompts. CallWare doesn't require TSAPI, although it will work with the interface. Because no NetWare voice-card drivers exist, CallWare's engineers ended up writing one themselves for the Rhetorex card - proving that CTI progress doesn't have to wait on infrastructure components from above.

CallWare's software has two basic pieces: a series of NetWare Loadable Modules (NLMs) that run on the NetWare server and a Windows utility that allows a user to manage a voice mailbox. What Mr. Strom liked in the demonstration he saw was the convenience of using Windows - when in an office and connected to the network - to see a voice mailbox at a single glance, and yet when travelling, still being able to use a phone for these tasks.

Me, too

Microsoft, of course, is not about to be left out of the server picture. When TAPI was first announced, it was assumed that companies would want to connect a modem (or some other telephony-capable device) to every desktop computer in the enterprise. This was unrealistic because analog phone lines cost money in organizations that have digital PBXs - more money these days than the modems do. Having dial-up access to each desktop is a security nightmare as well, since office workers can leave their computers turned on, logged in to the corporate network, with a modem ready to answer a call.
To counter these issues, Microsoft has announced plans to extend TAPI over a network connection. This means that a network server (typically Windows NT, although it could be anything that has the appropriate server driver software) is connected to a PBX and passes call information back across the network and to the appropriate desktop. While the TAPI extensions will eventually support more network servers than TSAPI, they currently support only Windows clients while the new version of TSAPI is expected to provide for multiple clients including Macintosh, NT, OS/2, and UnixWare machines. But the TAPI extensions contain media access support, something Novell still doesn't have formulated.

Dialing for dollars

Going back to our original brain teaser, it's still not clear exactly where the computer should start and the telephone leave off. What is clear is that CTI is still very much in flux. The industry needs, among other things, lower prices on the PBX add-ons that enable computer connections; development toolkits that support the greatest number of PC and Mac clients and PBX interfaces; Windows 95 shipping in volume and achieving significant acceptance; and perhaps a new generation of low-cost modem chip sets capable of concurrent voice and data transmissions. As all these factors become realities, major developers will be encouraged to write new and exciting applications. In the meantime, CTI remains a pioneer's opportunity with all the risks - and rewards - that designation implies.

Volume 11 Number 8 March 6, 1995