Export (0) Print
Expand All

Communications Server Mediation Server: Dual NIC Issue

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

e5df79c3-ff6c-4614-8793-5e5f2cbaa938

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

04f540ac-10ad-476e-81c1-95653e46f2bc

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

6d84d4fc-f8ef-4a4d-a1e1-54afd6b501af

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.

In conclusion, even when the Mediation Server is configured in the typical manner with two NICs and each NIC is configured with an IP address each on separate subnets, entities on the Mediation Server Gateway interface subnet should be isolated so that they cannot be reached by Communications Server and Communicator client entities on the other subnets. If this is not feasible, a single NIC and single IP address must be used to connect to the Mediation Server. TLS and SRTP should be used for secure communications.

To learn more, check out the following articles:

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft