Discontinuation of Session Border Controllers in O365 and Why You Should Care

Microsoft announced today the Discontinuation of support for Session Border Controllers in Exchange Online Unified Messaging. This article is meant to explain what this means and why it's such a big deal.

UPDATES:

• Option 3, using TE-SYSTEMS anynode, is no longer a Microsoft recommended option.

• On April 24th Microsoft extended the date to remove SBCs from Office 365 to April 30, 2019, based on user feedback. This is only an extension. They have no intention of supporting SBCs after that date.

Session Border Controllers (SBCs) are used to route SIP-SIP traffic. They act as two-legged single-purpose firewalls, used only for SIP traffic. SBCs are usually deployed in the DMZ, where one interface faces the internal network (gateway/PBX) and the other faces the Internet (Office 365). They are required for all PBXs except Lync Server and Skype for Business to connect to Office 365 for voicemail or cloud PBX. Two SBCs are required for this communication, one on-prem and another Microsoft-owned SBC in Office 365. ß This is what is being retired.

VOIP gateways are needed when a legacy TDM-based PBX does not speak SIP. They translate TDM (PRI) to SIP. A SIP trunk connects the VOIP gateway to the SBC in DMZ.

Customers have one or more of the following types of telephone systems that link to Office 365 for voicemail:

3rd party TDM-based PBX (analog)
Examples include Avaya, AT&T Merlin, Nortel. Requires a voice gateway and SBS to connect to either Exchange UM or EXO UM.

3rd party IP-based PBX (digital)
Examples include Cisco CallManager. Requires an SBS to connect to either Exchange UM or EXO UM.

Lync Server/Skype for Business
Makes an authenticated federated call to the Lync Online service.

An Office 365 customer must create an IP Gateway in the tenant for SBC connectivity to Office 365. This creates a public DNS entry that looks like [GUID].um.outlook.com that maps to the SBC in Office 365. There will be one for each customer, but all on-prem SBCs connect to the same IP Gateway address, so the actual number of SBCs is really unknown.

UM Gateway in Exchange Server

The number of customers utilizing SBCs to connect to Office 365 may be small according to Microsoft, but these are usually very large customers with many SBCs. Once customers settle on a connectivity solution they continue to invest and expand on it. That's why it's such a big deal, especially for these customers.

According to today's announcement, the Office 365 SBCs are scheduled to be decommissioned in July 2018. If you're one of the customers who rely on SBCs to connect your on-premises PBX to Office 365 for Exchange UM or Azure voicemail, you have till then to make a change. As the article states, you have four options:

• Option 1: Complete migration from 3rd party on-premises PBX to Office 365 Cloud PBX.
• Option 2: Complete migration from 3rd party on-premises PBX to Skype for Business Server Enterprise Voice on-premises.
• Option 3: For customers with a mixed deployment of 3rd party PBX and Skype for Business, connect the PBX to Skype for Business Server using a connector from a Microsoft partner, and continue using Exchange Online UM through that connector. For example, TE-SYSTEMS’ anynode UM connector can be used for that purpose.
• Option 4: For customers with no Skype for Business Server deployment or for whom the solutions above are not appropriate, implement a 3rd party voicemail system.

Options 1, 2, and 4 are pretty well understood, but not trivial. Option 3, the anynode UM connector, requires a bit more explaining.

The anynode Skype for Business Voicemail Connector is a software SIP-to-SIP SBC solution that uses the Microsoft Unified Communications Managed API (UCMA) to communicate directly with Skype for Business Enterprise Voice. It's available from a German software company called TE-SYSTEMS (kind of reminds me of Geomant MWI for Exchange 2007 - anyone remember that?) This is great if your PBX already does SIP, but a number of large customers have analog PBXs in one or more locations. Traditional SBCs can convert analog PSTN calls to SIP using a Voice Gateway feature, and then trunk it over to Skype for Business or Skype for Business Online.

I can understand why Microsoft is discontinuing their SBCs in Office 365. It makes them rely on a third-party system that's sometimes difficult to manage. And after all, Microsoft is in business to sell services like Skype for Business and cloud PBX. But forcing customers to plan for and deploy all-new phone systems, SBC solutions, or voicemail systems in one year is asking a lot. Especially for the size of the customers they're affecting.

So what do you think? Will this tactic make you go "all in" for cloud PBX, as Microsoft hopes, or will it drive you toward one of the other solutions? Either way, you better get started now.