TAPI with Cisco Phone; Working with "sidecar" 800 module

Question

I'm currently developing a TAPI-based application to provide "intelligent caller ID" to agents in our call center using our Cisco IP phone system. When a call comes in and the agent picks it up on a "real" phone at their workstation, the application, which lives in the workstation's system tray, gets the number on the remote side of the call, and runs it through a central database to see if the number is known as belonging to one of our client companies or their reps. If so, we display information about who the agent is now talking to (person or client location name, company, title, etc).

I developed a proof of concept that monitors my cubicle's phone, using Julmar's excellent ATAPI library, and got it working well. However, the agents' phones have a significant difference; they plug into a sidecar module with an additional 14 extensions connected to our 1-800 hunt line.

The problem I'm having now is that I need to know not just when a call is connected, but when it's connected to the single phone I'm monitoring, sitting underneath the workstation on which the application is running. Currently, I can see line state changes on all the 800 lines, but I can't tell which line state changes were the direct result of an action of the phone device I'm monitoring; obviously I can monitor changes in phone state and line state, but if two calls ringing on the 800 block are picked up by two agents at nearly the same time I can't tell which phone got which call.

This information simply has to be available somewhere in the TAPI interface, if possibly not wrapped by ATAPI. Any hints on what I should be looking at, hopefully from someone who's done this before, are appreciated.

Answer 1

I found the fix.

The ATAPI library is a bit disingenuous to those who just want to plug in and go. The CallStateChanged event of a TapiLine, whih you hook into to be notified of connected calls, uses a delegate that accepts a CallStateEventArgs as the EventArgs parameter. However, it turns out that CallStateEventArgs is a base class. Functional, but not complete for all cases.

What's actually passed to the event when a call is connected is a ConnectedCallStateEventArgs instance. This derived class exposes not only the old and new CallStates of the base class, but also the "call state mode" referenced in the Cisco docs, using a Mode readonly field of the ConnectModes enumeration type.

From the Cisco docs, if you are monitoring a shared line (like from an 800 block), and a call on that line is picked up or joined into by the phone associated with the line instance you are monitoring, the call state mode will be "LINECONNECTEDMODE_ACTIVE". If your phone is not a party to the call, it's "LINECONNECTEDMODE_INACTIVE". If the line isn't shared, the connect mode for any connected call on the line will be a zero ("None" in the ATAPI library; if you get this value, assume your phone is a party to the call).

Using this additional piece of information, it's possible to know that the phone associated with the line is actually on the call. You will get one line instance for that specific 800 block line for every phone you are monitoring with your TAPI instances that can access the line, so you can know which of the two or three or ten phones you're watching got the call. If you aren't monitoring multiple phones on one computer/TAPI instance, and/or the call is not active on any phone you are monitoring, you can't tell which phone does have the call; only that your phone(s) don't.

That's enough for me; the agents only need to know to whom they're talking, not anyone else. If we need an account for the floor manager's desk that monitors all 20 of the phones that have 800 blocks, we can handle that later.