Scenario 2: Legacy PBX replacement

Traditionally, institutions and companies are equipped with a PBX on (each of) its premises. Telephones are wired to the PBX which supplies them with power. The PBX handles all intelligence and routes calls to the PSTN over trunks (E1, T1, J1, ISDN30 etc).

Figure 3.4. Legacy PBX which trunks to the PSTN

Legacy PBX which trunks to the PSTN

One of the most economically feasible deployments of IP Telephony currently is in the area of installing voice over IP as a replacement of inter-building PSTN connections within one company, or even the complete replacement of the PBX phone system (and terminals) itself.

This chapter first describes the scenario's in which IP phones can be deployed in a peer-to-peer fasion without additional control entities in the network. This scenario is only covered briefly because the practical use is limited.

Then a common scenario will be described to introduce IP Telephony in the existing telephony infrastructure. The legacy PBX is still functional in this scenario, but the transportation of the voice calls can not only be done over regular PSTN trunks but also over IP backbones.

The last scenario describes total replacement of a PBX infrastructure by IP Telephony equipment.

Scenario 2a: IP-Phone without PBX

The simplest case of IP Telephony is making a point-to-point call between IP Phones. To make this succeed, the calling party needs to know the IP address of the called party, or its DNS entry.

Figure 3.5. IP-Phone to IP-Phone without PBX

IP-Phone to IP-Phone without PBX

For a (mission-critical) company or institutional phone system, this is an awkward method. Moreover, it is not possible to make a call to a regular telephone within the institution or to the PSTN over an VoIP-to-PSTN gateway. Also, common features like central address books, call forwarding etcetera are harder to integrate with the phone terminal. If the destination is unreachable, nothing useful can be done with the call, like redirecting it to voicemail etcetera. This setup is therefore only recommended for testing purposes.

The working of a call setup is very simple, either when using H.323, SIP or any variations on these protocols. Since the calling party directly enters the IP address of the destination, the call initiation signalling is sent directly to that IP address. If the terminal is running, it will process the signalling and the called party will be prompted to pick up the phone. When that happens, the call is setup, a codec is negotiated and the voice stream will start until signalling is exchanged that terminates the call.

Scenario 2b: Integration with legacy PBX systems

This scenario allows coexistence and intercommunication of institutional conventional telephony network (conventional phones connected to PBX) and local IP telephony network. The scenario is suitable when the local IP telephony network is constructed gradually in an institution that already has a conventional telephony network. In a later stage, the conventional telephony network and the PBX can be totally replaced by the IP telephony network, thus converging to scenario 2c.

In this chapter we give an overview of options for interconnecting a PBX to a Voice Gateway (VoGW). These options also apply to scenario 1. More technical details for individual interfaces are given in Chapter 4.

Figure 3.6. Integration of IP-Telephony with legacy PBX system

Integration of IP-Telephony with legacy PBX system

The choice of particular interface between a PBX and VoGW depends on required functionality, availability of interconnection ports on both sides and also on cost constraints. Interfaces can be divided into analog and digital. Analog interfaces include a 2-wire U-interface with subscriber loop and various types of E&M interfaces. Digital interfaces include E1/CAS trunk with MFC-R2 signaling and ISDN with DSS1 or QSIG signaling. The advantages and shortcomings of individual interfaces are summarized in the following list:

  • Subsriber loop - Suitable when conventional phones should be connected directly to VoGW via FXS interface (but can also be used for PBX interconnection). A disadvantage is that when calling inward PBX, an extension number can be dialed only as DTMF suffix after a call was established and is already accounted. Usually a low cost solution.
  • E&M interfaces - E&M is commonly explained as Ear and Mouth or recEive and transMit. Allows extension dialing before the conversation begins. Requires a special interface card for PBX, but if PBX is already equipped with this card, this can also be a low-cost solution.
  • E1/CAS trunk with MFC-R2 signaling - CAS (Channel Associated Signaling) exists in many variaties that operate over analog and digital interfaces. A common digital interface used is E1 (European version). The advantage of a digital interface is its ability to transfer the identification of the calling party, which is important for detailed accounting. This is the first digital solution that was used, which was later mostly replaced by ISDN interfaces. Requires special interface cards on both sides of interconnection, it is rather expensive solution.
  • ISDN with DSS1 signaling - In addition to calling party identification, supplementary services are available such as Call Waiting, Do not disturb, etc. Can be used with a BRI interface (up to 2 simultaneous calls) or PRI interface (up to 30 simultaneous calls). The interface card is usually already in place on modern PBXs. The PRI interface is economically preferable when more than 8 channels (4xBRI) are required.
  • ISDN with QSIG signaling - QSIG signaling supports more supplementary services, such as Call completion, Path replacements, etc. However, QSIG uses proprietary features of PBX from particular manufactures and is therefore suitable only for corporate networks, where IP telephony is used to interconnect PBXs in company branches.

Scenario 2c: Full replacement

In greenfield situations or when an existing PBX is fully depreciated, the time has come to consider IP Telephony as an alternative to a traditional PBX.

Figure 3.7. IP-Telephony fully replacing PBX

IP-Telephony fully replacing PBX

The design of a IPBX system includes a couple of choices.

Intelligent vs simple terminals

IPBXes can support terminals in two ways: either they have analogue ports that support analogue terminals, or they are IP only. The latter means that the terminals are intelligent devices, including an implementation of many signalling functions. Since so much intelligence is included anyway, these terminals are often equiped with interactive screens and other sophisticated functions. This makes the equipment expensive and requires the terminals to be provided with power, which can be supplied with Power over Ethernet. A feature that most of these advanced terminals support is pass-through of Ethernet, so that one wall outlet can be used for both IP Telephony as well as a computer.

Signalling

Though the choice between H.323, SIP or a proprietary system seems a purely technical one, it has implications for the interoperability with future expansions, inter-department trunking and the development of new advanced features like messaging etcetera. It is wise to have a supplier comply to at least one of the open standards.

Inter-department trunking

The choice for a full IP based institutional voice network does not automatically lead to a choice for the way that geographically separated locations are connected. The cookbook supports this choice in the Least Cost Routing section.

The inter-department architecture also includes a choice whether to break out local calls at local PSTN trunks, or to centralize all PSTN trunking on one of the locations of the institution. This choice depends on the tariff structure that the public operator(s) offer for centralized break out as well as the amount of calls that have a local public destination compared to long-distance public and private destined calls.

Legacy functionality

Traditional PBXes have the advantage that some legacy functions have been incorporated in the past. They need to be included in the IP Telephony architecture as well. The most elementary are:

  • Emergency call handling to public emergency numbers (911, 112 etc)
  • Public dialplan routing (regular numbers, blocking/routing of premiumnumbers etc)
  • Integration with public wireless telephony
  • Voice/data integration and call distribution for call center/help desk department
  • Support for beeper systems
  • Support for private wireless telephony
  • Support for elevator phones

Wireless VoIP

With three manufactureres currently presenting wireless IP terminals that can use IEEE 802.11b (WIFI) wireless data communication, a new aspect for VoIP is emerging. Where DECT has a strong position in the wireless PBX market, it can be expected that institutions that have WIFI networks in place want to reuse this infrastructure for their wireless telephony network, obtaining similar consolidation advantages as in the fixed IP telephony case. Wireless IP phones are equally intelligent as their fixed equivalents, but are different on the Ethernet level. The usual issues in wireless data communications hold in their case: low battery usage, portability, coverage etcetera. Developments show that manufactureres of public network mobile phones like GSM are planning to incluse Wireless VoIP into their terminals. This enables seamless roaming from public wireless telephony networks to the campus environment, potentially reducing costs when calling on campus.

Issues

Since the field of IPBX is rapidly emerging, many features that are known in the traditional PBXes are quickly adopted. New issues arise when data networks develop. An example is the introduction of network access control by IEEE 802.1X. This standard forces equipment that wants to send Ethernet frames to a network to first authenticate at a RADIUS server. All equipment on 802.1X enabled network ports should be 802.1X enabled as well. With the adoption of 802.1X, terminals are announced to include the standard as well.

A similar situation holds for VLANs. In case a network administrator chooses to put IP telephones in a different VLAN compared to PC (groups) and the IP telephones are in pass-through configuration, they should support VLAN trunking. This feature is arising in the market.