When someone mentions Computer Telephony Integration (CTI), there are two common reactions: "That'll cost you"; and "That'll be a pain in the backside to do".
These are both understandable reactions, because CTI has traditionally been tricky and expensive. With the commoditisation of telephone hardware, some vendors have used the pricing of the CTI options for their kit to make up the revenue shortfall – in one case I came across three years or so ago, it was almost cheaper to buy a new PBX than to pay for the CTI option of the old one. And when it comes to the actual implementation, support for CTI via concepts such as TAPI (the usual Windows telephony interface) is largely platform-specific, with Microsoft platforms at the forefront.
It's reassuring, then, to discover that not only are standards for platform-independent CTI becoming more and more robust, but that some companies have been doing it right for a while. Wouldn't it be nice, for instance, to find a PBX that gave you a complete CTI interface down a simple IP socket, so you could hook into it from any platform capable of talking to a basic socket? Well, this is precisely what you can do.
A real-life, usable CTI interface
The Axxess PBX from Inter-Tel has been around for some time now, and although I'd never heard of it until a few years ago, they seem to be springing up more and more in the UK – in fact three of the clients I've worked with recently have bought them. The CTI interface into the Axxess system is the Open Architecture Interface (OAI). By default this uses a TCP connection to port 4000 (or 4001 if you're doing CTI-intensive stuff and you've decided to buy the external CTI gateway box to relieve the load on the central PBX, or to integrate the CTI streams from a number of PBXs). You simply chant some incantations at it to let it know what information you want to receive, and it'll throw data at you in textual form, one event per line.
Say, for example, you're developing a call centre application and you want to report on how long your reservationists are spending on the phone. You'll want to know when calls are coming in, when they're being answered, and when they're finishing. You can tell the PBX to send you all event details if you wish, or you can ask it to filter out all the stuff that you're not interested in. The result is that it'll send you lines looking like this:
What's this tell us? Well, the basics are that a call with unique ID "3P5801" has been delivered ("DE") to extension 1009, that it's an incoming call (the "I" means the call is arriving at an internal number, and the "E" means that it was originated on an external number), that the caller's CLI is 07973893350, that the local DDI number the call arrived on is 355700 (the STD code is always omitted), and that we've called this "MainNumber" in the system setup. The other stuff tells us more esoteric things about the call, but for our purposes the things mentioned here are the ones we care most about.
OK, how about:
This is telling us that call "3P5001", which was active on extension 1002, has ended. Again, the other parameters tell us things, but we don’t necessarily use them in basic applications.
Telling it what to do
The events that the system throws at you cover the whole spectrum of what takes place – conferencing, calls ringing, being answered, diversions, the lot. The other side of the coin is that as well as listening to what the system's doing, you can throw commands at it to instruct things to happen. Implementing a skills-based routing system for your call centre? Easy – you can "deflect" calls with the "_DF" command, transfer ("_TF") and retrieve ("_RV") calls automatically, even initiate calls. Want a "Call me" button on your Web site? No problem – just find a free extension and throw the PBX a "_MC" command.
Quick to market
This approach to CTI is clearly the way forward. I was asked recently to develop a simple application for a call centre that would record which agents were logged into which extensions, and the details of the various calls that took place. Oh, and it had to run on the Mac (in other words, "Don't expect to use an off-the-shelf ActiveX plug-in to do it all"). The entire project took two days, plus a bit of on-site testing.
Thankfully, the standards people are making huge efforts to produce general, platform-independent standards for CTI. At the head of the list is the Enterprise Computer Telephony Forum (ECTF), whose website is packed with documentation on versatile and increasingly adopted CTI concepts. The standards are, however, just the start: to be useful, they have to be comprehensible and simple to use. And it seems to me that PBX vendors could do a lot worse than to follow Inter-Tel's approach: "just point an IP socket at it and it'll talk to you".