by Glen Taylor
By the middle of the twentieth century, the Bell System had developed quite a reputation. Some might have considered it too big and too powerful, but it was widely seen as extremely reliable. If your neighborhood lost power, you could still pick up your phone and report the outage. The phone system delivered its own power. If you pushed the touch tone keys to dial a number, you might miss-dial but the touch tones would be received with greater than 99% accuracy. The long-distance network itself had the famous “five nines” or 99.999% reliability. That meant the network would be “down” less than six minutes a year! When I proposed to place Conversant platforms based on commercial grade Olivetti PCs in the path of some of AT&T’s biggest customers’ calls, you can understand why the network engineers said, “You’d have to be an idiot to put a PC in the long-distance network!” This is the story of how we got there and what happened.
In early 1989, I received a call from a Bell Labs systems engineer. Her customer, Business Communications Services (BCS), had a problem. Their Software Defined Network (SDN) service’s Network Remote Access (NRA) feature gave corporate users a “calling card” that let them charge long distance calls to their corporate account. The “problem” was that callers couldn’t make multiple calls easily nor enter an alternative phone number if the first number was busy or rang without answer (“sequence calls”). Regular AT&T consumers using a consumer “calling card” could make sequence calls. This BCS customer insisted that their SDN NRA card users needed to have the same capability or they would take their business to MCI, AT&T’s chief competitor at the time. AT&T had been given no more than 6-9 months to “fix” this problem or they would lose this very important customer.
I actually quickly sketched out a proposal using Conversant “spliced” into the calls. In today’s world, this would be called a “man in the middle” approach that modern network security defends against. This was long enough ago that the term was unknown and besides the AT&T network itself was actually very secure. To understand what I was proposing, I need to explain how this SDN NRA service worked.
The caller would first dial a ten digit 800 number that accessed their SDN NRA feature. All 800 number calls are first routed to the main network “toll switch” serving the caller’s phone. Since 800 numbers aren’t the actual ten-digit destination for the call, the network engages in a simple form of IVR-like call direction. It interrogates a Network Control Point (NCP) that may directly respond with the number the call should be routed to or it executes a simple script. In this case, a prompt announcement would be played to the caller to enter the authorization code (another 10-digit number) from his or her “calling card.” Next it would play a prompt announcement asking for the 10-digit phone number. The authorization code would be validated and, if approved, the call directed to the desired phone number. BCS’s problem was that to enhance this routing logic to listen for a # digit (the “standard” signal to request a sequence call) and handle it correctly, multiple elements in the network needed to be changed. The lead time to make those types of changes was twelve to eighteen months. Changes to network behavior were significant, absolute reliability was paramount, code changes were very carefully scrutinized, and extensive testing was needed. Remember, 99.999% reliability! The core network elements couldn’t react quickly enough to deliver this little feature enhancement in 6-9 months.
My solution was innovative but simple. The original 800 number calls were first directed into a Conversant platform; a relatively simple administrative change, no development necessary. This would encounter a Conversant inbound script on an inbound T1 trunk group that accepted the call. The main application program running as a Unix process would initiate a Conversant outbound script on an outbound T1 trunk group that would call into the network EXACTLY like the call without Conversant in the loop. The control application would tie these two call segments together so that the caller and the rest of the AT&T network would be connected as if the Conversant wasn’t present. However, this Conversant SDN NRA Sequence Dialing platform would be listening to the caller and listening to the network. When the network asked the caller for the authorization code, the platform would “hear” the 10 digits the caller entered and it would remember them. When the network asked the caller for the phone number, the platform would hear these 10 digits and ignore them. Now it simply needed to wait on the call to see if the caller made any request. If the caller pressed a # digit at an appropriate point in the call, the platform would drop the side of the connection toward the network and prompt the caller for a new phone number. Once it had the new 10-digit number, it would mute the caller “on hold,” initiate a new outbound call to the network just as if the caller had dialed a fresh call, listen to the network prompts and reply with the authorization code and new phone number, and then reconnect the caller and the network. The platform became the caller’s “automated speed dialer” but the effect was as if the network now had a new feature. To make this even better for BCS, we committed to deploying our new arrangement in appropriate network central offices before the end of 1989 as needed. We actually beat our projected delivery date and entered service about a month and a half sooner than committed.
It was a good solution, but that wasn’t all that would be needed to get this project approved. The BCS offer managers were quickly convinced and anxious to move forward, but there was a network review process that had to be completed. When changes were contemplated for the AT&T network, several functional organizations had to review the proposal and effectively had veto power if they didn’t agree. In late spring, I accompanied my NJ Bell Labs colleague (the woman who’d called me) and the BCS offer managers to the review meeting in Basking Ridge, NJ.
First on the agenda were the Network Engineering team. These were the people who’d said, “You’d have to be an idiot to put a PC in the long-distance network” even before we got to the meeting. Their immediate statement was that they would not approve this plan.
I asked, “Why?”
I was told that PC equipment was unreliable and could fail. In that case all calls on that system would be lost. The network was designed to duplicate everything for reliability. My solution wasn’t duplicated, couldn’t be reliable, case closed.
I said, “Isn’t there anything in the network that can fail and lose calls?”
They answered, “Well, yes, that would be a line group controller on the 4ESS toll switch.”
And I said, “So how many calls does a line group controller handle?”
They said, “two T1s; 48 channels. That’s the network’s acceptable ‘failure group’ size.”
I said, “Ok, my solution has 48 ports in and 48 ports out that form a total of 48 completed calls. If a platform fails, at most 48 calls will be lost, exactly like a line group controller.”
They paused slightly but said, “But your platform isn’t redundant.” That was true. Each and every Conversant was completely independent from every other Conversant. Although the T1s going into a dozen or so Conversants might logically be grouped as a single “trunk group,” they were fully independent. If one failed, those T1s would be out of service and the 4ESS feeding them calls were ignore them until they came back into service.
I then pointed out that we would provide N+k sparing. That means, if we needed N platforms to provide the full engineered load, we could add 1, 2, or more extra platforms for high availability. That was actually a much higher standard of reliability than simple duplication. The Network Engineering team got rather quiet at that point. We’d won the technical argument.
One key aspect of the solution I haven’t mentioned is that we needed to have touch tones added to the network announcements. Again, that was a simple administrative change; no development needed. In the future, instead of hearing “Please enter your authorization code” the announcement would be “<beep beep> Please enter your authorization code.” Conversant wasn’t able to speech recognize the announcements. Not only was the speech recognition technology not quite good enough in 1989, but the announcements were specific for each customer and even the order of the prompts (code vs phone number) wasn’t fixed. The only way a Conversant application could reliably recognize the announcements properly was to hear touch tones. By pre-pending a pair of touch tones for the various types of announcements we needed to recognize, the Conversant application could function correctly.
The next group in the review was the Network Security group. These were the people who tried to prevent things that would allow toll fraud and who investigated potential instances of fraud. The representative from this group also said, “We can’t approve this proposal.” He went on to explain that putting touch tones in the announcements would almost certainly ATTRACT toll fraud. Phone hackers tended to create simple computer programs that would dial through all of the 800 number range and note “interesting” events. If an 800 number put out a FAX tone or played touch tones, the hacker would be alerted by their little scanning program. They would then manually “play” with the number to determine what it was and if they could exploit it. We were proposing to invite fraud.
I didn’t have a good answer for this objection. But I didn’t need to.
The BCS offer manager spoke up. He said, “What if I want to do this anyway?”
He was told, “We would object.”
He said, “And then how would I proceed?”
“Uh, we’d have to sign off saying that you chose to ignore our objection.”
He said, “Done. Let’s proceed.”
I don’t recall what, if any, additional discussion was necessary, but the decision was made. Columbus would build and deploy this feature in the AT&T network.
We had the development work done quite quickly. I personally took several Conversants to the AT&T central office in downtown Columbus, installed them, got them connected to T1 trunks, and conducted the live testing. Quite a number of Conversants were then shipped to two main central offices (I no longer recall exactly where; I didn’t do those installations) and the service was cut live. We’d achieved the desired goal and BCS was very happy. Interestingly, the security folks were absolutely right. Toll fraud on those 800 numbers shot up.
It was now early 1990 and Conversant & Audix had just been brought together into a single Bell Labs organization. As part of the consolidation, it was agreed that SDN NRA Sequence Dialing and a second BCS 800 project that I’d “sold” but that we hadn’t yet implemented would be moved to Denver. I took my two “babies” and handed them over to a group of strangers in Denver. Those “strangers” would become good friends over the next few months. I continued to support those projects as the systems engineer from Columbus. My new “Denver colleagues” had extensive experience with T1 PRI (the ISDN Primary Rate Interface) that we’d recently incorporated into Conversant. Together with my Denver colleagues, we proposed replacing the standard T1 E&M trunks we’d used initially with T1 PRI trunks. That had the advantage that we would know not only the 800 number that the caller had dialed but also the caller’s phone number.
With this proposed change, we could easily detect “suspicious” calls to an SDN NRA 800 number from a SPECIFIC phone number. If a phone hacker found an 800 number they wanted to “crack,” they would usually dial that number repeatedly trying various things to see if they could exploit it. The AT&T network security protocol would detect some forms of nefarious activity but it usually wasn’t alerted until a customer complained. When that happened, the authorization code was considered compromised and a new code issued (like a credit card that has to be replaced). Since most customers had a single authorization code for their entire company or perhaps for their entire salesforce and a second one for executives, canceling a code inconvenienced a large number of users. With our proposal, we would simply “turn off” calls from a specific phone number to a specific 800 number. Since the phone hackers likely did all of their “hacking” from their own phone line, that would defeat nearly all fraud. If they tried to use a different phone number, we could detect and turn off that number, too.
When we proposed our solution, the Network Security organization was ecstatic. Our solution was pin-point specific and inconvenienced no one other than the phone hacker! We implemented it, and fraud declined significantly back to baseline levels. Our original project was scheduled to be used in the network for only about 6 months. Network Systems was skeptical of Conversant in the network and planned to obsolete our little “quick fix.” However, once we provided a better security solution, the SDN NRA solution was there to stay. It would eventually become obsolete but only after about four or five years.
The SDN NRA project opened a flood gate. We’d done the VoiceMark messaging service with Conversant, but that wasn’t regarded as “Conversant in the network.” VoiceMark was “off to the side.” If that platform had a problem, it didn’t affect the “core” network reliability. SDN NRA was different. It was at the heart of an important business long distance feature. If we could do that with Conversant, there really wasn’t any reason it couldn’t be used for other “rapid network features.” Conversant became an “approved” component of something termed the Enhanced Services Complex (mostly a concept that gave a stamp of approval without enabling any specific application but good to have anyway). I received an AT&T Architecture Award for this effort. But, perhaps the finest testament to the architecture I created was its reuse by the Denver developers for an exceptionally useful service, AT&T Transfer Connect.