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:
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.
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.
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
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
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
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>@Litware.com>;tag=58856sw31a;epid=65v23rr8yy
To : <sip: :< Sing-remote-U1>@ Contoso.com; tag=34442fg23s;epid=87g34tt3ds
Call-ID : a985djhg983r38c09x13wotr967gh0d0
CSeq : 1 INVITE
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: 18.104.22.168 (Singapore user)
Reflective IP: 22.214.171.124 (Singapore user home router)
Relay IP: 126.96.36.199 (Singapore Edge)
Relay IP: 188.8.131.52 (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 184.108.40.206 2213
a=candidate : RRe1BuhxcvPEwFDgYqBzJ8nl2vntofS4rnotr2E8X1U 1 p3ws7tYJioXtyVwF1sQzqw UDP 0.780 220.127.116.11 2213
a=candidate :krclxLgIOPZ5uHpiert6Paa7GuZhoObH7645kR87fJw 1 vHMcdL8TfTYYplWUcT8Iaw TCP 0.165 18.104.22.168 52200
a=candidate : krclxLgIOPZ5uHpiert6Paa7GuZhoObH7645kR87fJw 2 vHMcdL8TfTYYplWUcT8Iaw TCP 0.165 22.214.171.124 52200
a=candidate :AVSbz17KXCCYJsVk1FEI6yds57P7hdS7Pz3unidon+0 1 U8jWmquvW+usL6V4dRpPFw UDP 0.560 126.96.36.199 57796
a=candidate : AVSbz17KXCCYJsVk1FEI6yds57P7hdS7Pz3unidon+0 2 U8jWmquvW+usL6V4dRpPFw UDP 0.560 188.8.131.52 51970
a= candidate:hZ1xn0LNerXwUYZcJBu0TKaeMVxn0YhYaO2xSgJIgSc 1 n3WhQS9pjzIxzKzSwIe3eQ TCP 0.410 184.108.40.20615172
a=candidate : hZ1xn0LNerXwUYZcJBu0TKaeMVxn0YhYaO2xSgJIgSc 2 n3WhQS9pjzIxzKzSwIe3eQ TCP 0.410 220.127.116.1115172
a=candidate :FAn6Pmwij+Fii87HpJ27MqlofGHD2iOwjO6pL+vKvd7 1 6MH8o37VC6WebAytJ/zqmw UDP 0.580 18.104.22.168 24123
a=candidate : FAn6Pmwij+Fii87HpJ27MqlofGHD2iOwjO6pL+vKvd7 2 6MH8o37VC6WebAytJ/zqmw UDP 0.580 22.214.171.124 24123
a= candidate: yX2cg9JJdeTuTERcJBu8OPwsKLxn0YhYaI2fShKlkCs 1 p4JhNB5jgdbvcKuRtIw4yU TCP 0.340 126.96.36.199 15172
a=candidate : yX2cg9JJdeTuTERcJBu8OPwsKLxn0YhYaI2fShKlkCs 2 p4JhNB5jgdbvcKuRtIw4yU TCP 0.340 188.8.131.52 15172
a=candidate :UYg3Nrtdc+Duu32IeX12CrkurCXZ1PgrT4eW+hTwe5 1 3MB5u46BB5ToiQkuT/weyq UDP 0.660 184.108.40.206 24123
a=candidate : UYg3Nrtdc+Duu32IeX12CrkurCXZ1PgrT4eW+hTwe5 2 3MB5u46BB5ToiQkuT/weyq UDP 0.660 220.127.116.11 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 18.104.22.168 45856 typ prflx raddr 22.214.171.124 rport 67439
a=candidate:33 2 UDP 2674893572 126.96.36.199 45857 typ prflx raddr 188.8.131.52 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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.