Merge pull request #269495 from rcdun/nslack/whitelistIPs

Make it clearer Operators need to allow full IP ranges

Author: prmerger-automator[bot]

articles/communications-gateway/deploy.md

@@ -168,7 +168,11 @@ When your resource has been provisioned, you can connect Azure Communications Ga
     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.
     1. 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.
 1. Configure your infrastructure to meet the call routing requirements described in [Reliability in Azure Communications Gateway](reliability-communications-gateway.md).
-    * Depending on your network, you might need to configure SBCs, softswitches and access control lists (ACLs).
+    * 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.
+
     * 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](https://azure.microsoft.com/).
         1. In the search bar at the top of the page, search for your Communications Gateway resource.

articles/communications-gateway/reliability-communications-gateway.md

@@ -52,7 +52,7 @@ For production deployments, we expect your network to have two geographically re
 
 Lab deployments must connect to one site in your network.
 
-Each Azure Communications Gateway service region provides an SRV record. This record contains all the SIP peers providing SBC functionality (for routing calls to communications services) within the region.
+Each Azure Communications Gateway service region provides an SRV record. This record contains all the SIP peers providing SBC functionality (for routing calls to communications services) within the region. This SRV record can point to any IP address in the /28 IP range provided to you by your onboarding team.
 
 If your Azure Communications Gateway includes Mobile Control Point (MCP), each service region provides an extra SRV record for MCP. Each per-region MCP record contains MCP within the region at top priority and MCP in the other region at a lower priority.
 
@@ -64,6 +64,7 @@ Each site in your network must:
 >     - Make a DNS SRV lookup on the domain name for the service region's connection to your network, 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 in the Azure portal. For example, if your deployment uses `commsgw.azure.com` domain names, look up  `_sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com` for the first region.
 >     - If the SRV lookup returns multiple targets, use the weight and priority of each target to select a single target.
 > - Send new calls to available Azure Communications Gateway peers.
+> - Be able to receive traffic from any IP address in each of the IP ranges associated with your Azure Communications Gateway.
 
 When your network routes calls to Azure Communications Gateway's SIP peers for SBC function, it must: