Traditionally, institutions and companies are equipped with a PBX on each one of its sites. 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).
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 itself, along with its terminals.
This chapter first describes the scenarios in which IP phones can be deployed in a peer-to-peer fashion without additional control entities in the network. This case is only covered briefly because its practical use is limited.
Then a more common scenario will be described, where IP Telephony is introduced in the existing telephony infrastructure. The legacy PBX is still functional in this scenario, and voice calls can not only carried over regular PSTN trunks, but also over IP backbones.
The last scenario describes the total replacement of a PBX infrastructure by IP Telephony equipment.
The simplest case of IP Telephony is making a point-to-point call between IP Phones. To place a call, the calling party needs to know the IP address of the called party, or its DNS entry.
For mission-critical cases, such as a commercial company or an 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, because no VoIP-to-PSTN gateway is available. Also, common features like central address books, call forwarding services, etc. 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 a voicemail service, etc. This setup is therefore only recommended for testing purposes.
Call setup is very simple, when using either H.323, or SIP or any variations of these protocols. Since the calling party directly enters the IP address of the destination, call initiation signaling is sent directly to that IP address. If the terminal is functional, it will process the signaling 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 signaling that terminates the call is exchanged.
This scenario allows the coexistence and intercommunication of the institutional conventional telephony network (conventional phones connected to PBX) and the 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.
For example, in order to provide for smooth transition, it might be worthwhile to buy a gateway with two ISDN PRI interfaces (or just with one interface and borrow the second interface for the transition period). One interface is connected to the PSTN and the second one to PBX. During the transition period Gateway performs also call routing between PSTN and the old PBX and vice versa providing a smooth transition in the meanwhile.
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.
The choice of a particular interface between a PBX and a 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. The former include a 2-wire U-interface with subscriber loop and various types of E&M interfaces. The latter include an E1/CAS trunk with MFC-R2 signaling and ISDN with DSS1 or QSIG signaling. Giving technical details about the trunks and interfaces mentioned above is outside the scope of this Chapter, refer to Chapter 4 for further details. On the other hand, technical people who want to understand this kind of scenario may benefit from a discussion of the advantages and shortcomings of individual interfaces, which are summarized in the following list:
- Subscriber loop - Suitable when conventional phones should be connected directly to VoGW (Voice GateWay) via an FXS interface - an FXS interface connects directly to a standard telephone and supplies ring, voltage, and dial tone, but can also be used for PBX interconnection. A disadvantage is that when calling inward towards the PBX, an extension number can be dialed only as DTMF (Dual-Tone Multifrequency) suffix, after a call is established and is already accounted for. This type of interface is 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 the PBX, but if the 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 variants that operate over analog and digital interfaces. 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 the interconnection, and it is a 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 (Basic Rate Interface, up to 2 simultaneous calls) or PRI interface (Primary Rate 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 the PBX from particular manufacturers and is therefore suitable only for corporate networks, where IP telephony is used to interconnect PBXs in company branches.
It is only in greenfield situations, when building a telephony service from scratch, or when an existing PBX is fully depreciated, that IP Telephony can be considered as a complete replacement alternative to a traditional PBX.
The design of an IPBX system involves a couple of choices.
IPBXes can support terminals in two ways: either through analogue ports that support analogue terminals, or through IP only. The latter implies that the terminals are intelligent devices, including an implementation of signaling functions. Since intelligence in IP phones is built-in anyway, these terminals are often equipped with interactive screens and other sophisticated functions. As a result, the equipment is expensive and requires to be provided with power, either externally or by Power-over-Ethernet. A feature that most of these advanced terminals support is pass-through of Ethernet packets, so that a single wall outlet can be used for both IP Telephony and computer data.
Though the choice among H.323, SIP and proprietary protocols seems a purely technical one, it has implications on the interoperability with future expansions, inter-department trunking and the deployment of new advanced features, like messaging, etc. It is wise to require that a supplier complies to at least one of the open standards.
The choice of a full IP-based institutional voice architecture does not automatically lead to a specific solution for connecting geographically separated locations. The cookbook examines the options for this case in the Least-Cost Routing section.
The inter-departmental architecture also involves a choice of 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 volume of calls that have a local public destination as compared to long-distance public and private destined calls.
Traditional PBXes have the advantage that long-recognized needs have been incorporated through decades of development in their functionality. These important features need to be implemented by the IP Telephony architecture as well, if it is to become a competitive solution. The most elementary of these 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
With at least three manufacturers currently presenting wireless IP terminals that can use IEEE 802.11b (Wi-Fi) 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 with Wi-Fi networks in place, will 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 IP equivalents, but are different on the Ethernet level. The usual issues in wireless data communications are battery autonomy, portability, coverage, etc. Current developments show that manufacturers of public network mobile phones like GSM are planning to include Wireless VoIP into their terminals. This would enable seamless roaming from public mobile telephony networks to the campus wireless environment, potentially reducing costs when calling locally on campus.
Since the field of IPBXes is rapidly emerging, many features that are known in the traditional PBXes are quickly adopted. Additionaly, new issues arise as data networks develop. An example is the introduction of network access control by IEEE 802.1X. This standard forces equipment to first authenticate at a RADIUS server before accessing the network. All equipment on 802.1X enabled network ports should be 802.1X enabled as well. With the adoption of 802.1X, the vendors are announcing terminals that support this standard as well.
A similar situation holds for VLANs. In case a network administrator chooses to put IP telephones in a different VLAN from PC (groups) and the IP telephones are in pass-through configuration, they should support VLAN trunking. This feature is also appearing in the market.