Tim, I noticed a question in the Ask Tim column about telephony books. Please forward this email onto Eric if you wish. Feel free to add this to the Q&A if you wish.

Thanks,
Brian

Eric,

Hello. My name is Brian McConnell. I was the author of the canceled TAPI book from a couple of years ago. My advice on TAPI is pretty simple... don't do it! I strongly recommend that you consider other APIs for telephony server applications. The only exception is if you are writing desktop software that enables users to sync their PC with their phone (e.g., auto-dial contacts from MS Outlook or pop-up caller ID information on screen).

The problem with TAPI is that Microsoft tried to cram telephony into their Windows architecture, even though most telephony devices do not run on Windows and have a limited ability to communicate with computers (e.g., low baud rate serial port and proprietary connection via ISDN D channel). Instead of focusing on creating an open protocol similar to other Internet protocols like SMTP, POP, etc., Microsoft put all of their effort into creating a Windows API, without defining client/server communication in a way that was practical. They tried to make all client/server communication fit into their remote method invocation protocols (similar to Sun's RMI), but did so in a way that was a complete nightmare to work with. In fact, the implementation was so bad that even experienced computer telephony developers had a very difficult time getting client/server TAPI to work. Even PC-based PBX vendors, who make NT-based phone systems, dumped TAPI in favor of their own proprietary client/server apps, primarily because of the technical support burden involved in supporting the Microsoft product. Things have probably improved somewhat in the past couple years, but I grew tired of waiting for Microsoft to ship a product that respected the fact that 99% of the telephony industry does not run on Windows (and that this was unlikely to change in the near future).

My recommendations are as follows:

• If you're developing a server application, for example a unified messaging server, you should look at the APIs being developed by the Enterprise Computer Telephony Forum (www.ectf.org). These are cross-platform standards being developed with the involvement of industry-leading companies, most notably Dialogic (now part of Intel). Dialogic has their own API/development platform that they are promoting heavily these days.

• You can also find some proprietary ActiveX controls from Parity Software (www.paritysoftware.com). The ActiveX controls are my personal favorite as they hide all of the hardware complexity from you, yet enable you to program at a low enough level to get useful work done. The Dialogic APIs are lower level APIs and make simple jobs fairly complicated. Parity has been around for a long time and is one of the best in the business (with the caveat that they work primarily with Dialogic cards).

TAPI is, for all practical purposes, useless for building multi-port server software. Avoid it like the black plaque. If you're developing a client app that talks to a server (e.g., PBX or ACD system), you can use TAPI if the server vendor provides a reliable TAPI driver (a lot of the client side drivers are crap, so you need to verify that they really do support TAPI). If not, your best bet is to write to the vendor's proprietary interface, which is probably a serial line interface or some sort of simple SMTP-like protocol. SIP (session initiation protocol) has been gaining a lot of popularity for IP telephony, and may also be used for computer telephone integration, although it's not yet widely supported by PBX vendors. I had campaigned to develop a simple client/server protocol dubbed SCTP (simple computer telephony protocol) that would have provided a simple, open interface through which client and server devices could talk to each other (without forcing either side to use a particular operating system). Of course, this is incompatible with Microsoft's "shove Windows down everyone's throat" strategy, and so the response from the industry was a big yawn (although a couple of smaller vendors used the protocol in their own implementations).

In short, unless you're doing something that TAPI does well (screen pops, integration with single line desktop phone, auto-dialing from contact manager), you'll probably be better off with another API.

So, that's my two cents worth. Thanks much for your time.

Brian McConnell