Skype for Business Server 2015 Geographically Dispersed Edge Topology (Part 2)

In Skype for Business Server 2015, 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 Skype for Business Server 2015 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 Skype users in different organizations, initiate a call to each other using Skype 2015. 

A Consolidated Edge Server delivers the following services:

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 Skype for Business Server 2015 pool.

Contoso’s data centers in Redmond and Singapore both contain a Skype for Business Server 2015 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 Skype for Business Server 2015 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 – Skype Call between Federated Contacts

In this scenario two Skype 2015 users, who reside in different Skype for Business organizations, decide to have an Audio/Video conversation using Skype 2015. Skype-U1 works offsite for Contoso. Skype-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 Skype –U1 and Skype-U2.

Remote User Authentication

1) Skype-U1 signs in to the Singapore Skype pool through Redmond Access Edge Server (Figure 1). Because Skype-U1 is remote and not leveraging VPN, the Skype 2010 client sends a SIP INVITE that contains Skype-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 Skype-U1 and proxies the connection to Singapore Skype 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 server role that can be deployed in a Skype for Business Server 2015 deployment. A common scenario where a Director is deployed is when security to the perimeter network is a concern andor 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) Skype-U1 signs in to the Singapore Skype pool through Redmond Access Edge Server (see Figure 2). Because the user is remote and not leveraging VPN, the Skype 2010 client sends a SIP INVITE that contains the Skype-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 Skype-U1 and proxies connection to Singapore Skype 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 Skype-U2. Skype-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) Skype-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 STUNTURN messages.

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

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

SIP Call Trace with Skype Users in Audio/Video Session

When Skype-U2 makes a call to a Skype-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. Skype-U2 initiates a federation call to Skype-U1.

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.

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

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

3. Skype-U2 and Skype-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 Skype client to use NAT traversal for media connectivity.

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 Skype 2010 client on these respective ports.

4. Skype-U2 is the initiator of the call to Skype-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.

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

Conclusion

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