Design Feature:August 3, 1995

Since the PC has appeared on our desktops, it has slowly absorbed virtually everything else that used to reside there: notepads, business-card files, address books, and drawing tools. Soon, it will absorb the telephone. That integration of computer and telephone opens the door to a host of telephone-enabled applications. Getting the pieces to fit together is the challenge.

The term "computer telephony" (CT) implies different things to different people. Their visions range from separate but coordinated telephone and database networks to the desktop computer as a combination speaker phone and answering machine (see box, "Computer telephony's many extensions"). Regardless of how they define CT, however, people in the communications industry agree that these two information-handling technologies are merging.

The current growth in CT began with the release of foundation software by computer-industry leaders Intel, Microsoft, and Novell. Novell, which dominates the PC-networking market, created a telephony-services application-programming interface (TSAPI) for the NetWare operating system. The TSAPI links the network's capabilities to those of the private-branch-exchange (PBX) switch. Intel and Microsoft, which dominate the PC's architecture and operating system, jointly created a telephony application-programming interface (TAPI) that gives Windows programs control over telephone call-handling functions. Both interfaces insulate application programmers from the details of the telephone system in use, eliminating the need to adapt programs to dozens of phone systems. The unified programming environment provides fertile ground for a range of CT applications to take root.

Architecture links PCs and phones

If you're growing your own CT application, one of the first things you need to consider is the architecture that connects the computer to the telephone. Three basic architectural structures have evolved, each with its advantages and limitations. The PC can link to the PBX through its network server (Fig 1a). Alternatively, the PC can tie directly to the telephone (Fig 1b), or the PC can serve as the telephone itself (Fig 1c).

Linking the PC and telephone through the network server involves the smallest hardware cost for larger installations. The only special hardware this architecture requires is the link between the server and the PBX; all other computers on the network need only telephony software. The PBX supplies the network with call-control information, such as caller ID, and the network uses the PBX to direct and manipulate calls.

This architecture has been in use for several years. Until the advent of TSAPI, however, application programmers had to rewrite programs for each of the more than 40 PBX switches on the market. Such rewriting was difficult, if not impossible, because PBX manufacturers kept their systems proprietary. Now, however, most PBX manufacturers supply TSAPI drivers, so that application programs can run unchanged on a variety of machines.

Computers running Windows TAPI-based applications can also run with this architecture by using the Tmap software, which Northern Telecomm developed. TAPI links applications to hardware through the TAPI service-provider interface (TSPI) (Fig 2). Tmap makes the TSAPI network look like a service provider to TAPI and translates TAPI commands to TSAPI commands.

The disadvantage of connecting the PC and telephone networks through the PBX is that the PCs don't gain access to the voice information, only the call-control data. A way around this limitation is to bring telephone lines to the server. By incorporating telephone cards such as those from Dialogic and others (Table 1), the server can act as a telephone, providing a path for network-stored outgoing messages and for answering-machine functions. These telephony servers also provide an opportunity to add computation-intensive functions, such as speech recognition, to the system by tying powerful DSP boards to the telephone interface.

PC-to-phone link

Directly connecting the PC to the telephone unit, the second common architecture may or may not provide the PC with access to the voice data. At the very least, however, this architecture provides computer control over the telephone in use as well as access to caller-ID and other call-setup information. The computer can then serve as a graphical interface for the telephone system's advanced functions, such as conference calling, and make intelligent decisions about where to forward incoming calls. The computer can also dial calls using information from user programs, such as address books, or can provide "screen pops," which are database displays specific to an incoming call.

Such direct connections typically use an adapter or a modified phone unit with a data link to a PC. C-T Link's recently introduced C-T Link 1000A, for example, connects with the standard telephone network. This device shares the PC's parallel port with the printer to provide a control link to a standard analog telephone. The control link allows Windows applications to place calls and to receive caller IDs. Future product generations will use the high-speed Universal Serial Bus (USB) for peripherals. Several companies, including Intel, Microsoft, and Compaq, are developing USB, which will allow digital-audio and control data to pass between the PC and the telephone line.

PC becomes the phone

The third architecture resembles the traditional data-communications structure, in which the PC connects directly to the telephone network and offers an optional pass-through to a telephone handset. With the proper interface circuits, this configuration works with any telephone system, including analog, ISDN (integrated services digital network), and digital PBX. Because embedded-system designers will most likely adopt this configuration when adding telephony functions to their systems, this approach merits closer examination.

Fig 3 details the hardware needs of such a computer telephone connecting to the public-switched telephone network (PSTN). The computer telephone's main elements are the data-access-arrangement (DAA) circuit, the data pump, a microcontroller, and the PC interface, each of which has many variations. There must also be an audio interface to allow the system to provide the voice functions.

The DAA circuit provides the final connection between the computer and the telephone network. Depending on the network in use, the DAA may provide an analog interface to the PSTN, use a digital interface to a PBX or to the ISDN, or connect to a cellular transmitter. This interface also varies within each of these categories. Connection to PBX switches, for instance, varies with the switch manufacturer. The PSTN interface differs for each country in which the DAA circuit must operate.

The data pump handles the conversion between digital information and audio tones. It also produces and decodes dual-tone multifrequency (DTMF) tones, provides line equalization, and performs echo canceling. A data pump typically comprises a DSP and either an analog front end or a codec for A/D and D/A conversion. A data pump can also be a simple analog codec that combines with the inherent processing power of the host PC, as with Intel's Native Signal Processing.

The microcontroller formats the data for audio encoding, including bit scrambling to break up long repeating strings, addition of error-correction codes, and data compression. It also reformats serial incoming data and provides the interface to the PC bus. This control function might use a separate microcontroller, be integrated into the data pump's DSP, or be handled by the host processor.

High-speed modem chip sets for fax and data communications include all of these functions. To be suitable for telephony, however, the modem must also offer a voice path. As Fig 3 shows, the voice path requires an additional audio codec. This codec can be part of the modem or part of a multimedia audio system, such as a sound card. If the codec is part of the modem, the user can employ a headset or an analog telephone handset for the voice port. If the codec is part of a multimedia audio system, the user can have a speaker phone. Both the codec and modem can also be part of the sound card, as with IBM's Mwave product family.

Software becomes vital to CT

With all the processors involved in a telephony modem, software becomes a vital part of computer telephony. Each of the computer telephone's processing blocks has its own software needs. The controller and data pump, for instance, need programs for modem emulation, DTMF coding and decoding, line echo canceling, acoustic echo canceling (for full-duplex speaker phone), error correction, formatting, and call-progress control. The system may also include advanced features, such as text-to-speech conversion and voice recognition.

Many of these software blocks are available in libraries. Some libraries come directly from the DSP chip manufacturer. EDN's annual DSP Chip Directory (Ref 1) lists DSP chips and their support software. You can also obtain software from DSP development-tool vendors, such as Spectron and Spectrum Signal Processing, and from independent software vendors, such as VoCal Technology and Delrina. The speed with which the CT market is growing has stimulated the emergence of yet another software source, independent algorithm developers. These companies, such as HotHaus, provide application-specific software rather than libraries of generic telephony functions.

In addition, the host system has its own software needs, many of which relate to handling call-control functions, such as dialing and answering- machine emulation. In this host software, the TAPI block serves as a common interface between applications and the hardware-specific drivers (Fig 4). On the hardware side, TAPI, free from Microsoft, provides a TSPI, which provides a link to hardware-vendor-supplied drivers. TAPI versions for Windows 3.1 are available over the Internet (Table 2). TAPI will also be an integral part of the Windows 95 operating system.

Although TAPI provides a path for controlling telephony functions, it does not provide a link to the audio data itself. Other application-program interfaces (APIs) under the Windows Open Services Architecture must fill that need. For instance, if the audio data is to pass through a sound card, the Wave API for handling audio files serves as the link to telephone audio. Many sources offer application software. Phoenix Technologies, for example, offers a Telephony Suite that provides speaker-phone, voice-mail, and fax capabilities. Radish Communications Systems offers a TalkShop program that lets your business call carry both data and voice.

Another class of software provider for telephony applications—the middleware provider—is also emerging. Middleware falls between end-user application and TAPIs, providing a means of rapidly producing custom application behavior without extensive programming. Aurora System's FastCall, for example, lets you specify behavioral rules so that you can customize the FastCall telephony functions without writing a line of code. SoftTalk's Phonetastic and Symetrics Industries' Icon-O-Voice provide similar customizable applications.

All the blocks are in place

The wide and growing availability of telephony software and hardware shows that all the blocks are available to build telephony functions into your system designs. Table 2 gives a representative sample of vendors for the various blocks. However, carefully consider how those blocks fit together, and look carefully at the network to which the system must connect. Although applications programs hardly care, the hardware interfaces to various network types differ widely. Know if your design connects to an analog PSTN, a digital PBX, the ISDN, or a cellular network. Also know which network provider you are using. PBX vendors are highly competitive and keep their system designs proprietary. Their competitive nature manifests itself, among other ways, in distinctive hardware interfaces and in unique call-handling methods and features. If you plan to connect your system's telephony features through a PBX, you must offer a hardware interface that matches the PBX's requirements. Less obvious is the fact that you may need to adapt application software to each PBX.

Glue software, such as TAPI and TSAPI, goes a long way toward isolating the application program from the network's specifics, but such software is not foolproof. Not all PBX systems have the same features. Make sure that the PBX offers the features your application needs, such as dialing, answering, and querying call status. TAPI defines a set of Basic Services that every system provides. Features such as call holding, transferring, and tone detection, however, are Supplementary Services, which the PBX may not provide.

Work is under way to correct this situation. The recently formed Enterprise Computer Telephony Forum (ECTF) is seeking to promote interoperability among software and hardware from different vendors. ECTF is working to achieve widespread agreement on CT implementations based on international standards.

The same variation that plagues PBX switches occurs in the public networks. In the United States, for example, features such as forwarding and conferencing are not uniformly available. Where they are available, the tones and codes for invoking them vary from region to region. In Europe, the situation is even more diverse. The operational characteristics of various nations telephone networks differ, as do their physical interfaces. Requirements for various European nations may conflict or even contradict each other (Ref 2).

Emerging technologies

You also need to consider emerging telephony technologies for which several competing open standards exist. One such technology is the use of a single phone line for concurrent voice and data traffic. Three competing open standards exist for this voice-over-data technology. Radish Communications Systems and its licensees offer VoiceView, which multiplexes digitized and compressed voice with the data stream. AT&T offers an analog simultaneous voice over data (ASVD) option. A group comprising Creative Labs, Hayes, Intel, Rockwell, and US Robotics has created a digital simultaneous voice over data (DSVD) standard that transmits digitized voice and data streams in different modulation bands. The three methods are incompatible. That incompatibility may not be a problem in a closed-end application, in which you control both ends of the telephone connection. The risk still exists that market forces may eradicate one or more of the competing methods, however.

Another set of competing standards arises in telephony-server design. The server that provides telephony access to the network may use several cards for multiple channels or to bring DSP boards to bear on voice recognition and text-to-speech synthesis. The ISA bus, however, isn't fast enough to handle the data, so telephony-card vendors created a data bus that connects boards via a ribbon cable. The two alternatives are the MVIP (multivendor-integration protocol), which Natural MicroSystems created, and the SCSA (signal-computing-systems architecture), which Dialogic created and ECTF administers. Although each standard boasts many compatible products, designers face the risk that market forces will eventually eliminate one or the other.

There also remain areas of CT that have no guidelines at all. For example, what should happen when an attempt at conferencing or call forwarding reaches a busy signal is up to the application designer. Efforts to standardize these behaviors are only beginning.

A final complicating factor in the development of CT is that the computer and telephone industries have trouble communicating. The PC industry has focused on the desktop, open standards, and rapid technology evolution. The telephone industry has traditionally focused on large systems, proprietary designs, and long-term answers. The two industries thus speak different languages.

Despite all the rough edges, however, the elements for adding telephony functions to PC-based systems are available. The widespread installation of TAPI and TSAPI has removed critical economic barriers to applications development, resulting in an explosion of new software and hardware from which to choose. The field is changing rapidly, so you must track the status of standards. However, unbounded opportunity exists to merge two powerful information-handling tools into one that is greater than the sum of its part.

You can reach Technical Editor Richard A Quinnell at (408) 685-8028; fax (408) 685-8028*.

References

1. Levy, Markus, and James Leonard, "1995 DSP Chip Directory," EDN, May 11, 1995, pg 40.
2. Dwyer, Joseph M, "Design your way through the maze of European telephone-company equipment," EDN, June 8, 1995, pg 147.