by 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.
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:
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:
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:
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:
This was a much simpler approach than adding all three FQDNs when configuring signaling groups or ACLs:
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
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:
dmunified 
Leave a Reply