Overview of interoperability of Azure Communications Gateway with Microsoft Teams Direct Routing

Azure Communications Gateway is a certified SBC for Microsoft Teams Direct Routing, allowing telecommunications operators to provide their customers with PSTN connectivity from Microsoft Teams. Azure Communications Gateway can manipulate signaling and media to meet the requirements of your networks and the Microsoft Phone System, which powers Microsoft Teams Direct Routing.

In this article, you learn:

• Where Azure Communications Gateway fits in your network.
• How Azure Communications Gateway supports many customers.
• Which signaling and media interworking features it offers.

Important

You must be a telecommunications operator to use Azure Communications Gateway.

Role and position in the network

Azure Communications Gateway sits at the edge of your fixed line network. It connects this network to the Microsoft Phone System, allowing you to support Microsoft Teams Direct Routing. The following diagram shows where Azure Communications Gateway sits in your network.

Architecture diagram showing Azure Communications Gateway connecting to the Microsoft Phone System and a fixed operator network over SIP and RTP. Azure Communications Gateway and the Microsoft Phone System connect multiple customers to the operator network. Azure Communications Gateway also has a provisioning API to which a BSS client in the operator's management network must connect. Azure Communications Gateway contains certified SBC function.

Calls flow from Microsoft Teams clients through the Microsoft Phone System and Azure Communications Gateway into your network.

Compliance with Certified SBC specifications

Azure Communications Gateway supports the Microsoft specifications for Certified SBCs for Microsoft Teams Direct Routing. For more information about certification and these specifications, see Session Border Controllers certified for Direct Routing.

Azure Communications Gateway includes multiple features that allow your network to meet the requirements for Direct Routing, including:

• Identifying the customer tenant for Microsoft Phone System
• SIP interworking
• Media interworking

Support for multiple customers with the Microsoft Teams multitenant model

An Azure Communications Gateway deployment is designed to support Direct Routing for many tenants. Its design allows you to provide Microsoft Teams calling services to many customers, each with many users. It uses the carrier tenant and customer tenant model described in the Microsoft Teams documentation on configuring a Session Border Controller for multiple tenants. In this model:

• Your own configuration for Microsoft Teams is defined in your organization's tenant: the carrier tenant.
• Each of your customers has its own customer tenant, representing the configuration for that customer.

Your Azure Communications Gateway deployment always receives an FQDN (fully qualified domain name) when it's created. You use this FQDN as the base domain for your carrier tenant.

Azure Communications Gateway also receives two per-region subdomains of the base domain (one per region).

Each of your customers needs customer subdomains of these per-region domains. Azure Communications Gateway includes one of these subdomains in the Contact header of each message it sends to the Microsoft Phone System: the presence of the subdomain allows the Microsoft Phone System to identify the customer tenant for each message. For more information, see Identifying the customer tenant for Microsoft Phone System.

For each customer, you must:

1. Choose a suitable subdomain. The label for the subdomain must:
   • Contain only letters, numbers, underscores, and dashes.
   • Be up to eight characters in length.
   • Not contain a wildcard or multiple labels separated by ..

   Important

   The full customer subdomain (including the regional subdomains and the base domain) must be a maximum of 48 characters. Microsoft Entra ID does not support domain names of more than 48 characters. For example, the customer subdomain contoso1.1-r1.a1b2c3d4e5f6g7h8.commsgw.azure.com is 48 characters.

2. Configure Azure Communications Gateway with this information, as part of "account" configuration available in Azure Communications Gateway's Number Management Portal and Provisioning API.
3. Liaise with the customer to update their tenant with the appropriate subdomain, by following the Microsoft Teams documentation for registering subdomain names in customer tenants.

As part of arranging updates to customer tenants, you must create DNS records containing a verification code (provided by Microsoft 365 when the customer updates their tenant with the domain name) on a DNS server that you control. These records allow Microsoft 365 to verify that the customer tenant is authorized to use the domain name. Azure Communications Gateway provides the DNS server that you must use. You must obtain the verification code from the customer and upload it to Azure Communications Gateway with the Number Management Portal (preview) or the Provisioning API (preview). This step allows Azure Communications Gateway to generate the DNS TXT records that verify the domain.

Tip

For a walkthrough of setting up a customer tenant and numbers for your testing, see Configure a test customer for Microsoft Teams Direct Routing with Azure Communications Gateway and Configure test numbers for Microsoft Teams Direct Routing with Azure Communications Gateway. When you onboard a real customer, you'll need to follow a similar process, but you'll typically need to ask your customer to carry out the steps that need access to their tenant.

Support for caller ID screening

Microsoft Teams Direct Routing allows a customer admin to assign any phone number to a user in their tenant, even if you don't assign that number to them in your network. This lack of validation presents a risk of caller ID spoofing.

To prevent caller ID spoofing, Azure Communications Gateway screens all Direct Routing calls originating from Microsoft Teams. This screening ensures that customers can only place calls from numbers that you assigned to them. However, you can disable this screening on a per-customer basis, as part of "account" configuration available in the Number Management Portal (preview) and the Provisioning API (preview).

The following diagram shows the call flow for an INVITE from a number that is assigned to a customer. In this case, Azure Communications Gateway's configuration for the number also includes custom header configuration, so Azure Communications Gateway adds a custom header with the contents.

Call flow diagram showing an invite from a number assigned to a customer. Azure Communications Gateway checks its internal database to determine if the calling number is assigned to a customer. The number is assigned, so Azure Communications Gateway allows the call. The number configuration on Azure Communications Gateway includes custom header contents. Azure Communications Gateway adds the header contents as an X-MS-Operator-Content header before forwarding the call to the operator network.

Note

The name of the custom header must be configured as part of deploying Azure Communications Gateway. The name is the same for all messages. In this example, the name of the custom header is X-MS-Operator-Content.

The following diagram shows the call flow for an INVITE from a number that isn't assigned to a customer. Azure Communications Gateway rejects the call with a 403.

Call flow diagram showing an invite from a number not assigned to a customer. Azure Communications Gateway checks its internal database to determine if the calling number is assigned to a customer. The number isn't assigned, so Azure Communications Gateway rejects the call with 403.

Identifying the customer tenant for Microsoft Phone System

The Microsoft Phone System uses the domains in the Contact header of messages to identify the tenant for each message. Azure Communications Gateway automatically rewrites Contact headers on messages towards the Microsoft Phone System so that they include the appropriate per-customer domain. This process removes the need for your core network to map between numbers and per-customer domains.

You must provision Azure Communications Gateway with each number assigned to a customer for Direct Routing. This provisioning uses Azure Communications Gateway's Provisioning API (preview) or Number Management Portal (preview).

The following diagram shows how Azure Communications Gateway rewrites Contact headers on messages sent from the operator network to the Microsoft Phone System with Direct Routing.

Call flow diagram showing an invite for +14255550100 sent from an operator network to Azure Communications Gateway. Azure Communications Gateway uses an internal database to find the appropriate customer subdomain for the number and updates the Contact header with the subdomain. Azure Communications Gateway then routes the invite to the Microsoft Phone System.

SIP signaling

Azure Communications Gateway automatically interworks calls to support requirements for Direct Routing, including:

• Updating Contact headers to route messages correctly, as described in Identifying the customer tenant for Microsoft Phone System.
• SIP over TLS.
• X-MS-SBC headers (describing the SBC function).
• Strict rules on a= attribute lines in SDP bodies.
• Strict rules on call transfer handling.

These features are part of Azure Communications Gateway's compliance with Certified SBC specifications for Microsoft Teams Direct Routing.

You can arrange more interworking function as part of your initial network design or at any time by raising a support request for Azure Communications Gateway. For example, you might need extra interworking configuration for:

• Advanced SIP header or SDP message manipulation.
• Support for reliable provisional messages (100rel).
• Interworking between early and late media.
• Interworking away from inband DTMF tones.
• Placing the unique tenant ID elsewhere in SIP messages to make it easier for your network to consume, for example in tgrp parameters.

The Microsoft Phone System requires calling (A-) and called (B-) telephone numbers to be in E.164 format. This requirement applies to both SIP and TEL numbers. We recommend that you configure your network to use the E.164 format for all numbers. If your network can't convert numbers to the E.164 format, contact your onboarding team or raise a support request to discuss your requirements for number conversion.

SIP trunks between your network and Azure Communications Gateway are multitenant, meaning that traffic from all your customers shares the same trunk.

RTP and SRTP media

The Microsoft Phone System typically requires SRTP for media. Azure Communications Gateway supports both RTP and SRTP, and can interwork between them. Azure Communications Gateway offers further media manipulation features to allow your networks to interoperate with the Microsoft Phone System.

Media handling for calls

You must select the codecs that you want to support when you deploy Azure Communications Gateway.

Microsoft Teams Direct Routing requires core networks to support ringback tones (ringing tones) during call transfer. Core networks must also support comfort noise. If your core networks can't meet these requirements, Azure Communications Gateway can inject media into calls.

Media interworking options

Azure Communications Gateway offers multiple media interworking options. For example, you might need to:

• Change handling of RTCP.
• Control bandwidth allocation.
• Prioritize specific media traffic for Quality of Service.

For full details of the media interworking features available in Azure Communications Gateway, raise a support request.

Microsoft Phone System media bypass support (preview)

Azure Communications Gateway has Preview support for Direct Routing media bypass. Direct Routing media bypass allows media to flow directly between Azure Communications Gateway and Microsoft Teams clients in some scenarios instead of always sending it through the Microsoft Phone System. Media continues to flow through Azure, because both Azure Communications Gateway and Microsoft Phone System are located in Azure.

If you believe that media bypass support (preview) would be useful for your deployment, discuss your requirements with a Microsoft representative.

Next steps

• Learn about monitoring Azure Communications Gateway.
• Learn about requesting changes to Azure Communications Gateway.