December 1997

BY JIM ZUBER, GENOA TECHNOLOGIES, INC. AND SCOTT SORENSEN, CORESOFT TECHNOLOGIES, INC.

Computer-telephony integration (CTI) evangelists are beating the drums of “shrink wrap PBXs” and “channel ready hardware” with good reason. When Plug & Play telephony becomes a reality, our rapidly growing CTI market will accelerate to warp speed. To that end, one of the major Plug & Play enablers — Microsoft’s Telephony Application Programming Interface, better known as TAPI — deserves a closer look.

The promise of TAPI is to allow any Windows-based CTI application to work transparently with any hardware device supported by a Windows Telephony Service Provider (TSP) driver. This goal is accomplished by having all applications write to a common programming interface (TAPI) and for all hardware suppliers to develop drivers that talk to a common Telephony Service Provider Interface (TSPI). The Windows operating system acts as the intermediary between these two layers, isolating the application from the details of the hardware.

This article will explore why TAPI comes up a bit short in achieving this objective, and will offer some suggestions as to what might be done to improve the situation. A general overview of some of the technical elements involved in TAPI can be found in the sidebar entitled, “A Quick Look at TAPI.”

WHAT’S THE PROBLEM?
The fundamental problem with Plug & Play in TAPI is that very little of TAPI’s defined behavior is mandatory. Of the 129 TAPI function calls defined in the 2.0 specification, 89 are optional in their implementation. This is why most off-the-shelf applications are rather trivial in their capabilities. If you use the more robust TAPI function calls, there is no guarantee they will be supported across a variety of Telephony Service Providers.

The updating of status structure members is device dependent. If a service provider can’t tell how many calls are on hold, it isn’t required to update this status. Application developers aren’t sure what they can count on, so they typically use a very small subset of the available status structure information. Almost everything about callback messages is implementation dependent. An identical scenario on two different Telephony Service Providers may result in a dramatically different sequence of messages. The number one interoperability problem for application developers is sorting out the differing message behaviors from various Telephony Service Providers.

Good programming practices and a thorough understanding of TAPI can overcome many of these obstacles, but the reality today is that most robust applications must be tested on each service provider they plan to support. This is hardly a Plug & Play state of affairs. Microsoft recognizes this issue and has tried to deal with it by holding periodic “bakeoffs,” where developers can identify and solve interoperability problems.

A REAL-WORLD EXAMPLE
Coresoft, an Orem, Utah software developer, has released CenterPoint, a communications manager environment. During the initial development effort, Coresoft tested their application across 4 TAPI service providers and are currently working to integrate with a number of other TSPs. While integrating their application with these TSPs, they found considerable differences between the various implementations. The following examples illustrate these problems: Even though conference calls can be initiated by using the lineSetupConference function call, not all TSP implementations support this function call.

Most TSP implementations do, however, support conferencing by using the lineSetupTransfer() function call and the lineCompleteTransfer function call with an option to conference. In one case, the TSP implementation did not support any method for conferencing. Most TSP implementations provide a LINE_APPNEWCALL when the receiver is taken off-hook to generate a new outgoing call, but some do not. Receiving notification of a new call when the receiver is lifted allows CenterPoint to pop a “hot list” of frequent contacts, which the user can click on to dial the number. In one implementation the LINE_APPNEWCALL is not sent unless the user begins dialing the phone. This does not allow CenterPoint to pop the “hot list” of contacts for the user to choose from. The problem is that TAPI doesn’t specify the exact point at which a message should be sent.

There is no consistency in the information available in the LINE_CALLINFO structure. A useful feature for an application would be to display a calling number ID, as well as a called number ID. In order to display these numbers when a call is made, the application needs to get a message when the phone is dialed, indicating the structure has changed, and the LINE_CALLINFO structure needs to have the caller ID and the called ID. Currently, of three implementations, one supplies the caller ID, one supplies the called ID, and one doesn’t supply anything at all.

Testing the CenterPoint application is complicated since different TSP implementations will probably exercise different code paths in the application. The complexity increases when you consider that a TSP change, which works with one integration, may not work with others. This makes the initial testing and the regression testing efforts significant and complicated.

This situation has forced Coresoft to create an abstraction layer to isolate the differences between the TSP implementations from the application; alleviating, but not solving, the underlying problem of TSP differences.

TESTING TAPI
There are two fundamental ways you can approach testing TAPI implementations. The first is interoperability testing. If you’re an application developer, you test with as many service providers as possible.

If you are a service provider developer, you test with as many applications as possible. Demonstrating interoperability does not mean everything has been tested, nor does it mean that you even conform to the TAPI specification. It just says that you work with the subset of devices used in your testing.

The second testing method is conformance testing. Essentially, you develop a set of systematic test cases that methodically exercise each aspect of the TAPI specification you implement. If you are testing a Telephony Service Provider, you write test cases at the application API layer. If you are testing an application, you write test cases at the TSPI layer (simulating TSP driver responses). While conformance testing does provide complete test coverage, it does not ensure interoperability if other devices are not playing by the rules or the rules are not defined well enough.

The bottom line is that any good testing strategy consists of both conformance and interoperability testing.

TESTING TOOLS
If you are faced with testing a TAPI application or service provider, the following tools are available from Microsoft (either on the Microsoft FTP site or on the MSDN CDs) or the other companies listed.

Microsoft’s TAPI Browser — This utility allows you to click the mouse on a TAPI function and see the results in a log window. It is useful for learning about TAPI and doing some simple TAPI trouble shooting.

Microsoft’s ESP Simulator — This is a TSP driver simulator that requires no hardware. In theory, it would be a great tool for testing an application. In practice, it comes with almost no help or documentation, and is quite frustrating to use.

GUI Testers — Rational Visual Test is the de facto standard for automated application testing. Visual Test was recently purchased from Microsoft by Rational Systems. Other popular GUI testers include WinRunner, AutoTester, and SQA TeamTest.

Stress Testers — Hammer Systems, Zarak Systems, and Ameritec offer call generators, with the Hammer product having additional functional testing capabilities.

TAPI Script Editor — Genoa’s TapiScript is a TAPI browser with the ability to build automated test scripts for testing TSP drivers. Script functions validate the conformance of messages, structure members, function return values, and call progress.

TAPI Test Systems — Genoa’s TapiTest is an integrated test system for testing TSP drivers. It includes development tools, test cases, a run time manager, and a test results archival system.

TSP Monitors — Genoa’s TapiVision monitors and displays in real time TSPI function calls and event traffic at the driver layer. It dramatically simplifies the isolation of TAPI interoperability problems. Microsoft provides a less elegant solution on its MSDN CD, called the Repeater TSP. API Event Monitor — Numetric’s Tap 2.0 product provides a real time summary of TAPI event notifications at the API layer.

SUMMARY
Some pessimists take the position that the inherent complexities of CTI make Plug & Play an impractical objective. While switching TAPI service providers may never be as transparent as swapping printers on your PC, there is reason to believe that the current situation can improve.

On the application side, the addition of an object layer between the application code and the Windows TAPI would be a good place to start. There have been numerous cries for such a layer in the Usenet groups, and some large players have developed their own libraries. Elegantly implemented, the object layer would provide a more consistent usage model for the TAPI by isolating the application from the differences between the various TSP implementations. This will only be helpful, however, if the elements of the model are guaranteed to provide full functionality across different TSP implementations.

On the TSP side, one possible solution is to define a normalized behavior for certain classes of robust Telephony Service Providers, such as a PBX. This defined behavior might include supported messages, sequence of message appearance, supported status structure fields, triggering events that cause messages to be sent and structures updated, and supported optional functions. The definition of the normalized behavior would enable application developers to develop more robust solutions without the burden of having to test them extensively for every supported hardware platform.

Jim Zuber is president of Genoa Technology, Inc., a leading supplier of test tools for CTI, facsimile, printer, and local connectivity technologies. In addition to the TAPI testing tools noted in the article (TapiTest, TapiScript, and TapiVision), Genoa offers the following additional products that may be of interest to CTI developers: USB Protocol Analyzer; Serial Infrared Protocol Analyzer and Test Suites; Facsimile T.30 Protocol Analyzers, Test Suites, and Simulators; Internet Fax Tester; and Class 1 and 2.0 Test Suites and Analyzers. For more information, visit the company’s Web site at www.gentech.com

Scott Sorensen is vice president of engineering at Coresoft Technologies, Inc. Coresoft’s CenterPoint Pro allows users to communicate with the right people when, where, and how they choose, while CenterPoint Pro is screening and directing phone calls, capturing and storing important information, assembling voice mail, email, and fax messages, and doing it automatically from one centralized location. For more information, visit the company’s Web site at www.coresoft.com.

TAPI consists of 3 primary elements: function calls, structures, and callback messages.

Function calls are the basic building blocks of TAPI. Most normal telephony activities, such as making a call or placing someone on hold, have a corresponding function call in TAPI. These function calls are used by the application to get work done. There are Line functions, which focus on call control, and Phone functions that deal with the buttons, lights, and capabilities of the handset.

Structures are used to store the capabilities and the current status of the Telephony Service Provider (i.e., hardware). Applications query the capabilities structures to learn what a device can do, such as the TAPI features it supports. The status structures are used to determine things such as the current number of lines on hold, the caller ID of an inbound call, and the valid TAPI actions that can be taken while a call is on hold.

Callback Messages are sent to an application when anything changes state in the Telephony Service Provider. Some of these messages have obvious meaning, such as notification of a new call arriving or a call reaching a connected state. Other messages simply indicate that one of more members of a status structure has changed. The application must examine the status structure to determine the exact nature of the change.