Communications Server Mediation Server: Dual NIC Issue

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

There have been several great blog posts on the Internet concerning the Mediation Server dual NIC configuration or single NIC with multiple IP addresses in Communications Server 2007 R2. In this article, Greg Anthony shares an additional scenario that explains why both Mediation Server network interfaces need to be on physically distinct and separate subnets.

Author: Greg Anthony

Publication date: March 2010

Product version: Microsoft Office Communications Server 2007 R2

There have been several great blog posts on the Internet concerning the Mediation Server dual NIC configuration or single NIC with multiple IP addresses in Communications Server 2007 R2. I wanted to share an additional scenario that explains why both Mediation Server network interfaces need to be on physically distinct and separate subnets.

The issue as reported was that outbound calls from Office Communicator to the PSTN were delayed up to 10 seconds before connecting Communicator to the external called party. Basically, when the person receiving the call answered the phone, the Communicator user did not hear the called party answer. Then the called party would hang up because they did not hear a response from the calling party.

When I first started troubleshooting the issue, the topology and configuration of the Mediation Server looked correct. It had two network adapters each with a separate IP address configured for separate and distinct subnets. This topology is shown in Figure 1.

Figure 1. Topology

A Wireshark trace showed that the external party call was established with basically no delay and audio was established to the Mediation Server gateway interface. Then, about 10 seconds later, audio would be established on the Communications Server listening interface of the Mediation Server to Communicator as shown in Figure 2.

Figure 2. Wireshark VoIP call statistic

The network trace taken on the Mediation Server showed that the Communicator client was making a Simple Traversal Underneath NAT (STUN) binding request to the Mediation Server gateway listening interface as shown in Figure 3. The Mediation Server does not reply as the default gateway, and the route back to the Communicator client was through the Mediation Server Communications Server listening interface and not the Mediation Server gateway listening interface on which the STUN binding request was received.

Figure 3. Client STUN binding request

The Mediation Server NIC binding order was changed to no effect. Through additional testing it was discovered that the Communicator client, regardless of whether it was internal or remote, could access the Mediation Server directly due to the publically routable IP scheme.

Now the issue was clear. Subnet C to which the Mediation Server gateway interface was connected needed to be isolated from receiving traffic from any Communications Server entities on Subnets A and B. Changes were made to the firewall access control lists to deny traffic from the subnet with the Communication Servers and clients to the subnet connecting the Mediation Server gateway listening address to the VoIP gateway. After this was completed, the STUN binding request from the Communicator client never reached the Mediation Server gateway interface because the firewall reset or blocked the connection request. This resulted in a re-invite from the Mediation Server that didn’t include the gateway side interface instead of the delay timeout that was received before and then the re-invite.