×

SUBSCRIBE TO TMCnet
TMCnet - World's Largest Communications and Technology Community

CHANNEL BY TOPICS


QUICK LINKS




 

August 1998


To: CTI Subscribers
Cc:
ECTF, Lucent Technologies, Microsoft, Nortel, Novell, Sun Microsystems
Subject: An API Refresher Course

Tom Keating


The mills of the gods grind slowly, but exceedingly fine — those words could describe the workings of the Microsoft Telephony Application Programming Interface (TAPI). At the moment, TAPI is by no means complete. Nor is it widely used. Nor is it the only API available to developers. But — for all its shortcomings, and although we may grow impatient with Microsoft’s efforts to address these shortcomings — TAPI will improve. And, in time, it will improve some more. And … some more. Relentlessly. That being the case, we need to ask ourselves: What do we do with other APIs in the meantime?

Will other APIs ultimately compliment TAPI, or will they conflict with TAPI? Could alternative APIs give the Microsoft API serious competition, or will alternative APIs eventually become superfluous?

These questions can’t be answered soon enough to suit developers, who are eager to create applications bridging the gap between voice and data communications. Developers, however, must select APIs cautiously. Developers want capable, powerful APIs, but they also need persistent APIs. Development time invested in a short-lived API (including any time spent porting applications to an ascendant API) could be time wasted. And time wasted could translate into lost opportunities.

WHY RESORT TO AN API?
While data and phone networks weren’t designed to work together, it is possible to link these disparate systems at the application level — provided you have a common interface with which to build the applications. Such an API abstracts the hardware layer, which is a great convenience to developers. If the hardware layer is abstracted, the developer needn’t write code specific to each proprietary switch. Basically, the developer can take advantage of a system’s unique capabilities without writing a lot of unique code.

Developers aren’t the only people who appreciate APIs. Management likes them, too. Consider this: With an appropriate API, a company can deploy new and improved applications while using the same old hardware. Now what manager wouldn’t like to preserve existing hardware investments?

THREE POPULAR APIs
The CTI industry boasts three popular interfaces for linking the data network to the phone system. These interfaces include the aforementioned TAPI, the Telephony Server API (TSAPI), and the Java Telephony API (JTAPI).

TSAPI was the first successful API. TAPI came out a bit later, and has since gone through 2 revisions. Although many complained that these revisions didn’t appear fast enough, every revision, without exception, significantly improved the API. JTAPI, though newer than TAPI, is in many ways more stable than TAPI, and it enjoys use in several CTI product lines. Now, let’s take a closer look at each of these CTI development APIs.

TAPI
As you might expect, TAPI is rolled into various Microsoft operating systems. Both Windows NT Server 4.0 and Windows NT Workstation 4.0 were released with built-in support for the 2.0 version of TAPI. The 2.1 version of TAPI, which includes some enhanced features and bug fixes, is available on Microsoft’s Web site. All Windows 95 computers currently offer built-in support for TAPI 1.4 applications, which are compatible with TAPI 2.0.

Microsoft’s TAPI 3.0 is still in beta testing, so developers are currently using either TAPI 2.0 or TAPI 2.1. Those that want to be ahead of the game can take a sneak peek at TAPI 3.0, which is included in the Windows NT 5.0 beta. To get the beta, you have to be part of the Microsoft Developers Network.

The current version of TAPI distinguishes between different media streams (data, voice, fax) and routes calls to the appropriate application or device. Incoming faxes, for example, go to the fax application or machine.

TAPI is part of the Windows Open Services Architecture (WOSA). Similar to other WOSA services, TAPI has two interfaces. The first is the API for developers writing the software. The second is the service provider interface, which provides a means of connecting to a specific device.

In TAPI 3.0, the service provider interface extends connectivity to IP telephony. That is, TAPI 3.0 abstracts the connection layer such that it doesn’t matter whether you connect to the Public Switched Telephone Network (PSTN), to an ISDN network, a PBX, or an IP network.

Other features introduced with TAPI 3.0 include support for Unicode, Intel’s Universal Serial Bus (USB), and ActiveX controls. With the ActiveX controls, developers can take advantage of a component-based, graphical environment and avoid a lot of tedious rote programming. Specifically, developers will be able to combine small, specialized programs to create large applications. And, since many components will be reusable (at present, developers can access over 1,000 reusable ActiveX controls from Microsoft), programmers will be able to concentrate on those parts of their applications that are unique. Creating programs in this way is faster and allows for a high level of customization.

TAPI 3.0 will also support Active Directory integration and unified call control and media streaming (for PSTN and IP). It will provide an object-oriented, language-neutral API as well as a streaming architecture consistent with the Win32 Driver Model (WDM). In short, TAPI 3.0 will allow developers to create scalable telephony server applications.

I should point out, however, that some types of applications have been beyond TAPI. For example, TAPI 1.4 and TAPI 2.0 simply weren’t adequate for call center applications. (I suppose even Microsoft would acknowledge that.) However, TAPI 2.1 filled in a lot of missing pieces, and TAPI 3.0 may finally complete the picture, giving developers all the tools they need to create CTI applications, including applications for the lucrative call center market. Certainly, with its support for ACDs, agents, groups, and routing, TAPI 3.0 presents a palette broad enough for the creation of call center applications.

TSAPI
TSAPI, developed by Novell and AT&T (Lucent), is designed to integrate PBX or Centrex phone systems with NetWare networks. TSAPI was the first telephony API to have some (limited) success in the market, beating TAPI and JTAPI, which were developed later. However, despite its early lead, TSAPI lost momentum, apparently disadvantaged by its half-hearted marketing and exorbitant client license fees. And now that Novell has dropped its TSAPI development team, it seems that TSAPI has been cast adrift. But Lucent, Novell’s erstwhile partner, has suggested it will put TSAPI back on course.

TSAPI installations usually require that a NetWare file server be placed near or in the phone closet with a physical link to the switch. On the client side, several third-party TSAPI applications are on the market for performing call control functions. In the case of TSAPI applications running on a PC, incoming calls can execute a WAV file, which will ring over the PC’s multimedia speakers.

TSAPI makes for an excellent call control API, since applications built with TSAPI have a logical link between the PC and the desktop phone, which is controlled over the network. Call control can be performed through these TSAPI applications from either end of the connection. Alternatively, call control can be delegated to a third party. (TSAPI provides excellent third-party support.)

Unlike TAPI, TSAPI supports all the major operating systems, including Windows (all versions), the Mac OS, OS/2, and Unix. Obviously, this cross-platform support appeals to larger companies, which often need applications that can run in heterogeneous environments.

TSAPI, thanks to its client/server design, can do without a physical link between the PC and phone. That is, there is no need for additional hardware on every PC just to link the PC and phone. Certainly, this arrangement can save a lot of money in a large organization, but there is a trade-off. Because the PC and phone are linked logically (over the LAN), not physically, TSAPI applications cannot identify different media streams. For example, with TSAPI, you cannot automatically route a fax to a fax application. The ability to identify different media streams is, however, a feature of TAPI.

JTAPI
JTAPI is the Java Telephony API proposed by Sun Microsystems, which developed the specification with a handful of companies, including Intel, Lucent Technologies, Nortel (Northern Telecom), and Novell. JTAPI is essentially a set of reusable telephone call control objects, which can be used in Java-based telephony applications, which will run on any computer (write once, run anywhere) with a Java virtual machine and a JTAPI telephony subsystem. Because they are based on Java, JTAPI objects are independent of any operating system and hardware platform and are therefore portable from platform to platform.

JTAPI defines a set of class libraries consisting of a core of telephony capabilities and a set of extensions that developers can use as needed for individual applications. For example, one set of extensions handles tasks such as call routing and setting up conferences among groups of callers.

JTAPI is moving toward a new generation of hybrid phones that combine traditional telephone service with Web capabilites such as browsing and e-mail access. Sun says it is working with Nortel to develop an Internet telecommunications device that uses JTAPI to link to other phones, desktop computers, and network computers via the Internet.

JTAPI works with other telephony APIs, such as TAPI and TSAPI, to invoke telephony capabilities. And, in another demonstration of its openness, JTAPI may become a standard recognized by the Enterprise Computer Telephony Forum (ECTF). At present, the ECTF is still considering Sun’s suggestion that it accept JTAPI.

PROS AND CONS
Of the three APIs discussed in this article, TAPI is by far the most popular for telephony applications. Let’s say you’ve got an NT-based network. When the time comes for you to consider server-based telephony, you’ll no doubt decide you need TAPI.

TAPI also makes sense for many small companies. These companies would likely use a direct connection between the PC and phone, utilizing the network and TAPI’s media processing capabilities to transmit voice over the network.

TSAPI is better suited for more diverse environments running on a NetWare network. And, despite its cost, TSAPI is often cheaper to implement in non-Windows NT environments. The alternative is client-based TAPI 1.3, which requires an add-in board on each PC, which is not cost-effective.

Despite this advantage over TAPI, TSAPI’s future is unclear. TSAPI no longer enjoys Novell’s support. TAPI, on the other hand, has a strong proponent in Microsoft. In addition, TAPI continues to mature.

JTAPI is superior to TAPI in many ways, but it suffers from the "it didn’t come from Microsoft" syndrome. JTAPI could use stronger support and marketing from Sun Microsys-tems. I’ve been to several trade shows, and I’ve yet to see Sun Microsystems demonstrating JTAPI. When it comes to pushing JTAPI, Sun’s partners seem to be doing most of the work. They, unlike Sun, are actually demonstrating some intriguing JTAPI-based systems.

Many in the CTI industry speculate that the vendors backing JTAPI are motivated by their hatred of Microsoft. Others disagree, stating that JTAPI has its own intrinsic merits. For example, JTAPI has many features that TAPI lacks. (JTAPI could be used in conjunction with TAPI; however, there would be some feature overlap.)

The advantage of JTAPI over TAPI and TSAPI is that JTAPI focuses on application software, whereas TAPI and TSAPI focus on connecting computers to the phone network. JTAPI offers developers a way to define CTI functions in an object-oriented programming model, which allows them to build object libraries consisting of common CTI functions. For example, IBM introduced JavaBeans, reusable software objects that developers can use to create call center applications, including objects for transferring, answering, conferencing, and associating data with a caller. Microsoft’s TAPI currently lacks these capabilities, though TAPI 3.0 is supposed to address these limitations.

Which API will win the battle is still anyone’s guess. Most people are betting on TAPI, but I wouldn’t discount JTAPI’s chances just yet. JTAPI has strong appeal in the call center industry, which still has many non-Windows computers and terminals. And network computers (NCs) may finally come into their own, raising JTAPI’s fortunes as they do so, since it happens that NCs are better addressed through the JTAPI "run anywhere" specification.

Since CTI has its roots in the call center, JTAPI could take advantage of its popularity in the call center, consolidating its position to prepare a push into the general business desktop arena as well. But with TAPI 3.0 just around the corner, Sun Microsystems better move quickly. If it doesn’t, Microsoft will become the de facto standard for CTI at the desktop. If that happens, TAPI will eventually become the API of choice in every arena.


Scrutinizing S.100

Many developers are considering yet another API, the S.100 specification. Promulgated by the ECTF (Enterprise Computer Telephony Forum), the S.100 specification was intended, at least in part, as a way to address development needs that were not being met by TAPI. However, TAPI has grown stronger since the need for S.100 was defined. And future versions of TAPI grow even stronger. So, now that the original rationale for S.100 is becoming less of an issue, and is on its way to becoming a non-issue, the need for S.100 is becoming less clear.

Do we really need S.100? We have been told that S.100 will be interoperabile with TAPI, but what does this mean? Will a CTI developer be able to take an application developed entirely in TAPI and use a board that strictly supports S.100? Not unless the hardware board understands both S.100 calls and TAPI calls, or has a piece of middleware to translate TAPI calls to S.100 API calls. But if the hardware board understands TAPI calls, what’s the point of having the board also understand S.100? Why maintain two APIs that accomplish essentially the same thing?

And if the board does not understand TAPI, do we really want extra middleware to translate TAPI calls to S.100? Software developers avoid having their code translated into another programming language if at all possible. Extra translation introduces too many variables, and too many places where the application can go wrong. And, what if something did go wrong? How would the developer tell whether the middleware translation or the application was at fault?

In my opinion, S.100 would have been a great idea a year or two ago, when nothing else on the market addressed the need for an open telephony API. However, with TAPI 3.0 just around the corner (TAPI 3.0 will coincide with the Microsoft NT 5.0 release), I’m less than optimistic about S.100’s future.

Not only does TAPI 3.0 provide virtually all of the functionality of S.100, it also has enhanced features that S.100 lacks. For example, TAPI 3.0 supports Internet telephony. S.100 doesn’t. TAPI 3.0 supports the H.323 standard. S.100 doesn’t. TAPI supports call control. S.100 doesn’t.

Granted, S.100 is still a new standard. It may grow more capable itself. On the other hand, as a new standard, S.100 has been used in only a few products and applications. Will S.100’s limited success embolden anyone to continue refining it? If not, developers might think twice about investing time and effort toward creating S.100-based products. It’s possible that S.100 could thrive, and serve developers well for some time to come, but then again, it’s also possible TAPI will leave S.100 twisting slowly in the wind.

Microsoft has a huge installed base of application developers, partners, and distribution. Microsoft will surely take advantage of this base to push TAPI as the de facto standard for telephony development. Also, Microsoft will surely have a TAPI certification program, and this program will certainly omit any S.100 training.

Will S.100 resist the TAPI onslaught, and perhaps find a niche for itself? Some S.100 proponents suggest that S.100 can provide the media control while TAPI provides the call control. I doubt that will happen. Application developers aren’t going to be happy learning, supporting, and debugging two different sets of APIs. Today’s world is a world of convergence, not divergence. Thus, having one centralized/converged API is the only way to go.

 







Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: [email protected].
Comments about this site: [email protected].

STAY CURRENT YOUR WAY

© 2023 Technology Marketing Corporation. All rights reserved | Privacy Policy