Live Chat Software by Kayako |
|
Voice Network Redundancy
Posted by Albert Diaz, Last modified by Albert Diaz on 09 April 2024 02:50 PM
|
|
|
RingLogix operates what we refer to as an Active/Active Geo-Redundant Network. The concept is simple… spread infrastructure across multiple geographically dispersed locations and keep it all in sync. The execution however, is what’s borderline magic :). This method of redundancy helps ensure that if something goes wrong in one data center (think power loss, hardware failure, connectivity loss, etc…), services can keep running smoothly from another. And because everything is always in sync, all your call routes, settings, and history are always available and working as expected. This helps RingLogix Partners limit service disruptions for their customers, ultimately leading to a better customer experience. How it works Each data center operates dedicated clusters of servers acting as standalone systems and as a backup to other data centers in the ecosystem. These clusters are for critical components of the voice infrastructure like the session border controller, multi-tenant PBX, billing engine and nearly all other dependencies. In most cases these clusters are horizontally scalable to increase processing capacity, and in some cases, managed by a load balancing system further running in High Availability (HA) locally. Connectivity to a specific data center is determined by the DNS record used by the customers equipment. And aside from the replication magic mentioned earlier, DNS is the primary tool in keeping your customers service running. When a customer is onboarded, its devices connect to their primary datacenter and server. Through out the course of the service use, all the settings and call history are both stored locally and actively replicated in real-time to all the other datacenters via our replication messaging bus.  Customer Endpoint DNS Redundancy Methods SRV-Record: This is the default method implemented when auto provisioning your customers devices on our hosted PBX solution. During bootup the device will query a DNS server for the SRV record of its configured SIP Server. Unlike a standard A-Record lookup, which contains a single IP, SRV responses will contain a list of servers with additional priority and distribution parameters. That single query provides the device with several geo distributed datacenters it can connect to, with no need to reboot or flush local DNS settings. Should a SIP Server become unresponsive or unavailable, during a re-registration or outbound call attempt, the device will then attempt to connect with the next server in its SRV list. *For manually configured devices like IP PBXs, ATAs, Gateways, and the occasional one-off IP Phone, please check your devices administrative guides for instructions on how to implement SRV redundancy. Standard A-Record: This method is inferior to SRV based redundancy and should only be considered as a last resort. During bootup the device will query a DNS server for the A-Record of its configured SIP Server. The response will contain a single IP. The device will then attempt to connect to the SIP Server via that IP. Should that SIP Server become unresponsive or unavailable the device connection and its calls will fail. In the event a SIP Server is globally unavailable, and our Infrastructure Team has determined that it cannot be immediately restored then its corresponding A-Record will be updated with the IP of another SIP Server capable of handling its load. *Note the TTL on our A-Records are 5 minutes. However, we cannot guarantee when global DNS servers will propagate and serve the changes. Further, customer devices must be rebooted so they can query and retrieve the updated A-Record Dual Registration A-Records: This method is inferior to SRV based redundancy and is known to have issues with certain device <> firmware combinations. In this method 2 SIP Servers are configured on the device. How and when devices perform DNS lookups may vary from model to model. In most cases it will look like one of these examples. During bootup the device will query a DNS server for the A-Record of its configured Primary SIP Server. The response will contain a single IP. In some cases it may query the A-Record for both the Primary and Secondary SIP Servers at the same time. The device will then attempt to connect to the Primary SIP Server via that IP. Should that Primary SIP Server become unresponsive or unavailable, and if the device hasn’t done so already, the device will lookup and attempt to connect to its configured Secondary SIP Server. *The switching experience from primary to secondary sip server varies from device to device. Helpful Links Voice Network Details: Hostnames and IPs for different services. Device Auto Provisioning: List of devices with provisioning support and links to more resources. | |
|
|