Twilio's Global Low-Latency (GLL) routing helps ensure users have the best call quality by connecting to the nearest network edge or region. We also allow users to manually set the desired edge in many of our products. This guide explains how GLL routing works with our edges, and how to manually set the edge.

In which scenarios is global low-latency routing relevant?

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 edge 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 locations 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 edge location to connect to?

By defauly, the Twilio Voice JavaScript SDK (formerly "Twilio Client") performs a real-time DNS latency evaluation when Twilio.Device.setup() is called, and automatically determines which data center is closest to your user. You can, however, override this, and call out a specific edge location for connecting. For full details, see Voice JavaScript SDK: Edge Locations.

In most cases, the default edge as determined by DNS latency is the correct choice as we have observed that the DNS latency is highly correlated to media latency. That said, there are cases where it might make sense to specify a different region as a call quality mitigation tactic. For example, callers located in the Netherlands are likely registering to our edge in Germany. If there are reports of quality issues when calling to the US, you might try experimenting by pointing to our US East Coast edge, ashburn. The idea here is to reduce the number of hops a call takes once it reaches the PSTN. A 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. Connecting to the edge closest to the destination can sometimes help with intractable quality problems.

How are PSTN calls associated with an edge?

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

How is the edge determined for SIP trunking calls?

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

For full details, see Elastic SIP Trunking - The edge parameter.

How is the edge 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 edge. For calls to SIP endpoints using TwiML <Dial><Sip> an optional edge parameter can be added to the <Sip> noun's URI to ensure the call leaves Twilio from the specified location.

What about calls dequeued using TwiML <Queue>?

Any calls dequeued using TwiML <Queue> are routed through the US, and therefore do not utilize the global low-latency infrastructure. However, if an enqueued call is instead redirected to a Global Conference, the conference edge 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.