Teams Direct Routing Improvements for Australian Tenants

If your organisation is using Microsoft Teams and your Microsoft 365 tenant is hosted within the Australia region, there are two ways that PSTN calling can be introduced to your Microsoft Teams environment:

• Use Telstra Calling (calling plans)
• Use Direct Routing

Given its deployment flexibility and ability to support a wide range of deployment scenarios, more often that not we see Direct Routing as the chosen technology to meet an organisation’s needs when adding PSTN calling to Microsoft Teams. Whether an organisation wants to migrate from an existing PABX platform to Teams Voice over time, or has an existing Skype for Business environment where infrastructure already exists that natively supports Direct Routing with Teams, it’s relatively quick and easy to augment the existing telephony environment and introduce Teams Calling.

What is Direct Routing?

Plainly speaking, a Direct Route is a SIP trunk between a Session Border Controller (SBC) and Teams: it’s one of two call legs between Teams users and a telco trunk provider:

When an SBC is configured to interface with Teams via Direct Routing, we need to let the SBC know where it needs to send calls to (and receive calls from) in order to support PSTN calling. No matter where you are in the world, the same configuration is used, with the following Fully Qualified Domain name (FQDN) resolving to the closest Teams Direct Route infrastructure in relation to the SBC:

• sip.pstnhub.microsoft.com

Today in Australia, if I resolve the above FQDN, Teams Direct Route SIP infrastructure that’s returned is located in South East Asia (Singapore), with an IP address of 52.114.14.70. This is where my SBC will send SIP signalling when setting up a call:

Just in case there’s an outage with infrastructure located closest to the SBC (in our case, SE Asia), Microsoft also publish the following FQDNs that will resolve to secondary and tertiary infrastructure located somewhere else in the world. So again, when resolving these FQDNs from an SBC located in Australia, they return the following:

• sip2.pstnhub.microsoft.com (United States)

• sip3.pstnhub.microsoft.com (Europe)

As the examples above show, historically SIP signalling for Teams PSTN calling has not routed via Teams infrastructure located in Australia. That is not to say that media associated with my call follows the same path: infrastructure that supports media traversal (Media and Transport relays) have been deployed and available in Australia for some time, it’s just the signalling component that negotiates and sets up the call that’s been routing via infrastructure that resides off shore for Australian Tenants.

New Infrastructure Deployed in Australia

In order to cope with increased traffic (mainly due to COVID-19), and to reduce latency, Microsoft have recently deployed additional infrastructure in Australia that will handle SIP signalling for Direct Routing. This ensures that all traffic associated with Teams PSTN calling (signalling and media) stay within Australia and should mean call setup is quicker for Australian tenants.

One other FQDN that Microsoft publish that is related to direct routing is sip-all.pstnhub.microsoft.com. This one is useful, as it resolves to all IP addresses that an SBC might use globally when Direct Routing is deployed. Looking at the IP addresses that are returned when resolving this record, note two new entries:

These IP Addresses represent SIP infrastructure that has been deployed in Australian data centres to support local SIP signalling for Australian tenants.

How do I use them?

Today, these IP addresses are not being returned when resolving the primary Direct Route FQDN sip.pstnhub.microsoft.com from Australia. We expect this will be the case soon, however if you want to use them anyway, you can!

1. Add static DNS host entries to your SBC (the following example is from a Ribbon SWe Lite virtual appliance) using the two new IP addresses for infrastructure located in Australia:

• Confirm that SIP Signalling is routing to one of these IP addresses:

This configuration won’t be necessary once Microsoft’s primary FQDN for direct routing resolves to these IP addresses automatically. But until then, manual configuration lets you take advantage right away.