If you’re considering deploying IP Telephony, even just for a pilot to see how it works, you’ll need to make some decisions right at the start as to which of the various deployment models you want to follow. If you only have one site, then it’s pretty straightforward, but where IPT can bring benefits is in cases where you have multiple remote sites, each currently with its own PBX or key system.

Deployment models
The most basic IPT deployment is single-site. You need to install one or more (typically at least two for resilience) softswitches (usually termed media servers, IP PBXs or media convergence servers depending on your vendor of choice, but they all provide a similar functionality) to do the call processing, a media gateway to link to the PSTN, and, assuming of course that your LAN is up to scratch (see So you think you have a voice-ready network?), that’s more or less it in terms of infrastructure. If you’re installing IPT in a phased approach, you’ll also need a gateway to link to your existing PBX, there will be voicemail and possibly Music on Hold servers, but these can be added as needed. Softswitches come in various shapes and sizes, so if you just have one small office to cater for, you don’t necessarily have to go for the full-blown package—systems more akin to key systems, with inbuilt voicemail and PSTN services are now available as well as the larger solutions that involve multiple discrete servers.

Multi-site deployments
If you have several sites, you have a couple of options. There is, of course, nothing to stop you just installing softswitches and gateways at every site—you then have the option to pass voice calls between sites over either your WAN or the PSTN—but you’re not gaining much here.

The most popular deployment option for multi-site IPT is a centralised call processing model. One set of softswitches at a head office provides the call setup functionality for all your smaller remote branches. At those remote sites, you just plug your IP phones into the LAN and away you go. Rip out those individual PBXs or key systems and save yourself a fortune.

Well, not quite. First there’s your WAN to consider. Now, remembering that only call setup information goes between phones and softswitch, not usually the whole call, it’s not as scary bandwidth-wise as it might be. Depending on vendor equipment and configuration, it’s possible to handle all the call setup traffic for up to 50 phones at a remote site using about 10kbps of your WAN bandwidth, which is pretty insignificant.

However, assuming that a fair number of calls are between your remote and central sites, you will need to think about upgrading the WAN to cater for these. And what happens if the WAN is full, or fails?

You may have enough resilience (dual homed branch offices, resilient routers etc) that that isn’t an issue; however if that’s too much of a risk, then you’ll need PSTN access into each remote site. You’ll probably want that anyway, both for safety or regulatory concerns, and to save all of your remote sites’ external calls traversing your expensive WAN to then pop out onto the PSTN at head office (and vice versa for incoming calls)—although that can be useful in some circumstances. So you’ll need gateways at each site—which may or may not be the WAN router—that connect to PSTN lines, and then you can configure your softswitch to use that path as the first option for external calls, while the WAN is first choice for internal ones. Both can back the other up for overflow or failure situations, with a bit of digit translation to put in or take out area codes and private site selection routing codes.

If the WAN link to a remote office fails completely, you’ve lost all call processing at that site though. Even with ISDN back up, say, there’s always the chance head office fails completely or you lose your branch routers. To cater for this, you need to look at the remote survivability options offered by your vendor. Survivable media gateways typically have software onboard that kicks in when the IP phones lose all contact with their softswitches, and provides limited call processing functionality. This will at least let you make calls to find out what on earth’s going on: some options provide more functionality than others, so best to find out what services you would lose should this scenario occur. And how to configure and manage it, since these mini-PBXs don’t necessarily pull their configs from the central softswitches, so may need set up separately.

IPT certainly has its advantages when you have to link up multiple sites, since you can use your WAN to carry the IP-based calls along with your data and manage things (more or less) all from one site. But make sure you know all the pieces you need, and how things cope when you experience failures, if you don’t want to leave your branch users out in the cold.