Introducing Multiple Origination URIs for SIP Trunking: Load balancing and failover made easy

Introducing Multiple Origination URIs for SIP Trunking: Load balancing and failover made easy

Today we are excited to add a feature to make it even faster to configure your load balancing and resilience strategy on Twilio Elastic SIP Trunks. We are providing this through Multiple Origination URIs, which are configurable in your account portal and through the API.

Since we first launched Elastic SIP Trunking we have offered a Disaster Recovery feature. This further helps our customers failover gracefully when their voice infrastructure is critically down, by replicating the call logic that lives in your PBX in the cloud. However, there are many nuances in between a 200 OK response and a full outage. Perhaps one of your IP-PBXs or SBCs is over capacity, or maybe you’ve lost local connectivity to one site, but not all sites.

Load Balancing

The first use for Multiple Origination URIs is managing load-balancing with a simple interface by distributing the “weighting” across different Origination URIs. This provides a mechanism to handle scaling and fault tolerance across your different voice infrastructure components.

This unique feature allows you to configure the distribution of Twilio SIP call requests across all of the points of ingress to your network. This load balancing can be used not only to help avoid overloading your infrastructure, but also to help avoid overloading the people behind it. If you have a 100 seat call center and a 200 seat call center you can send twice as many calls to the larger call center.

Seamless Failover

The other core feature of Origination URIs is handling failover by allowing you to design how Twilio will react to outages of your infrastructure. You can set “Priority” to indicate which URIs we should hit first (and we will round robin based on weighting) and then the subsequent sets of URIs to send invites to in case we get an error message or no response for 4 seconds. This means that if you are experiencing an outage at one premise we can redirect traffic to another premise before failing over to Disaster Recovery. This is our newest feature in our continuous efforts to add resilience to our customers communications. For examples of both of these features please see our Elastic SIP Trunking docs.

It has actually always been possible to configure this sort of behavior with Elastic SIP Trunking by using SRV DNS records (and still is). SRV DNS allows a Fully Qualified Domain Name (FQDN) to map to different IPs, providing a weighting and priority for each one. However, we learned from our customers that not all of them wanted to create and update SRV DNS records and in many enterprises the person deploying voice connectivity doesn’t maintain DNS, leading to setup times that weren’t quite instant.

Now we offer a simple, but sophisticated way of load balancing and failing over to different premises directly within the Twilio account portal and through the API. This is one more step in our mission to provide the most scalable, resilient SIP Trunking service available.

To learn more about using Multiple Origination URIs, check out the docs.