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.
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
- Whenever an incoming call is received on the local land line, the application shall read the information
associated with that event. Information will include time of the event and, as available, caller ID (name and number).
- Information associated with each received call event shall be persisted in a form that facilitates access to aggregate call data over time.
- The application shall provide a generic mechanism for performing custom actions when call is received.
Examples of custom actions might include:
- display an 'incoming call' notification on local or remote workstations.
- play a custom ringer, possibly based on incoming caller.
- update webpage content
- send a notification to remote network node or mobile device.
- if caller is a known contact, show summary of contact's recent call, messaging or email activitiy.
- Normal operation of the application should be automatic, requiring no significant user interaction
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.
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