<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'><style>p { margin: 0; }</style><div style="font-family: Times New Roman; font-size: 12pt; color: rgb(0, 0, 0);">If you're going to use SRV records in an Access deployment with registration caching on the Acme SBC one thing to keep in mind is that non-HA SBCs (or two separate pairs) will not share their registration and NAT databases.<span><br><br><div><div><div>-- <br>Jason Nesheim<br><div><div></div></div></div></div></div><br></span><br>----- Original Message -----<br>From: "Brad Anouar" <Brad@broadcore.com><br>To: voiceops@voiceops.org<br>Sent: Thursday, September 3, 2009 4:25:10 PM<br>Subject: Re: [VoiceOps] Acme SBC geographic redundancy<br><br><br>I agree with Alex, SRV records could be a more realistic solution for the access side given that you are willing to accept some post dial delay in failover mode. If you plan on using ACME for peering, since most providers don't support SRV records, you will have to provide them with multiple IPs and the order in which you would like them to be used.<br><br><br><br>Brad Anouar<br>Director - Systems Engineering <br>P: 310-360-2028<br>F: 310-360-2029<br>brad@broadcore.com<br><br><br><br>-----Original Message-----<br>From: voiceops-bounces@voiceops.org [mailto:voiceops-bounces@voiceops.org] On Behalf Of Alex Balashov<br>Sent: Thursday, September 03, 2009 4:03 PM<br>To: Brandon Buckner<br>Cc: voiceops@voiceops.org<br>Subject: Re: [VoiceOps] Acme SBC geographic redundancy<br><br>As with any HA setup of IP nodes, the main problems boil down to:<br><br>1. Adequate network bandwidth and network availability between the <br>primary and standby unit (or silo) for reliable and sufficiently <br>low-latency synchronisation of various information (config changes, <br>standby status, any call state information shared among them in Acme's <br>HA setup, etc.);<br><br>2. The more common way to make them effectively redundant from a user <br>perspective is to have them share an IP address, in which case it is <br>necessary to ensure that the traffic destined for that IP network can <br>pass into the other POP in the event of a failure, which requires <br>complicated integration with your BGP and/or IP connectivity <br>arrangements and any interior routing protocols you may be running.<br><br>A more realistic approach is to have all the clients use an SRV record - <br>if all your clients are capable of SRV lookups - and specify the <br>secondary with lower priority, avoiding the complexities of IP sharing <br>across disparate geographic sites altogether.<br><br>-- Alex<br><br>Brandon Buckner wrote:<br><br>> Is anyone doing geographic redundancy with their Acme Packet SBCs? We've <br>> got an HA pair of nn4250s right now and are installing a new Metaswitch <br>> system that is geographically redundant at two locations with external <br>> call agents, TDM links, etc. We'd like to get SIP to be the same. I'm <br>> still waiting on a response from our Acme SE about it but wanted to see <br>> what others had done, if anything. I figure some discussion will spark <br>> questions I can bring up with Acme as well.<br><br><br>-- <br>Alex Balashov - Principal<br>Evariste Systems<br>Web : http://www.evaristesys.com/<br>Tel : (+1) (678) 954-0670<br>Direct : (+1) (678) 954-0671<br>_______________________________________________<br>VoiceOps mailing list<br>VoiceOps@voiceops.org<br>https://puck.nether.net/mailman/listinfo/voiceops<br>_______________________________________________<br>VoiceOps mailing list<br>VoiceOps@voiceops.org<br>https://puck.nether.net/mailman/listinfo/voiceops<br></div></div></body></html>