AT&T CONVERSANT

Author: glentaylor47

  • The Early Days of the Conversant Venture

    by John Moosmiller

    I joined Bell Labs in October, 1983 (a year after Chemical Abstracts graciously funded my Masters in CIS). I think the “official” internal venture approval came a few months later. The public venture launch was in San Francisco in September, 1985. Almost immediately when I joined in 1983, I was assigned by Dean Hester to find trial sites for speech recognition transactions that could work robustly over limited bandwidth telephony networks. Bob Perdue will recall the focus on keyword recognition and the use of error-correcting catalog code numbers.
     
    I cold-called Fortune 100 R&D executives and found that doors opened in many cases by merely saying I was in a Bell Labs research project that would revolutionize the human-computer interface using computational linguistics and natural language processing.*  Some of the most memorable trips Dean and I made in early 1984 or thereabouts were to LLBean (then only one store and factory in Freeport, ME), a phone-in, drive through grocery store start-up in Los Angeles, and Fidelity Investments in Boston that ultimately did lead to a successful trial. It was exciting and exhausting to be prospecting for customers before we had a marketing organization.
     
    Dean was tightly wound and by nature an introvert, but he had a vision and could intellectually override his nature to achieve his ends. On long airplane rides, he would unwind by listening to the BBC RADIO dramatization of the Lord of the Rings (1981) on his Sony Walkman.**
     
    * The late Gene Rissanen and Bob Perdue got US Patent #5003574A for a “voice capture system” that had these possible applications. 
     
    ** That BBC LOTR adaptation was quite good with Ian Holm as Frodo, Michael Hordern as Gandalf, and Bill Nighy as Sam Gamgee.

  • Working for Bell Laboratories – My Story

    by Glen Taylor

    I’ve had many paying jobs over the past sixty years.  During that time, I’ve worked for and worked with some amazing people.  However, the high point of those sixty years were the twenty-one years I worked for Bell Labs.  Of those years, the thirteen that I worked in Conversant R&D in Columbus, OH, were the apex.

    I had two short careers prior to joining the Labs.  I spent three and a half years in the Navy.   And, I spent seven years as an academic culminating with one year as an Assistant Professor at Texas A&M University.  In 1979, I joined Bell Labs in Holmdel, NJ, as a human factors specialist.  My academic background included a PhD in Experimental Psychology, and during graduate school, I’d co-enrolled in a Master’s program in Computer Science.  In late 1978, I had decided to change direction once again.  At the time, my impression of Bell Labs was similar to the popular image.  I was aware that Bell Lab scientists had won Nobel Prizes and invented such things as the transistor and the laser.  When I was encouraged to apply, I had some trepidation.  I knew my accomplishments weren’t of that caliber. 

    What I didn’t know, but would soon discover, was that a research and development (R&D) institution like Bell Labs resembles the fabled iceberg.  That extremely visible and impressive research component is just the visible tip of a much larger iceberg.  The nationally known research area was perhaps 10% of Bell Labs with the remaining 90% “invisible below the surface.” Those were the development areas that were responsible for creating the hardware and software products used by the AT&T long distance business, by the local telephone companies, and by consumers.  To be clear, the most qualified candidate possible was sought for every job, but not every Bell Labs employee was just waiting his or her turn to receive a Nobel Prize. 

    For established scientists and engineers, their prior work played a major role in the admission process.  However, many of the young engineers that Bell Labs hired were straight out of school.  Historically, Bell Labs hired PhDs, although for hardware and software jobs the engineering and computer science graduates might only need a Master’s degree.  Some very bright Bachelors graduates might be hired and possibly sent to get their Master’s degree at company expense; a program called One Year on Campus or OYOC (pronounced “oh” “yock”).  As a “soft science” candidate, my required entry credential was a doctorate.  I was a bit more than a recent graduate having done two years postdoctoral research and taught for a year.  I had published ten refereed journal articles and had a research monograph in publication.  Those were helpful, but it was the combination of my computer science and psychology research backgrounds that seemed to attract attention.  I would interview with thirteen different Bell Labs supervisory groups in five locations across three states.  The job I selected as my first choice hired me, and I started in Holmdel in June 1979.

    Holmdel was an interesting place.  The building was a huge, rectangular solid whose exterior walls were a smoked glass.  The interior was four multi-story towers containing a warren of cross aisles connecting to an exterior walkway along the glass outer wall and an interior walkway overlooking an atrium area on the ground floor.  The exterior walls were the only windows.  Every building looked exactly like every other building.  It was very easy to get lost. 

    Bell Labs had a somewhat schizophrenic relationship with human factors or human engineering.  On the one hand, the company well understood the need to develop products and services that were easy to use and satisfying to its customers.  It usually employed experimental psychologists for this work because we were trained in empirical observation and research design.  We generally were invested in understanding how people learned and how they performed various tasks.  I and my peers who hired in as human factors specialists were led to believe that we’d employ those skills doing applied research.  We’d design test scenarios where user “subjects” would interact with the user interfaces we were evaluating and engage in tasks using the systems under observation.  That would allow us to determine what was easy, what was hard, what led to errors, what led to correct behavior.  My initial work in Holmdel actually did some of this, and we published that work in the Bell System Technical Journal.  However, that honeymoon was soon over.

    Although the company understood at some level what was required for “good” human factors work, it was unwilling to spend the time and resources.  Engineers, mathematicians, and computer scientists are all trained that there are well known methods and procedures for most work.  Yes, research goes on in every area, but development is the application of learned principles to the creation of products and services.  When a software designer came to me with his or her interface design, the question was “How should I have the user do X?”  My response would be, “I don’t know the best way to do X, but give me the time to conduct a small study and I can tell you.”  That created a fundamental tension.  As pressure to develop code grew and deadlines loomed, the software developers would soon come in with their designs and simply say, “Here’s the design.  I need you to ‘bless it’.”  I believe nearly every one of us who was hired into human factors jobs in that late 1970s & early 1980s period would soon go elsewhere.  Some left Bell Labs.  Most of us migrated to other “jobs.”  I became a C programmer for a year or so.

    My Holmdel project was high pressure.  We were building the first product that AT&T could not deliver as a regulated entity.  We would have to be spun off into an unregulated subsidiary.  On July 1, 1982 my project, about a thousand people across several functional AT&T organizations, became the nucleus of a new company, American Bell.  When the pressure became unbearable and morale was at its lowest point, I escaped NJ to Indianapolis, IN, and returned to a human factor’s role.

    Indianapolis was the AT&T Consumer Products division.  It designed telephones for home and business.  It had a “lab home.”  This was a building whose primary rooms were designed and furnished like a consumer’s home.  The “home” rooms such as the kitchen, living room, dining room, and bed rooms were surrounded by other spaces that contained equipment for observation and testing.  Indy was working on “smart house” concepts including security systems, videotex terminals that would connect to a standard television and telephone line, etc.  This lab made actual experimental observation possible.  I would, once again, have the opportunity to do some amount of applied research, but it was still clear that the company had only a limited appetite.  I made the transition that was probably the most common for human factors psychologists, and I became a systems engineer.

    It would be as a systems engineer that I would transfer to Columbus, OH, in January 1987.  There was a fairly large exodus from Indy at the end of 1986, and five of us would end up in Columbus working on the Conversant project:  Skip Tourville, Bill Erwin, Dennis Noonan, John Siroky, and me.  Skip and I were systems engineers although from much different backgrounds.  Skip was an engineer by training.  I would be joining my colleague Steve Riederer as an ex-“human factors” systems engineer.  Although there were individual differences in our personalities, those of us with the psychology backgrounds tended to maintain a fundamental perspective looking out for the end user that not all of our development or even systems engineering colleagues had. 

    I quickly felt at home in the Conversant organization.  I’d worked in an emerging venture my last year in Indianapolis so the venture “vibe” was very comfortable.  The entrepreneurial spirit of Conversant in 1987 was infectious.  Having all of the core business functions co-located within easy walking distance and having the opportunity to see all aspects of the business were eye opening.  Instead of feeling like a very small piece of the hundreds of thousands of employees that was AT&T when I joined, I was an integral piece of a business of less than a hundred people (or so it seemed).

    My focus almost from my arrival in Columbus was directed toward positioning (“selling”) Conversant into the AT&T and local telephone company networks.  Other colleagues would be more focused on other customers.  It would be several years before I would actually recognize my work as a form of “sales” work.  Once that clicked, I began to realize how much value there was interacting with customers and how much I enjoyed it.  I would transition around 1996 from my network projects to more of a focus on the Conversant product itself.  I had the privilege of using all of that exposure to our customers to gain a deeper understanding of what Conversant needed to do.  I could then translate those into the requirements documents that would guide our release developments.  I was deeply involved in Conversant V6 which was the “international” release to many countries around the globe.  Although I didn’t get the opportunity to globe trot, I had the extreme pleasure of working directly with Linda Dotts as the product manager and George Hsieh as the development manager.  The three of us formed the nuclear “core team” responsible for getting that release out the door.  I would continue to be the primary systems engineer for the V7 and V8 releases.

    All good things must come to an end.  That’s the old aphorism.  The year 2000 saw the end of my time in Bell Labs.  AT&T had already broken up leaving Bell Labs and Western Electric to form Lucent.  In 2000, Lucent would spin off the “enterprise” business – PBXes, contact center, and contact center adjuncts such as Intuity Audix and Conversant.  Lucent would retain its “network” business.  At that point, Conversant development would transition to Denver where the bulk of the “enterprise” R&D work was done.  Most of my Columbus R&D colleagues would be reabsorbed into a Network Systems organization that remained in Lucent.  I was given the choice of transferring to Denver to go with Conversant R&D or remaining with the Columbus Network Systems R&D.  I chose neither path.  I wanted to stay with the Conversant product and the IVR business and make the transition to the new Avaya, but I wasn’t prepared to move my family to Denver.  I left R&D and moved into a technical sales specialist role.  I would remain in that role by various titles for nearly a decade.

  • “You’d have to be an idiot to put a PC in the long-distance network!”

    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.