What is the role of the SBC in a cloud-first world? Microsoft and Zoom have built cloud-based UCaaS (unified communications as a service) phone systems that provide a reliable, and potentially, far less complicated (than their on-prem cousins) avenue for companies moving phone services to the cloud. Initially, these services offered companies both a “phone system” (such as Skype for Business) and connectivity to the Public Switched Telephone Network (PSTN) combined. However, recently both Microsoft Teams and Zoom Phone have begun offering companies an avenue to use their existing PSTN circuits via their Microsoft Teams Direct Routing and Zoom Phone’s Premise Peering (formerly Bring Your Own Carrier, BYOC) offerings using a Session Border Controller (SBC).
Session Border Controllers, and voice gateways, have been used in unified communications (UC) deployments for over a decade. SBCs allowed market-leading UC platforms like Skype for Business to interoperate with different PSTN vendors and PBXs and provide connectivity to various ports and protocols. As UC deployments began to use PSTN provided SIP (session initiation protocol) connections, SBCs role in the demarcation between the customer’s network and the carrier’s network became more important. As VoIP (voice over IP) vendors like Microsoft started transitioning their Skype for Business platform offering directly to the cloud (in the form of Microsoft Teams) and also began to offer PSTN services, the value-added role of the SBC became unclear or diminished to some.
The SBC Reborn
The resurgence of UCaaS for cloud phone systems, the overall push for a cloud-first digital workplace, and especially the COVID-19 pandemic — all of these factors and more have catalyzed the use of SBCs. Going forward, SBC’s are becoming more and more vital, especially in many parts of the world. A few reasons for this include:
- While both Microsoft and Zoom offer PSTN services in a few countries, they are not available in ALL or even a majority of countries. It prevents many multi-national companies from being able to migrate from an on-premises (such as Skype for Business) PBX system fully.
- Many PSTN providers offer better rates than either Zoom or Microsoft Calling Plans. While the ease of a single bill is appealing, it can also come with a higher price tag. Also, many companies may be in the middle of a contract, and the total expenditure of changing providers becomes cost-prohibitive.
- SBCs provide companies with the ability to integrate with existing voice systems; these voice systems may be on-premises PBXs, analog gateways, contact centers, and IVR systems. This integration also offers larger organizations the opportunity to migrate at a slower pace than a simple big bang cut-over.
Both Microsoft Teams Direct Routing and Zoom Phone’s Premise Peering give customers the ability to address these issues.
Direct Routing vs Premise Peering Comparison
So how are they the same? Unlike the Skype for Business on-premise model for working with an SBC, both Microsoft Teams Direct Routing and Zoom’s Premise Peering require specific licensing to enable this feature. Microsoft Teams requires a Phone System License, Microsoft Audio Conferencing License, and a Microsoft Teams + Skype Business Plan 2 license. Zoom requires a Zoom Phone license and a BYOC license. Both Microsoft Teams and Zoom require a public certificate and require that your SBC trust a specific certificate authority. For Microsoft Teams, you need to install the Baltimore CyberTrust Root certificate; for Zoom Premise Peering, you need to install the GoDaddy Root Certificate.
The most significant difference between configuring Microsoft Teams Direct Routing and Zoom Premise Peering is the interaction with Microsoft and Zoom. When configuring Microsoft Teams Direct Routing, it is entirely a self-service installation – add the licenses, setup your SBC, run the scripts in your Office 365 tenant, and you’re done. When configuring Zoom Premise Peering, you need to engage with a Zoom resource to coordinate changes on the Zoom side. While this Zoom interaction can slow down the process, it also provides a helpful guide to understanding the process. It provides direct contact to your organization for troubleshooting if a problem occurs during the installation.
The SBC Deployment Process
Directions for deploying and configuring Microsoft Teams Direct Routing are well documented and can be found on Microsoft’s website and detailed in multiple blog articles. We’ll save on blog length and purposefully skip any details regarding deploying SBCs for Teams. In general, based on experience, the PSTN provider configuration can be straightforward. However simple, though, even the most mundane of Skype for Business to Zoom or Teams migrations can’t leave out this critical step.
The SBC deployment process can also be a complicated and challenging configuration depending on your provider and type of connectivity. One area that many customers overlook relates to SBC is a security device. As such best practices dictate that SBCs need to be actively monitored, managed, and updated. We should also note that this article does not address the configuration with your existing PSTN provider.
Zoom Premise Peering Complexities for SBC
Overall, configuring Zoom Premise Peering is straightforward, especially if you have experience configuring SBCs. However, as you need to integrate with other systems, the configuration becomes increasingly complicated. The process for configuring Zoom Premise Peering is less documented. Based on our Unify Square best practice experience, here are a few high-level steps to configure Zoom Premise Peering are listed below:
- Ensure you have the appropriate licensing – as stated above, you need a BYOC license and a Zoom Phone license
- Configure your SBC to connect to Zoom’s Go Environment. It is a proof of concept type environment that Zoom uses to test your SBC connectivity.
- Work with Zoom to test your environment. This step verifies basic connectivity from your environment to Zoom’s environment.
- After successfully testing your SBC configuration, Zoom moves the configuration to its production SBCs. It typically happens during a change window in their environment. In addition, they enable the ability to add “External” numbers in your Zoom tenant.
- Update your SBC with Zoom’s production SBC’s IP addresses. As a note, at this stage, you will now no longer connect to the Go Environment. In addition, this is the step when you enable TLS in your SBC configuration. Typically, when you test in Zoom’s Go Environment, you test using only UDP.
- After receiving confirmation that Zoom has updated its production SBCs with your configuration, you can begin making Premise Peering calls in your environment. Be sure to do the following:
- Add your external phone numbers to your Zoom environment
- Configure users with the appropriate licenses and assign them phone numbers
The Future of SBC and UCaaS
The trend shows that more companies continue to move services and applications to the cloud. We expect to see the use of SBC hosted in either Azure or AWS as a typical deployment scenario by as early as 2021. Cloud hosting of SBC does remove the need for on-premises hardware but can raise security concerns if not correctly configured. Some PSTN vendors are beginning to offer managed SBCs using the vendor’s PSTN service. For example, this is an offering that both Verizon in the US and British Telecom in EMEA are beginning to rollout.
Unify Square has several solution offerings that can address the complexities of SBC architecture, deployment, and management and provide guidance for both Zoom and Microsoft Teams voice solutions. Our experience with helping companies transition from Skype for Business to new UCaaS systems and with deploying SBCs across various platforms will simplify your migration from an existing PBX platform to Zoom or Microsoft. In addition, our PowerSuite Cloud Manage Services offering will actively monitor and manage your SBCs and ensure they are updated and follow security best practices.