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 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:

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.

If you need help with implementing this in your environment, reach out to supportau@rapidcircle.com and we can assist.