Problem solve Get help with specific problems with your technologies, process and projects.

Remote site survivability

Redundant IP-PBXs might not be enough if the WAN fails, here's how to keep your phones working in case of WAN failure.

Remote site survivability
Tom Lancaster

Many organizations deploying IP Telephony solutions are using a similar, very cost effective model where a central telephony server supports many IP/Ethernet-based phones in remote sites. Recognizing the need for reliability, these companies are making their central IP-PBXs highly redundant, often deploying multiple servers for failover. However, what happens if there's an issue on the WAN? Perhaps a circuit fails, or a routing loop occurs. No matter how redundant your telephony server is, if your IP phones can't reach it, they lose dial-tone.

To protect against this kind of failure, without having to put full-blown PBXs in each remote office, most IP Telephony vendors now offer some sort of feature that is commonly called survivable remote site telephony. Although it seems each vendor has a different approach to solving this problem, each offers a method of supporting remote phones when the WAN becomes unavailable, often with a reduced feature-set. In most of these schemes, the IP phone is configured with a list of possible servers. For example, Cisco's solution allows the phones to failover to the remote router, which can provide gateway access to the PSTN. So you could configure an IP phone to talk to the Call Manager, and if it is unavailable, to talk to a local router that has voice capability.

When you configure this, one thing you want to watch out for is how you set your timers. Specifically, you want to make sure they are compatible with your network settings. For instance, let's say you have two T1s between a group of remote users and your IP PBX. Test the failover to find out how long it takes your routing protocols to reconverge and establish connectivity again. You probably don't want to set your phone's failover timer less than this value (unless the value is very large, of course), so you don't failover unnecessarily, potentially dropping calls in the process. On the other hand, if a site is using a relatively unreliable link, without a backup, it may make sense to set your timeouts much lower.

Of course, each network is different and a lot of different factors can affect how long it takes connectivity to be restored, so test this thoroughly.


Thomas Alexander Lancaster IV is a consultant and author with over ten years.


This was last published in May 2002

Dig Deeper on Branch office network design

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

  • How do I size a UPS unit?

    Your data center UPS sizing needs are dependent on a variety of factors. Develop configurations and determine the estimated UPS ...

  • How to enhance FTP server security

    If you still use FTP servers in your organization, use IP address whitelists, login restrictions and data encryption -- and just ...

  • 3 ways to approach cloud bursting

    With different cloud bursting techniques and tools from Amazon, Zerto, VMware and Oracle, admins can bolster cloud connections ...

SearchITChannel

Close