[Post is better viewed on the blog Website]
In the early days of SIP, I was working on VoIP protocol stacks at Radvision. As part my role there I used to attend many of the IETF meetings and SIPit interoperability events. The standards where the holy grail and we were a bit naïve in assuming that everyone would be implementing the standard and nothing but the standard…and networks and products would interconnect easily.
The SBCs Come to life
In those days, almost 15 years ago, new startups that focused on something they called a Session Border Controller (SBC) were coming to life. Later down the road of VoIP deployment, more established companies adopted this concept.
I remember a panel at one of the VON shows in which I came out against this trend. At the end of the day, I said, every single SBC function is handled by the standards. As long as the VoIP community will follow the standards, life will be good and simple.
I guess it is needless to say that the world of VoIP is more complex than simply implementing the standard. The reality is that networks and products usually don’t interwork without a special effort to make this interworking possible. There are 2 fundamental reasons for this:
- Standards are complex, very detailed with multiple options, and many times companies interpret them differently
- Companies want to add their special secret sauce into their products and sometimes, due to technical or commercial reasons, they implement some of the functionalities in a proprietary manner
Regardless of the reasons this is the reality. The naïve position of the past didn’t pass the reality check of real life.
The business communications angle
VoIP is deployed in many enterprises and service providers’ networks, yet there are still many enterprises and SMBs that are not connected to VoIP services. Taking a closer look at those already using VoIP in the enterprise or receiving such a service from their service providers, we see several common characteristics:
- Not all branches use the same PBX. This is due to acquisitions or changes along the life of the network that were not implemented across the board
- A hosted service was added servicing some of the branches, requiring the connecting of the on-premise PBX and phones with the hosted service network
- A unified communications service such as Microsoft Lync was added in addition to the existing telephony system requiring the connection of the 2 networks together
- Survivability needs and local PSTN termination require an on-premise “box” to provide these capabilities
Each one of the points above introduces complexity and a mix of standard and proprietary (or as some vendors call it, “SIP like” or “in the spirit of SIP”). As this phenomenon is the reality of today’s business networks, a smart mediation box is required to connect between the different elements and support these requirements.
What is special about the SBC that makes it the “Swiss Army Knife” of VoIP?
An SBC is like a Swiss Army Knife as it handles many functions. It is well aware of the specific environment in which it is deployed and typically has a flexible configuration that allows adapting it to the specific deployment environment. On the other hand, SBCs are also known for complex configuration due to their complex functionality. As such, a configuration wizard that contains various vendor product profiles for automatic and easy configuration of the SBC for specific deployment scenarios comes in handy for simplifying SBC configuration.
A typical SBC would have the following functions:
Mitigation & connectivity – connect between different PBXs and different hosted services, connectivity with different SIP trunk providers.
Security – detect security threats such as denial of service, call theft and eavesdropping and protect the network from them. The SBC may also perform encryption/decryption functions to force a policy requiring all outbound traffic to be encrypted.
Quality of Service – the SBC monitors call quality, reports on issues and may enhance quality through media manipulation
Routing & policy enforcement– making sure calls routed based on the enterprise policy-based on user identity & privileges, call termination cost, quality requirements and network conditions
Regulatory compliance – route calls to recording services
The list of functions above is a general and non-exhaustive list. Naturally, there are different functionalities required depending on the type of the SBC, be it an access SBC or an enterprise SBC.
In conclusion, if in the past there was a debate about the need for an SBC, today SBCs are found in most deployments, on-premise as well as in hosted services, providing functionalities such as security and resiliency. Moreover, the SBC is included in many of the architectures defined in the standards.
Image credit: Flickr user Hiking Artist