What’s Driving SBC Growth?

Seven years ago I sat down in a cramped office outside Boston. I was visiting Acme Packet, and the question on everyone’s mind was this: How long will this “SBC” thing hold out?

You see, in 2004, everybody I talked to about the Acme Packet thought it was a temporary fix to a technical oversight. Maybe the SIP people would modify the standard to accommodate NAT and Firewalls better. Or perhaps the firewall and NAT vendors would improve their behavior and start supporting VoIP natively.

And nobody liked the cost the SBC added to the network. In the past seven years, multiple major VoIP software vendors have pleaded with me not to bring up SBC’s with my network design clients. “Isn’t there a way to design these networks without so much cost?”

But that hasn’t happened. I’ve probably dealt with 100 carrier networks since then, and every one of them was either using an SBC, or making elaborate contrivances to avoid doing so.

But now the question is different. We have at least three significant SBC vendors to think about — Acme Packet, Metaswitch, and Sonus — plus Cisco too. And the questions aren’t “when will this go away?” so much as “how big will this market become?”

So, what is driving this growth? What has convinced Metaswitch to enter the market at this stage in the game, after such a clear leader has emerged?

PRIs. Specifically: they’re turning them off. And SIP trunking is vacuuming up the calls that used to flow through them. How many PBX ports were in use in 2001? That’s probably a reasonable estimate for the upper limit of the SIP trunking market over the short term.

Nosiness. Or, more precisely, “Busy Lamp Field,” “Line State Monitoring,” “Shared Call Appearance,” and other popular Hosted VoIP features. These features require many more SIP packets than basic call control, and they consume lots of SBC CPU time as they traverse the network. Carriers are buying SBCs in many cases simply to provide capacity for new features.

SS7 Peering that isn’t there any more. Yes, there are ISUP trunks and SS7 linksets out there, but they’re becoming the domain of specialized carriers, not every telephone company. Many carriers who have SS7-capable equipment aren’t even using it at all; instead, they do SIP peering with other carriers. And the SBC often handles these calls twice: once on the access leg, and again on the carrier leg. So the SBC vendors may be paid twice for each “call.”

I frankly wish the SBC wasn’t a fact of life. But due to several interesting technical, historical, and human reasons, it’s here to stay. I’ve listed a few, and I’d be glad to discuss others with any reader who is interested.


2 thoughts on “What’s Driving SBC Growth?

  1. I too have been asked by countless providers why the need for such expensive specialized equipment. Though they all want to avoid the expense, in my mind I know they will end up buying one. They all do eventually!But the biggest reason of all – SECURITY! no doubt a growing and massive threat to VOIP/SIP all together. Mitigating this is most effective by an SBC and for a laundry list of technical reasons that will always out of grasp by cheaper equipment. Sure it's just my opinion, but I've not seen one legitimate technical reason to not implement these devices up front unless they just have a very low call volume at that time. Even then, it's risky.

  2. My original thought was that SBC functionality would be subsummed into firewalls, but firewalls are a big pain and resource hogs in their own right. So then I though that routers would incorporate SBC functions, like Cisco’s UBE, but then there was the problem of the data and voice people tripping over each other and not playing nice. But really the UBE is just a normal router running a SBC application so its not really what I was thinking about, ie a device that does routing and SBC features holistically. But a this point, I think SBCs still exist because the voice teams demand it, they don’t want to have to deal with Cisco IOS. They also need a device that “understands” the SIP protocol and that can constraint the type and quantity of traffic flowing through them. Also nice that Acme and Metaswitch SBCs come in redundant HA configurations.

    But I can’t believe the cost of these things still. I did a naive calculation of SBC costs over 5 years for 4000 ports (i.e 2K in and 2K out).
    Dialogic Bordernet 4000 $139K
    Oracle 3820 $259K
    Metaswitch Perimeta $138K

    Thats a lot of coin to justify.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s