Integrating your computers and phones? Here's a guide through the maze of design approaches, technologies, standards, APIs, and industry politics.
James Burton
Things used to be so simple. There was only one type of light bulb. Gasoline was all leaded. Mustard was only yellow. Now incandescent lights are being replaced with fluorescents and halogens, gasoline has at least three octane ratings, and mustard fills three shelves at the supermarket.
It's the same with telephones and computers. When they didn't need to talk to each other much, a modem was more than sufficient. But now, the business advantages of computer-based call control are forcing this unnatural bond. Springing up to cement the union are myriad APIs and hardware designs. Without an understanding of how they work and which are most likely to
succeed, you could wind up with a CTI (computer telephony integration) system destined for the scrap heap.
CTI Architectures
Today's CTI systems generally fall into one of four different architectures or configurations, based on their approach to making the actual connections and managing calls. (See the figures
"Four CTI Architectures: Phone-Centric,"
"Four CTI Architectures: Server-Centric,"
"Four CTI Architectures: Voice-Server,"
and
"Four CTI Architectures: PC-Centric."
)
Phone-centric systems
are the easiest to implement; they only require a direct link from the phone to an external adapter that connects to the PC's serial or parallel port. They don't require extensive changes to an existing phone system. Users can have direct control over call routing (known as
first-party call control
). To transfer a call, for example, the user just clicks on an ic
on, and the PC sends a message to the switch that emulates a command from the phone requesting the switch to transfer the call.
Many PBX vendors offer adapters that give that kind of control to the PC. Unfortunately, these adapters don't provide a connection to the phone line and can't be used to connect data or fax lines to the PC.
Server-centric systems
connect your telephone switch to a server on your LAN. Here, the phone system becomes another part of the computer network, and you don't need a physical connection between the phone and individual desktop PCs. The LAN server, not the switch or the user, is responsible for routing calls (thus, it's termed
third-party call control
).
To transfer a call, the user clicks on the transfer icon, which sends a message to the server requesting that it transfer the call. The third party (the server) sends a message telling the switch where to route the call. The server's processing power lets it screen and route incoming calls. F
or example, caller-ID information may help route the call to the proper person. Third-party call control is particularly helpful in workgroups and call centers.
But the server-centric model manages only call control. The switch-to-server link is for status and requests only. It doesn't carry the voice path and in no way physically connects a phone line to the server. For a server to send and receive faxes and data, a physical phone line would have to be connected to a fax-modem board in the server.
Voice-server systems
are a variation on the server-centric model. Where server-centric systems deliver call-control links but not the calls themselves, voice-server systems deliver the calls directly, but not a separate control-and-status link.
In a voice-server model, phone lines from the switch connect to a board in the voice server. Depending on the board's capabilities, the lines can be analog, ISDN, or proprietary digital. The board can do anything that the phone it replaces can d
o; for example, it can issue a flash hook to transfer, conference, hold, call park, call forward, initiate call pickup from another office, and so forth. Digital phones usually have other features, such as speakerphone control and caller-ID display.
With the phone line going into a voice server, you get the media--that is, the voice path, or the data path for faxes and modem calls--but you don't get all the information and control that's available on the server-centric model. For example, a phone line can't force the switch to take control of another call; it can only control a call that it has received or placed. It can't tell the switch to forward a call from the next office to another phone.
In a server-centric call-center application, the server receives the caller ID and tells the switch where to send the call. In the voice-server model, on the other hand, the call is sent to the server, which must then answer it and transfer the call. But this is just too slow for a call center.
PC-centric systems
have the telephone line and the telephone itself connected directly to an add-in board in the PC. The telephony board emulates the type of telephone that the switch is designed to support, whether analog or proprietary digital.
When we have isochronous Ethernet or ATM (asynchronous transfer mode) data pipes going directly into our PCs, which looks to be the long-term prospect, we'll use PC-centric telephony systems. For the shorter term, however, we'll see fax-modem boards with telephony features that will provide an interim solution.
TAPI Dancing
Beyond network configuration, there are issues of APIs to iron out before you can point and click your way through the phone network. Two leading APIs (Microsoft/Intel's TAPI and AT&T/Novell's TSAPI), plus an emerging technology (Tmap from Nortel, formerly Northern Telecom), are designed to bring them together.
The most widely known current standard is TAPI (Telephony API). Developed by Intel and
Microsoft to support both client and server telephony, TAPI's key attributes are its tight integration with Windows, support for coexisting multiple applications, telephone network independence, support for all the different CTI configurations, and access to the information carried over the telephone line. Of course, it can also dial, forward, transfer, and perform other signaling operations. TAPI supports a wide variety of telephone networks, including PSTN (the Public Switched Telephone Network), PBXes, ISDN, cellular, and Centrex.
Besides supplying support for first- and third-party call control, TAPI provides a software interface for accessing media streams (i.e., the information carried end-to-end over the telephone network). This means TAPI can support applications such as answering machines, voice mail, conferencing, faxes, voice recognition, and data. TAPI also supports a wide range of telephone-switching equipment, such as legacy PBXes, voice servers, and PC-based switches, as well as a varie
ty of network connections, including isochronous LANs and ATM networks.
To date, TAPI has been implemented on Windows 3.1 and Windows 95. Microsoft has announced the TAPI implementation for Windows NT, which will allow suitably equipped NT machines to be computer-telephony clients (for the end user) or telephony servers on a network. TAPI allows desktop PCs to be either physically connected clients of a switch system or logically connected software clients of a Windows NT server.
So, if the phone and PC are physically connected at the desktop with, say, a Comdial TAPI adapter, TAPI interfaces between the Windows application and the Comdial hardware. In a server environment, TAPI interfaces with the server application running in the NT server.
This is where Microsoft and TAPI have a big edge over TSAPI -- tight integration into the desktop PC's OS, combined with tight integration into the server OS. This is a big win for developers because they can easily port their software from first-par
ty to third-party applications.
"Since TAPI is a standard part of the Windows family, developers and customers don't have to pay extra or try to figure out how to install a bunch of plumbing to enable their applications," says Charles Fitzgerald, a product manager in Microsoft's Personal Systems Division.
TSAPI, Anyone?
TAPI's main competitor, TSAPI (Telephony Server API), was developed by AT&T and Novell. TSAPI is an API for call control, call/device monitoring and query, call routing, and device/system maintenance for workgroups on a NetWare network. It integrates NetWare services with the functionality of a telephone PBX.
TSAPI uses the link between the PBX and the NetWare file server to create a logical connection at the workstation between the individual phone set and the desktop computer. This link enables an application to deliver the full capabilities of the phone system, control calls from either end of the call, or give a third party complete call-contro
l and monitoring abilities.
Using TSAPI, many software developers are delivering client/server applications that provide desktop dialing, visual voice mail, integrated messaging (i.e., fax, voice mail, and E-mail), conference-call bridging, sales-call restriction, and data/call synchronization. For example, the NetWare Telephony Services product from Novell is designed to provide easy server-based administration of a CTI environment. It also enables applications to generate usage reports, as well as access and share central network databases.
However, TSAPI has a problem: It does not provide media access -- that is, it does not provide a physical connection between the PC and the phone. Consider this scenario: A fax call comes in. Because TAPI accesses the call directly, it's smart enough to recognize a fax tone and can automatically transfer the call to a designated fax application on the user's PC.
A TSAPI-based server, however, would have no direct way of knowing what kind of call it i
s. It might, perhaps, recognize the calling phone number as a fax line that it already knows about. But even then, it can't transfer the call directly; it has to instruct the switch to do so.
TSAPI's designers evidently assumed that only call control really mattered. Now they're playing catch-up. Versit, an industry consortium (see the sidebar "Strategic Industry Alliances"), has adopted TSAPI as a cornerstone of its CTI solution and says it will develop extensions to handle media-control services.
A wide range of PBX companies and ISVs (independent software vendors) support TSAPI. Many PBX manufacturers in the U.S., Europe, and Japan -- including Alcitel, AT&T, Comdial, Ericsson, Fujitsu, Mitel, NEC, Nortel, and Siemens/ROLM -- have committed to developing NetWare drivers for their PBXes.
TSAPI supplies support for multiple desktop OSes, including OS/2, Windows, UnixWare, and the Mac OS. In addition, Versit has announced that it will extend TSAPI support to include Windows NT.
Tmap Ties APIs
With the CTI world choosing sides, users need a bridge to unite the two main telephony APIs. Tmap provides that link between TAPI and TSAPI, and it has been adopted by the ECTF (Enterprise Computer Telephony Forum). Tmap was developed by Nortel, which worked closely with Intel and received support from both Microsoft and Novell.
Tmap enables TAPI-based applications to work with PBX systems designed to support TSAPI. By translating TAPI programming calls to TSAPI requests, Tmap also lets TAPI-compatible desktop applications run on networks using NetWare Telephony Services. Developers can now build applications for the universal Windows client, which enables users to use whatever back-end server they choose.
Susan King, director of CTI at Nortel, explains that the company "created Tmap with the intention of easing developer confusion and has made it available to the industry free of charge."
Extending Tmap to the ECTF umbrella was a natural extension, an
d the ECTF will be able to define Tmap's evolution based on input from multiple vendors, which should ensure its viability in the marketplace. King notes that Nortel "has agreed to evolve Tmap based on the ECTF specifications and future iterations of TSAPI and TAPI."
Bringing in Resources
The real bottleneck in cross-platform interoperability is not the API but the lack of a resource model for the API to call. Every switch vendor implements a different model for each telephony command. Two different models are vying to become an architectural standard.
SCSA (Signal Computing System Architecture) is an industry initiative started by Dialogic and now supported by more than 260 companies. SCSA is a comprehensive hardware and software architecture for building call-processing systems with multiple technologies and standard interfaces. The architecture covers many facets of system design, from low-level bus and hardware interfaces to high-level software APIs.
With SCSA
, developers can integrate multivendor components within standard PCs or larger computer systems using the VME bus, which enables them to create computer-telephony systems ranging from medium to very large in size. The hardware-independent SCSA software model is compatible with TAPI and TSAPI.
The SCSA TAO (Telephony Application Object) Framework is the software portion of SCSA. This object-oriented architecture provides an open infrastructure that lets independent applications share a pool of discrete telephony resources--generally, call channels and data-stream-processing resources.
This is particularly important because one of the big issues (and common requirements) of telephony is real-time transmission. Computer-telephony resources require more complex resource management than does simple data transmission, which can often tolerate minor delays. This is comparable to a conversation stopping in midword and your having to wait for an indeterminate amount of time for another packet of wisdom
to finish the word.
Client applications to a TAO server running in a client or desktop PC typically call the server through an SPI (service provider interface), which converts one type of service to another. (Tmap, which converts TAPI to TSAPI, is a good example.) Usually the SPI is in the client software, but it can be in the telephony server.
An SCSA server can have many different operations and calls going on, and it has to be able to support them all in real time to avoid annoying delays; this is known as
dynamic resource sharing
. For example, say two calls come into an SCSA server at once. One caller uses an interactive voice-response system to retrieve data from a database linked to the server, while the second caller requests a fax back.
The SCSA server needs to handle both calls simultaneously. And it has to be able to hand off the fax call for data-stream processing when the second caller sends the appropriate command (and has turned on his or her fax machine).
Th
e model makes it simple for an application to pass call-data streams between different processing resources (e.g., recorders, recognizers, and phone ports) and also between applications. This allows, for example, an E-mail message to become a database query or another transaction.
SCbus (a part of the SCSA initiative) also allows servers to work together more easily. If you have multiple SCSA servers, for example, one server may need resources from another. In this situation, the time slots of the two servers aren't contiguous, so a
hyperchannel
is used to give one server access to a time slot in another server. SCbus supports this bundling of time slots, which is especially useful for transmitting services such as video.
"SCSA solves the fundamental problem in CTI today -- developing a common resource model," comments Carl Strathmeyer, director of marketing at Dialogic and chairman of the CTI trade association ACTAS (Alliance of Computer-Based Telephony Application Suppliers). "Until n
ow, developers would have to modify their software to work with each switch vendor's resource specifications. With SCSA and the ECTF, it's very encouraging to see industry vendors finally agreeing to a
single open architecture
that software and telephone-equipment vendors can build around in total confidence."
Green with MVIP
An older alternative to the SCSA hardware platform is MVIP (Multivendor Integration Protocol), which is another digital auxiliary bus. The SCSA TAO software environment supports both.
MVIP is based on the Mitel ST bus reference design and was defined in 1990. It's a bus developed for use in computer-telephony servers as well as to allow videoconferencing workstations to hop from an ISDN or T1 adapter card to an H.320 videoconferencing codec.
MVIP uses a distributed switching model that's similar to modern PBX architectures and makes software development easy, and bandwidth and CPU utilization highly efficient. (However, SC
bus offers even more bandwidth than MVIP.) It's used in telephony servers and for distributed computer-telephony systems.
If It's Plug-and-Play, Whose Plug?
Besides a software API and architectural platform, CTI needs a standard mechanism for connecting peripheral devices. The RJ-11 phone jack can't carry the load, and the RS-232 serial port is too cumbersome. To address these limitations, two new contenders have emerged: USB (universal serial bus) and GeoPort. Both will be used in phone-centric designs, because the phone line connects to an adapter or to a phone with a built-in interface.
USB was jointly developed by Compaq, Digital Equipment, IBM, Intel, Microsoft, NEC, and Nortel. It has a multidrop interface and uses a single connector for phones, modems, keyboards, mice, game ports, serial devices, digital audio, printers, and scanners. It has a built-in port for connecting to PBXes, ISDN lines, Centrex systems, and even POTS (the industry acronym for "plain old tel
ephone service"). With the vendor support that it has, USB will become a standard feature on most PCs by mid-1996.
The USB specification will simplify and improve the performance of PC-to-peripheral and PC-to-telephony applications. It will bring support for new computer-telephony integration capabilities -- communicating mixed-media information, including sound, images, and data - -and will eliminate the need for special add-in telephony connections.
USB runs at 12 Mbps, compared to the standard PC serial port's speed of 115 Kbps. It also offers isochronous and asynchronous data transfer, a star-hub architecture that allows a single PC-port controller to link up to 63 digital peripherals, and automatic recognition and configuration of external USB-based peripherals.
GeoPort, the other contender, is Apple's point-to-point interface. It supports phone/PC connection, as well as devices such as Apple's digital camera. In a CTI architecture, GeoPort provides the connection between the PC and
the phone, as well as a flexible means of attaching peripherals via a single, compact, mini-DIN connector.
GeoPort is a cross-platform interface that delivers voice, data, audio, and video communications over any analog (POTS) or digital (PBX or ISDN) telephone line to a PC. It provides a flexible, scalable architecture for multiplexing several dozen simultaneous data streams, such as the 24 channels found in an ISDN primary-rate interface.
Versit opted for Apple's GeoPort architecture, which allows isochronous communications as fast as 2 Mbps. The Versit GeoPort provides up to 200 times the bandwidth of traditional serial ports.
Bye-Bye, PBX
We believe the recipe for a successful CTI system will likely include the following:
-- Architecture: SCSA
-- API: TAPI (for some NetWare users, the Versit version of TSAPI)
-- PC operating environment: Windows
NT for mission-critical CTI applications
-- Physical interface: USB
The
future of CTI will consist of departmental and workgroup solutions where SCSA-based servers operate behind existing switch systems. The trend toward increasing intelligence in call control will result in a platform-independent API that will enable cost-effective applications development. The next step will put the switching technology into the PC server.
Emerging CTI applications are transport-independent -- they don't rely on the underlying switch architecture. Once we arrive at the stage where the phone is just another part of the PC, transport-independent CTI applications are running over isochronous Ethernet or ATM, and SCSA servers are connected directly to the PSTN, we can finally say good-bye, once and for all, to proprietary PBXes.
Where to Find
Comdial
Charlottesville, VA
(804) 978-2200
ECTF (Enterprise
Computer Telephony Forum)
Foster City, CA
(415) 578-6852
fax: (415) 378-6692
Nortel (formerly Northern Telecom)
Richardson, TX
(800) 466-7835
(214) 684-3
726
SCSA (Signal Computing System Architecture)
c/o Dialogic Corp.
Parsippany, NJ
(201) 993-3000
Versit
c/o Apple Computer
Cupertino, CA
(408) 862-5154
illustration_link (8 Kbytes)
The phone is linked via an external adapter that connects to the PC's serial or parallel port (and soon via a USB [universal serial bus]). The PC is not directly connection to the phone line, but rather to the adapter.
ADVANTAGES:
Such systems are easy to implement and don't necessitate extensive changes to an existing telephone system.
DISADVANTAGES:
Today
's adapters don't provide a connection to the phone line and cannot be used to connect data or fax lines to the PC. This will change with USB.
illustration_link (8 Kbytes)
Here the phone lines connect to a switch, which in turn connects to a telephony server on the LAN. The LAN server manages call routing, although it has to have the switch perform the actual transfers.
ADVANTAGES:
No physical connection is needed between the phone and the desktop PC. Third-party call control is good for workgroups and call centers.
DISADVANTAGE:
The server can'
t perform automated, intelligent switching of different types of calls -- fax, voice, and data.
illustration_link (8 Kbytes)
Phone lines are connected to a board in a voice server that sits on the LAN. The server gets the voice or data call, but not control information -- just the opposite of what happens in the server-centric configuration.
ADVANTAGES:
This configuration provides access to the media stream (e.g., voice, data, and fax).
DISADVANTAGES:
A phone line can only control a call that it has received or placed; it can't send other types of i
nstructions to the switch. This architecture can be too slow for call-center operations.
illustration_link (6 Kbytes)
The telephone line and the phone itself are connected directly to an add-in board in the PC. The telephony board emulates the phone to the switch.
ADVANTAGES:
This configuration provides a direct voice path from the phone into the PC, which is useful for I/O operations. Ultimately, it can eliminate the PBX entirely.
DISADVANTAGES:
This is an expensive solution, because considerable processing power is required in each PC. If the system u
ses proprietary phones, it's even more costly.
illustration_link (12 Kbytes)
We'll say farewell to the PBX as we know it when SCSA (Signal Computing System Architecture) servers on our networks are linked to each other and to the telephone company's central office.
James Burton is the CEO of C-T Link, Inc., in Boston, Massachusetts. You can reach him on the Internet at
jburton@internetmci.com
or on BIX c/o "editors."
Standard Issue
