Towards the end of 2021, Microsoft made a number of announcements via Message Center that will impact calls that route to and from Microsoft Teams via Direct Routing. If you’re using Direct Routing, it’s important to review these items and ensure you won’t be affected in the coming months.

Let’s take a closer look at what’s changing, and what you need to do to prepare.

MC299923: Trusted Certificate Authorities for Direct Routing SIP Interface are Changing

Action required by February 1st 2022

What’s the change?

Starting from February 1 2022, the Direct Routing SIP interface will only trust certificates that are signed by Certificate Authorities (CAs) that are part of the Microsoft Trusted Root Certificate Program.

What does this mean?

Direct Routing is a Microsoft term for a SIP trunk between a Session Border Controller (SBC) and the Microsoft 365 Cloud. To ensure communications are secure between SBCs and M365, Direct Route trunks must use TLS for signaling. This in turn means that your SBCs must have a certificate installed that is publicly trusted, and more importantly trusted by Microsoft.

Teams Direct Routing Overview

If you do not have a supported public certificate on your SBC from February 1st onwards, your Teams Direct Route will no longer be supported and calls between Teams and your SBC will fail.

How do I confirm I won’t be affected?

You can find a full list of supported public Certificate Authorities (CAs) here. In the below example, I have reviewed what public CA is being used for a Direct Route between a Ribbon SWe Lite SBC and Microsoft Teams. Searching for the certificate issuer on the supported list confirms that this is a supported public CA:

Ribbon SWe Lite – Identify Certificate Issuer
Confirm Issuer CA Supported

MC307310: SIP-ALL FQDNs will no longer be Supported

Action required by March 1st 2022

What’s the change?

On March 1 2022, Microsoft will be removing support for sip-all.pstnhub.microsoft.com and sip-all.pstnhub.gov.teams.microsoft.us FQDNs from Direct Routing configuration.

What does this mean?

For some time now, Microsoft have published the two sip-all FQDNs outlined above to make it easy to identify all Microsoft IP addresses I should expect to see traffic from for Direct Routing deployments. These should not be confused with the FQDNs that should be used for routing, as outlined here:

Teams Direct Routing Connection Points

When configuring SBCs for Direct Routing, the sip, sip2 and sip3 FQDNs should be configured as per Microsoft requirements in a priority list as shown below (examples below are from a Ribbon SWe Lite SBC but same approach applies regardless of SBC vendor you are using). This would ensure that calls route via the closest Microsoft Point of Presence to my SBC based on my geographic location, but also ensures I have redundancy from another M365 datacentre location in the event of an outage:

Teams Direct Routing Connection Points – Ribbon SWe Lite

However, when configuring the Teams Signaling Group to limit where I should expect SIP traffic to come from, it became common practice to use SIP-ALL.pstnhub.microsoft.com which would resolve to all IP addresses that all three of the FQDNs listed above resolve to:

sip-all.pstnhub.microsoft.com – Resolved IPs

This was a much simpler approach than adding all three FQDNs when configuring signaling groups or ACLs:

Ribbon SBC – Federated IP/FQDN list for Teams Direct Routing

What do I need to do?

If you are using Direct Routing, check your ACL\Federated lists that limit traffic between your SBCs and Microsoft Teams. If you are using either of the sip-all FQDNs, update those lists to use the full Microsoft Teams IP subnet ranges:

  • 52.112.0.0/14
  • 52.120.0.0/14
Ribbon SBC – Updated Federated IP/FQDN List

This also goes for anything else sitting between your SBCs and M365 – if your firewalls were using sip-all to limit traffic, they should be updated also.

MC299922: Direct Routing Will Stop Processing SIP Requests which have ‘Replaces’ Headers

Action required by April 5th 2022

What’s the change?

Starting on April 5 2022 (previously January 3, 2022), Direct Routing will stop processing SIP requests which have Replaces headers.

What does this mean?

Understanding this change and possible implications requires a little more of a deep dive into the SIP Protocol itself, but in short it will be required to ensure your SBCs are not sending Replaces headers within SIP INVITES to Teams.

What do I need to do?

For Ribbon SBC deployments (SBC Edge and SWe Lite), there will be an update released (before April 5th one would hope) that will address this requirement. For AudioCodes Mediant SBCs, you can find a fix here. For other SBC makes and models, check with your respective vendor.

Want to learn more about SIP Replaces? Go here.

MC297438: TLS1.2 Enforcement for Direct Routing SIP Interface

Action required by February 1st 2022

What’s the change?

On February 1st 2022 (previously January 3rd 2022), to provide the best-in-class encryption, Microsoft will begin retiring Transport Layer Security (TLS) versions 1.0 and 1.1 and begin obligating TLS1.2 usage for the Direct Routing SIP interface.

The move to TLS 1.2 is to ensure that services are secure by default and in alignment with the rest of Microsoft 365 services.

What does this mean?

To prevent cyber criminals from accessing sensitive data as it moves through the internet, over the years various cryptographic protocols have been introduced, one of which being Transport Layer Security (TLS). We’ve stepped through various iterations of TLS: namely TLS 1.0 and 1.1, with 1.2 now being the lowest iteration that Microsoft will support for anything that communicates with Microsoft 365.

If TLS 1.2 is not selected as your TLS Protocol for Direct Routing post February 1st 2022, Your Direct Route trunks will cease to work and calls between your SBCs and Teams will fail.

What do I need to do?

If you are using Direct Routing, ensure that TLS 1.2 has been selected as the TLS Protocol:

Ribbon SBC – Teams TLS Profile

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.