Five reasons you should add an SBC to your IP network

We consider session border controllers (SBCs) to be a best practice in most enterprise contexts because of the improved security, control and overall VoIP system functionality they lend.

So what exactly are SBCs and why do you need one?

Session border controllers were originally developed to address some of the shortcomings of SIP (session initiation protocol) standards, and have since evolved to handle a rather broad range of IP network functions. The primary purpose they were created for was NAT traversal, or allowing media sessions to be established between user agents placed behind network address translators (NATs), since the SIP standards ignore the existence of NATs. SBCs also perform services that improve SIP interoperability, connectivity, security, quality of service, regulatory compliance, and media (data) administration.

SBCs are versatile devices that are used by different operators and enterprises for different objectives. Within an enterprise context, SBCs are commonly referred to as enterprise session border controllers or eSBCs. The most common implementation is that of a back-to-back user agent (B2BUA). A B2BUA sits in between the calling and called parties in a VoIP (voice over Internet protocol) call or media session. On the side facing the user agent client (UAC), it acts as a server, and on the side facing the user agent server (UAS), it acts as a client.

In this position, it is able to regulate and improve the flow of signals and media. Five of the most common functions include:

1. NAT traversal
   Nowadays, most SIP phones support NAT traversal protocols like STUN, TURN, ICE, or Universal Plug and Play (UPnP), in which case NAT traversal can be accomplished without an SBC. When using an SBC for NAT traversal, the SBC generally acts as the public interface of the user agents by replacing the user agent’s private IP address with its own in the contact headers of the SIP messages.
   
   This also adds network security through topography hiding: since outsiders can only see the SBC’s IP address, they cannot detect the other devices behind it.
   
   There are some limitations of using SBCs for NAT traversal of media, however. One is that it only works with “symmetric” clients that use the same port for sending and receiving media packets. Fortunately, this is the case for most equipment on the market, so it’s not normally a problem. Keep in mind that this symmetry involves two outbound and two inbound paths per VoIP call, which requires more bandwidth – although not generally enough to be an issue in this day and age. Phones are different by manufacturer and we normally tell our dealers to expect anywhere from 80 kbps to 120 kbps bandwidth usage per phone, regardless of the presence of an SBC.

2. Interoperability mediation
   
   SIP standards are open to interpretation, and not all developers interpret them the same way. This creates compatibility issues between devices of different manufacturers, even if they are all “SIP compliant.” That’s where SBCs can help. They can do things like remove or add headers, modify SIP extensions, adapt call flows (like send messages one side is expecting but the other doesn’t emit), change the order of information, add or remove tags, or tweak authentication so that different network components receive information in the format they expect. Similarly, SBCs can translate between incompatible transport protocols, for example if one component uses TCP and the other uses UDP.

3. Security
   
   SBCs can perform a number of security functions by functioning as a gatekeeper or firewall to the local network. For example, they can enforce traffic limits to protect against distributed denial of service (DDoS) attacks or network overload. They can also keep dynamic blacklists where user agents whose incoming requests meet certain criteria are automatically added to the block list. SBCs can perform deep packet inspection to verify content integrity and maintain lists of known SIP viruses so they can be detected and kept out.
   
   SBCs also perform caller prioritization, so only calls from registered users are accepted in cases of network overload. They can also track call usage and user behavior over time to detect and prevent fraudulent use of the network.

4. QoS (quality of service)
   
   SBCs can implement rules for managing data traffic and the prioritization of voice packets, bandwidth management and resource allocation, and call admission control, all for the purpose of improving the quality and reliability of voice transmission.
   

5. Media transcoding
   
   SBCs also handle media transcoding. Different components don’t always use the same codecs, protocols or compression formats, so transcoding is necessary to allow them to communicate with each other. An example might be translating H.323 to SIP, or the G.729 codec to G.711.

The other side of the coin

Even with all of its features and benefits, SBCs do have issues of their own. The B2BUA deployment breaks up the peer-to-peer pathway between the caller and callee, lengthening the media pathway and adding latency to the network.

This also means that the SBC, in order to mediate between the two parties, needs to understand all of the received messages. So, new updates to SIP involving call flows, headers and the like may not be able to be deployed without upgrading the SBC.

Thirdly, inserting an SBC in between the endpoints adds complexity to call monitoring and quality assurance and may make troubleshooting more difficult.

So, do you need an SBC?

In most enterprise contexts, we consider the benefits of improved security, control and overall system functionality that SBCs provide to outweigh any concerns about added network latency or complexity. Without an SBC in place, we advise that you:

• Only purchase SIP endpoints that support NAT traversal
• Subscribe to a DDoS protection service and maintain a rigorous network firewall
• Buy all of your communications hardware from the same manufacturer and, where this is not possible, be sure their interoperability has been tested before installation
• Refrain from placing any device on the public network and limit the number of open or forwarded ports to your local network. VPNs may be a good alternative for installations without an SBC in place

CONCLUSION

All told, SBCs are a net benefit to most IP networks. Click here to see session border controllers available through TeleDynamics.

You may also like:

Implementing VoIP safely and efficiently on the network edge