Metaswitch has been talking a lot lately about VoIP Session Border Controllers (SBCs). They recently took their DC-SBC product to the SIPit interop testing event in June. And they just published another white paper about SBCs and their role in IMS.
The Enfield company formerly called Data Connection Limited definitely makes solid software. Rumor has it some of these gents were hired to make some of the first VoIP implementations for Cisco and for Microsoft. And if you look closely when doing VoIP troubleshooting, you’ll still see Alcatel-Lucent gear advertising their SIP stack built years ago. So they certainly know VoIP protocols, and I have reason to expect great things from their SBC implementation.
Nevertheless, rolling out a Session Border Controller product at this stage in the market is tough. Acme Packet has a dominate lead in market share; but more importantly, they dominate in field-tested features. The Acme Packet Configuration Guide reads like a military history of battle plans of the form:
so your endpoint devices came at you with <insert insane endpoint behavior here>? Well, add this magic incantation to sip-options and you’re off and running!
But Metaswitch isn’t trying to go up against Acme Packet. In fact, in early 2009, they signed a deal to re-sell Acme Packet gear.
So what is Metaswitch’s angle on Session Border Controllers?
As the recent white paper “Session Border Controllers in IMS” discusses, they see three key markets for their SBC software:
- High End Tier-1 Mongo Service Provider: Integrate the SBC into the other VoIP equipment, like the access media gateway.
- Small/Medium Mom-and-Pop Telco: Integrate the SBC into the Service Provider Edge Router.
- Enterprises: Integrate the SBC into the Access router.
SBC as part of Core VoIP Equipment
The brilliant minds behind IMS believe the SBC features will be smeared across your core feature server, media gateways, and other such devices. You’ll have bits of SBC functionality here and there. This logic follows the classic zero-one-infinity principle of Computer Science:
0: The IETF told us we didn’t need SBCs at all.
1: Most VoIP Service Providers wanted SBC at one point in the network.
∞: But we IMS guys love SBCs so much, we’ll put it everywhere!
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.)
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.
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:
- Stability: The platform works all day, every day for months at a time.
- 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.
- 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.⊗