Network Management Strategies for the CIO
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.
Requires Free Membership to View
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 first published in May 2002
Join the conversationComment
Share
Comments
Results
Contribute to the conversation