Subject: Lack of Good Telephony Books
From: Eric Lavergne
A while back, O'Reilly was asking its readers what would be a good subject for a "nutshell" book....
Well, I've been working on a telephony project involving Microsoft's TAPI technology (building a Telephony Service Provider). The documentation on this technology is very scarce. It would be a good thing for TAPI developers to have more (recent) books on this subject.
An avid O'Reilly reader
Unfortunately, we don't have any TAPI/telephony books in the works. We had one signed at one point, but the author, Brian McConnell (who has since written another book for us titled Beyond Contact: A Guide to SETI and Communicating with Alien Worlds), gave up in disgust, saying that the software wasn't complete enough to be really useful. If you have a different experience, we'd love to hear about it.
Jon Udell has written on the dearth of good Computer-Telephony Integration software. His most recent article, Whatever Became Of Computer Telephony? was just published on BYTE.com. It does seem like an area that ought to be really fertile, but it hasn't shown as much movement as we'd all expect.
I do believe that will change over the next couple of years. Obviously, IP telephony is starting to bring networking vendors like Cisco and the various PBX vendors closer together, and I imagine that we may start seeing some movement from that direction. Further, I see a lot of interesting stuff coming up from the instant messaging space--for example, I know people who are exploring the integration of Jabber with telephony for "presence management." That is, before placing a call, use IM to make sure that the person is there. Integrating call-setup for conference calls and so forth seems like a natural thing to do on a computer.
As this area heats up and there are real products delivering real solutions, it's definitely an area we'd like to have books on. Anyone who's doing interesting work that pushes the envelope should let us know.
[Editor's Note: The following message is from Brian McConnell, the author of O'Reilly's canceled TAPI book. Brian explains why TAPI should be avoided, and then suggests some alternatives.]
Date: November 2000
Subject: Q&A About Telephony
From: Brian McConnell
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
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.