Session Boarder Controllers are very misunderstood creatures in the network world. These highly evolved devices fill a gap in the network that has arisen with the invention of the SIP trunk. While SIP trunking as given the world the ability to escape the confines of the old telecom world T-1s and PRI it has also been an area of security concern. The Session Boarder Controller provides us the ability to better leverage SIP trunking, it also gives us a way to do it securely.
A SIP trunk is a network data connection to the carrier that can be a MPLS connection, an Internet connection or both. These connections are considered data not voice so they tend to be cheaper to buy and maintain. The carrier sends calls to the end customer PBX via a SIP session these sessions have the call connection information and audio payload. These sessions use a small amount of the circuit’s bandwidth (29-84Kbps) and the carrier can put as many sessions on the circuit as the bandwidth will allow. These sessions can be scaled individually so users are no longer locked to 23 or 24 channel divisions to scale. Because of the granular scaling and the generally lower cost of the data circuit SIP trunking is expanding exponentially in the communication world.
So having a SIP trunk is great but everything it has a down side and for SIP trunking that down side is security. When customers first started with SIP trunking the people handling them were the telecom admins and they saw these circuits as a different form of voice connection so they just brought in the connection directly to the network the PBX was on and all was great. That was until the network security audit was done and it was found that a network connection from outside the company was bypassing the firewall. Bypassing the firewall was needed because then current firewalls were not SIP enabled or even aware that voice traffic was there so they blocked it. There were also problems getting varied systems talking the same version of SIP. To fix these issues the SIP community of vendors invented the Session Boarder Controller.
In this development two schools of thought prevailed and two types of Session Boarder Controllers came into being. The first type was developed by vendors with a security background and these resembled routers or firewalls in design. The second type was designed by vendors with a voice background so these resembled a voice gateway. Both these designs address the issues but from a different tack.
The first type of Session Boarder Controller or SBC is a voice enabled firewall that has over time gained telecom facilities like dial plan and codec translation services. The main focus is the protection of the network from intrusion with a secondary function of manipulating the SIP traffic for disparate systems. Besides maintaining the SIP trunk these devices are able to manage remote IP phones so they can connect to the PBX from outside the network securely.
The second type of Session Boarder Controller is the Enterprise SBC or E-SBC these devices are more like voice gateways. They support SIP traffic over the network and are mainly for connections between disparate systems or to be placed behind traditional firewalls that have been SIP enabled. The main focus of the E-SBC is to manipulate the SIP traffic with a secondary or no focus on security. These E-SBCs do not handle remote IP phones that are off network.
Both types of SBCs have a use in SIP trunking but which one is used is based on the goals of the customer. To figure out which you need the following questions need to be answered.
1. Is the SIP trunk between disparate systems or to an outside carrier?
2. Are the current firewalls SIP enabled?
3. Are remote IP phone users involved?
4. How many circuits are needed?
5. What type of circuit is needed?
Once you have these basic questions answered the type of Session Boarder Controller needed will become apparent. Next up will be how to size the SBC but that’s a different story for a different day.






And then we have the Microsoft Lync Mediation Server, which can take the place of the SBC when properly configured. Microsoft recommends that you deploy the Mediation role on a stand-alone server and in a multi-homed manner, with one network interface connected to the ITSP/router and the other to the internal Lync deployment, essentially turning it into an edge device.
With the proper security precautions and configuration, this seems like a great alternative to a traditional SBC. The cost savings could be substantial when you consider that a (non-virtualized) Mediation Server which is already part of the Lync deployment could potentially manage ~1,000 calls and that a SBC equipped for that much capacity would easily cross the $50,000 mark.
Still, I would imagine that from a security and reliability standpoint, some organizations, especially those in the financial industry with strict network security requirements, might have concerns with using a typical Windows Server to perform the functions of a dedicated network appliance.
I am interested in hearing any real-world experiences or opinions on this topic.