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).
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.
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.
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.
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.
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:
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.
The design of a IPBX system includes a couple of choices.
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.
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.
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.
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:
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.
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.