Connectivity for Azure Communications Gateway

Each Azure region in your deployment connects to your core network. You must choose the type of connection (for example, Microsoft Azure Peering Service Voice). You must use specific IP addresses and domain names to route traffic between your network and Azure Communications Gateway.

This article describes:

• The types of connection you can use.
• The IP addresses and domain names you need to know about.
• Your options for choosing domain names for Azure Communications Gateway.

Connecting to your network

Azure Communications Gateway supports multiple types of connection to your network.

• We strongly recommend using Microsoft Azure Peering Service Voice (also called MAPS Voice or MAPSV).
• If you can't use MAPS Voice, we recommend ExpressRoute Microsoft Peering.

Azure Communications Gateway is normally deployed with public IP addresses on all interfaces. This means that you can use connectivity methods supporting public IP addresses to connect your network to Azure Communications Gateway such as MAPS Voice, ExpressRoute Microsoft Peering and the public internet. If you want to control and manage the traffic between your network and Azure Communications Gateway you can use VNet injection for Azure Communications Gateway (preview) to deploy the interfaces which connect to your network into your own subnet.

The following table lists all the available connection types and whether they're supported for each communications service. The connection types are in the order that we recommend (with recommended types first).

Connection type	Operator Connect / Teams Phone Mobile	Microsoft Teams Direct Routing	Zoom Phone Cloud Peering	Notes
MAPS Voice	✅	✅	✅	- Best media quality because of prioritization with Microsoft network - No extra costs - See Internet peering for Peering Service Voice walkthrough
ExpressRoute Microsoft Peering	✅	✅	✅	- Easy to deploy - Extra cost - Consult with your onboarding team and ensure that it's available in your region - See Using ExpressRoute for Microsoft PSTN services
VNet Injection (preview)	⚠️ ExpressRoute Private Peering must be used for production deployments	✅	✅	- Control connectivity to your network from your own VNet - Enables use of ExpressRoute Private Peering and Azure VPN Gateways - Additional deployment steps -Extra cost
Public internet	⚠️ Lab deployments only	✅	✅	- No extra setup - Where available, not recommended for production

Note

The Operator Connect and Teams Phone Mobile programs do not allow production deployments to use the public internet, including VPNs over the public internet.

Set up your network as in the following diagram and configure it in accordance with any network connectivity specifications for your chosen communications services. For production deployments, your network must have two sites with cross-connect functionality. For more information on the reliability design for Azure Communications Gateway, see Reliability in Azure Communications Gateway.

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

IP addresses and domain names

Azure Communications Gateway (ACG) deployments require multiple IP addresses and fully qualified domain names (FQDNs). The following diagram and table describe the IP addresses and FQDNs that you might need to know about.

IP address or range on diagram	Description	Notes
1	IP address range in operator site A for sending signaling traffic to ACG	Specify this information when you deploy ACG.
2	IP address range or FQDN in site A for receiving signaling traffic from ACG	Specify this information when you deploy ACG.
3	IP addresses or address ranges in operator site A for sending and receiving media traffic	Specify this information when you deploy ACG.
4	IP address range in operator site B for sending signaling traffic to Azure Communications Gateway	Specify this information when you deploy ACG.
5	IP address range or FQDN in operator site A for receiving signaling traffic from ACG	Specify this information when you deploy ACG.
6	IP addresses or address ranges in operator site B for sending and receiving media traffic	Specify this information when you deploy ACG.
7	ACG region 1 FQDN for receiving signaling traffic from operator network	Get the FQDN from the Hostname field for region 1 in the Azure portal. Configure your network to route calls to this FQDN.
8	ACG region 1 IP addresses or address ranges for sending signaling traffic to your network	Ask your onboarding team for the values. Configure them in your network's access control lists (ACLs).
9	ACG region 1 IP addresses or address ranges for media traffic between operator network and ACG	Ask your onboarding team for the values. Configure them in your network's access control lists (ACLs).
10	ACG region 2 FQDN for receiving signaling traffic from operator network	Get the FQDN from the Hostname field for region 2 in the Azure portal. Configure your network to route calls to this FQDN.
11	ACG region 2 IP addresses or address ranges for sending signaling traffic to your network	Ask your onboarding team for the values. Configure them in your network's access control lists (ACLs).
12	ACG region 2 IP addresses or address ranges for media traffic between operator network and ACG	Ask your onboarding team for the values. Configure them in your network's access control lists (ACLs).
13	ACG base domain providing the Provisioning API	Get the FQDN from the Overview field in the Azure portal.
14	ACG region 1 IP addresses or address ranges for sending signaling traffic to communications services	- For Zoom Phone Cloud Peering, ask your onboarding team for this information and provide it to Zoom. - Microsoft manages this information for other communications services.
15	ACG region 1 FQDN or IP addresses for receiving signaling traffic from communications services	- For Zoom Phone Cloud Peering, ask your onboarding team for this information and provide it to Zoom. - Microsoft manages this information for other communications services.
16	ACG region 1 IP addresses or address ranges for media traffic between communications service and ACG	- For Zoom Phone Cloud Peering, ask your onboarding team for this information and provide it to Zoom. - Microsoft manages this information for other communications services.
17	ACG region 2 IP addresses or address ranges for sending signaling traffic to communications services	- For Zoom Phone Cloud Peering, ask your onboarding team for this information and provide it to Zoom. - Microsoft manages this information for other communications services.
18	ACG region 2 FQDN or IP addresses for receiving signaling traffic from communications services	- For Zoom Phone Cloud Peering, ask your onboarding team for this information and provide it to Zoom. - Microsoft manages this information for other communications services.
19	ACG region 2 IP addresses or address ranges for media traffic between communications service and ACG	- For Zoom Phone Cloud Peering, ask your onboarding team for this information and provide it to Zoom. - Microsoft manages this information for other communications services.
20	IP addresses or FQDNs used by communications services to receive signaling traffic	You don't need to manage this information.
21	IP addresses or FQDNs used by communications services to send signaling traffic	You don't need to manage this information.
22	IP addresses used by communications services to send and receive media traffic	You don't need to manage this information.

Tip

This diagram shows three sets of IP addresses for the communications service for simplicity. The details might vary for each communications service, but you won't need to manage the details because we manage the connection from Azure Communications Gateway to communications services.

Each site in your network must send traffic to its local Azure Communications Gateway service region by default, and fail over to the other region if the local region is unavailable. For example, site A must route traffic to region 1, and, if it detects that region 1 is unavailable, reroute traffic to region 2. For more information on the call routing requirements, see Call routing requirements.

Autogenerated domain names

Azure Communications Gateway provides multiple FQDNs:

• A <deployment-id>.commsgw.azure.com base domain for your deployment, where <deployment-id> is autogenerated and unique to the deployment. This domain provides the Provisioning API. It's item 13 in IP addresses and domain names.
• Per-region domain names that resolve to the signaling IP addresses to which your network should route signaling traffic. These domain names are subdomains of the base domain. They're items 7 and 10 in IP addresses and domain names.

Port ranges used by Azure Communications Gateway

Azure Communications Gateway uses the following local port ranges which must be accessible from your network, depending on the connectivity type chosen:

Port Range	Protocol	Transport
16384-23983	RTP/RTCP SRTP/SRTCP	UDP
5060	SIP	UDP/TCP
5061	SIP over TLS	TCP

All Azure Communications Gateway IP addresses can be used for both signaling (SIP) and media (RTP/RTCP). When connecting to multiple networks, additional SIP local ports are used. For details, see your Azure Communications Gateway resource in the Azure portal.

VNet injection for Azure Communications Gateway (preview)

VNet injection for Azure Communications Gateway (preview) allows the network interfaces on your Azure Communications Gateway that connect to your network to be deployed into virtual networks in your subscription. This allows you to control the traffic flowing between your network and your Azure Communications Gateway instance using private subnets, and lets you use private connectivity to your premises such as ExpressRoute Private Peering and VPNs.

If you use VNet injection (preview) with Operator Connect or Teams Phone Mobile, your network must still meet the redundancy and resiliency requirements described in the Network Connectivity Specification provided to you by your onboarding team. This mandates that your network is connected to Azure by at least 2 ExpressRoute circuits, each deployed with local redundancy and configured so that each region can use both circuits in the case of failure as described in the diagram below:

Warning

Any traffic in your own virtual network is subject to standard Azure Virtual Network and bandwidth charges.

Related content

• Learn how to route calls to Azure Communications Gateway.
• Learn more about planning an Azure Communications Gateway deployment