When I was working for BT, I was a systems and software development manager, running a small team of programmers linking a Summa Four switch to VAX computers. This was part of BT's Telemarketing facility, handling inbound and outbound telephone calls relating to all aspects of the company's marketing. We provided similar bureau facilities for other "Blue Chip" companies.
There are an increasing number of options in the CTI world, but the fundamental problem is that the user/customer has to deal with a switch supplier, a computer supplier, a software package supplier, maybe a voice processing supplier, and all these people may never have talked to one another before that customer came along. The result is a systems integration nightmare.
We overcame some of the problem by doing the systems integration and some of the operational package supply "in house" but this requires resources most smaller companies cannot afford to employ. The standards situation is still in its infancy - at least if you want to implement a complex application - and until this is resolved the systems integration problem is very real.
There is a UK CTI site which links to Rob Walters' activities in this field, and also to the ECMA standards and also the CSTA standards.
Although my own experience has been in implementing CTI on VAX based systems, there appears to be a growing interest in the PC world. Microsoft and Novell as well as smaller companies have implemented CTI systems which are PC based, Microsoft's Telephony Applications Programming Interface (TAPI) to be integrated into Windows 95, but reports never seem to mention the telephone switches which can be linked to them. There is currently no fully-featured standard for the interface from the telephone switch, and I feel this is the area where it is most needed. After all, computers are general purpose machines and can be expected to be programmed/configured to do all sorts of unexpected tasks; telephone systems are, well, telephone systems, and the suppliers (and telcos) are understandably reluctant to allow too much functionality to be devolved to an outside agency. But this is where it must happen; neither switch supplier or computer supplier can be allowed to inhibit what a third part can provide in the way of facilities. It doesn't require much. I could write a specification if anyone is interested!
According to a report by Ovum - Computer Telephony Integration: the Business Opportunity - this will be a $6 billion business by 2000AD. Perhaps I retired too early????
My first experience with the integration of computers and telephone switching was in the early 1980s, when I transferred to BT's Telecom TAN department. They were using a MITEL SX200 PABX linked to an Apple II micro, the Apple being linked in turn to a VAX on which the telemarketing applications were run. The telemarketing was mostly order entry for brochures and other information, dealt with by a team of operators - "Customer Service Advisors" (CSAs) - who got a different screen for each line group on which the call arrived. The interesting thing from my point of view was the fact that the Apple - which was there to reduce the processing load on the VAX - was not interrupt driven - but merely scanned the data from the PABX, looking for changes. This was possible because the SX200 generated "frames" of data every 100 ms, each frame taking about 60 ms to transmit, leaving 40 ms to process the frame into messages to and from the VAX - possible, but not very reliable in 6502 assembly language.
Each frame was an image of the PABX operator console lamp and indicator display, so from looking at the frame you could tell which lines and operators were engaged on calls, and whether any new calls had arrived. This was sent to the VAX which worked out which agent should answer a new call, sent this back to the Apple, which emulated the console key presses to answer the call and send to the requested agent.
A story went round that BT showed the system to a representative of a large company, in the hope of selling complete systems. When the representative discovered that one of the crucial parts of the system was an Apple II, he lost interest, as nobody ran production systems on domestic micros in those days. In spite of this, the system went on for several years, with the Apple disguised in a standard 18" rack.
My job was specifically to implement direct dialling in as a means of product/service identification. BT and other telcos allowed large number groups to terminate on customers equipment, so that the final digits were dialled into the PABX, in order to dial direct to a specific extension. What we needed was to identify the digits dialled, but use them as data rather than routing information, the routing of the call being determined by the VAX/Apple combination, and not by the switch. As a result, we replaced the Apple with a more easily configurable micro - 8085 based and interrupt driven! - and built a separate module for reading the dialled digits, direct off the telephone line. This approach was necessary, due to restrictions on the PABX, and the lack of interest by Mitel at that time in doing any sort of non-standard modification to the switch. The regulations for telephone equipment at that time meant submitting our equipment for test and approval before we were allowed to use it, but this was obtained - after much head scratching by the approval authority, who were not convinced it was necessary to connect computers to telephone equipment, and surely it wasn't a GOOD THING? Again, this equipment ran on for several years, giving us 1000s of telephone numbers, spread over 60-odd lines.
The next step was taken as a result of the success of the business; call volumes went up, and even splitting the bureau into multiple operational areas still gave traffic problems on the PABXs, including slowing down the data frame until it took 100ms to transmit. The decision was taken to move the call routing out of the VAXs and back into the switch, which was replaced by a large Datapoint ACD, which offered the most flexible call routing that we could find at that time. Some mods were made to the Datapoint, which sent all its call routing information to a central computer for stats purposes, to send this information off to the VAX as well. The VAX now simply used this to bring up the appropriate screen at the position where the call was taken. This was the system that took us into the 1990s, in spite of problems at high traffic levels and the need to do much software work on the VAXs. The need for the micros had now gone, as the VAXs got faster, and we speeded up the code, and the data rate from the Datapoint was much lower than from the SX200.
The Datapoint solution had its problems, however, and it became obvious that the switch was insufficiently flexible to meet the needs of the business, for example, the numbers of operator groups was too small, the support for voice processing equipment was very limited, and so the next decision was to go back to routing the calls from the VAX. In the long term, the key to business flexibility was to maximise the usage of the operators/CSAs, by offering virtually any combination of routing required by the management. This was done by buying a new switch - from Summa Four - and using a little VAX as a single user system to interface to the VAXs on which the applications were run. By now, of course, everything is networked, and a small VAX costs only a bit more than an expensive PC, and it has the advantage of a real operating system. (I hope Bill Gates is not reading this!) The use of a "dumb" switch has the advantage that it can be integrated with almost anything you can write the software for, although it has the disadvantage that you have to write the software..... When I left, it was working in the bureau with a wide number of different types of telephone and agent equipment, including voice processing. The flexibility in call handling was really enormous - far more than any other system I have seen described. Inevitably, problems were initially experienced with high call volumes - a real feeling of having been here before on that one - but the system is one which I feel proud to have been associated.
We used Periphonics voice processing kit (VPS) with E1 digital links to the switch; the Periphonics had to be modified to allow it to be driven by the telemarketing application, rather than the other way round, and we had some problems with this, and also with the need for the VPS kit to work with all the port in an "off hook" condition. It had been designed to wait for an incoming call, notify the application, answer the call, perform all its own processing, and wait for the caller to hang up or the VPS application to complete. We wanted it to wait "off hook", perform record/playback under instruction from an external application, and hang up when told!
This is fairly typical of the problems of integrating telephone systems to computers; the telephone systems (which are all driven by computers, nowadays) tend to have rigid software, designed to meet well documented network specifications, and to provide relatively simple functions which have not changed significantly in years. (When did you last have a real new function provided on the telephone on your desk?) The result tends to be overlay software. When a switch is initially designed, much work goes into designing interfaces and driving hardware, giving a dumb switch, which can deal in input and output ports, channels, trunks, etc. To this is added a software overlay which defines PABX facilities, call queuing, line groups, answering groups, etc. To this again is added an ACD facility overlay, comprising the specialist links between queuing and call handling points, special stats, etc. and then finally the manufacturer wakes up to the need of the telemarketing industry to provide simple computer integration facilities, in the way of data input and output. Unfortunately, the underlying concepts of PABX and ACD may prevent a sufficiently flexible integration - it may not be possible to take a call out of a queue other than at the head, for example.
Copyright © 1996 Roger Yeates
Most recent revision 30 September 1996