Standards for CTI: hard choices ahead.
By combining the power and parsimony of PCs with the reliability, ubiquity and user-friendliness of the telephone, Computer-Telephony Integration (CTI) has emerged as one of the fastest growing areas of information processing.
Because of this growth, though, product development threatens to outpace the ability of standards organizations to set ground rules.
Already, CTI implementers must choose between two popular application programming interfaces (APIs):
* Novell/AT&T's Telephony Services API (TSAPI) allows a NetWare server to be connected directly to a PBX, giving users third-party call control for applications such as conference bridging, call monitoring, intelligent call routing and integration with NetWare Directory Services.
* Microsoft/Intel's Telephony API (TAPI) runs on Windows machines and provides first-party call control. With this desktop- rather than server-based approach, users control :: basic telephony functions such as dialing, answering, transferring and conferencing calls from their PCs.
Choosing an API is important because it determines the hardware and software you need to buy, the applications you can run and the capabilities you can deliver to end users. What complicates matters is that products developed to these APIs often must interoperate with each other and with many types of legacy PBXs and switching systems.
Last year, a group of leading vendors founded the Enterprise Computer Telephony Forum (ECTF) to address this interoperability issue and accelerate acceptance of CTI. ECTF has quickly grown to more than 50 companies, including developers, integrators and users, with the common goal of promoting "enterprise" computer telephony.
In this vision, standards-based services from multiple vendors would be implemented in various ways to meet all the needs of the enterprise. ECTF has decided against adopting one implementation model universally, believing such an approach would be unrealistic since the needs of different enterprises vary widely. A manufacturer with 100 workers, for example, would need a different CTI solution than a service company with thousands of employees.
Also, since it's unlikely there will soon be a single standard API or other component, the Foster City, Calif., consortium has chosen to focus on promoting interoperability among the diverse elements needed for CTI. It will provide coordinated input to standards bodies and seek consensus in areas where standards are not fully defined, including interoperability agreements by key vendors.
Most enterprises embrace CTI for call center and other workhorse applications such as the automated Rolodex.
A typical call center package will route incoming calls to an appropriate live operator, either by using an interactive voice-response system to gather customer information or by employing the caller-ID to pull records from a database and display a "screen pop" on the operator's PC.
With the automated Rolodex feature, a salesperson simply clicks on the "dial" button of a prospect's database record. The phone number is dialed without error or concern for long-distance access codes.
While these applications can save considerable time and money, they represent a low level of integration between computers and telephony, Newer CTI applications such as interactive fax and unified messaging seek to leverage more of the computer's power and versatility.
Networked fax servers are nodes on the network for sending files outbound. Callers can dial in to request that documents be sent to them, or the same fax can be broadcast to a list of recipients overnight, say, when rates are low or you want to leave lines free for incoming faxes.
With unified messaging, users can access voice, fax, E-mail and, possibly, video messages from a single inbox, with links to paging or other systems. It gives users better control of their personal communications, whether they are in the office or away.
A more advanced CTI approach comes from Mitel Corp. of Kanata, Ontario, which recently released an enterprise "voice-LAN" solution called NeVaDa (Networked Voice and Data) that delivers data, voice and video traffic over a single converged broadband network It also makes possible advanced CTI applications such as voice-mail databases and voice-annotated files
Besides expediting CTI applications at the desktop and in the workgroup, NeVaDa provides a single network infrastructure for organizations with disparate data and voice networks. In addition, the integrated network can be managed from a Unix workstation running the HP OpenView platform.
NeVaDa employs an ATM/SONET module, developed jointly by Mitel and Madge Networks, which fits in Madge's LANswitch. The module uses switched LAN techniques to transport the multiple media over a 155-Mb/s fiber backbone. It supports a variety of switched and shared modes of operation, including Ethernet, token ring, 10BaseT and FDDI.
Mitel believes that CTI products that integrate LAN hubs into PBXs are doomed to fail because the PBX architecture cannot support high-performance networking. By doing the inverse, merging the PBX into the LAN, it hopes to capitalize on the network's ability to support voice as just another desktop application.
Mitel's vision raises an intriguing premise: for CTI applications to realize their full potential, the data network infrastructure itself must be made "voice-ready".
TSAPI VS. TAPI
Thanks to improved technology and the development of popular APIs, CT1 costs have dropped to a few hundred dollars per desktop, making it cost-effective for a growing number of organizations.
The APIs shield application developers from the complexities of dealing with PBXs, servers and other network elements, making CTI solutions available in weeks rather than months and slashing deployment costs.
Most PBX suppliers now support one or both of the popular APIs: Novell/AT&T's Telephony Services API (TSAPI), which runs on a NetWare server connected physically to the PBX, setting up logical links between handsets and PCs; and Microsoft/Intel's Telephony API (TAPI), which runs on Windows machines with a physical link between handset and PC.
TSAPI is generally more cost-effective in large networks, since the hardware cost is limited to the connection between server and PBX. Server-based solutions are also easier to administer, since management can be centralized and user and applications information entered and distributed via the server. Further, TSAPI supports third-party calling, which makes it possible to implement more advanced features.
TAPI supports first-party call control, which is good for simple telephony functions such as dialing, answering, transferring and conferencing calls.
TAPI must be installed individually in each PC, along with the applications and adapters, so it can be expensive for anything other than small networks. Microsoft is mitigating this by offering TAPI applications with its Windows 95 operating system. It is also releasing a server-based version for Windows NT, enabling third-party call control.
TAPI appears to have the edge with developers, while TSAPI enjoys better support from PBX vendors. Versit, the joint development initiative of Apple, AT&T, IBM and Siemens Rolm, has also embraced TSAPI and gone one stage further by introducing Encyclopedia, a set of specifications for insuring interoperability among any client, server or switching mechanism.
For users. the encouraging, news is that the members of Versit also belong to the Enterprise Computer Telephony Forum, which is working to make sure that applications developed for TSAPI will be able to work, without any changes, on TAPI computer-telephony implementations, and vice versa.
Data communications consultant Morris Edwards is program chairman of the Network Computing Solutions Conference and Exposition, or NetCom, to be held in Charlotte, N.C., Oct. 9-10 and in Nashville, Tenn., Oct. 30-31.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Technology Information; NetComm Update; competing computer-telephony integration APIs from Novell AT&T and Microsoft Intel|
|Date:||Sep 1, 1996|
|Previous Article:||Java: Online marvel or menace?|
|Next Article:||Beefing up browsers.|