Skip to content

Load balancing with Cloud SIP

Overview

Cloud SIP load balancers allow you to load balance calls to your telephony infrastructure based on flexible policy rules. With a Cloud SIP load balancer, you can also define disaster recovery rules in case your infrastructure becomes unavailable.

Concepts

The following concepts are important to understand the behavior of Cloud SIP load balancers.

SIP domain is the FQDN (Fully Qualified Domain Name) associated with your SIP trunk service.

Load balancer is a resource created within a SIP domain that is used to direct traffic to a sequence of one or more load balancer endpoints.

Load balancer URI is the SIP URI that the load balancer is associated to. It is of the format sip:name@sip-domain.

Load balancer endpoint URI is a SIP URI that is defined within a load balancer that specifies an endpoint that traffic can be directed to when using the load balancer.

Originating URI is the SIP URI that is used within VoiceML, Flow, phone number instances and other Enfonica products that is pointing to the load balancer URI and that can contain other information such as user-to-user and custom headers.

Analogy to registered users

A Cloud SIP load balancer is similar in concept to a registered user. Where a registered user maintains a dynamic list of location records based on REGISTER messages, a Cloud SIP load balancer maintains a static list of endpoint URIs based on its configuration.

How it works

Creating a load balancer

Cloud SIP load balancers are created within a SIP domain. When creating a load balancer, you must specify its name. This name will set the userinfo of the load balancer URI.

For example, if your SIP domain is example.sip.enfonica.com and your load balancer name is load-balancer-1, then your load balancer URI will be sip:load-balancer-1@example.sip.enfonica.com.

Configuring the load balancer

A load balancer configuration consists of load balancer endpoint URIs and failover handler URIs.

Load balancer endpoint URIs

You specify endpoints to a load balancer by adding load balancer endpoint URIs to the configuration of a load balancer. Each endpoint consists of:

  • a SIP URI, representing a destination the load balancer can send calls
  • a priority, representing the order which the endpoint will be selected (lower will be chosen first)
  • a weight, representing the proportion of calls the endpoint will be used for between endpoints of identical priority

Failover handler URIs

If all endpoints fail, the specified failover handler URIs will be executed. Typically you will just define one failover URI, unless you want additional failover for your failover.

This is useful for configuring disaster recovery for your incoming calls, and can direct to any supported endpoint type, including: programmable voice, Flow, SIP and tel URIs.

Sending calls to a load balancer

To send calls to a Cloud SIP load balancer, you specify the load balancer URI when using VoiceML, Flow or phone number instances.

The way you send calls to a load balancer varies based on Enfonica product you are using:

  • Using VoiceML, you should <Redirect> to the SIP URI, or use <Call Strategy="failover">, to enable full load balancer functionality. If you <Call> with a different strategy, the failover handler URIs will not be active.
  • Using Flow, you should use the Load Balancer step to enable full load balancer functionality. If you use the Call step instead, the failover handler URIs will not be active.
  • Using Phone number instances, you should use the SIP > Load balancer option when configuring incoming calls.

You can only send calls to a load balancer in the same project.

Evaluation of the load balancer policy

When you send calls to a Cloud SIP load balancer, it's policy is evaluated to determine the final order and composition of SIP URIs it will attempt to send calls to.

Firstly, the originating URI headers are merged with each load balancer endpoint URI and any defaults are applied.

Secondly, the load balancer endpoint URIs are ordered based on priority and weight. Higher priority URIs (lower priority number) are ordered first. Any URIs with the same priority are then randomized by their associated weight. For example, if URI 'A' has weight 2 and URI 'B' has weight 1, they will be balanced in the proportion 2:1, where 'A' will be first 2/3 of the time and 'B' will be first 1/3 of the time.

After this, the URIs are formed and ordered, and are attempted in that order.

Request URI and To header

If the load balancer endpoint URI contains userinfo, this URI will be used as the request URI.

Otherwise, the userinfo of the load balancer endpoint URI will be populated with either the specified or default to URI header of the originating URI.

The To header of the SIP dialog will be set as the specified or default to URI header of the originating URI.

Example 1

Scenario:

  • Parent call: { "to": "+61255501234" }
  • Load balancer URI: lb1@example.sip.enfonica.com
  • Load balancer endpoint URI: sip:ingress@customer.example
  • Originating URI: sip:lb1@example.sip.enfonica.com

Result:

  • Protocol: UDP
  • Request URI: sip:ingress@customer.example
  • To URI: sip:+61255501234@customer.example

Example 2

Scenario:

  • Parent call: { "to": "+61255501234" }
  • Load balancer URI: lb1@example.sip.enfonica.com
  • Load balancer endpoint URI: sip:customer.example;transport=tls
  • Originating URI: sip:lb1@example.sip.enfonica.com

Result:

  • Protocol: TLS
  • Request URI: sip:+61255501234@customer.example;transport=tls
  • To URI: sip:+61255501234@customer.example;transport=tls

Example 3

Scenario:

  • Parent call: { "to": "+61255501234" }
  • Load balancer URI: lb1@example.sip.enfonica.com
  • Load balancer endpoint URI: sip:customer.example;transport=tls?X-Custom=my-lb
  • Originating URI: sip:lb1@example.sip.enfonica.com?to=0255501234&X-Custom-2=test

Result:

  • Protocol: TLS
  • Request URI: sip:0255501234@customer.example;transport=tls
  • To URI: sip:0255501234@customer.example;transport=tls
  • Additional headers:
  • X-Custom: my-lb
  • X-Custom-2: test