As we discussed previously, session border controllers perform a variety of functions, including providing security and interworking between different flavors of SIP (Session Initiation Protocol), transcoding to enable unified communications equipment to work with legacy gear, and more. With so many functions to consider, what are the most important aspects to look for when choosing an SBC?
Architecture is Crucial to SBC Performance at Scale
Given the various functions an SBC performs, you need to look at its underlying architecture to make sure it can perform them all well, all at the same time and even under extreme loads.
Consider security, which is one of the main functions an SBC provides. A key security function is protecting against rogue packets and denial-of-service (DOS) attacks. DOS attacks can take multiple forms, including sending malware to try to crash a Unified Communication application server, or just flooding a network with packets such that routers get overwhelmed. An SBC can protect against all of these attempts, at least in theory.
“When looking at an SBC remember that each additional feature requires more CPU,” explained Mykola Konrad, VP of Cloud and Strategic Alliances for Sonus Networks, Inc.. “You need to make sure it’s architected correctly so it can handle all these functions while still providing the performance you need.”
If you need your SBC to handle, say 1,000 simultaneous calls, you have to make sure it can do that with all of the features you may need turned on, such as encryption, lawful intercept, call recording and transcoding. Many customers purchase an SBC with one task in mind and then start adding features to it as their business and needs evolve. So ask your SBC vendor how many calls it can handle under such conditions – and whether there are any caveats.
Considerations for Virtual SBCs
By the same token, if you prefer to go with a virtual SBC, you need to make sure it can perform the functions you want on the hypervisor you need at the scale you require. “If it’s a software-based SBC on VMware, has the vendor made sure it can handle denial of service protection at scale?” Konrad says. “That’s a hard problem to solve.”
A number of SBC vendors can handle DOS and other attacks on the appliance versions of their products but struggle to do the same with the virtual versions. Again it gets down to how the tasks are architected in software, he says.
The Sonus virtual SBC, for example, has a specific software thread running on its own processor that’s dedicated to DOS monitoring and protection. “If you didn’t architect it that way and have just one thread doing DOS plus normal SIP interworking functionality, you’d have an issue,” Konrad says.
Dedicating different threads to different functions also makes it possible to configure how much processing power you want to dedicate to each one. For example, perhaps you want to give the DOS thread 80% of the virtual CPU while call processing gets 20% and scale it back and forth until you hit on the right combination. “If the virtual SBC is not architected properly, it’s very difficult to do that,” he says.
Beware the SBC that Requires ‘Extras’ to Perform Various Functions
Finally, some SBCs require that you buy different add-on modules depending on the exact functions you want. Others have all the features built in, and you simply buy the license for what you want and turn them on. The former obviously requires more work on IT’s part, between ordering and installing the modules. Nobody needs more work, so it’s a good question to ask.