Deploy Azure Communications Gateway

This article guides you through planning for and creating an Azure Communications Gateway resource in Azure.

Prerequisites

You must have completed Prepare to deploy Azure Communications Gateway.

Important

You must be a telecommunications operator or service provider and you must have signed an Operator Connect or Teams Phone Mobile agreement with Microsoft. For more information on these programs, see Operator Connect or Teams Phone Mobile.

Important

You must fully understand the onboarding process for your chosen communications service and any dependencies introduced by the onboarding process.

Allow sufficient elapsed time for the deployment and onboarding process. For example, you might need wait up to two weeks for a new Azure Communications Gateway resource to be provisioned before you can connect it to your network.

You must own globally routable numbers that you can use for testing, as follows.

Type of testing Numbers required
Automated validation testing by Microsoft Teams test suites Minimum: 6. Recommended: 9 (to run tests simultaneously).
Manual test calls made by you and/or Microsoft staff during integration testing Minimum: 1

After deployment, the automated validation testing numbers use synthetic traffic to continuously check the health of your deployment.

1. Collect basic information for deploying an Azure Communications Gateway

Collect all of the values in the following table for the Azure Communications Gateway resource.

Value Field name(s) in Azure portal
The name of the Azure subscription to use to create an Azure Communications Gateway resource. You must use the same subscription for all resources in your Azure Communications Gateway deployment. Project details: Subscription
The Azure resource group in which to create the Azure Communications Gateway resource. Project details: Resource group
The name for the deployment. This name can contain alphanumeric characters and -. It must be 3-24 characters long. Instance details: Name
The management Azure region: the region in which your monitoring and billing data is processed. We recommend that you select a region near or colocated with the two regions for handling call traffic. Instance details: Region
The voice codecs to use between Azure Communications Gateway and your network. Instance details: Supported Codecs
The Unified Communications as a Service (UCaaS) service(s) Azure Communications Gateway should support. Choose from Teams Phone Mobile and Operator Connect. Instance details: Supported Voice Platforms
Whether your Azure Communications Gateway resource should handle emergency calls as standard calls or directly route them to the Emergency Services Routing Proxy (US only). Instance details: Emergency call handling
The scope at which Azure Communications Gateway's autogenerated domain name label is unique. Communications Gateway resources get assigned an autogenerated domain name label that depends on the name of the resource. You'll need to register the domain name later when you deploy Azure Communications Gateway. Selecting Tenant gives a resource with the same name in the same tenant but a different subscription the same label. Selecting Subscription gives a resource with the same name in the same subscription but a different resource group the same label. Selecting Resource Group gives a resource with the same name in the same resource group the same label. Selecting No Re-use means the label doesn't depend on the name, resource group, subscription or tenant. Instance details: Auto-generated Domain Name Scope
The number used in Teams Phone Mobile to access the Voicemail Interactive Voice Response (IVR) from native dialers. Instance details: Teams Voicemail Pilot Number
A list of dial strings used for emergency calling. Instance details: Emergency Dial Strings
How you plan to use Mobile Control Point (MCP) to route Teams Phone Mobile calls to Microsoft Phone System. Choose from Integrated (to deploy MCP in Azure Communications Gateway), On-premises (to use an existing on-premises MCP) or None (if you don't plan to offer Teams Phone Mobile or you'll use another method to route calls). Instance details: MCP

2. Collect Service Regions configuration values

Collect all of the values in the following table for both service regions in which you want to deploy Azure Communications Gateway.

Value Field name(s) in Azure portal
The Azure regions to use for call traffic. Service Region One/Two: Region
The IPv4 address used by Azure Communications Gateway to contact your network from this region. Service Region One/Two: Operator IP address
The set of IP addresses/ranges that are permitted as sources for signaling traffic from your network. Provide an IPv4 address range using CIDR notation (for example, 192.0.2.0/24) or an IPv4 address (for example, 192.0.2.0). You can also provide a comma-separated list of IPv4 addresses and/or address ranges. Service Region One/Two: Allowed Signaling Source IP Addresses/CIDR Ranges
The set of IP addresses/ranges that are permitted as sources for media traffic from your network. Provide an IPv4 address range using CIDR notation (for example, 192.0.2.0/24) or an IPv4 address (for example, 192.0.2.0). You can also provide a comma-separated list of IPv4 addresses and/or address ranges. Service Region One/Two: Allowed Media Source IP Address/CIDR Ranges

3. Collect Test Lines configuration values

Collect all of the values in the following table for all the test lines that you want to configure for Azure Communications Gateway.

Value Field name(s) in Azure portal
The name of the test line. Name
The phone number of the test line, in E.164 format and including the country code. Phone Number
The purpose of the test line: Manual (for manual test calls by you and/or Microsoft staff during integration testing) or Automated (for automated validation with Microsoft Teams test suites). Testing purpose

Important

You must configure at least six automated test lines. We recommend nine automated test lines (to allow simultaneous tests).

4. Decide if you want tags

Resource naming and tagging is useful for resource management. It enables your organization to locate and keep track of resources associated with specific teams or workloads and also enables you to more accurately track the consumption of cloud resources by business area and team.

If you believe tagging would be useful for your organization, design your naming and tagging conventions following the information in the Resource naming and tagging decision guide.

5. Start creating an Azure Communications Gateway resource

Use the Azure portal to create an Azure Communications Gateway resource.

  1. Sign in to the Azure portal.

  2. In the search bar at the top of the page, search for Communications Gateway and select Communications Gateways.

    Screenshot of the Azure portal. It shows the results of a search for Azure Communications Gateway.

  3. Select the Create option.

    Screenshot of the Azure portal. Shows the existing Azure Communications Gateway. A Create button allows you to create more Azure Communications Gateways.

  4. Use the information you collected in 1. Collect basic information for deploying an Azure Communications Gateway to fill out the fields in the Basics configuration section and then select Next: Service Regions.

    Screenshot of the Create an Azure Communications Gateway portal, showing the Basics section.

  5. Use the information you collected in 2. Collect Service Regions configuration values to fill out the fields in the Service Regions section and then select Next: Tags.

  6. (Optional) Configure tags for your Azure Communications Gateway resource: enter a Name and Value for each tag you want to create.

  7. Select Review + create.

If you've entered your configuration correctly, the Azure portal displays a Validation Passed message at the top of your screen. Navigate to the Review + create section.

If you haven't filled in the configuration correctly, the Azure portal display an error symbol for the section(s) with invalid configuration. Select the section(s) and use the information within the error messages to correct the configuration, and then return to the Review + create section.

Screenshot of the Create an Azure Communications Gateway portal, showing a validation that failed due to missing information in the Contacts section.

6. Submit your Azure Communications Gateway configuration

Check your configuration and ensure it matches your requirements. If the configuration is correct, select Create.

Once your resource has been provisioned, a message appears saying Your deployment is complete. Select Go to resource group, and then check that your resource group contains the correct Azure Communications Gateway resource.

Note

You will not be able to make calls immediately. You need to complete the remaining steps in this guide before your resource is ready to handle traffic.

Screenshot of the Create an Azure Communications Gateway portal, showing a completed deployment screen.

7. Wait for provisioning to complete

Wait for your resource to be provisioned and connected. When your resource is ready, your onboarding team contacts you and the Provisioning Status field on the resource overview changes to "Complete." We recommend that you check in periodically to see if the Provisioning Status field has changed. This step might take up to two weeks.

8. Connect Azure Communications Gateway to your networks

When your resource has been provisioned, you can connect Azure Communications Gateway to your networks.

  1. Exchange TLS certificate information with your onboarding team.
    1. Azure Communications Gateway is preconfigured to support the DigiCert Global Root G2 certificate and the Baltimore CyberTrust Root certificate as root certificate authority (CA) certificates. If the certificate that your network presents to Azure Communications Gateway uses a different root CA certificate, provide your onboarding team with this root CA certificate.
    2. The root CA certificate for Azure Communications Gateway's certificate is the DigiCert Global Root G2 certificate. If your network doesn't have this root certificate, download it from https://www.digicert.com/kb/digicert-root-certificates.htm and install it in your network.
  2. Configure your infrastructure to meet the call routing requirements described in Reliability in Azure Communications Gateway.
    • Depending on your network, you might need to configure SBCs, softswitches and access control lists (ACLs).
    • Your network needs to send SIP traffic to per-region FQDNs for Azure Communications Gateway. To find these FQDNs:
      1. Go to the Overview page for your Azure Communications Gateway resource.
      2. In each Service Location section, find the Hostname field. You need to validate TLS connections against this hostname to ensure secure connections.
    • We recommend configuring an SRV lookup for each region, using _sip._tls.<regional-FQDN-from-portal>. Replace <regional-FQDN-from-portal> with the per-region FQDNs that you found in the Overview page for your resource.
  3. If your Azure Communications Gateway includes integrated MCP, configure the connection to MCP:
    1. Go to the Overview page for your Azure Communications Gateway resource.
    2. In each Service Location section, find the MCP hostname field.
    3. Configure your test numbers with an iFC of the following form, replacing <mcp-hostname> with the MCP hostname for the preferred region for that subscriber.
       <InitialFilterCriteria>
           <Priority>0</Priority>
           <TriggerPoint>
               <ConditionTypeCNF>0</ConditionTypeCNF>
               <SPT>
                   <ConditionNegated>0</ConditionNegated>
                   <Group>0</Group>
                   <Method>INVITE</Method>
               </SPT>
               <SPT>
                   <ConditionNegated>1</ConditionNegated>
                   <Group>0</Group>
                   <SessionCase>4</SessionCase>
               </SPT>
           </TriggerPoint>
           <ApplicationServer>
               <ServerName>sip:<mcp-hostname>;transport=tcp;service=mcp</ServerName>
               <DefaultHandling>0</DefaultHandling>
           </ApplicationServer>
       </InitialFilterCriteria>
      
  4. Configure your routers and peering connection to ensure all traffic to Azure Communications Gateway is through Azure Internet Peering for Communications Services (also known as MAPS for Voice) or ExpressRoute Microsoft Peering.
  5. Enable Bidirectional Forwarding Detection (BFD) on your on-premises edge routers to speed up link failure detection.
    • The interval must be 150 ms (or 300 ms if you can't use 150 ms).
    • With MAPS, BFD must bring up the BGP peer for each Private Network Interface (PNI).
  6. Meet any other requirements for your communications platform (for example, the Network Connectivity Specification for Operator Connect or Teams Phone Mobile). If you don't have access to Operator Connect or Teams Phone Mobile specifications, contact your onboarding team.

Next steps