Voice Network Redundancy
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.
Related Articles
Voice Network Details
RingLogix operates an Active/Active Geo Redundant Infrastructure to best meet the needs of our Partners and your Customers. Below are the addresses and related IPs for different segments of the network. We recommend that you always use auto ...FCC Compliance/Abuse
Please be aware that any call originated on the RingLogix network is subject to inspection and investigation if the call is suspected of being fraudulent, abusive, or illegal. Calls meeting any of these criteria will be blocked. If these conditions ...Understanding How NAT and Firewalls Affect UCaaS Services
What is NAT? NAT (Network Address Translation) is a technology most commonly used by firewalls and routers to allow multiple devices on a LAN with 'private' IP addresses to share a single public IP address. Should I configure specific SIP or NAT ...SIP and TLS
TLS (Transport Layer Security) and SIP TLS is a common security protocol used for private, and secure communications over the Internet. When enabled, TLS encrypts the signaling of VoIP calls. Why Use TLS? TLS is often used for security purposes and ...Ensure that Messages are Delivered to Email
To help ensure that email messages (like invoices and service notices) reach your recipients inbox, we recommend adding RingLogix to your SPF DNS record. SPF (Sender Policy Framework) DNS records are used by many email providers to identify which ...