The cons:

Several vendors are trying to do this in the media gateway. Did you know Convergent is still in business? They’re attempting to sell a SIP version of their media gateway, complete with SBC functionality built right in. Genband is trying this too with their SBC product, integrating it into their core media gateway.

SBC in the Service Provider Edge Router

It’s clear from all the marketing that one of Metaswitch’s big pushes is get their DC-SIP software integrated into Service Provider Edge Routers. This is the router to which service providers connect their DSL, T1, DS3 and other customers.

Metaswitch has some neat ideas here. For example, they discuss the ability to assign a virtual SBC instance to individual interfaces on the router. That sounds a lot like the way the Cisco Firewall Services Module (FWSM) lets you assign firewall instances to individual VLANs.

But more specifically, this sounds like Metaswitch wants to provide exactly the kind of functionality found in the Cisco Unified Border Element, an SBC available in some of Cisco’s routers. (In fact, it’s possible Cisco is already using DC-SBC for this purpose, but I don’t have any direct evidence of that.)

The pros:

The cons:

SBC in the Customer-Premise Edge Router

Metaswitch would love to get their DC-SBC into the customer premise equipment. Who wouldn’t? This is the device that gets sold millions of times. The Edgewater EdgeMarc is one leading Customer-premise SBC-type gadget.

The pros:

The cons:

Many network designers want an ALG at the customer premise, so there’s good reason to expect Metaswitch could be quite successful here.

MetaSwitch’s Gentle Argument against Standalone SBCs

Metaswitch has gently argued against the standalone SBC, e.g., the Acme Packet SBC products.

They seem to argue:

However, as a network integrator and operator for the past seven years, I find these arguments weak:

The SBC Integration that Makes Sense

In many networks, the SBC sits side-by-side with a data firewall. It’s not parallel to the Media Gateway, and it’s not parallel to the Provider Edge router. So as designer of functional networks, I would be most interested in an SBC / data-firewall integration.

The combination of two security devices that sit at the border of the same security domain would be quite practical. You could use the same two-plane architecture commonly employed in high-end SBCs (e.g., Acme 4250) and high-end firewalls (e.g., Cisco FWSM):

• A conventional processor to handle signaling. Scale it up by splitting endpoints across different processors.
• Network Processors to handle packets after the flows have been approved. Scale it up splitting flows across different NPs.

Should Acme Packet fear?

The key reasons I recommend Acme Packet for standalone SBC deployments are:

1. Stability: The platform works all day, every day for months at a time.
2. Features: I’m rarely the first to need a feature, so the oddball and innovative features are there by the time I need them. Plus, there are features that are only needed as a carrier scales up.
3. Deployment Scale: Thousands of these things are out in use, which means they’re being tested heavily by those thousands of deployments.

The DC-SBC might do great for Stability; let’s assume it will. And because DC-SBC is a young platform, it’s not clear just how widely used it is used, and actually knowing that will be tough. For example, it’s important to note that not ever Cisco ISR with IP-IP-Gateway functionality is actually using that functionality; likewise when the DC-SBC is integrated into another device, it’s not always clear when or if that will be used.

But I don’t know that DC-SBC has the thousands of oddball features needed for interworking in modern, diverse carrier environments. When I talk to large service providers using Acme Packet SBC, they’re always employing tons of custom processing of the signaling by rewriting the SIP in many ways. Further, Service Providers large and small use many of the bizarre and obscure features of the SBC to get a reliable network.

So if you, dear customer, are considering the DC-SBC, be sure it really has the features you actually need. And the only way to know that is to actually integrate and prove the network under load. And then you have to anticipate what features you’ll need as the network scales up.

I’m not an Acme Packet shareholder, and I genuinely hope for some honest competition among SBCs. SBCs are mind-blowingly complex — almost as complex as the telephony application itself. For a new SBC to enter the market seriously, some service providers are going to have the guts to deploy and test the things, and the vendors are going to have to work awfully hard to meet the existing expectations for SBCs.⊗