Deploying Microsoft Lync Server 2010, Edge Servers across a multiple-location organization presents numerous challenges. Lync Server 2010 gives remote users, who are not using a Virtual Private Network (VPN) connection, the ability to take advantage of the same Lync Server 2010 features as users on the local network. Edge Server is the server role that enables this functionality. The Edge Server contains roles such as the Access Edge, Web Conferencing Edge, and Audio/Video Edge. Each role acts to proxy data or media to different destinations. This article walks you through a scenario that explains Edge Server roles and how traffic flows between Edge Servers located in different locations.
Author: Byron O. Spurlock
Publication date: May 15, 2012
Product version: Microsoft Lync Server 2010
In Lync Server 2010, server roles perform specific functions. For example, the Front End Server provides IM and presence, web conferencing, user authentication and so forth. The Edge Server enables remote workers to access instant messaging, presence, audio/video, and web conferencing without using a Virtual Private Network (VPN).
As Edge Server deployments become more common, it’s import for administrators to understand the paths that protocols follow in various user scenarios—especially remote-to-remote scenarios. This article explores a scenario where two remote users, in different geographic locations, within the same Lync Server 2010 organization, communicate through an Edge Server topology.
A consolidated Edge Server delivers the following services:
Access Edge service: Manages SIP traffic for signaling and instant messaging.
Web Conference Edge service: The Persistent Shared Object Model (PSOM) protocol enables Microsoft Office Live Meeting 2007 conferences.
A/V Edge service: The Simple Traversal of UDP through NAT (STUN)/Traversal Using Relay NAT (TURN) protocols traverse firewalls and NATs.
Sample Edge Server Environment
In this Edge Server environment, Contoso has data centers deployed in Redmond and Singapore. Each office is considered the primary user location for that region. Each location has an existing Lync Server 2010 pool that is deployed and functional.
Redmond and Singapore each house a data center that contains a Lync Server 2010 pool with an Edge Server deployed in the perimeter network. The Edge Server topology allows remote users in Redmond and Singapore to collaborate with internal users in either pool with all modalities—IM and presence, conferencing, application sharing, and audio/video. Remote traffic is kept regionalized whenever possible.
Scenario – Lync-to-Lync Calls in Different Pools
Two users, homed in different Lync pools, call each other using Lync 2010 while working from home. User1, Red-Redmond-U1, is located in Redmond and User2, Sing-Redmond-U1, is located in Singapore. In the diagram to follow we will take a look at the call setup and flow of a Lync call.
Figure 1. Redmond user sign in
1. Red-Remote-U1 signs in to the Redmond Lync pool through Redmond Access Edge Server. Because the user is remote and not leveraging VPN, the Lync 2010 client sends a SIP INVITE that contains the Red-Remote-U1’s credentials to the Edge Server over NTLM. The SIP OK will contain valid MRAS information to setup the call.
2. The Redmond Edge Server proxies the remote connection to Redmond Director.
3. The Redmond Director authenticates the remote user and proxies the connection to the user’s home pool which is Redmond pool.
Note: In a Lync-to-Lync call with remote users, the first connectivity attempt is from the internal IP address of each user. The private IP address of each client’s network interface card is passed to each other in the Interactive Connectivity Establishment (ICE) candidate exchange process. If the internal IP address is not available, the connection is relayed through the reflective IP, which is the public IP address of the home router. If the reflective IP address is not available, the media relay address of the Audio/Video Edge Server, of the user who initiated the call is leveraged.
Figure 2. Singapore user authentication
1. Sing-Remote-U1 signs in to the Singapore Lync pool through Redmond Access Edge Server. Because the user is remote and not leveraging VPN, the Lync 2010 client sends a SIP INVITE that contains the Sing-Remote-U1’s credentials to the Edge Server over NTLM. The SIP OK contains valid MRAS information to setup the call.
2. Redmond Edge Server proxies a connection to the Redmond Director
3. Redmond Director authenticates Sing-Remote-U1 and proxies connection to the Singapore Lync pool, which is the user’s home.
Call Flow -Internals
1. Red-Remote-U1 initiates a call to Sing-Remote-U1
Figure 3. Call SIP trace
Note: The example IP addresses used in figures 4 and figure 5 are:
- Local IP: 175.145.5.132
- Reflective IP: 60.170.30.219
- Relay IP: 215.10.80.90
2. Sing-Remote-U1 and Red-Remote-U1 exchange candidate information that contains the relay address of the Audio/Video Edge public interface. The caller, Red-Remote-U1, initiated the call to the callee, Sing-Remote-U1, and begins the ICE protocol connectivity checks to determine the best media path. In this case, the Redmond Edge Server.
3. Sing-Remote-U1 and Red-Remote-U1 both exchange candidate information for each other in order to connect using the most direct route.
Figure 4. Call SIP trace
4. Sing-Remote-U1 and Red-Remote-U1 both exchange candidate information for the local IP, reflective IP and the Relay IP of the Audio\Video Edge public interface. The following process is depicted in the Figure 5 below; the example addresses that are used are included: (only the trace that coincides to this step is shown.
5. The caller (Red-Remote-U1) was the initiator of the call to the callee (Sing-Remote-U1) and begins the ICE protocol connectivity checks to determine the optimal media path, which is the Redmond Edge Server. The process below depicts the result of the candidate check and the identification of the Edge Server being used for the call.
Figure 5. Call SIP trace
In our scenario it is assumed that both users cannot connect using the following methods:
- UDP direct: UDP ports of each user’s computer IP addresses.
- UDP NAT: Connecting through the reflexive IP address of the public IP address of the home router for each Lync user.
Note: When you configure your Lync 2010 pool in Topology Builder, you can configure which Edge Server pool the Lync pool will communicate with. Because the Lync 2010 organization contains a single entry point (SRV Record) for remote access, it is responsible for all SIP communication through the Access Edge Server(s) located in the Redmond data center.
Figure 6. Edge Server configuration.
Figure 6 displays Topology Builder configuration where the administrator associates an Edge Server to a pool.
Conclusion
When deploying geographically disbursed Edge Servers, the key takeaways are:
- Access Edge is responsible for proxying SIP traffic for remote clients to the next hop, which can be a Director or a Lync pool.
- The initiator of the call broadcasts multiple methods to establish the call to the callee.
- Lync clients attempt to communicate using the most direct path which is peer to peer. If that fails, the public interface of the home router and the Edge Server are leveraged last.
- Topology Builder allows administrators to select the respective Edge pool for Lync pool.
Lync Server Resources
- Lync Server 2010 Documentation Library
- DrRez blog
- NextHop blog
- Lync Server and Communications Server resources