by Philip Carden

Strategies for building VoIP networks

So much for the theory. How do you actually implement Voice over IP (VoIP)? There are a few different strategies available, including the following:

The simplest of these strategies from an implementation perspective is probably the first, so we’ll begin with that approach and then explore the additional requirements of the other two strategies.

Simple toll bypass

IP telephony toll bypass solutions are relatively straightforward to implement — and pretty much similar to other forms of toll bypass (good old Time Division Multiplexing, Voice over Frame, and Voice over ATM). Before we get into the alternative approaches, let’s examine what it is that we’re likely to be replacing. The following diagram shows two interconnected PBXs.

The basic function of a PBX (or Private Branch Exchange), as the name suggests, is to connect phone calls coming in on trunk lines from the Public Switched Telephone Network (PSTN) to the particular extension associated with the called party (and similarly, in reverse for outbound calls). However, PBXs are not limited to simply switching calls between the PSTN and the extensions — they are equally capable of switching calls to extensions on other connected PBXs. In the good old days, these interconnections took the form of leased analog voice circuits — if there were likely to be 10 conversations occurring between two offices at any one time, that meant you needed 10 separate leased lines. While that approach may still be taken for interconnecting smaller offices, most PBX interconnections today are digital. These digital connections might be T1 circuits dedicated purely to the interconnection of PBXs or, more likely, they are channels allocated on a Time Division Multiplexing (TDM) backbone, which divides up bandwidth between voice, various data streams (probably including IP) and perhaps video conferencing. The problem with both dedicated voice tie lines and multiservice TDM backbones is that bandwidth must be permanently allocated (and paid for) for each voice circuit despite the fact that the voice circuits are not used all the time. A better solution is to split the traffic into packets (or "cells" or "frames") so that all the traffic types can be interwoven in the most efficient manner. Each of the so called "voice over" technologies — voice over Frame Relay, voice over ATM and voice over IP are able to achieve this improved efficiency, but it is Voice over IP that best fits with most organizations’ convergence strategies.

How do you implement Voice over IP for toll bypass? The easiest approach to illustrate is simply to unplug the existing PBX tie line(s) and to plug them into a separate unit that converts the voice signaling and transport to an IP format. I call such units VoIP relays (they’re sometimes also referred to as VoIP gateways, but the gateway term is more commonly used for PSTN interconnection, as we’ll discuss later). The VoIP relay connects directly to a router for transport over the IP network, as shown in the following diagram.

Examples of stand-alone products that can be used in this way include Nortel’s V/IP and Nokia’s IP Relay. [Incidentally, as we move through this chapter I’ll mention products that illustrate concepts so as to help readers tie back theory to practice (and to provide a flavor for some of the vendors involved in different areas). However, it is emphasized that there are numerous vendors involved in IP telephony and no attempt is made here to provide a comprehensive list.]

There is no reason why the VoIP relay functionality need be provided in a separate unit — you might instead want to implement the functionality in the PBX or in the router itself. For example, both Lucent’s Definity PBXs and Nortel’s Magellan offer IP-trunking, while various Cisco routers can provide direct PBX interfaces (including the 1750, 2600 and 3600).

Regardless of which approach you take, there are three practical design issues that you’ll need to address. Firstly, you’ll need to make sure that from a functional perspective the VoIP relay will relay sufficient signaling information to support the features in use on the PBXs. Secondly, you’ll need to consider whether standards are important in your situation — while some of the products claim H.323 compliance, many still use proprietary schemes. This may not matter if your network is relatively small and you feel comfortable that the vendor is committed to standards, but give it consideration. Remember also that H.323 comes in three versions — I’ve not come across any products that currently support H.323 v3 (or SIP), but remember to check whether the H.323 support is v1 or v2. Thirdly, and perhaps most importantly, you’ll need to figure out how you’re going to offer the voice quality that’s required. This last aspect is a combination of the encoding scheme you choose and the QOS capabilities of the IP network and your VoIP relay’s ability to work with those QOS mechanisms. Since encoding and QOS requirements are substantial practical considerations in all IP telephony implementations, we’ll discuss these issues at the end of this chapter.