What does the new announcement regarding Skype4B online ports mean anyway?

So you might have seen the recent announcement regarding Skype for Business online port requirements changing, if not take a quick stop by Thomas Binder’s article over on the MS Tech Community.

 

First off, this change only affects users homed in Skype for Business Online (IE, Office365) So if you’re running an On-Prem or Hybrid deployment move on unless you want to learn a little bit about ICE TRUN and STUN

Okay, but what did those ports used to do, and what do they do in a hybrid or On-Prem deployment.

They are used as part of the Interactive Connectivity Establishment (aka, ICE) features of Lync/Skype4B

I’m not going to go too in depth with what ICE, and more specifically STUN and TURN protocols do, mainly because Jeff Schertz has a brilliant article on it back from 2012 and its still relevant today. (Take a bow Jeff) Thomas Binder, the writer of the Office365 announcement also gave a Teched session a few years back talking about it, so if you really want some info it’s all there.

We’re going to discuss what these ports are used for in an on-prem environment and why they are needed despite the firewall administrators distain.

When establishing a Peer to Peer call, such as a voice or video call between 2 parties. Lync and Skype for Business will always try to take the most efficient path for the media packets possible. For the sake of simplicity were excluding discussions on enterprise voice, media bypass and CAC. Multiparty calls involve the  AVMCU on the frontend so that’s excluded as well.

Anyway, when 2 users who are external to the Skype for Business deployment attempt to call each other, their clients typically cant communicate directly with each other as they are behind NAT firewalls. So when User A calls User B the first and most preferred connection method “direct” fails as they are in non-routable networks

Lync and Skype for Business then kick in the next method to connect, “Session Traversal Utilities for NAT” STUN. Using the Edge Server to discover the Public Address of each client. Some more magic occurs to open up holes in the NAT table on each NAT Firewall to try and allow them to communicate directly with the Edge Server facilitating the transfer of information between clients.

In some cases, the NAT type of the external routers prohibits this connection due to a whole bunch of stuff I’m not getting into here. So Lync and Skype for Business fall back to “Traversal Using Relay around NAT” aka, TURN (Someone really wanted these acronyms to sound cool)

It does this by hair-pinning the media through the edge server using unique ports for each media stream, then each of the clients make outbound connections to the edge server on their assigned ports, thus mitigating any NAT issues.

The main reason we need different Ports on the Edge Server is to track multiple connections from the same Public IP (although, in theory these should be direct calls… damn those security guys!

The disadvantages of this method is that we need a bunch of available ports to track each of the connections and we add extra latency into the media path.

 

So what about the new solution with Office 365?

Well, I can’t say for sure as I’m not a 365 engineer, but for TURN traffic I assume the new method is to use either multiple edge servers and track connections via sending them to different IP addresses, forwarding media between the edge servers as appropriate.

 

Something like this. (Note: This is pure conjecture)

So okay, you have been going on for this for ages, what does all this actually mean.

Well. Like Thomas’s article said, you don’t need to allow access from your Private Lan to the Office365 infrastructure on ports 50,000  through 59,999

 

I hope this interests someone, articles like this do take a while to write so please leave a comment or question below.