The Avalo Voice Platform is designed to be self healing and fault tolerate, ensuring that all of the features, user input data, and platform processing elements are mirrored in all of the operational US based SuperNodes. The concept is that the platform will always have resources at the disposal of a User Agent, as long as the User Agent (UA) is able to contact the SuperNode.
There are several long established methods of managing system failures. Some UAs subscribe to some methods, while other don’t, as such Avalo Networks has created several Failover and Redundancy strategies for just this reason. Each Strategy has it’s pros and cons and which one used is largely determined by what the UA is compatible with. In this article we will go over each method, as well as the draw backs, if any, of the method.
SRV-DNS
SRV or Service DNS records is one of the more largely excepted method used by SIP UAs today. This method uses a special DNS hostname knows as a SRV record to provide details SBC resolution addresses based on a Weighted and Prioritized scale.
Avalo Network’s own use of this method is somewhat unorthodox but yet still falls well within the protocols guidelines.
In this method, the outbound SIP proxy should be directed to sipproxy.avpnet.us. This hostname resolves to two different addresses, primary-sip.avpnet.us, and secondary-sip.avpnet.us. This is done because Avalo Networks used a DNS resolution method knows a GEO-Proximity. the primary-sip and secondary-sip addresses will resolved to different SuperNodes depending on your proximity to them.
Example:
If you were to make a resolution request from Atlanta, GA, primary-sip.avpnet.us will resolve to our SuperNode in Miami, because it’s the closest point of presences with in the network to Atlanta, GA. In the same way the primary address resolves to Miami, secondary-sip.avpnet.us may resolve to the next closest SuperNode, in this case possible New York.
What makes the SRV method so powerful is that in the event of a failure, transfer of a UA’s registration from the primary to the secondary resolution point should be nearly instant. Now most UAs do in fact support this method completely. All expect any of the Cisco SPA class devices, and any Asterisk Based PBX.
Primary and Secondary outbound Proxies
This method is what we would refer to as a direct resolution. Meaning, the UA is directly responsible for the failover action, not the network. In this case, a Primary (primary-sip.avpnet.us) and Secondary (secondary-sip.avpnet.us) SIP/Outbound proxy address is directly entered into the UA. In the event a SIP Registration or Call Dialog fails, the UA has the option of directly attempting the same dialog with the secondary proxy.
This method while less graceful than the SRV-DNS method still overs a good means of creating a failover state. It still takes advantage of the GEO-Proximity DNS resolution method, so again your UA’s signaling dialogs and registrations will be routed to the closet SuperNode, however we are relying on the UA to detect and properly handle the failover and recovery actions. In most cases these devices should recover fairly quickly, within about 60 seconds depending on their configuration.
In the case of any of the CISCO SPA family of UAs provisioned by the Avalo Voice Platform, the failover should happen with in 60 seconds.
Many of your IP enabled PBXes will need to use this method, including your Asterisk based IP-PBXes (optionally).
Direction Resolution
This method completely relies on DNS resolution of a A Record Hostname, in this case sipproxy.avpnet.us. Using this method our anycast DNS network is always monitoring our SuperNodes, and in the event of a failure failover will happen to the next closest SuperNode. The down side to this method is that, there is a minimum of 30 seconds before the monitoring systems will adjust the resolution results with in the A Record, and then furthermore the resolvers used on the UA’s network need to be in a non-cached state.
If you have to use this method, it should be ONLY as a last resort, and the DNS resolvers on the network, or DNS servers set of the IP-PBX should be set to something like Google’s DNS (8.8.8.8, 8.8.4.4) since they are designed for just this reason.
This method also will take advantage of the GEO-Proximity feature of our AnyCast DNS network, however any changes made in the resolution results should for see more than 5 minutes before updates are made live in the public internet DNS network.
As you can see each method has it’s pros and cons, and choosing the right one for your case is important.