One successful implementation of voice over IP for small enterprises (that is, one-location businesses with fewer than 100 extensions) has been demonstrated by local area network (LAN)-based PBXs. Figure 1 depicts a simple LAN-based PBX, where the LAN performs the physical switching function among H.323 terminals while the calls are administered by a control unit. The latter contains a gatekeeper at a minimum, and—in some products—a T.120 MCU. Other products postulate a more modular approach by which multimedia features are offered on a separate server. Such multimedia servers are separate products that can be integrated with LAN-based PBXs offered by different vendors. These servers support conferencing with multipoint collaboration, application sharing, and other conferencing services. Still other servers—for messaging, for example—can be integrated into the LAN-based PBX.
Figure 1: LAN-based PBX.
Connections to the PSTN (as well as to traditional PBXs and non-IP voice messaging systems in a LAN-based PBX) are achieved by integrating a reverse VoIP gateway. There, the role of the gateway was to connect a traditional PBX to the IP network; here, it is to connect what is effectively an IP network to the PSTN. This is an important example of duality manifested in the old PSTN and new IP converging products.
Except for a few especially sophisticated features (for example, whisper paging), the leading LAN-based PBX products support all traditional PBX features. The minimal list of such features includes call-forwarding, call transfer, call-waiting, calling party ID, conferencing, and support of multiple lines on one extension.
A LAN-based PBX can be distributed over several locations or even the whole enterprise network by adding routers, as depicted in Figure 2, thus creating a full-blown IP PBX.
The hardware of a typical IP PBX offer includes the following components:
§ H.323 or SIP terminals, which may look and feel (with their many buttons, the number of which determines their pricing) like traditional PBX multiple-line telephones
§ VoIP gateways to access the PSTN and other (non-IP) PBXs (number of ports varies)
§ Analog station gateways for connecting fax devices and traditional (POTS) telephones
§ Control unit (includes the gatekeeper at a minimum)
§ All the necessary connectors, LAN hubs, and cables
§ Servers for multimedia conferencing, unified messaging, administration, and other functions
Software is, of course, the most versatile part of the IP PBX. Its key enabling component, almost invariably called a call manager, resides in the control unit. In addition to provision and control of the PBX features, the call manager is responsible for gatekeeper-like functions, including registration of the H.323 or SIP terminals, admission control, guaranteeing QoS to participants (a significant function if the IP PBX spans several LANs), and, when necessary, cooperation with the software on the servers. Again, the presence of telephony application programmer interface (TAPI) and Java TAPI (JTAPI) libraries should be an important product differentiator, because these libraries allow you both to modify many service applications already provided by the vendor and to develop your own services. Theoretically, with a single control unit, the whole IP network can be turned into a PBX of sorts.
If different LAN-connected parts of an enterprise each have their own control units, as depicted in Figure 3 (such a configuration can often speed up and otherwise improve both communications and network management), the PBX is called distributed. Note that what actually is distributed (compared to the configuration of Figure 4) is the function of call manager software. In this case, support of a form of signaling among the control units that aids in negotiating QoS and optimizing the use of servers is also required.
Finally, we should demonstrate what may already be obvious to you: Despite the introduction of IP PBXs, legacy non-IP PBXs can still be used. Figures 6 and 7 depict two ways of integrating IP and non-IP PBXs: (1) through the IP network and (2) through the PSTN. Both cases demand tailoring of the original software (one more reason to emphasize the importance of software tool kits!), but in the latter case the PSTN (through IN, with the SCPs as servers) will cooperate in or even do the whole job of supporting features such as call distribution and single numbering plans.
Figure 5: Hybrid PBX (IP connection).
Figure 6: Hybrid PBX (PSTN connection).
No comments:
Post a Comment