by David Schinke
I joined the Columbus laboratory in 1979, by transfer within AT&T. Dick Machol was the Dept. head and my supervisor was Dean Hester. During an interview I was shown the west-side lab with DEC VAX 11-780 computers, washing machine sized disk storage units, and terminals arrayed on several tables in a glass separated space. Such was the state of computing in 1979. Remote terminals in a person’s office came later. Our assignment was No. 2 SES (Service Evaluation System) that was computerizing the human task of evaluating the completion of calls on a random basis. The regulated monopoly communications service company, AT&T, was very concerned about providing good service and voice quality to customers. (How quaint?) I learned “C-code” and completed an AT&T sponsored set of in-house Computer Science courses. Memory is dim, but I think the No. 2 SES system consisted of task-designed hardware in a tall cabinet and possibly also a VAX computer. The hardware could attach to analog phone lines (maybe also T1?), listen to the sounds on the line, interpret sounds like RING, BUSY, REORDER, completion, and presence of voice, then cut-off within a time limit. Completion statistics were compiled and reported to the operating telephone company.
In the early 1980’s, significant legal change came to the Bell System. The operating telephone companies were separated from AT&T who kept the provision of long-distance services. A little-noticed side effect of this court order was that AT&T was no longer required to offer its patents and ideas to the public at a fair rate, and could generally enter unregulated markets if it chose to do that. Well, we had hardware that could interact with analog and digital phone lines and, using Digital Signal Processing, “listen to” tones etc. on the line. It could play out pre-recorded speech files. How about Interactive Voice Response as an unregulated market that could be entered? Customers could place a call, a computer could speak recorded phrases to them, they could select things by pressing Touch-tones and hear strung-together recorded voice responses with the desired information.
Jumping forward, our department developed the “Model 80” IVR system. The cabinet was taller than I was, and weighed several hundred pounds with redundant power supplies, etc. The software was written in “C language” and ran on a UNIX operating system. A single cabinet could handle up to 48 voice lines, either analog [tip-ring in the nomenclature of the day] or digital [T1, @ 1.544 mbits/sec with an equivalent 24 voice lines]. It also had an external data interface to interact with and to provide/obtain information from our purchasing customer. This entire cabinet could run ONE, SINGLE voice response “script” (the sequence of customer inputs and speech outputs) on any or all of the incoming lines. Memory is dim, but I think we programmed the voice response transaction in “C”.
Is there a way to provide more than one “IVR service script” on this hardware? Then our purchasing customer could group a subset of the phone lines for one service, and have another service applied to another group. The digital T1 interface provided the “called number,” which is the destination number called from the phone network. This number could be used to decide which “service script” to provide to a caller. Noodling around with this idea, the concept of a “State Machine” seemed like a possible way to deal with these multiple service scripts. A state machine could keep track of which script was started on an incoming line, and where it was in the script [its state]. I went to the lab one afternoon to talk with Roy Grubbe and Cliff Perkins about what information came up from the hardware. After some discussion we agreed that all the incoming hardware interrupts contained enough information to “drive” a Transaction State Machine, and that it did seem “possible” to construct such a thing in software. Toward the end of the conversation Roy Grubbe slapped both hands down on his thighs and said “Lets Do It!”
Realizing that this was more work than could be done on a “Friday afternoon,” Roy and I went to our supervisor, Dean Hester, with the idea. After some discussion he said “Write me a memo about what you want to do so I can allocate some resources.” I wrote a memo with Roy Grubbe as a co-author called “Transaction State Machine.” Mainly the advantages of running multiple things, but not very detailed in HOW it would be accomplished. Well, Dean let us get to work with Cliff Perkins to produce a “reduction to practice” of the concepts and make a demonstration system.
Roy Grubbe and Cliff Perkins wrote the state machine software to interface with the Model 80 hardware. I started working on a way to script the transaction. We thought about an assembly style language that had a few commands and control statements. After all, an IVR transaction is just answering the phone, “talking,” “getting some digits,” maybe interacting with a “back-end” on-site customer data base, and hanging up. How hard could it be? How many commands do you really need to run an IVR? Do you really need the idea of a subroutine? [YES] Cliff wrote a compiler to take the “pidgin assembly language” script into a file that would run on the TSM. This was called TAS [Transaction ASsembler].
With apologies for hazy or enthusiastic memory, I think it took about a month or 6 weeks to get to a demonstration of two phone calls with different speech databases and sequences running independently on the same machine. We asked Dean Hester into the lab to dial up on two different phone lines and do the interaction with each. Afterwards, he smiled and said “Very good. Where do we go from here?”.
This is the TSM origin story as I remember it. It grew in complexity and features, but retained the “channelized” idea and was able to support the needs of the product for a number of years.
Leave a Reply