Migrating a PBX system to VoIP over multiple sites can be difficult, especially when using WAN to support it. Systems integrators and value-added resellers (VARs) rolling out VoIP will find strategies that will keep their customers happy as well as avoid delays, cost-inflation and degradation of service quality.
In the previous tip we discussed one decision in voice-over IP (VoIP) migration strategies: whether your customer should upgrade the existing private branch exchange (PBX) to support VoIP, or install an IP-only softswitch in parallel. In this article, we’ll look at a different decision in the migration strategy that revolves around the order in which we roll out VoIP over the local area network (LAN) and wide area network (WAN). Obviously, this is only applicable to multi-site deployments connected by a WAN, and specifically, the decision revolves around using WAN to support VoIP.
We’ll assume the current state of the network is PBXs at each location, with local public switched telephone network (PSTN) connections and possibly voice “tie” lines. In addition, we’ll assume that there is a WAN that might be frame-relay, or leased-lines with insufficient bandwidth, or Quality of Service (QoS) to support VoIP. We’ll further assume you want to make your move as quickly as possible, and that upgrading the WAN will be expensive and take a long time.
The most common migration path in this scenario is to create VoIP islands. In this scenario, IP phones are rolled out to a site, and calls inside the site are VoIP from IP phone to IP phone, but all calls to other sites — even those with IP phones — are over the PSTN or your tie lines. Gradually, as you upgrade the WAN segments to support VoIP, you configure your voice routing to permit calls to traverse the WAN.
This type of migration is advantageous because your customer will be less likely to experience poor call quality related to congestion or latency on the WAN. It also won’t sink your project if you do run into a problem because you can run offsite calls over the PSTN until you have a chance to remediate the WAN. Also, your rollout is faster because you don’t have to wait for WAN upgrades to take place.
A variant of this migration plan uses your project as the control mechanism for limiting calls over the WAN, instead of using specific softswitch configuration as the control. The softswitches are configured to send calls from IP phone to IP phone when the phones can reach each other. As you roll IP phones out to a site (lets call it site A), calls between site A and other sites with IP phones go over the WAN, but calls from site A to sites without IP phones go over the PSTN. The faster your project puts phones on desktops, the faster calls migrate from the PSTN to the WAN. As long as your schedule is realistic, this strategy is easy.
Another sub-decision here is when to do tail-end hop-off. You can do it as soon as calls to the site are going over the WAN, or you can wait until things are fairly stable to start adding external destinations to your dial plan. The obvious advantage to doing it sooner is that you can start saving toll charges sooner. The advantage to waiting is that you probably have enough to worry about already. Also, sending calls through the remote gateway can introduce some quality issues you won’t have when you’re just going IP phone to IP phone due to the additional components and conversion between codecs. Sometimes it’s better to let your customer gain some confidence in the new phone system by culling higher-risk activity from your initial scope. Then you can tackle more sophisticated activity in a follow up project.