How global low-latency routing and region selection work for conferences and Client calls

In which scenarios is global low-latency routing relevant, and in which scenarios would it be unlikely to make a difference?

Twilio’s paid conference product features global low-latency (GLL) region selection which reduces audio latency in call scenarios where two or more parties are being connected in a region other than the United States. Using GLL, conference audio latency will be reduced in cases where two or more parties are physically close to one another, but far from the United States. For example, a call from Sydney to Sydney will see the greatest benefit from global low-latency as the difference from a locally routed media path and a media path that routes through the United States is the greatest. A conference call where all participants are dialing in from European countries which is mixed in Ireland will have lower audio latency for all parties versus the same conference mixed in the United States.

Global low-latency provides less benefit when the distance between the parties on the calls is greater and there is less of a distance between the length of a media path routed through a region or the US. For example, a call from Mexico City to London will have a similar audio latency whether it is routed through the US or Ireland. A conference call where participants are in the Asia-Pacific and South America regions will provide lower audio latency for the APAC participants if mixed in Tokyo/Singapore, or lower latency to the South America participants if mixed in Sao Paulo, but due to the large distance between participants, one group of participants will always experience increased latency; however, if global low-latency is disabled and audio is mixed in the US audio latency will be suboptimal for all participants.

Global low latency does not provide a benefit for one-party calls. 

How do global low-latency conferences identify which region to use?

Once a moderator joins, (a moderator is any conference participant whose startConferenceOnEnter parameter is set to true) the conference will begin and its audio will need to be mixed, and it is during the setup of this conference audio mixing that the region determination is made. Twilio’s internal services will note the regions of the participants joining the conference during setup and will make the determination of which region to use based on where the largest number of participants are located. In the event of a two-party conference the region selection is based off of Twilio's internal conference configurations which aren't externally exposed, but ultimately a two-party conference won't benefit from GLL regardless of where the conference is mixed--one participant is always going to experience higher latency. Once the conference has started, the region does not change and additional participants joining from other regions cannot influence the region selection process.

You can also specify the region a conference is mixed in via TwiML.

How do browsers identify which Twilio region to connect to?

For Client 1.2 and later, Twilio Client performs a real-time DNS latency evaluation when Twilio.Device.setup() is called and the application opens a websocket connection to our gateway.

In Client 1.3 and later the region selection may be specified during Twilio.Device.setup(). In each case the region will remain the same until the device setup is called again.

What scenarios would it be appropriate to override a GLL region selection in Client?

In most cases the default region as determined by DNS latency is the correct choice as we have observed that the DNS latency is highly correlated to media latency; however, there are cases where it might make sense to specify a different region as a call quality mitigation tactic.

For example, if you have a call center located in the Netherlands that is placing calls to destinations in the US, Client instances at the call center are likely registering to our media gateway in Germany, or possibly Ireland. If there are reports of call quality issues, you might try experimenting by pointing the Client instances to register in the United States.

The idea here is to reduce the number of hops a call takes once it reaches the PSTN. A Client call that hits the PSTN in Germany will bounce around in the EU before making a transatlantic hop to the US for couple more hops. Registering your Client instances to the media gateway closest to the destination can sometimes help with intractable quality problems.

How are PSTN calls associated with a region?

For incoming PSTN calls Twilio will tag that inbound call with with the region of the server where the inbound call was received. For outgoing PSTN calls Twilio will use the region where Twilio’s connection to the carrier being used to terminate the call is located.

How is the region determined for SIP trunking calls?

Each trunk has localized termination SIP URIs to deliver traffic to a specific region. For origination traffic append the region parameter to your SIP URI.

How is the region determined for SIP domains or TwiML <Sip> calls?

For calls sent to Twilio SIP domains, a localized SIP URI can be used to deliver calls to a specific region. For calls to SIP endpoints using TwiML <Dial><Sip> an optional region parameter can be added to the <Sip> noun's URI to ensure the call leaves Twilio from the specified region.

What about calls dequeued using TwiML <Queue>?

Any calls dequeued using TwiML <Queue> are routed through the US region and as such do not utilize the global low-latency infrastructure. However, if an enqueued call is instead redirected to a Global Conference, the conference region would be dictated by the location of the participants as described above. Redirecting the enqueued call via <Dial> to a PSTN number would similarly use global low-latency infrastructure.


Have more questions? Submit a request
Powered by Zendesk