Publicly Routable IP Address for External A/V Access

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.

To enable this external access to media sessions and audio and video, the A/V Edge server and Office Communications Server clients rely on Interactive Connectivity Establishment (ICE) and Simple Traversal of User Datagram Protocol (UDP) through network address translators (NATs) (STUN) protocols. To support the protocol requirements, the A/V Edge server requires the assignment of a publicly routable IP address to its external interface.

The follow except from RFC 3489 summarizes the reasons that STUN requires a publicly routable IP address.

STUN assumes that the server exists on the public Internet. If the server is located in another private address realm, the user may or may not be able to use its discovered address to communicate with other users. There is no way to detect such a condition. (RFC 3489 Section 14.3).

STUN imposes some restrictions on the network topologies for proper operation. If client A obtains an address from STUN server X, and sends it to client B, B may not be able to send to A using that IP address. The address will not work if any of the following is true:

The STUN server is not in an address realm that is a common ancestor (topologically) of both clients A and B. For example, consider client A and B, both of which have residential NAT devices. Both devices connect them to their cable operators, but both clients have different providers. Each provider has a NAT in front of their entire network, connecting it to the public Internet. If the STUN server used by A is in A's cable operator's network, an address obtained by it will not be usable by B. The STUN server must be in the network which is a common ancestor to—in this case, the public Internet.

The STUN server is in an address realm that is a common ancestor to both clients, but both clients are behind the same NAT connecting to that address realm. For example, if the two clients in the previous example had the same cable operator, that cable operator had a single NAT connecting their network to the public Internet, and the STUN server was on the public Internet, the address obtained by A would not be usable by B. That is because some NATs will not accept an internal packet sent to a public IP address which is mapped back to an internal address. To deal with this, additional protocol mechanisms or configuration parameters need to be introduced which detect this case (RFC 3489 Section 14.3).

In an A/V Edge Server array, where the edge servers operate as logical entity one and are supported by the use of hardware load balancer, each A/V Edge Server in the array requires a dedicated public IP address.

Not placing a publicly routable IP address on the A/V Edge Server drastically reduces the effectiveness of STUN and hampers the ability of the ICE protocol to establish A/V communications between clients. The loss of functionality due to this improper configuration ranges from inconsistent A/V connectivity between clients to the complete inability to establish a successful connection.

In Office Communications Server 2007, Microsoft does not support non-publicly routable IP address on the A/V Edge server. If a reported problem is believed to be caused by the A/V Edge Server, we will be unable to continue support until the configuration is adjusted.