Configuring the A/V Edge Service for NAT in Communications Server 2007 R2
Published May 20 2019 02:24 PM 588 Views
Brass Contributor
First published on TECHNET on Jul 09, 2010

When configuring the A/V Edge for NAT it's possible that remote users (both employees and federated) will be able to establish IM connectivity and view presence data but not escalate the conversation to an audio session. If this is happening to your users, find out why.


Author: Rick Varvel


Publication date: March 2010


Product version: Microsoft Office Communications Server 2007 R2





Communications Server 2007 R2 introduced support for configuring a firewall to perform Network Address Translation (NAT) for the A/V Edge external interface. This option is available only with the single consolidated topology as shown in Figure 1.


When configuring the A/V Edge for NAT it's possible that remote users (both employees and federated) will be able to establish IM connectivity and view presence data but not escalate the conversation to an audio session. The call will typically appear to connect but then drop within about 5 seconds and display the error message: "The call was disconnected because you stopped receiving audio from firstName lastName. Please try the call again."


Figure 1. Typical AV Edge configured for NAT



Cause


The error occurs only when remote users are trying to establish a Communicator to Communicator audio conference with an internal user. (In the case of 2 remote Communicator clients, the audio stream is point to point between them via the Internet.)


The error is caused by a change in R2 A/V Edge service behavior. When the "External IP address is translated by NAT" check box is selected, it signals the A/V Edge service to provide the pool's front-end server the IP address that is associated with A/V Edge's external FQDN. That IP address is then returned to the remote client via in-band provisioning, and if it happens to be the IP address of the A/V Edge service that has been translated by NAT instead of the public IP address, the remote Communicator client will not be able to connect.


Detection


A Snooper trace of the Communicator-uccapi-0.uccapilog will look similar to what is shown in Figure 2.


Figure 2. Snooper trace showing sample A/V Conference InitiationTrace of failed connection



200OK from Address Exchange (16:18:07.558) - a=candidate: list indicates which IP addresses are available to the remote endpoint (Figure 3). Note that all candidates are non-routable in this trace.


Figure 3. IP addresses available to the remote endpoint



200OK from Candidate Promotion (16:18:13.246) - a=candidate: list indicates to which IP addresses the remote endpoint will attempt to connect (Figure 4). The remote endpoint will fail when trying to connect to 10.45.16.5.


Figure 4. IP addresses to which the remote endpoint will attempt to connect



For comparison, the trace from a successful connection (Figures 5 and 6) shows that the remote endpoint will attempt to connect to a publicly routable IP address (which will go through NAT to the A/V Edge service's private IP address) and the audio conferencing session will be established.


Trace of Successful Connection


200OK from Address Exchange (16:18:07.558) - a=candidate: list indicates which IP addresses are available to the remote endpoint (Figure 5). Note that four of the candidates are publicly addressable in this trace.


Figure 5. IP addresses available to the remote endpoint



200OK from Candidate Promotion (16:18:13.246) - a=candidate: list indicates to which IP addresses the remote endpoint will attempt to connect (Figure 6). The remote endpoint will succeed when trying to connect to 63.123.155.5.


Figure 6. IP addresses to which the remote endpoint will attempt to connect



Prevention


To avoid this issue, perform the following steps as part of the A/V Edge service configuration. Keep in mind that these steps are unique to the single consolidated Edge topology.


Step 1. Configure the firewall to perform DNAT inbound and SNAT outbound for the A/V Edge external interface.


In any location that has multiple Edge Servers deployed behind a load balancer, the external firewall cannot function as a network address translation (NAT) device. However, in a site that has only a single Edge Server deployed, the external firewall can be configured as a NAT.


If you do so, configure the NAT as a destination network address translation (DNAT) for inbound traffic. In other words, configure any firewall filter used for traffic from the Internet to the Edge Server with DNAT, and configure any firewall filter for traffic going from the Edge Server to the Internet (outbound traffic) as a source network address translation (SNAT). The A/V Edge server external interface will have a private IP address, as shown in Figure 7.


Figure 7. Sample AV Edge configuration for NAT



Step 2. Configure the Edge server to resolve the FQDN associated with public A/V Edge service to the public IP address, not the IP address translated by NAT.


Using Figure 1.0 for reference, assume your A/V Edge service has a public IP address of 63.123.155.5 and a NAT IP address of 10.45.16.5. If you run CMD.exe from the Edge Server and type ping av.contoso.com it must return 63.123.155.5.


Step 3. Configure the A/V Edge service to support NAT by selecting the "External IP address is translated by NAT" check box.


Step 4. Restart the Edge Server (or at least the A/V Edge service) to force the changes to take effect.


Remember, if the A/V Edge external interface is not publicly addressable, federated A/V conferencing with Communications Server 2007 R2 clients is not an option.


Communications Server Resources



We Want to Hear from You



Version history
Last update:
‎May 20 2019 02:24 PM
Updated by: