November 1997

BY BROUGH TURNER

Microsoft has had a public position in computer telephony (CT) for several years now with TAPI — Telephony Application Programming Interface. A variety of desktop call handling applications have emerged, based on TAPI, and, in the past two years, Windows/NT has made significant inroads into server- and enterprise-level computer telephony. But until recently, these trends have been independent. Server-based CT applications like voice mail or voice response have used proprietary APIs and diverse software tools from dozens of companies. Except at the desktop, Microsoft has not been a driving force in computer telephony. This is about to change.

A SLOW START
TAPI was introduced in 1993 as an API for placing and receiving telephone calls. It allowed a computer program to do the kinds of call control you could do with the telephone set on your desk. Used strictly for call control, with some DTMF handling, TAPI was not integrated with media APIs — even though Microsoft had media APIs available in 1993. TAPI 1.0 also lacked effective PBX integration. So, TAPI was adopted for desk-top applications that needed only call control. It made little headway in computer telephony server systems. To this day, TAPI is not a fundamental portion of most customer premise auto-attendant, voice mail, or IVR systems. If included, it’s likely to be a “check-off” item, not a core piece of the product.

Another reason for TAPI’s slow start, and its relegation to low-end applications, was competition. In 1994, Novell was still the undisputed leader in PC LANs. In partnership with AT&T, Novell had introduced TSAPI (Telephony Services API), a client/server API that successfully addressed PBX integration and call center automation. So Novell won the high-end call control business and no one addressed the tools that fullfeature computer telephony systems require. Once again, Microsoft has lived up to their reputation for releasing a product that is not quite ready, and then fixing it over a period of time. Remember, Windows took three major revisions and 6–10 years before it became the useful — and dominant — operating system it is today. TAPI seems to be on a similar course. TAPI 1.0 lacked features, modeled only the desktop telephone, and had a reputation for being hard to use, but it got Microsoft into the CT market.

A CHANGING ENVIRONMENT
Now the industry is changing and so is TAPI. Four years later, OS/2 is just about gone. UNIX is still viable, but Windows NT is getting the press, and the new design wins. Microsoft has evolved TAPI to provide PBX control, call center features, and client/server functionality. And, Microsoft has waged a successful marketing war against Novell. With the advent of TAPI 2.1, Microsoft now has caught up with or surpassed TSAPI features, while maintaining dominance in desktop call control.

Still, neither party has addressed the rest of the tools needed for midrange or high-end computer telephony systems. Today’s voice mail and IVR systems are typically based on standard hardware with Windows NT or UNIX, but with vendorspecific APIs and application development tools. Each component vendor has their own family of C or C++ APIs. Most IVR vendors provide their own proprietary programming environments. And there are dozens of smalland medium-sized vendors with application development environments for computer telephony. These frequently include GUI tools or state table programming systems, together with a runtime environment and administrative tools. Each development environment is specific to one vendor. There are no broadly adopted industry standards.

THE MISSING LINK
What’s missing is integrated media services. After your voice application has received a call, how do you initiate a voice prompt? Microsoft has had a set of Wave APIs for a number of years. These let you play or record audio files over an I/O device, but integration with TAPI has been cumbersome to nonexistent. When you placed a call using TAPI, there was no easy way to coordinate Wave outputs to that telephone call. The Wave APIs were developed for SoundBlaster boards and for desktop audio, not for telephony. TAPI functions that recognize touch tones couldn’t easily be used to terminate a Wave play function, so IVR, as we know it, didn’t work. These problems, plus the lack of a fax API, left the computer telephony industry on its own.

This situation is about to change. Microsoft has started a beta test of TAPI 3.0 (targeted for release with Windows NT 5.0 in mid-1998). A careful look shows Microsoft is not just fixing TAPI, but they are taking a very forward-looking approach to the whole subject of telephony. TAPI 3.0 starts with a common framework for telephony in the public switched telephony network (PSTN) and the Internet. While brand new, Internet telephony (or IP telephony) will be the highest growth market in the future. And with TAPI 3.0, Microsoft is positioned to dominate this new field.

TAPI 3.0 DETAILS
The most important fix is the integration of media streaming with telephony call control. TAPI 3.0 now incorporates Microsoft’s DirectShow and WDM streaming APIs for audio and video. These APIs have been evolved to provide highperformance, low-latency streaming, and switching for voice telephony. But there’s more. Beyond traditional voice telephony, TAPI 3.0 provides the same interface whether your telephone call is over the traditional PSTN or over the Internet. And over the Internet, there is the potential to support point-topoint audio and video, multipoint conferencing, and new applications we haven’t even thought of yet. TAPI 3.0 brings a COMbased interface (COM is Microsoft’s common object model, an objectoriented programming framework). So, TAPI 3.0 promises to be accessible from Visual Basic, Visual C++, Visual Java, and an emerging set of COMenabled development environments. This approach has the potential to open up computer telephony to over three million Windows developers. Another potential benefit of the COM framework is that TAPI 3.0 will work across a number of servers and thus be highly scalable.

Other features of TAPI 3.0 include integration with Microsoft’s emerging directory services APIs (Active Directory) and a backwards compatibility mode that preserves TAPI 2.1 operation for existing TAPI applications.

By integrating media functions with telephony call control for both IP Telephony and traditional telephony, Microsoft is stealing a march on existing computer telephony vendors. IP telephony will be the highest growth segment of computer telephony in the next 2–5 years. Meanwhile, traditional telephony is needed for the installed base of users and today’s accepted computer telephony applications.

A single solution is the optimum approach. Consider, in an interactive voice response session, you are trying to get information from a server. It shouldn’t matter if you are doing that via a Web site that is providing information to your Web browser; via a Web site that i s p roviding streaming audio, video, or seemingly live interactions with an IP telephony client like NetMeeting; or via voice and DTMF interactions over the existing PSTN. The reality is that there is one goal — to make a source of information available to users over a variety of different media.

Being able to accommodate all media and all delivery channels is the way to go.

THE WAY TO THE FUTURE
Microsoft has spent the last four years learning about our industry. Now they are poised to make a real impact. They have released a competitive call control product (TAPI 2.1). And they are about to introduce a product (TAPI 3.0) that appears to be significantly better than anything else currently proposed. As a result, it becomes risky to build solutions around existing APIs, or proposed “standard” APIs such as the ECTF’s S.100 specification, without understanding how these APIs are going to interoperate with Microsoft’s road map for computer telephony.

Everyone in the market today needs to pay attention. Platform providers need a plan that supports Windows NT and TAPI 3.0, and application developers need to pay close attention. A big impetus for the computer telephony market has been the wealth of software development tools available on PCs. The quality of these tools will get substantially better over the next 2–5 years. And right now, it looks like progress will follow a new paradigm — dictated by Microsoft. Consider, all of telecommunications is in Microsoft’s sights. Windows NT is gaining market share in the telecommunications sector. And Microsoft controls the APIs for Windows. So any reasonable Microsoft offering would be widely used. But with TAPI 3.0, Microsoft’s beta product and product road map are more impressive than the architectures and frameworks coming from the rest of the industry. It’s taken a while, but Microsoft has developed a clear understanding of the technology and a strong vision for what is possible.

Of course, nothing happens overnight. And, products can take longer than expected to emerge from beta testing. So, 1998 may be just a leading indicator. Low- and mid-range customer premises applications will migrate to TAPI 3.0 first. Central office applications and other high-end computer telephony applications will take much longer. But as the Windows-based application development environments continue to get richer, Windows NT will penetrate every corner of computer telephony.

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 620-9300 or visit the company’s Web site at www.nmss.com. E-mail to the author ([email protected]) is also welcome.