Lync Server 2010 Geographically Dispersed Edge Topology: Part 2

Deploying Microsoft Lync Server 2010, Edge Servers across a multiple-location organization presents numerous challenges; add communication with federated organizations and things get interesting with call routing. Federation allows Lync 2010 users to communicate with users in other organizations that are using Office Communications Server or Lync Server 2010. The Lync Server 2010 Edge Server enables organizations to establish a trust relationship with each other to allow federation to take place.

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. In Lync Server 2010 Geographically Dispersed Edge Topology: Part 1 we explored Edge Server roles and how traffic flows between Edge Servers located in different locations. This article walks you through a scenario that explains Edge Server roles and how traffic flows when a remote user  communicates with a federated contact who resides inside a different organization.

Author: Byron O. Spurlock

Publication date: September 17, 2012

Product version: Microsoft Lync Server 2010

In Lync Server 2010, server roles perform specific functions. For example, the Front End Server provides instant messaging (IM) and presence, web conferencing, user authentication, and so forth. Edge Server enables remote workers to access instant messaging, presence, audio/video (A/V), and web conferencing without using a virtual private network (VPN).

Federation allows organizations to communicate with each other with the following modalities: IM and presence, web conferencing, A/V, and desktop sharing. To establish federation each organization must contain an Edge Server in their respective organization. The type of federation varies from organization to organization. In this article we explore automatic discovery open federation; which means both organizations have the necessary public DNS records.

As Lync Server 2010 deployments with multiple Edge Servers in different geographic locations become more common, it’s import for administrators to understand the paths that protocols follow in various user scenarios—especially remote-to-federation scenarios. This article explores the Audio/Video traffic flows when two federated Lync users in different organizations, initiate a call to each other using Lync 2010.

A Consolidated Edge Server delivers the following services:

  • Access Edge service: Manages SIP traffic signaling and instant messaging.
  • Web Conferencing Edge service: The Persistent Shared Object Model (PSOM) protocol enables Microsoft Office Live Meeting 2007 conferences.
  • Audio/Video 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 its region. Each location has a deployed and functional Lync Server 2010 pool.

Contoso’s data centers in Redmond and Singapore both contain 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 A/V. Remote traffic is kept regionalized whenever possible. Contoso is open federated; this allows users to find contacts in other organizations and to communicate with them.

Litware also has Lync Server 2010 deployed with an Edge Server in the perimeter network. Litware is also automatic discovery which allows its users to find contacts in other organizations and to communicate with them as well.

Scenario – Lync Call between Federated Contacts

In this scenario two Lync 2010 users, who reside in different Lync Server 2010 organizations, decide to have an Audio/Video conversation using Lync 2010. Lync-U1 works offsite for Contoso. Lync-U2 works onsite for Liteware. Contoso and Liteware are federated with each other. In Figures 1, 2, and 3 we look at three different segments of the call setup and call flow between Lync –U1 and Lync-U2.

Remote User Authentication

1) Lync-U1 signs in to the Singapore Lync pool through Redmond Access Edge Server (Figure 1). Because Lync-U1 is remote and not leveraging VPN, the Lync 2010 client sends a SIP INVITE that contains Lync-U1’s credentials to the Edge Server over NTLM. The SIP OK contains valid Media Relay Authentication Server (MRAS) information to establish a call.

2) Redmond Edge Server proxies a connection to the Redmond Director.*

3) Redmond Director authenticates Lync-U1 and proxies the connection to Singapore Lync pool (because this is where the user is homed).

4) MRAS response information is sent to the client by sending a SIP 200 OK message from the Redmond Access Edge Server.

*Note: The Director is an optional and recommended server role that can be deployed in a Lync server 2010 deployment. A common scenario where a Director is deployed is when security to the perimeter network is a concern and\or remote usage will be leveraged with multiple pools in an organization. The Director is responsible for proxying SIP traffic to and from the Edge environment.

Figure 1. Remote user authentication

Remote user retrieves MRAS credentials.

1) Lync-U1 signs in to the Singapore Lync pool through Redmond Access Edge Server (see Figure 2). Because the user is remote and not leveraging VPN, the Lync 2010 client sends a SIP INVITE that contains the Lync-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 Lync-U1 and proxies connection to Singapore Lync pool (because this is where the user homed).

4) The Singapore client request MRAS credentials through the Singapore Front End pool.

5) The MRAS service on the Singapore Edge pool responds to the Front End pool request.

6) The Singapore Front End pool is responsible for sending the MRAS response to the client by sending a SIP 200 response through the Redmond Access Edge service.

Figure 2. Remote user retrieves MRAS credentials

Federated Onsite User Initiates Call to Remote User

1) The call is initiated by Lync-U2. Lync-U2’s Edge pool sends SIP INVITE information, which contains all the ICE candidates for the call, to the Redmond Edge pool. Redmond Edge pool contains the Access Edge service for the Singapore Front End pool (see Figure 3).

2) Lync-U1, the call recipient, sends back a SIP SESSION PROGRESS message that contains the call information and also sends ICE candidate information from the client, through the Redmond Edge pool.

3) The Partner Edge pool and Redmond Edge pool communicate with each other through STUN\TURN messages.

4) Audio flows between the two clients; and the caller relays media traffic through their Audio/Video Edge service.

Figure 3. Lync onsite user initiates a federated call to a remote user

SIP Call Trace with Lync Users in Audio/Video Session

When Lync-U2 makes a call to a Lync-U1, the call flow proxies between the two federated Audio/Video Edge services, through each organization’s Edge Pool. As a result, port negotiations must occur on each client, in addition to each Audio/Video Edge service. Figure 6 and 7 show this port negotiation process.

1. Lync-U2 initiates a federation call to Lync-U1.

Max-Forwards: 70

From: <sip:<Federated-user>>;tag=58856sw31a;epid=65v23rr8yy

To: <sip: :< Sing-remote-U1>@; tag=34442fg23s;epid=87g34tt3ds

Call-ID: a985djhg983r38c09x13wotr967gh0d0


Figure 5. Shows the call SIP trace (the example addresses that are used are included)

Note: The example IP addresses are used are included Figures 5 and Figure 6.

Local IP: (Singapore user)

Reflective IP: (Singapore user home router)

Relay IP: (Singapore Edge)

Relay IP: (Federated Partner Edge)

Figure 5. IP addresses used in the Lync call to federated contacts scenario

2. Lync-U2 and Lync-U1 both exchange candidate information that contains the available options for the federated Audio/Video call to take place. Since Lync-U2 is inside his Lync 2010 organization, he provides the relay address of the Audio/Video Edge public interface of his respective Edge pool. Lync-U2 initiates the call to the Lync-U1 and begins the ICE protocol connectivity checks to determine the best media path. In this case, the Partner Edge pool.

3. Lync-U2 and Lync-U1 exchange candidate information for each other in order to connect in the most direct route.

*Note: Candidates are possible combinations of available IPv4 addresses and randomly allocated TCP/UDP ports within the configured port ranges for the Lync client to use NAT traversal for media connectivity.

a=candidate:RRe1BuhxcvPEwFDgYqBzJ8nl2vntofS4rnotr2E8X1U 1 p3ws7tYJioXtyVwF1sQzqw UDP 0.780 2213

a=candidate: RRe1BuhxcvPEwFDgYqBzJ8nl2vntofS4rnotr2E8X1U 1 p3ws7tYJioXtyVwF1sQzqw UDP 0.780 2213

a=candidate:krclxLgIOPZ5uHpiert6Paa7GuZhoObH7645kR87fJw 1 vHMcdL8TfTYYplWUcT8Iaw TCP 0.165 52200

a=candidate: krclxLgIOPZ5uHpiert6Paa7GuZhoObH7645kR87fJw 2 vHMcdL8TfTYYplWUcT8Iaw TCP 0.165 52200

a=candidate:AVSbz17KXCCYJsVk1FEI6yds57P7hdS7Pz3unidon+0 1 U8jWmquvW+usL6V4dRpPFw UDP 0.560 57796

a=candidate: AVSbz17KXCCYJsVk1FEI6yds57P7hdS7Pz3unidon+0 2 U8jWmquvW+usL6V4dRpPFw UDP 0.560 51970

a=candidate:hZ1xn0LNerXwUYZcJBu0TKaeMVxn0YhYaO2xSgJIgSc 1 n3WhQS9pjzIxzKzSwIe3eQ TCP 0.410

a=candidate: hZ1xn0LNerXwUYZcJBu0TKaeMVxn0YhYaO2xSgJIgSc 2 n3WhQS9pjzIxzKzSwIe3eQ TCP 0.410

a=candidate:FAn6Pmwij+Fii87HpJ27MqlofGHD2iOwjO6pL+vKvd7 1 6MH8o37VC6WebAytJ/zqmw UDP 0.580 24123

a=candidate: FAn6Pmwij+Fii87HpJ27MqlofGHD2iOwjO6pL+vKvd7 2 6MH8o37VC6WebAytJ/zqmw UDP 0.580 24123

a=candidate: yX2cg9JJdeTuTERcJBu8OPwsKLxn0YhYaI2fShKlkCs 1 p4JhNB5jgdbvcKuRtIw4yU TCP 0.340 15172

a=candidate: yX2cg9JJdeTuTERcJBu8OPwsKLxn0YhYaI2fShKlkCs 2 p4JhNB5jgdbvcKuRtIw4yU TCP 0.340 15172

a=candidate:UYg3Nrtdc+Duu32IeX12CrkurCXZ1PgrT4eW+hTwe5 1 3MB5u46BB5ToiQkuT/weyq UDP 0.660 24123

a=candidate: UYg3Nrtdc+Duu32IeX12CrkurCXZ1PgrT4eW+hTwe5 2 3MB5u46BB5ToiQkuT/weyq UDP 0.660 24123

Figure 6. Call SIP trace

*Note: Figure 5 is part of the ICE protocol, the protocol that allows external clients to use NAT traversal for media connectivity. The ICE protocol candidates show local IP addresses, reflexive addresses in addition to relay IP addresses. The addresses are shown with pairs of TCP and UDP ports. These addresses are tried to test media connectivity between the Audio/Video Edge service and the Lync 2010 client on these respective ports.

4. Lync-U2 is the initiator of the call to Lync-U1 and begins the ICE protocol connectivity checks to determine the optimal media path which is the Partner Edge pool server. The process in Figure 6 shows the result of the candidate check and the identification of the Edge Server being used for the call.


a=candidate:33 1 UDP 2674893572 45856 typ prflx raddr rport 67439

a=candidate:33 2 UDP 2674893572 45857 typ prflx raddr rport 67440

a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:+IU8yrt89sE4hHGMLmn*Ioxs6EQgxCV/RerdMUY+|3^27|1:1

Figure 7. Call SIP trace (negotiated media protocol and ports)


The key takeaways from this scenario, when following call flows with Geographically Disbursed Edge Servers and federation, are as follows:

  • Access Edge is responsible for proxying SIP traffic for remote clients to the next hop, which can be a Director or a Lync pool.
  • During communication (IM/Conferencing/Audio/Video) with federated partners SIP is responsible initiating and tearing down all sessions. The Edge Server in each organization will establish a SIP sessions through the Access Edge service.
  • Remote users will communicate with a specific Edge Pool in the organization for SIP authentication.
  • There are three types of candidates.
    • Internal - The IP address assigned to the network interface of the client computer.
    • Reflective - The IP address of the public address assigned to the home router.
    • Media relay - The public IP address of the Audio/Video Edge service that is associated with the internal Lync 2010 user’s pool.

Lync Server Resources

We Want to Hear from You

Comments (6)
  1. AFAI: We require to publish DNS records for all edge pool public interfaces (edge/web/AV0 in Redmond. Have 2 Qs: 1. Apart from assigning public IPs to Singapore edge interfaces, any DNS records for external facing interfaces required?

    2. SIP traffic irrespective of which modality used flows always through Redmond edge and then media will traverse respective media edge. Is that right?

Comments are closed.

Skip to main content