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 to use Azure Communications Gateway.

For Operator Connect or Teams Phone Mobile, you must also 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.

For Zoom Phone Cloud Peering, you must also have started the onboarding process with Zoom to become a Zoom Phone Cloud Peering provider. For more information on Cloud Peering, see Zoom's Cloud Peering information.

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 for two types of testing:

• Integration testing by your staff during deployment and integration
• Service verification (continuous call testing) by your chosen communication services

The following table describes how many numbers you need to allocate.

Service	Numbers for integration testing	Service verification numbers
Operator Connect	1 (minimum)	- Production deployments: 6 - Lab deployments: 3
Teams Phone Mobile	1 (minimum)	- Production deployments: 6 - Lab deployments: 3
Microsoft Teams Direct Routing	1 (minimum)	None (not applicable)
Zoom Phone Cloud Peering	1 (minimum)	- US and Canada: 6 - Rest of world: 2
Azure Operator Call Protection Preview	1 (minimum)	None (not applicable)

Important

Service verification numbers must be usable throughout the lifetime of your deployment.

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 type of deployment. Choose from Standard (for production) or Lab.	Instance details: SKU
The voice codecs to use between Azure Communications Gateway and your network. We recommend that you only specify any codecs if you have a strong reason to restrict codecs (for example, licensing of specific codecs) and you can't configure your network or endpoints not to offer specific codecs. Restricting codecs can reduce the overall voice quality due to lower-fidelity codecs being selected.	Call Handling: Supported codecs
Whether your Azure Communications Gateway resource should handle emergency calls as standard calls or directly route them to the Emergency Routing Service Provider (US only; only for Operator Connect or Teams Phone Mobile).	Call Handling: Emergency call handling
A comma-separated list of dial strings used for emergency calls. For Microsoft Teams, specify dial strings as the standard emergency number (for example 999). For Zoom, specify dial strings in the format +<country-code><emergency-number> (for example +44999). (Only for Operator Connect, Teams Phone Mobile and Zoom Phone Cloud Peering).	Call Handling: Emergency dial strings
Whether to use an autogenerated *.commsgw.azure.com domain name or to use a subdomain of your own domain by delegating it to Azure Communications Gateway. Delegated domains are limited to 34 characters. For more information on this choice, see the guidance on creating a network design.	DNS: Domain name options
(Required if you choose an autogenerated domain) The scope at which the autogenerated domain name label for Azure Communications Gateway is unique. Communications Gateway resources are assigned an autogenerated domain name label that depends on the name of the resource. 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.	DNS: Auto-generated Domain Name Scope
(Required if you choose a delegated domain) The domain to delegate to this Azure Communications Gateway deployment	DNS: DNS domain name

Collect configuration values for service regions

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

Note

Lab deployments have one Azure region and connect to one site in your network.

Value	Field name(s) in Azure portal
The Azure region to use for call traffic. If you are enabling Azure Operator Call Protection Preview there are restrictions on where your Azure resources can be deployed; see Choosing Management and Service Regions	Service Region One/Two: Region
The IPv4 address belonging to your network that Azure Communications Gateway should use 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

Collect configuration values for each communications service

Collect the values for the communications services that you're planning to support.

Important

Some options apply to multiple services, as shown by Options common to multiple communications services in the following tables. You must choose configuration that is suitable for all the services that you plan to support.

For Microsoft Teams Direct Routing:

Value	Field name(s) in Azure portal
IP addresses or address ranges (in CIDR format) in your network that should be allowed to connect to Azure Communications Gateway's Provisioning API, in a comma-separated list. Use of the Provisioning API is required to provision numbers for Direct Routing.	Options common to multiple communications services: Allowed source IP addresses/CIDR ranges for connecting to the Communications Gateway Provisioning Platform
Whether to add a custom SIP header to messages entering your network by using Azure Communications Gateway's Provisioning API	Options common to multiple communications services: Add custom SIP header
(Only if you choose to add a custom SIP header) The name of any custom SIP header	Options common to multiple communications services: Custom SIP header name

For Operator Connect:

Value	Field name(s) in Azure portal
Whether to add a custom SIP header to messages entering your network by using Azure Communications Gateway's Provisioning API	Options common to multiple communications services: Add custom SIP header
(Only if you choose to add a custom SIP header) The name of any custom SIP header	Options common to multiple communications services: Custom SIP header name
(Only if you choose to add a custom SIP header) IP addresses or address ranges (in CIDR format) in your network that should be allowed to connect to the Provisioning API, in a comma-separated list.	Options common to multiple communications services: Allowed source IP addresses/CIDR ranges for connecting to the Communications Gateway Provisioning Platform

For Teams Phone Mobile:

Value	Field name(s) in Azure portal
The number used in Teams Phone Mobile to access the Voicemail Interactive Voice Response (IVR) from native dialers.	Teams Phone Mobile: Teams voicemail pilot number
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'll use another method to route calls).	Teams Phone Mobile: MCP

For Zoom Phone Cloud Peering:

Value	Field name(s) in Azure portal
The Zoom region to connect to	Zoom: Zoom region
IP addresses or address ranges (in CIDR format) in your network that should be allowed to connect to Azure Communications Gateway's Provisioning API, in a comma-separated list. Use of the Provisioning API is required to provision numbers for Zoom Phone Cloud Peering.	Options common to multiple communications services: Allowed source IP addresses/CIDR ranges for connecting to the Communications Gateway Provisioning Platform
Whether to add a custom SIP header to messages entering your network by using Azure Communications Gateway's Provisioning API	Options common to multiple communications services: Add custom SIP header
(Only if you choose to add a custom SIP header) The name of any custom SIP header	Options common to multiple communications services: Custom SIP header name

There are no configuration options required for Azure Operator Call Protection Preview.

Collect values for service verification numbers

Collect all of the values in the following table for all the service verification numbers required by Azure Communications Gateway.

For Operator Connect and Teams Phone Mobile:

Value	Field name(s) in Azure portal
A name for the test line. We recommend names of the form OC1 and OC2 (for Operator Connect) and TPM1 and TPM2 (for Teams Phone Mobile).	Name
The phone number for the test line, in E.164 format and including the country code.	Phone Number
The purpose of the test line (always Automated).	Testing purpose

For Zoom Phone Cloud Peering:

Value	Field name(s) in Azure portal
The phone number for the test line, in E.164 format and including the country code.	Phone Number

Microsoft Teams Direct Routing and Azure Operator Call Protection Preview don't require service verification numbers.

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.

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.

   

3. Select the Create option.

   

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

5. Use the information you collected in Collect configuration values for service regions to fill out the fields in the Service Regions tab and then select Next: Communications Services.

6. Select the communications services that you want to support in the Communications Services configuration tab, use the information that you collected in Collect configuration values for each communications service to fill out the fields, and then select Next: Test Lines.

7. Use the information that you collected in Collect values for service verification numbers to fill out the fields in the Test Lines configuration tab and then select Next: Tags.

   • Don't configure numbers for integration testing.
   • Microsoft Teams Direct Routing and Azure Operator Call Protection Preview don't require service verification numbers.

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

9. 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.

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.

Wait for provisioning to complete

Wait for your resource to be provisioned. When your resource is ready, 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 is "Complete." This step might take up to two weeks.

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).

   Important

   When configuring SBCs, firewalls, and ACLs, ensure that your network can receive traffic from both of the /28 IP ranges provided to you by your onboarding team because the IP addresses used by Azure Communications Gateway can change as a result of maintenance, scaling or disaster scenarios.

   • If you are using Azure Operator Call Protection Preview, a component in your network (typically an SBC), must act as a SIPREC Session Recording Client (SRC).
   • Your network needs to send SIP traffic to per-region FQDNs for Azure Communications Gateway. To find these FQDNs:
     1. Sign in to the Azure portal.
     2. In the search bar at the top of the page, search for your Communications Gateway resource.
     3. Go to the Overview page for your Azure Communications Gateway resource.
     4. 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 from the Hostname fields on 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 Microsoft Azure Peering Service Voice (also known as MAPS 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 Voice, 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 need access to Operator Connect or Teams Phone Mobile specifications, contact your onboarding team.

Configure domain delegation with Azure DNS

Note

If you decided to use an automatically allocated *.commsgw.azure.com domain name for Azure Communications Gateway, skip this step.

If you chose to delegate a subdomain when you created Azure Communications Gateway, you must update the name server (NS) records for this subdomain to point to name servers created for you in your Azure Communications Gateway deployment.

1. Sign in to the Azure portal.
2. In the search bar at the top of the page, search for your Communications Gateway resource.
3. On the Overview page for your Azure Communications Gateway resource, find the four name servers that have been created for you.
4. Note down the names of these name servers, including the trailing . at the end of the address.
5. Follow Delegate the domain and Verify the delegation to configure all four name servers in your NS records. We recommend configuring a time-to-live (TTL) of two days.

Configure alerts for upgrades, maintenance and resource health

Azure Communications Gateway is integrated with Azure Service Health and Azure Resource Health.

• We use Azure Service Health's service health notifications to inform you of upcoming upgrades and scheduled maintenance activities.
• Azure Resource Health gives you a personalized dashboard of the health of your resources, so you can see the current and historical health status of your resources.

You must set up the following alerts for your operations team.

• Alerts for service health notifications, for upgrades and maintenance activities.
• Alerts for resource health, for changes in the health of Azure Communications Gateway.

Alerts allow you to send your operations team proactive notifications of changes. For example, you can configure emails and/or SMS notifications. For an overview of alerts, see What are Azure Monitor alerts?. For more information on Azure Service Health and Azure Resource Health, see What is Azure Service Health? and Resource Health overview.

Next steps

Integrate with Azure Communications Gateway's Provisioning API