I have been involved with communications Application Programming Interfaces (APIs) since the dawn of Computer Telephony Integration (CTI). I remember flying to Beaverton, Oregon in 1993 to meet with Intel to discuss this thing they were cooking up with Microsoft that they called Telephony API (TAPI).
Along with a few of my Nortel coworkers we put together one of the first TAPI drivers for first party call control (an application controls a single phone). That work eventually morphed into a server version for third party call control (an application can control multiple phones).
Shortly after Intel and Microsoft announced TAPI, Novell introduced their API which they called Telephony Services API (TSAPI). Frankly, I wasn’t a TSAPI fan since I felt it was too closely aligned with Lucent and their Definity PBXs. Still, I worked on the team that built Nortel’s TSAPI server software.
Not to be left behind, Sun Microsystems created a Java telephony API that they called Java Telephony API (JTAPI). I played with JTAPI as part of my work on the Nortel Symposium Contact Center.
So, what exactly is this API thing I keep talking about? In its most simplistic sense, it’s a collection of software commands that a computer program uses to invoke specific functionality. For example, to make a call, a program can invoke the TAPI function lineMakeCall(). To release a call it would invoke lineDrop(). There are similar commands for functions such as hold call, transfer call, and conference call. TSAPI and JTAPI have their own specific commands, but they essentially do the same things.
It’s important to understand that communications APIs like TAPI and TSAPI need something underneath them to actually do the work of making and managing telephone calls. In my Nortel days we used the call control links that the Nortel PBXs exposed. For instance, on the Meridian 1 we used AML and Meridian Link. When I worked on the SL100 we used something called Compucall. Other companies’ products have their own call control links that allow APIs to gain access to PBX functionality.
An API like TAPI abstracts the underlying call control link allowing the program that uses that API to be ported from one PBX type (e.g. Nortel CS1000) to another PBX type (e.g. Avaya Communication Manager) with little to no change to that application’s software.
The world of telephony APIs began to change with the explosion of the web and web-based applications. TAPI, TSAPI, and JTAPI were written for “thick clients.”
A thick client is a program that you install on your PC or Mac. It takes up disk space and is typically invoked with a double-click.
A “thin client” lives in your web browser and is dynamically loaded on your PC when you navigate to a specific webpage. Thin clients and web browsers do not work well with programming language APIs and another mechanism to invoke functionality is needed. Enter Web Services.
A Web Service is a method of communications between two applications over the Internet. For example, you could build a service that tracked stocks on the New York Stock Exchange. That service could then expose an interface that allows some other application to get the current stock price for a particular company. The client application could be on any device as long as that device had access to the Internet. This relationship between the service and application is known as loose coupling. Web Services are at the heart of the Service Oriented Architecture (SOA).
My first encounter with a Web Services based communications API was again back in my Nortel days. Nortel created a product that they called Agile Communications Environment (ACE). ACE exposed communications functionality through web services allowing an application access to commands to make audio calls, video calls, instant messages, and other kinds of other communications mediums. This loose coupling allowed all sorts of applications to become communications aware and capable.
For example, with ACE you can click to call from a web page. You can also have an emergency management system create ad-hoc conference calls during crisis management. There was no limit to the kind of application that could use ACE. Avaya now owns ACE and continues to enhance it with new functionality.
Traditional APIs such as TAPI and TSAPI will continue to have a place in the world of CTI, but web services will increasingly become the preferred method to communications-enable applications. They are much easier to use. They are much more portable between programming languages, device types and operations systems. Using web security methodology, they create secure access links between clients and servers. They offer the ability for services to scale to huge numbers of clients and in this world of cloud computing, that aspect alone makes Web Services based communications highly desirable.
I plan to take up this topic again when I write about Avaya’s Collaboration Environment. Stay tuned for more excitement!
Tao, Zen, and Tomorrow 