home

Caller ID Tracking

This is a quick and dirty writeup of a quick and dirty application. The application keeps track of calls received on the local land line.

1. Motivation

I'm at home working on a computer and the land line phone rings. I could choose to ignore it, but more often I'll look at the caller ID on the phone to guage whether answering seems worth the interruption. If I don't happen to have a phone in front of me already, then just retrieving the phone already constitutes a significant interruption. Then there are the calls for which I would prefer the phone not ring at all (e.g., the caller named 'Toll Free'). The bill from the provider of my mobile phone service gives me a detailed account of all calls handled. Not so for the land line -- the land line bill doesn't even give me a means to determine how many times I was interrupted by 'Toll Free' in a given month.

The above can be remedied via an application that detects and keeps track of incoming calls.


2. Application Requirements


3. Design

We receive caller ID information from a suitably configured modem that's otherwise unused. We address persistence requirements by inserting received call records into a database. We provide a hook for custom actions by having our event dispatcher optionally invoke an external command.

Here's a solution outline (with all due apologies to the diagramming police).

4. Implementation Notes

In its current form, the app runs on an old, no longer mobile, WindowsXP laptop. (This machine contains the requisite unused modem which is always powered up and connected to a land line phone jack). The machine also hosts a mysql database. The comtool box on the above diagram is implemented via a C++ program that interact with the modem port and relays the bytestream from the modem. The callerIdFeed box from the above diagram is implemented via a perl script that dispatches call information as events are detected. The onIncomingCall box is implemented as a Windows batch file that sends out local notifications using 3rd party app Growl for Windows.

The app starts up via another windows batch file. This batch file is set to run as an automatically launched NT service using the srvany utility from an old NT resource kit.


5. Evolution

This is not particularly robust or flexible software. As is, it resides squarely in the rapid prototype realm. Out of the gate, we only support modems that behave just like the one I'm using. The use of lowly Windows batch files limits us to that OS. Any configurability requires editing the included script files. If we were wanting to turn this into more of a viable product, we'd likely start by replacing what is currently implemented in batch files with something more tractable, and factoring out configuration info. Assuming we're OK with being tied to Windows, the phone line access would be better handled via TAPI services. (This would effectively collapse the comtool and callerIdFeed boxes from the design diagram into a single entity.) I'd then expect that the most interesting area of the application would relate to defining and maintaining custom actions for call events.


Feedback: steve hardy