The Edge Server controls traffic across the firewall and usage of the internal deployment by external users. The Edge Server runs the following services:

• Access Edge service. The Access Edge service provides a single, trusted connection point for both outbound and inbound Session Initiation Protocol (SIP) traffic.
  
  
• Web Conferencing Edge service. The Web Conferencing Edge service enables external users to join meetings that are hosted on your internal Communications Server deployment. It also processes meeting invitations that your internal and remote users send to federated, public, and anonymous users.
  
  
• A/V Edge service. The A/V Edge service makes audio, video, application sharing, and file transfer available to external users. Your users can add audio and video to meetings that include external participants, and they can share audio and video directly with an external user in point-to-point sessions. The A/V Edge service also provides support for desktop sharing and file transfer.
  
  

Authorized external users can access the Edge Servers in order to connect to your internal Communications Server deployment, but the Edge Servers do not provide any other access to the internal network.

The reverse proxy is required for the following:

• To enable external users to download meeting content
  
  
• To enable external users to expand distribution groups
  
  
• To enable remote users to download files from the Address Book Server or to submit queries to the Address Book Web Query service
  
  
• To enable remote users to obtain updates to client and device software
  
  

Note:
External users do not need a VPN connection to your organization in order to participate in Communications Server-based communications. External users who are connected to your organization’s internal network over a VPN bypass the reverse proxy.

You can deploy your edge topology with only an external firewall or both external and internal firewalls. The reference architectures include two firewalls. Using two firewalls is the recommended approach because it ensures strict routing from one network edge to the other, and it protects your internal deployment behind two levels of firewall.

A Director is an Enterprise pool that does not home users; instead, it serves as an internal next-hop server to which an Edge Server routes inbound SIP traffic destined for internal servers. The Director authenticates inbound requests and redirects them to the user’s home pool or server.

If your organization is going to enable external access, we recommend that you deploy a Director. By authenticating inbound SIP traffic from remote users, the Director relieves Enterprise pool servers from the overhead of performing authentication of remote users. It also helps insulate home servers and Enterprise pools from malicious traffic such as denial-of-service attacks; if the network is flooded with invalid external traffic in such an attack, this traffic ends at the Director, and internal users should not see any effect on performance. For more information about the use of Directors, see Director.

The Microsoft Communications Server 2010 scaled consolidated Edge topology is optimized for DNS load balancing, but hardware load balancing is still supported. If you choose to deploy hardware load balancers, you can configure them for both the external and internal interfaces of the Edge Server pool.

Regardless of whether you use hardware load balancing for your Edge server pool, you will need a hardware load balancer if there are two or more reverse proxy servers deployed.

Note:
If you are using a hardware load balancer, the load balancer deployed for connections with the internal network must be configured to load-balance only the traffic to the Access Edge service and the A/V Edge service; it cannot load-balance the traffic to the internal Web Conferencing Edge service.

Note:

Direct Server Return (DSR) NAT – This NAT mode applies only to hardware load balancers and is used in cases where a hardware load balancer is a bottleneck for traffic flow. With DSR NAT, servers are tricked into accepting traffic for a VIP, but instead of sending a response back to the hardware load balancer, it is sent directly to a router. Direct server return NAT is not supported with Communications Server 2010.