Spotlight on Session Border Controllers – State of the Market and Outlook for 2021

My contributions to BCStrategies take many forms, and from time to time I’ll do a spotlight feature, usually focused on a particular technology that’s important to the collaboration space. This time around, the format is an executive Q&A, which I recently did with long-time industry colleague, Steve Johnson of Ingate Systems. Entering its 20th year, Ingate is an SBC pioneer, and Steve runs the North American operation, which accounts for some 80% of overall revenues. Here’s our conversation, and I hope you enjoy it.

---

Jon Arnold: Let’s start with some basics. Session Border Controllers – SBCs – have been in the market over 15 years, and are now indispensable for IP networks. Back in 2004, while at Frost & Sullivan, I wrote the industry’s first report on SBCs, and despite significant evolution since then, this space remains poorly understood. So, to begin, could you outline the role of an SBC and its key functions for enabling real-time communications?

Steve Johnson: An SBC is a device that connects to a network to seamlessly enable SIP communications (Session Initiation Protocol). SIP is the gold standard for secure enterprise-class real-time communications, including SIP trunking. While traditional firewalls block SIP traffic – including mission-critical applications like Voice over IP (VoIP) – the Ingate SBC resolves this problem, working in tandem with current security solutions.

An SBC is a border element in any network that enables, manages and controls real-time communications traversing and resolving challenges such as security, privacy, standards mismatching, interoperability, QoS assurance and many more value-added functionalities that go beyond what a UC/PBX platform or devices/client applications have been designed for.

As the industry has evolved, SBCs are now used to connect IP-PBX and unified communications (UC) systems to SIP trunks. SBCs are also used to provide UC systems with an easy and secure way to integrate remote endpoints, and even more in parallel to SIP mediation as, for example, adding other protocols’ intermediation for additional features (XMPP for presence, http/https/ftp for provisioning, desktop sharing, address books, etc.).

In addition, the SBC adds other important elements to the delivery of SIP. For example, the SBC can mitigate differences in expected SIP behavior between the IP-PBX and the service provider’s network, or IP-PBX and endpoint vendors. The SBC can also prioritize voice over data traffic to ensure optimal quality.

Since the SBC is positioned at the edge of the network, it is in a perfect location to monitor traffic, report on anomalies, provide diagnostics logs and assist the company in managing their SIP traffic as they do their data traffic. Providing hooks to feed time-series data will serve many purposes from the point of view of forensic analysis as well as service evolution planning.

Jon: SBCs can actually play a few roles, and it would be helpful to clarify the rationale for using them. Initially, they were developed for carrier networks, but our focus here is how enterprises are using them. So, for an IT decision-maker or a CIO, is the driver more about providing security for the network when using IP communications, or enabling the business to adopt new services and applications?

Steve: Based on the most recent interactions we’ve had with large customers, the key points of decision have been:

• Security/privacy (mostly in remote endpoints, but starting to be demanded also in trunking services)
• Seamless endpoint deployments (provisioning phones). This is a big area of attention as the ‘new normal’ of working from home is forcing corporations to find ways to just ship a phone to an employee’s home, and be plug-and-play.
• Easy integration of a non-hardware-based solution to work from home, which puts a lot of pressure to add WebRTC.

Security will always be a top priority. There are new threats to enterprises every day and we have seen an explosion of cyberattacks in the last several months. And as more people work from home, company concerns for attacks grow. The SBC can provide management with a means to control who and what is allowed into the network.

In this changing COVID-19 environment, our ability to help businesses adopt new services and applications – specifically, supporting remote workers – has become a key need for CIOs. For example, Ingate’s far-end NAT traversal (FENT) functionality, which lets remote workers access and use their business’ applications from their home, has been used by customers for about a decade.

Now that most every business has had to move to a remote worker scenario, the ability for an SBC to allow your VoIP phone to plug into your home internet network and work as if you were in the office, is priceless. We see this trend continuing into the 2021 and beyond as the paradigm of work changes radically.

Additionally, providing SBC functionality through the cloud has helped CIOs navigate the quick changes that have needed to be made as they’ve migrated (in some cases) large-scale workforces to working-from-home scenarios.

Jon: For businesses that are just starting to adopt IP communications – namely VoIP and SIP trunking – how should they be thinking about SBCs? What role will it play? Will it replace/displace existing network infrastructure? Will it be difficult to integrate with that infrastructure? What deployment challenges will they face?

Steve: The SBC will continue to play a pivotal role in the delivery of Voice-over-IP and other real-time communications. As we said above, the SBC offers security, interoperability fixes, support for remote workers, quality-of-service and diagnostic capabilities. In addition, the SBC can be used to easily provision phones and soft clients with the help of a configuration server.

The SBC is not going to replace the company’s firewall. That is not its job. The SBC will and does work in tandem with existing infrastructure to seamlessly bring SIP to the enterprise.

Jon: I’d like to touch on two specific challenges that must be anticipated. First would be interoperability with legacy phone systems – namely the PBX – as well as broader platforms like Unified Communications. Second would be protocol support. Not only are there many protocols for VoIP, but newer protocols like SIP aren’t fully standardized, so there are multiple flavors of SIP. For IP communications to work effectively, an SBC has to support all of this. How hard is this to do, and how well are these challenges understood?

Steve: Interoperability with the legacy PBX is a challenge we see frequently with SIP trunking, which is VoIP. For SIP trunking to work, the PBX must be interoperable with the SIP trunking service provider (ITSP). However, there are thousands of ITSPs. There are hundreds of PBXs. Oftentimes, we get calls from CIOs who say, “I have this PBX and just signed a contract for an ITSP and they don’t talk to one another. HELP!”

SBCs solve this problem. Ingate SBCs, for example, enable full interoperability between EVERY ITSP and EVERY PBX. No matter which PBX you have, and regardless of your ITSP, interop challenges can be smoothed out, and done so in a secure manner.

Indeed, one reason this is so challenging is because there are many variations of SIP. SBCs manage this. You can think of it as the SBC “translating” SIP to ensure that whichever one you happen to be using, your PBX, your VoIP phones, whatever equipment you have will “understand” your particular kind of SIP.

These challenges aren’t well understood, especially now that some of the larger PBX companies have acquired SBC companies. Frustrated CIOs call us all the time, thinking that they’re locked out from using any SBC other than the one sold by their PBX vendor. What if their SBC doesn’t support their ITSP? Or their phone? Or what if it’s just really hard to use? We’ve successfully worked the Ingate SBC into many of these kinds of deployments.

Jon: Let’s explore some of the important variations around SBCs. First would hardware vs. software – premises-based vs. e-SBC. This space started out being hardware-based, but we see both types in the market. How are they different, and what are the best use cases for each?

Steve: Today, they’re not very different at all. Hardware SBCs have limited capacity which is governed by their processing power. But they offer a dedicated device, which is optimized by the manufacturer to handle all of the voice and video traffic. To some this is a major advantage, because the SBC is not competing for resources if it were one of many applications on a virtual machine.

Software-only SBCs, for implementation on a virtual machine, place the hardware decision with the enterprise. The capacity may still be limited, and there may be competition of computing resources, but the virtual machine may be more powerful than anything the vendor offers, or has better failover capabilities in the case of a catastrophic failure. They are good in situations where the traffic patterns are well-known and the computing speeds can be specified.

We sell a lot of product into call centers, for example. They have very high throughput needs, with possibly hundreds of call agents and many thousands of customers trying to reach in at the same time. In these cases, a large hardware SIParator from Ingate is often the best choice, because it isolates the SIP traffic while offering many features to optimize the delivery in a high-demand environment. Call set-up rates and capacity can be easily specified and matched to the hardware SBC capabilities.

On the other hand, smaller companies with less demanding call scenarios would find a software-based SBC best suited to their budget by limiting the need for rack space in a colocation facility, and placing the software on a machine of their choosing. In some cases, this will go to outsourcing the implementation into a cloud service such as AWS or Azure, or to a managed service provider.

Jon: A second variation would be the architecture, where the SBC is built either on a media gateway – MGW – or a firewall. Both firewalls and MGWs have distinct capabilities, but neither can natively address what SBCs can do. In basic terms, how are these architectures different, and what are the inherent advantages of each?

Steve: There are some, but very few, integrated devices like that. Ingate is built on top of a firewall and in some cases the preferred deployment is with that configuration. We have often thought that firewall vendors should be looking to add SBC functions to their products, but we haven’t seen anything more than rudimentary attempts.

What makes our approach to SBCs unique is the fact that we change the order of how traffic should be qualified before deciding what to do with it. In other words, when Ingate is deployed as a device on the network edge (as a border element), the SIParator first identifies and qualifies whether it is a RTC service. If so, then it is treated as such. However, if it is not a RTC flow, then the customer can either decide to use all of the additional Ingate features for firewalling and QoS, or to simply use the features already built in the SIParator.

So, rather than a firewall with added SBC functionalities or layers for RTC (which is an approach that firewall vendors had taken without too much success), we have a core SBC engine with added functionalities and layers to add firewalling and QoS.

Jon: On a business level, enterprises want to benefit from today’s technology, and SIP telephony and WebRTC are prime examples. How well do they understand the role of SBCs here? To what extent do they think that core network elements like firewalls and MGWs will be sufficient to support them?

Steve: SBCs have been around for 15 years or more. But in a recent webinar we still hear very basic questions about the role of the SBC and why it is necessary if they have a firewall installed. The simple answer of course is that firewalls block SIP traffic and only an SBC can resolve the issue while maintaining security.

Firewalls have not been designed from the core to manage RTC and media-based services. That’s why SBC features has been very difficult for firewall vendors to add on top of their core engines.

Jon: Ingate has been in this market a long time, and that’s a reflection of how well you understand the SBC value proposition. You also have a good idea of where the market is going. How do you see SBCs evolving over the next few years? How far away are we from having all-IP networks, and at that point will there still be a need for SBC?

Steve: Unfortunately, we are a long way from having universal all-IP networks. There are many areas of the US and whole countries around the world that suffer from limited or even no bandwidth. Even in the most developed countries, the adoption of IPv6 has yet to replace IPv4. SIP remains a protocol with many variants. We are finding new requirements for voice-over-IP and video-over-IP in the days of the pandemic. What would life be like if we didn’t have the applications that we all use to work from home instead of the office? And a good part of that is reliant on the SBC.

I think the short answer is that SBCs will be around for years to come and will continue to evolve as the necessary element to make everything else work seamlessly. There should never be a fully integrated PBX that includes security, because if the security feature is hacked, the whole system will collapse.

Jon: To close out, based on your long perspective of this market, what should buyers be looking for in a technology partner for SBC? Where have their expectations been off the mark? Conversely, what’s the ideal type of customer for Ingate?

Steve: Buyers should be looking for a technology partner that’s been around for a long time and knows what is needed to make things work. Customers should also look for a technology partner that’s easy to work with, and a team that is genuinely invested in their success.

There is no “ideal” customer for Ingate. We have a wide product line with products to serve enterprises of any size, from the smallest with a need for only five concurrent sessions, to large call setup rates per second. Since our products can be used with every SIP PBX and every SIP service provider, our customers get full interoperability, along with flexibility and security. In our experience, we have come across most of the complex scenarios and can apply our knowledge, and the capabilities of the SIParator, to solve any customer’s problem, quickly, easily and competitively.