SIP has been around since the late 1990’s, but confusion still exists regarding what it is and what it can do. Most old school telephony people realize that it changes the way we make voice and video calls, but after that their understanding is sketchy.
The confusion surrounding SIP is often greatest when it comes to the Session Border Controller (SBC). People know that it is part of a SIP solution, but they are unsure of exactly why. On top of that, even those that have an acceptable understanding of what an SBC is used for are still confused as to its placement in the network. Does it sit on the network edge or inside the DMZ? What is its relationship with a company’s existing data firewall? Can I split two SBCs between my geographically separated data centers? These questions stymie many experienced telephony managers and their staffs.
However, as important as those questions are, there is a very basic one that needs to be asked and answered first. “My SIP carrier has an SBC in their network. Do I need one, too?”
The simple answer is “yes,” but if you are like me, you require more than simple answers. So, in no particular order, here are my reasons.
I live in a gated community, but I still lock my doors
My home Internet is delivered by Comcast and I am positive that they have a firewall on their end. That doesn’t mean that my wireless router and many PCs don’t implement their own firewalls. Comcast’s firewall is designed to protect their network against anything running on mine. It’s not meant to protect me from all the nasty stuff that might be lurking out there on the Internet. That’s my responsibility.
The same holds true for an SBC. A SIP carrier will always have an SBC on their end of the network, but like that Comcast firewall, it’s there to protect the carrier against me. I want control over my own security and I am not about to trust that someone else may or may not protect me from the bad guys. My first line of defense needs to be an SBC that I own, maintain, and manage.
At its core, an SBC is a SIP firewall. It performs deep packet inspection to insure that only properly formatted SIP messages enter an enterprise’s network. It maintains a list of known “SIP viruses” (e.g. SIPVicious) and prevents them from wreaking havoc. It stops denial of service (DOD) and distributed denial of service (DDOD) attacks. It maintains a black list of IP addresses of known hackers. It monitors for failed login attempts. It prevents registration floods from bringing down your call server.
Again, you cannot look to your SIP carrier to perform those functions on your behalf.
Call Admission Control
Only you know the bandwidth configuration and usage of your network so it makes sense that an enterprise SBC perform call admission control (CAC) duties. These duties need to extend to all forms of communication. A high definition video call will consume significantly more bandwidth than an audio call. An enterprise SBC can ensure that call quality remains high regardless of your chosen form of communication.
Network Address Translation
The world ran out of IPV4 addresses a long time ago and nearly every enterprise uses a large number of private IP addresses and a very small number of public IP addresses. Since IP addresses are embedded inside SIP messages, you need something to map these private addresses to a small pool of public addresses. This network addresses translation (NAT) can be performed by your enterprise SBC. Without a NAT element, SIP communication outside the bounds of your network is impossible.
I deal with medium to large enterprises on a daily basis and it’s rare to find one that isn’t a hodge-podge of communications systems, software versions, applications, and trunk providers. Sadly, even though SIP is “a standard,” there are a number of variants and interpretations that make interoperability much more difficult than it should be.
SBCs offer adaptation tools that manipulate SIP messages into forms that different vendors and products require. This allows Cisco to speak to Avaya to speak to Nortel to speak to AT&T.
For more on adaptation, please see my blog, SIP Adaptation.
We’ve all called into a contact center and heard the words, “This call may be recorded for quality purposes.” In the TDM world, you typically had to have special hardware to tap into a trunk and split the audio into two different paths. A number of SBCs do that in software making them the perfect spot to implement call recording.
Would a SIP carrier want to get into the business of recording your calls? I think not.
With distributed and high availability SBC configurations, you can ensure that your employees are able to communicate during equipment and network failures. Properly installed SBCs keep your business up and running if and when disaster strikes. You cannot guarantee that with carrier-based SBCs.
Transcoding is like language translation and is required when you have two different communications elements that want to interact, but don’t have a common form of speech. For instance, you might need to transcode from H.323 to SIP. You might also have the need to transcode codecs – e.g. G.729 to G.711. Other transcoding opportunities include IPV6 to IPV4, SRTP to RTP, and TLS to unencrypted SIP.
I am sure you’ve figured out the pattern already, but many SBCs perform all or most of these forms of transcoding.
Remember that hodge-podge of communications systems and applications that I constantly run into? An enterprise SBC can also help your enterprise route SIP sessions between them. A common case would be to have one ingress/egress point for SIP trunks that is distributed amongst a number of disparate SIP PBXs. Centralization of resources not only makes maintenance easier, but it saves money by eliminating duplication.
There may be other reasons why you need your own SBC, but these are the big ones. In future blogs I will tackle the unanswered questions I raised at the start of my missive, but this should be enough for today. Even I can only handle so much tech talk before my eyes start to glaze over.