Before I can answer that, I should probably explain what a Session Border Controller (SBC) is and what it brings to the party when deploying SIP Trunking. An SBC can be either a physical or virtual device which sits between your network and the Internet Telephony Service Provider (ITSP). It is basically the point of demarcation between your phone system and the ITSP. If you think about it in the form of old school telecoms, it is the equivalent to your ISDN gateway. A session border controller has 3 main jobs (it does do more!):
- Network Address Translation (NAT) Traversal
- SIP Interoperability
As the name suggests, “Board Controller”, it sits on the border of your network. It typically will manage the authentication to the ITSP. Some SBC can be a firewall as well as an SBC, (out of the scope of this post).
You should expect the following from your SBC:
Near-end NAT traversal for connecting SIP communications between an enterprise and a carrier
· Dynamically open and close the media ports (both voice and video on both UDP and TCP ports)
· Encryption for both media and signalling (the ITSP will need to support this as well)
· Authentication and registration with the ITSP
· Access control
· Intrusion Detection/Prevention Systems (IDS/IPS) functionality
On a slight side note, telephone fraud has been around long before SIP. SIP now gives those naughty people the chance to hack your phone system with out even picking up a phone. The most famous tool for this is SIPVICIOUS. I installed a sip trunk for a customer within the last few weeks, within a day of the customer providing the SBC with a public address, I saw SIPVICIOUS attacks. This was not a concern as I had a SBC with IDS/IPS enabled.
SIP as a protocol is absolutely hopeless when it come to NAT. Typically when an IP packet leaves your network for the Internet, your firewall will NAT it. So it will change the source address from the internal IP address to your public IP address and when your firewall receives a response, it will change the destination IP address back to the original source internal IP address. A little confusing, but this diagram explains it better! It shows how NAT is applied to a typical packet leaving a private network destined for a server on the web.
So the problem with SIP, is that the packet’s payload also contains IP addresses, for example of the users telephone. The packet will reach the ISTP as it was NATed, but the data within the packet still has the internal IP address of the users phones, so the ITSP has no way of routing the media back the user’s phone. This typically results in a one way audio call.
So what a Session Border Controller does, is opens all the SIP packets and rewrites the content, so it still makes sense when the far end receives it. Depending on the SBC deployment model, the diagram below is a little over simplified as the SBC should have its own IP address. I decided to miss this out as the diagram does show in essence what an SBC does for NAT transversal and it was getting very busy!
You may ask why do we need to Interoperability? SIP is a standard, right? Well wrong! SIP is an RFC. (to be more precise RFC3261). Wikipedia says
“A Request for Comments (RFC) is a type of publication from the Internet Engineering Task Force (IETF) and the Internet Society, the principal technical development and standards-setting bodies for the Internet.
An RFC is authored by engineers and computer scientist in the form of a memorandum describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.”
So now I’m guessing you’re asking why do we need Interoperability when the RFC is describing methods and behaviours? Well. that is a good question! The RFC details many methods, for example to transfer a call you have a couple of methods to pick from. You can use the refer method or the redirect method. However it is not uncommon for PBX vendors and ITSPs not to support both of them.
So the SBC has a profile of what the PBX will accept and what the ITSP will accept and can rewrite the SIP packets to conform the PBX and ITSP take on SIP.
SBC can also do the same for codecs. If the ITSP and the PBX do not have a Codec in common, the SBC can help with is too. However I have never needed this, G711 is typically excepted everywhere!
Other functions you get from your SBC are:
- Quality of Service (QoS) tagging on your voice traffic
- A whole range of logging and Call Detail Records (CDR) (call reports etc), typically via a radius server.
- Call Control – control bandwidth usage over you WAN
- Low cost routing – If you have several SIP Trunks throughout your organisation
So do you need a Session Border Controller when deploying SIP Trunks?
The answer is it depends! Can your ITSP provide you with a SIP Trunk without NATing? They might be able to if they are your WAN provider as well. In this case and there is no SIP interoperability issues between you and the provider and you trust them enough not to add your own security, then technically no you do not need one. In all other cases I can think of, the answer is yes, you do need a SBC.
However in the case where you do not need a SBC, with all the benefits listed above, Why wouldn’t you? It does add some cost to the product, but this is small in the scheme of your SIP trunking project. Also you don’t always need to purchase an SBC, some phone systems come with their own built-in and I have seen some providers within the UK and USA which provide their own SBC on your site.
Hope this helps, basically you might not need a SBC, but you sure do want a SBC when deploying SIP Trunks. If you have any questions, please feel free to use the comments below.
For information about methods of deploying an Session Border Controller and SIP Trunking, check out my post on SIP Trunking