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 Microsofts 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 cant 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 werent 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 neednt write code specific to each proprietary switch.
Basically, the developer can take advantage of a systems unique capabilities without
writing a lot of unique code.
Developers arent 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 wouldnt 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 didnt 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, lets 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 Microsofts Web site. All Windows 95 computers currently
offer built-in support for TAPI 1.4 applications, which are compatible with TAPI 2.0.
Microsofts 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 doesnt 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, Intels
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 werent 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,
Novells 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 PCs 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 Suns 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. Lets say youve got an NT-based network. When the time comes for
you to consider server-based telephony, youll 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 TAPIs 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, TSAPIs future is unclear. TSAPI no longer
enjoys Novells 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 didnt
come from Microsoft" syndrome. JTAPI could use stronger support and marketing from
Sun Microsys-tems. Ive been to several trade shows, and Ive yet to see Sun
Microsystems demonstrating JTAPI. When it comes to pushing JTAPI, Suns 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. Microsofts TAPI currently lacks
these capabilities, though TAPI 3.0 is supposed to address these limitations.
Which API will win the battle is still anyones guess. Most people are betting on
TAPI, but I wouldnt discount JTAPIs 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 JTAPIs 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 doesnt, 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,
whats 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), Im
less than optimistic about S.100s 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 doesnt. TAPI 3.0 supports the H.323 standard. S.100 doesnt. TAPI
supports call control. S.100 doesnt.
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.100s 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.
Its possible that S.100 could thrive, and serve developers well for some time to
come, but then again, its 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 arent going to be happy
learning, supporting, and debugging two different sets of APIs. Todays world is a
world of convergence, not divergence. Thus, having one centralized/converged API is the
only way to go. |