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).
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.
- Access Edge service: Manages SIP traffic signaling and instant messaging.
- Web Conferencing Edge service: The Persistent Shared Object Model (PSOM) protocol enables conferences.
- Audio/Video Edge service: The Simple Traversal of UDP through NAT (STUN)/Traversal Using Relay NAT (TURN) protocols traverse firewalls and NATs.
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.
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.
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.
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.
3) Redmond Director authenticates Skype-U1 and proxies the connection to Singapore Skype pool (because this is where the user is homed).
*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 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) 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.
3) Redmond Director authenticates Skype-U1 and proxies connection to Singapore Skype pool (because this is where the user homed).
5) The MRAS service on the Singapore Edge pool responds to the Front End pool request.
Federated Onsite User Initiates Call to Remote User
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.
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
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.
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
3. Skype-U2 and Skype-U1 exchange candidate information for each other in order to connect in the most direct route.
*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.
Conclusion