opening up the architecture of the PBX so it's easier to tap a PBX's functions and services. And they're making the PBX a better network citizen by adding support for traditional data network management.
How It Works
Before you start plugging cards into your server and installing software on your PBX, you should probably know what's going on in there. A PBX is easy to understand, at least from a high level: it's a switch. It has a bus into which you plug cards that provide various functions, such as ISDN and Switched 56 service, or for plugging telephones (or other devices) into the outside world.
These devices, which all have their own unique addresses, set up virtual circuits with other devices. When you pick up your telephone and dial an internal extensi
on, the PBX basically hands your phone's address to a memory location that's reserved by the other extension's telephone, and vice versa, then sends a ring signal to the other phone. Easy enough. The switch part of the PBX keeps track of all the exchanged memory locations and routes signals to the appropriate ones. A central processor and a real-time operating system control the switch.
Recently, PBX vendors have added the capability to handle data directly from PCs and LANs. There are two approaches to handling data traffic in a PBX. One is to dedicate PBX channels to data traffic and circuit-switch that traffic; basically, the PBX handles voice and data the same way (see the figure
"Dialing for Data"
). The other approach is to switch voice traffic through the PBX but use LAN-based packet switching for the data, essentially creating a hybrid PBX/LAN hub (see the figure
"Bringing It Together"
).
Today it makes sense that you could run data and voic
e over a PBX. It's just a digital signal, after all. PBX vendors even created digital PBXes that could handle both voice and data as many as 10 years ago. But it's not that simple. The problem lies in the PBX's closed architecture.
The first PBXes had closed hardware and software architectures that were tightly integrated. Hardware was usually proprietary--the processors were often designed specifically for a vendor's PBX. Since the hardware was proprietary, so was the OS. And since the OS was proprietary, all the applications were, too. Consequently, PBX functions like call processing were closely tied to a specific PBX model (or, if you were lucky, to a PBX family). With all this proprietary design, software vendors were a little concerned about developing for a PBX that would become extinct. Consequently, they didn't develop the software that would have facilitated the joining of PBX and computer or network.
Today, most vendors build their PBXes around commonly available processors running co
mmon operating systems (typically Unix) and use common programming languages (C and C++). Modular architectures have replaced monolithic, and all functional aspects, such as systems management, applications, and applications management, are decoupled from each other (see
"Building Blocks Add Up"
).
This architectural change makes it much easier to develop, troubleshoot, and add new applications to a PBX. Granted, you probably won't go off and develop a quick telephony app, but you're no longer stuck waiting for the PBX vendor to modify its software for a new service or function. You can now choose from many telephone VARs and systems integrators to write applications for you.
The modular software approach also makes it easier to take advantage of new telecommunication services, such as wireless networks, as they become available. A PBX manufacturer would have to provide only wireless network interfaces and wireless call-management software in order for you to connect to a
wireless service.
Additionally, the modular approach decouples the call-processing functions of a PBX from the actual switching fabric. That means the same administrative and management functions can be applied to different switch fabrics. In essence, you can upgrade a PBX's switching fabric to a new technology, such as asynchronous transfer mode (ATM), without having to redo all the software.
PBX Glasnost
Thanks to open hardware and software architectures, PBX vendors can now offer more features and newer WAN services faster than they could in the past. Suddenly, PBXes look pretty attractive to data networking folks. And additional modifications will enhance the PBX's status as a data network element.
For example, it's now easier to connect a PC or a LAN to a PBX. Older PBXes have low-speed, proprietary connections between the PBX and any data device--64 Kbps was typical.
Much has changed. PBX vendors have added higher-speed data interfaces and embraced stand
ard approaches to connect the networking environment with the PBX. These approaches include TCP/IP connections and support for new APIs.
A Uniform Language
Probably the most important development in the last two years is the near universal support by PBX vendors of two programming interfaces: AT&T and Novell's Telephony Services API (TSAPI) and Intel and Microsoft's Telephone API (TAPI). These two APIs provide standard ways for PCs to give PBXes orders and receive information back. Historically, integrating computers and PBXes was expensive--it was something you did with several hundred-thousand dollars' worth of hardware and software. Today you can buy VBXes and OLE Controls that you can plug into any Visual Basic application. You can generate a telephony-enabled application for about a hundred dollars, and ready-to-roll applications would cost you only a few hundred dollars per seat.
TSAPI creates a logical connection over a LAN between the computer and the telephone on a
person's desk (see
"Logical Links"
). It defines the function calls the client and server applications use to manage and execute telephony services. This has been possible for a while, but older systems used a physical connection between the computer and the telephone--a computer with an adapter card that incorporates a jack for a phone handset, for example.
A common use of TSAPI is automatic call distribution (ACD), where a call can be routed based on the time of day, day of the week, information the caller enters in an interactive voice response system, or the caller's telephone number. Most ACD systems link calls to data that they make available on someone's PC. For example, in a bank's customer-service department, the ACD system would display the caller's account information on the PC screen as the bank employee picked up the phone.
To achieve such integration requires that the PBX and the LAN server (to which the PCs are connected) work closely together. The PBX must sup
port the NetWare Telephone Services (NTS). Most major PBXes, such as those from AT&T, Fujitsu, Mitel, and NEC, do.
TSAPI also requires several software components on the server. Specifically, a NetWare file server must run a set of NetWare loadable modules (NLMs) that establish and maintain the logical connection between each phone and desktop computer. These NLMs include Novell's TServer, a PBX driver, and a PBX link driver. TServer is the TSAPI NLM. It defines how a PBX and a computer communicate. It's through this interface that a client sends requests to a PBX to do things like dial a telephone number.
The PBX driver takes client requests and translates them into the proprietary command language the PBX understands. It then passes the instructions to the PBX through the PBX link driver, which simply passes the commands across the link connecting the PBX and the server. The PBX vendor supplies these two drivers.
When you put it all together, it works like this: The client sends its req
uests for telephony services over the LAN to the TServer NLM using the SPX protocol. The TServer NLM talks to the PBX driver, which routes the TSAPI request to the PBX via the link driver. When the PBX receives a request, it carries out the action.
In the case of the customer-service department, for example, a TSAPI-enabled ACD application would direct an incoming call to the appropriate associate, ring that person's phone, and pop the caller's account information up on the associate's computer screen.
There are many third-party developers writing TSAPI-enabled applications. CallWare Technologies, for instance, offers several telephony NLMs that provide features such as voice mail, auto attendant, and audiotext (which allows a user to record frequently requested information). One NLM, VoiceView, allows users to manage all their voice messages through a simple PC-based graphical interface.
Another CallWare NLM supports NetWare Directory Services. It lets a network manager administer both t
he data network and the CallWare voice-messaging system from one point. For example, from a single NDS user object, an administrator can set access rights to all network files, enable CallWare to notify your pager when you receive voice mail, and add or change CallWare voice-mailbox assignments.
Applied Voice Technology offers a TSAPI-enabled interactive voice-response product called CallXpress3 Automated Agent. The system can use either caller ID or automatic number identification (ANI) to direct a call to a customer-service associate or order-entry agent. If caller ID or ANI are not available, Call-Xpress enables you to write automated agent scripts to ask the caller who they are and why they are calling. Regardless of the way it identifies a caller, CallXpress routes the call to an appropriate person and brings up the caller's files on that person's computer screen.
Aurora Systems offers TSAPI-based middleware tools to endow any Windows application, such as a database management or contact ma
nagement program, with telephony capabilities. The tools let you route incoming calls based on caller ID or ANI and open an application screen displaying the calling customer's information. Users could transfer the call to another person, who would receive the customer's records along with the call. For outgoing calls, Aurora's software enables a user to access any telephone function with the computer's keyboard instead; for example, a user could set up conference calls by clicking on names in a database.
The TAPI Alternative
PBX vendors and developers of computer telephony integration (CTI) applications are also considering TAPI. TAPI's strength is its tight integration with Windows. A user can dial, forward, and transfer calls from any TAPI-enabled application. And any off-the-shelf application running on a Windows PC can access TAPI services. That means, for example, you can place calls from your existing customer database by double-clicking on a customer's phone number displaye
d on your screen.
Last year, many leading PBX vendors, such as Mitel, NEC, and Nortel, announced they'd support TAPI in their PBXes. However, unlike the case with TSAPI, most of the TAPI activity by third-party developers has focused on desktop applications and not on LAN-based TAPI-enabled applications. The reason is simple: The server part of TAPI is not available. (Sources at Microsoft tell us it should be by the time this issue is out.)
Last March, Microsoft announced it would port TAPI to Windows NT. And last fall, Microsoft said it would give vendors the necessary code to develop TAPI drivers. Such drivers, like the TSAPI drivers, would translate the TAPI commands and requests for services into the proprietary command language of each PBX vendor's switching system.
The anticipation of TAPI-enabled servers and PBXes has primed the CTI application pump. At last fall's Comdex, several vendors showed or announced LAN-based CTI applications built around TAPI. Nortel demonstrated its TAPI
toolkit that offers many call-processing and routing utilities from which you can build LAN CTI applications. Dialogic late last year introduced a TAPI-based version of its CT-Connect software, which hooks a PBX to a LAN, providing applications with call-status information.
Faster Links
TSAPI and TAPI help open the software that talks to a PBX. PBX vendors are also adding support for standard interfaces, such as ISDN and Ethernet, to address the physical openness, and they're adding open network protocols to get PBXes talking to LANs. About two years ago, InteCom offered TCP/IP connectivity for its PBXes. Last year, AT&T and Mitel did, too.
Having TCP/IP is great, but enterprise network managers are not likely to add any device to their networks that doesn't appear on their management consoles. Easily done: Vendors are making PBXes so they can be managed by SNMP. PBXes have always had extensive diagnostic and management systems, but they've been proprietary: All the informa
tion about the system and call status has not been accessible from your standard network management platforms, such as HP OpenView or SunNet Manager.
SNMP changes that. AT&T's OneVision Definity Fault Management system, for example, employs SNMP to pass PBX status information to a network administrator. The system uses hardware and a software proxy agent to convert Definity's proprietary management data protocol into SNMP Management Information Base II (MIB II) data that is accessible through HP OpenView.
Bright Future
The efforts by PBX vendors in the last two years to make their products more data-friendly are starting to show results. We're seeing the first wave of standards-based CTI applications and a tighter integration between LANs and voice networks. The PBX is now a communications server in a LAN environment.
Some PBX vendors are adding server functions to their products. Basically, they're taking a processor in the PBX and running NT or NetWare on it. PBX fe
atures, such as call-forwarding, become available to data applications. With the tight integration of PBX services and network operating systems, standard telecom functions can more easily be made available to LAN applications.
But the real buzz has to do with the future of the PBX. ATM is a key part of most PBX vendor's strategy. By opening up the architecture of their PBXes, many vendors are poised to move quickly. In the process of modularizing software and hardware within PBXes, many vendors decoupled the switching functions from all other functions. That means today's circuit-switched PBX could, in theory, easily be modified by swapping in an ATM switching matrix. Of course, there's call-processing software that needs to be developed, but the point is this: Vendors do not have to start from ground zero.
Once ATM-based PBXes start to appear later this year or early next, it will be hard to tell the difference between a PBX and a switching hub. That's when the voice and data worlds will truly
become one.
In the meantime, remember: Press the Conference button, then dial the new person's number, then press Conference again.
WHERE TO FIND
PBX VENDORS
AT&T
(Business Communications Services Division)
Basking Ridge, NJ
Phone: (800) 242-6005 or (908) 221-2000
Internet:
http://www.att.com
Opening PBX Doors
