[VoiceOps] Geographic redundancy

[Mark R Lindsey]

It works in that (a)  BroadWorks can synchronize between servers at  
different sites. (b) When either of the sites fails, service is  
restored automatically and quickly after the fault. (c) When the fault  
is corrected, BroadWorks servers re-synchronize gracefully without  
interruption to subscribers.

But the hard part is not the BroadWorks servers -- it's the access  
network.

In most cases, the geographic distribution the voip servers  
(BroadWorks application servers, in this discussion) means that you  
have geographically-distributed SBCs. And such SBCs are usually not  
call-state synchronized.

And typically that means that each SBC has a separate IP address  
facing subscribers.

And most subscribers only have a single link to the access network.

The customer's device has to handle this properly, and the SBC has to  
handle this properly.

For example, when a failure of one site occurs, you want all of your  
devices to re-register through the secondary site. How long will it  
take before they re-register? How will they detect that one site has  
failed? What happens to calls headed toward the subscriber during the  
period until the customer re-registers?

For the SBC, how will it handle the mass re-registration from  
subscribers moving over from the other SBC? How will it protect the  
core registrar (BroadWorks AS in our example) against attack?

Nathan, "Zero" impact on customers is incredibly expensive to achieve.  
You can, in fact, engineer capacity to make this switching (and even  
route flapping) graceful, but it means you have orders-of-magnitude  
more expense in your access network. An SBC that can handle 10,000  
subscribers today might be able to handle 100 subscribers if we need  
to ensure zero new calls are lost, because each those subscribers has  
to hammer away at the SBC doing polling. It's probably less costly to  
bring each subscriber to each of your two sites, then to put more  
failover at the customer premise (like a smart ALG).

Nevertheless, without call state synchronization in the SBCs, it may  
not be possible to achieve full site-to-site failover with Nathan's  
Zero affect on customers. For example: If a call started on SBC-site-A  
and then fails to SBC-site-B, SBC-site-B would normally reject re- 
INVITES for that dialog; therefore session audits, call hold/resume,  
etc. can cause the standing call to drop.

Application Server / Call Server redundancy is great, and there's much  
more to consider in fault-tolerant voip network designs.



On Aug 13, 2009, at 3:19 PM, Nathan Stratton wrote:

> On Thu, 13 Aug 2009, Mark Holloway wrote:
>
>> When you say "it works" - what is the impact to the customer?
>
> Zero

Mark R Lindsey lindsey at e-c-group.com http://e-c-group.com/~lindsey  
+12293160013