Many challenges exist today when deploying edge servers across an organization that has multiple locations. Skype for Business Server 2015 has the ability to provide remote users (who are not using a Virtual Private Network (VPN) connection) the ability to take advantage of the rich features of Skype for Business Server 2015 just as if we were on the local network within the organization. The server role that allows this capability is the Skype Edge Server. It contains various services such as the Access Edge service, Web Conferencing Edge service, and Audio/Video Edge service. Each service will proxy data or media in different methods and destinations. This article will walk you through a scenario that explains these roles and the media that flows between Skype Edge Servers that are located in different locations for an organization, helping administrators and implementers to better understand what goes on under the hood.

Skype for Business Server 2015 Edge Role

Skype for Business Server 2015has specific server roles for different functions. They include the Front-End servers to service instant messaging (IM/presence, conferencing, audio/video, and so on). Skype for Business Server 2015 also has the Edge Server, which should be located in the perimeter network. The Edge Server allows organizations to remotely use IM/presence, conferencing, and audio/video without needing to use a Virtual Private Network (VPN).

As Skype Edge deployments become more nomenclature, having the ability to segment and localize remote user access traffic for IM, conferencing, audio, and video traffic is critical. It is important for administrators to understand the paths that protocols flow in various user scenarios; especially remote-to-remote scenarios.  In this article, we will walk through a scenario where two users are communicating within the same Skype for Business Server 2015 organization, but are doing so remotely through an Edge topology that consists of Edge Servers in different geographic locations.

Skype for Business Server 2015 Edge Server Protocols

Skype for Business Server 2015 has the consolidated Edge Server, which consists of the following services:

  • Access Edge: Protocol (SIP) for signaling purpose and is the basis of instant messaging.
  • Web Conference Edge: The Persistent Shared Object Model (PSOM) protocol provides services that are necessary for Microsoft Office Live Meeting 2007 conferences.
  • Audio/Video Edge: The Simple Traversal of UDP through NAT (STUN)/Traversal Using Relay NAT (TURN) protocol are used only to traverse firewalls and NATs.

Sample Environment

In this Edge Server environment design, Contoso has two data centers that are geographically separated: Redmond and Singapore. Each office is considered the primary user location for that particular region location. Each location has an existing Skype for Business Server 2015pool that has been deployed and is functional.

Redmond and Singapore each contain a data center that houses a Skype for Business Server 2015pool with an Edge Server that resides in the perimeter network for that particular data center. The purpose of this Edge Server topology is to allow remote users in Redmond and Singapore to collaborate with internal users in either pool with all modalities—IM/presence, conferencing, application sharing, and audio/video and to keep remote traffic regionalized if possible.

Scenario - Remote Skype to Skype Call in Different Pools

Two users who are homed in different Skype pools are planning to participate in a call with each other by using Skype 2015 client later in the day. User1 is located in Redmond (Red-Redmond-U1) and User2 is located in Singapore (Sing-Redmond-U1). Both users go home for the day and prepare for their call.

 Call Flow -Internals

1. (Red-Remote-U1) signs in to Skype to prepare for the conversation. He signs in to the Redmond Skype pool via the Redmond Data Center Access Edge role.  The Skype 2015 client sends a SIP INVITE that contains (Red-Redmote-U1) credentials to the Edge server via NTLM since the user is remote and not leveraging VPN. During the sign in process (Red-Remote-U1) obtains credentials from its home pool MRAS service in Redmond Edge pool to connect to the (Redmond Edge Server) Audio/Video Edge service.  This will allow (Red-Redmote-U1) to relay the media traffic if necessary on its homed pools edge server.

NOTE: In a Skype to Skype call with remote users, connectivity will try to be established from the reflective IP address of each user.  If not possible connectivity would be relayed through the public IP address of the Audio/Video Edge server of the user who initiated the call.

2. (Sing-Remote-U1) signed in to the Singapore Skype pool via the Redmond Data Center Access Edge role, which passes his initial SIP request to the Director, which determines (Sing-Remote-U1), is homed on the Skype pool in Singapore.  The Singapore Skype pool authenticates the users SIP request and (Sing-Remote-U1) is signed into Skype. During the sign in process (Sing-Remote-U1) obtains credentials from its home pool MRAS service from Singapore Edge pool to connect to the (Singapore Edge Server) Audio/Video Edge service.  This will allow (Sing-Redmote-U1) to relay the media traffic if necessary on its homed pools edge server.

3. (Sing-Remote-U1) and (Red-Remote-U1) both exchange candidate information for each other in order to connect in the most direct route.  

NOTE: As stated above the assumption here is both users are not able to connect in 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 Skype user. 

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 below; for the example the addresses that are used are included: (only the trace that coincides to this step is shown).

  • Local IP:
  • Reflective IP:
  • Relay IP:

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 most 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.

Note: When you configure your Skype 2015 pool in Topology Builder, you have an option to configure which Edge pool the Skype pool will communicate to. Because the Skype 2015 organization contains a single entry point (SRV Record) for remote access, it will be responsible for all SIP communication through the Access Edge Server(s) located in the Redmond Data Center.

Sample Environment 

The main takeaways from this article when deploying “Geographically Disbursed Edge Servers are the following items:

  • The Access Edge service is responsible for proxying   SIP traffic for remote clients to the next hop, which could be a Director or Skype Pool.
  • Topology Builder will allow an Administrator to select the respective Edge Pool for Skype Pool.
  • Skype clients will always try to communicate in the most direct path, which is peer to peer, but if not capable, the public interface of the home router and then the Edge server are leveraged.
  • The initiator of the call will broadcast multiple methods to establish the call to the callee.