Session Border Controllers (SBCs) are, to some, a saving grace and, to others, the devil’s breath. The reason, I think, is because the SBC can solve quite a few problems, but, if not used appropriately, core network costs can easily double for a business. They also have a tendency to flood the network with requests when coming back to life after a failure, which causes a host of other problems.

Because I, myself, will ultimately have to answer for escalating network costs, I am inclined to do just about anything to stay away from SBCs. The sad part is that it is nearly impossible to get around using an SBC entirely in today’s world of VoIP, Video, and IM — here’s why.

NAT traversal is a nasty business and, unless your plans are to operate only in managed private IP space, you will need a mechanism to get off those pesky firewalls. For mobile users, this is a common issue and asking the network admin at any given hotel, for instance, to open up ports on his firewall is nothing short of a pipe dream, especially when you tell them that you plan on bypassing their telephone system and the 500% up-charge on long distance by making calls using your softphone over the broadband connection you paid $10 for. Yes, SBCs are useful here and there is nothing special the user has to do to take advantage of it; it’s provided as an invisible service to the end user.

So, we need SBCs today to solve some basic NAT traversal problems, but should we be routing all traffic over SBCs? Is this necessary? No, in my opinion it is not, but, if you are short some good network security engineers and time, you may feel it’s easier to go the SBC route. Hardening firewalls and SIPifying network security is not for the faint of heart. It takes experience, but if you have those resources, you can probably save yourself a wheelbarrow full of cash by not using an SBC for this piece.

What about SIP Peering? Many people say that, unless you are using SBCs, you will not likely gain access to many SIP trunk partners and carriers. I am not so sure about this. It’s usually your own network with which you are most concerned and, as long as you are confident the holes are plugged, you should be able to peer with most providers offering the service. So, if the pitch is to use an SBC to provide more security for your core SIP network, I say this argument can be more of a resource driven issue.

In the end, it’s really up to you, as the network architect, to decide if you are gaining enough for the 50-70% increase in cost, as opposed to what you would pay if you were to spend a few more dollars on the firewalls in your network.

SBCs can easily cost around $20 per initial session — at a minimum of 1,000 sessions, you are looking at $200k. Multiply that for every 1,000 sessions you need to grow your network and the number gets very high very quickly. I can’t speak for you, but I am confident I can put that money to better use elsewhere in my network.

For me, the SBC is a necessary evil, but I also have my ear pasted to the rails. The first commercial TURN server is right around the corner. Couple TURN & STUN servers with ICE, and the appeal of SBCs (and the Backto- Back User Agent or B2BUA) quickly diminishes. Bring on open standards!

Erik Lagerway is CTO at Shift Networks. (news - alert) For more information, please visit the company online at http://www.shiftnetworks.com.