Rarely within the rapidly changing worlds of technology, does something manage to remain relevant for organisations for many years, let alone over two decades. TAPI, or Telephony Application Programming Interface, was created in 1993 in a joint venture by Microsoft and Intel. It enabled applications to manage telephony functions between a Windows computer and a communications network for data, fax, and voice calls. Now, with multiple different versions available, it allows basic functions, such as dialing, answering, and terminating a call directly from a Windows OS. It also enabled more complex supplementary functions, such as hold, transfer, conference, and call park.
Utilising TAPI, and enabling its more complex features to work correctly in certain environments, has not been an easy process. One of the world leaders in telephony CRM integration, Mondago provide a range of products to companies around the world and have specialized in TAPI since its inception.
UC Today spoke to their Development Director, Alex Rogers, who is one of the world’s leading TAPI experts about how the use of TAPI has developed and if it is still relevant for customers today.
Mondago began by helping customers utilise TAPI in a direct connection between a computer and a telephone. This offered the basic functionality required back then, being able to make and answer calls directly from a PC and receive information on who was calling when an inbound call was received.
“At that time, it was the only option, or protocol, for the PBX systems that organisations were using if they wanted any sort of interaction between the computer and their phone. Back then it was futuristic and a very new concept for people.”
This sort of integration was not straight forward, it required direct configuration between the PC and the phone. For larger organisations with hundreds, or thousands, of potential users the process was a complex and labor intensive one. This direction connection (or more specifically the control of a single handset) is known as first-party TAPI. It requires the TAPI driver to be installed directly onto the end user’s PC.
As networks developed, telephone systems became LAN-enabled and it was then possible to make a server-type connection directly to the PBX, thus allowing control of all of the systems devices through a single driver. This method of connection is known as third-party TAPI. It requires the developer to write their own server-based application to distribute telephony control to their own users.
Before long, operating systems developed and the process became more and more complex. Microsoft’s acceleration in operating system architecture from 16-bit to 32-bit created further compatibility conundrums.. The same problem repeated as operating systems developed again from 32-bit to 64-bit.
“This has always been the challenge. Drivers have always been written for a particular operating system and test environment, if you try and take them outside of that environment then they don’t behave properly, and this can lead to CTI failures and ultimately customer dissatisfaction.”
These types of problems slightly tarnished TAPI’s reputation within the industry, even though it was a robust and well-designed API. This, along with differences in TAPI implementations by each PBX manufacturer, led to a situation where integration between the business application, typically a CRM system, and the PBX became a custom project requiring specialist resources such as those provided by Mondago.
“It was at this time, seeing both the issues faced and the demand for TAPI drivers, that we wrote our Universal TAPI driver, which was designed to provide a standard normalized TAPI interface for application developers across a wide range of popular premise-based PBXs”
Cloud and TAPI
Where it was almost standard for premise-based PBX manufacturers to provide a TAPI driver for the system, this has not been the case with cloud system manufacturers. Perhaps this is because TAPI is seen as legacy technology and not one that would be employed should an application provider be looking to add telephony to their product. To a certain extend they are correct, however there are two important points that have, perhaps, been overlooked. There are an enormous number of applications in the market that have been developed to use TAPI and the developers are reluctant to change them. Also developers want to work with standard APIs and not modify their application based on the platform they are connecting to, the costs are simply too high.
With this is mind, Mondago have been using their expertise, gained with premise-based systems, to produce an individual TAPI driver, where possible, for some of the major hosted platforms, and are already seeing great success with their “Go TAPI for BroadWorks” product, demonstrating that the need for TAPI is far from dead!
