Previous Table of Contents Next


Linking Distributed PBX Components

For organizations with large campus environments, an intermediate step between the legacy PBX and server-based telephony may be an architecture featuring multiple PBX components distributed throughout the campus.

This type of architecture has traditionally required a dedicated fiber backbone to connect multiple units. Under a voiceLAN solution, these units, outfitted with network adapter cards, can be connected over a LAN backbone infrastructure. This infrastructure is already in place in most larger campus network environments. In this case, the horizontal connection between the PBXs and the telephone sets at the desktop can continue to use the traditional voice network infrastructure.

There are two advantages to this architecture:

1.  Distributed PBXs scale more cost-effectively than a single, large PBX.
2.  The necessity for installing and maintaining dual backbones, one for voice and one for data, is eliminated.

Because this architecture does not implement voiceLAN to the desktop, it represents only a partial step toward a server-based telephony architecture. However, it also does not necessitate replacing old PCs with new ones outfitted with a USB interface.

Server-Based Telephony

A server-based telephony architecture allows for the traditional functions of the PBX to be broken down into its components and distributed on the voiceLAN network. The switching function of the PBX can be handled by the frame or cell switches of the data network, whereas the call control function can be moved to a server. Specific telephony applications can also be moved to distributed application servers and integrated with other networked data applications.

Initial Implementation Tips Implementing the ultimate voiceLAN architecture (depicted in Exhibit 4) cannot be accomplished through a wholesale changeover, except perhaps when an organization moves to a new building. Rather, this new architecture is typically deployed alongside the legacy PBX/dedicated voice network in the same way that organizations have deployed distributed servers running alongside centralized mainframes.

Server-based telephony should be implemented initially in specific workgroup environments. The best candidates are those workgroups that can best leverage server-based telephony applications that are available today.

Where a voiceLAN model is implemented, the user’s port on the legacy PBX should be left unchanged until the voiceLAN deployment has stabilized and been thoroughly tested. This is recommended because it provides, during the migration, redundancy and a backup system that can deliver phone service to the user.

The first phase of server-based telephony applications installed at the desktop is relatively basic. This configuration is similar to desktop PCs running terminal (i.e., phone handset) emulation and communicating with a LAN-attached mainframe (i.e., the PBX). While the integration with networked data applications is limited compared to a full-scale server-based telephony architecture, it does give users an intuitive GUI interface for voice communications and allows the users a certain level of integration with their desktop applications.


Exhibit 4.  VoiceLAN Architecture.

Desktop Telephony Applications Following are some examples of desktop telephony applications that should be considered for implementation in this initial phase. In these examples, the applications are enhanced by voiceLAN, in that they are melded with real-time voice communications:

  GUI phone At its basic level, this application running on the desktop provides a phone handset interface on the PC. The GUI phone prompts users to take more advantage of advanced call features that they are reluctant to utilize today simply because of the nonintuitive interface of existing phone handsets.
  Integration with PIM software Integrating the GUI phone with PIM software provides a seamless link between the user’s PIM application (e.g., an advanced electronic Rolodex) and the user’s actual communications interface (e.g., the GUI phone). This application offers functionality similar to call center applications to general users right at their desktop.
  GUI voice mail Voice mail can easily benefit from a graphic representation. At the click of a mouse, users scroll through a list of voice mail messages, saving, deleting, or forwarding messages. With this type of application, voice messages are treated as objects that can be manipulated in the same way data files are. For users, this method is potentially far more user-friendly and time-efficient than using the keypad of a phone handset.
  Integrated messaging When voice mail is decoupled from the PBX architecture, full integration with other types of messaging applications (i.e., E-mail) can more easily take place. VoiceLAN simplifies the process of combining message media and potentially reduces the cost of integrated messaging.

MIGRATING USERS

As the voiceLAN network is tested for its reliability as a dedicated voice network, the organization can begin to migrate the general population of users. Individual users or entire workgroups can be moved on a line-by-line basis by installing a USB PC and USB handset at the desktop, eventually eliminating the legacy phone set connected via the dedicated voice network. The order in which users/workgroups are moved depends on each user/workgroup’s ability and willingness to take advantage of integrated voice/data applications.


Previous Table of Contents Next

Copyright © CRC Press LLC