The hardware had special filters on it to recognize the DTMF digits, probably because the CPU was thought of as too wimpy to do it by itself. I experimented writing WAV-file processing filters on my own, and discovered that it took less than 10% of CPU time per phone line to run such filters in software, so it could certainly be done, but then again there existed systems out there in configurations of 30 or even 100 lines per computer, and of course the CPU was not enough in these cases. We only worked with configurations of four lines per computer, but still, since the filters were made available by the hardware, I made use of them for the work project, and I only re-invented the wheel at home, for fun.
My employer at that time managed to secure a number of computer telephony contracts for a couple of big clients; he gave me a rough description of what the projects were supposed to do, and he had my coworkers slide pizza under my office door for as long as it took me to complete them. He probably charged his clients the equivalent of a dozen programmers for this, and it was all done by me. The only external help that went into these projects was messages recorded by a professional at a recording studio.
What follows is some screenshots of the telephony application that I created to run these projects, in Microsoft Visual C++ using MFC and the Dialogic Telephony API.
|All applets waiting to start. Click to enlarge.|
This is a Multiple Document Interface (MDI) application (remember those?) which opened one MDI client window per phone line made available by the underlying hardware, and allowed the user to select a telephony applet to run on each phone line. The operator could see the status of each line and the log messages produced by each applet, and he could start, stop, and select applets to run.
|All applets running. Click to enlarge.|
Each applet was instantiated by the framework to run on its own thread, and it was given a simple abstraction of the telephony API to do work with, and another simple API to display its status and log messages. I also wrote an emulated implementation of my telephony API abstraction, so as to be able to test the applets without having to place actual phone calls. The emulator would run in a special MDI client window with a few additional controls on it for calling the applet, sending DTMF digits, hanging up, and even faking a timeout so that I did not have to wait while testing.
|The emulator. Click to enlarge.|
The main application also provided a uniform means of specifying configuration parameters for the applets, so that the applets did not need to have any GUI of their own.