January 12, 2004

Role of SBC in the VoIP Architecture

Today, David Beckemeyer commented on an earlier post. Instead of replying him under that post, I am creating a new entry because the comment branches to a separate, fundamental topic.

A clip of his comment is the following:

One issue with application level gateways (ALGs) or SBCs, is that they fundamentally break a major benefit of SIP, that of separation of session establishment from session description. A SIP proxy isn’t supposed to know or care what the end-points are going to do, or how they're going to talk to each other. That's between the end-points. When a nifty new thing comes out, SIP proxies don't have to be updated to accommodate or support it. But a ALG that is handling media won't understand the nifty new thing unless it is upgraded or recoded.

SBC is a nifty (if I am allowed to say myself) idea that comes at a price. To understand why it is nifty, a short description of SBC and its role in the VoIP architecture is needed. You may already know about them, but here is my version. SBC is strictly a layer 3 device, meaning it operates only at the IP layer. Specifically, it processes the header of a received IP datagram and maps the quad (Source, Destination IP addresses and port numbers) to a new quad. The mapping rule will be established by the SIP Proxy. With this simple device added to the network architecture, we can overcome the NAT traversal problem. Interestingly, we can offer additional services like Anonymous call, entry-point to a QoS-enabled network, and pivotal point for call altering services like transfer. SBC could be the point where Legal Enforcement Agency taps the media path. The basic function of SBC is already available in NATs (called Twice NAT?); but we need to add the control interface. This was one of the proposals to Midcom. I understand that Midcom is dormant; but given the activity in SBC market segment, it is safe to assume that SBC functions are required by the service providers.

An observant reader will also note that the new architecture resembles circuit-switched network in a significant way: the standard circuit switch which is made up of a control element and a switching fabric is replicated by a Proxy and SBC. So it is very easy to port the service logic from the circuit switch to this new architecture. This is very attractive for traditional voice vendors and service providers. But it is easy to manage because one can add additional SBCs or can replace a failed SBC with a new SBC. No new calls will be affected even though existing calls will be lost.

An SBC that follows this design (rather than the widely available kind that intercepts the signaling messages as well) does not encounter the difficulty that David is anticipating. But it does extract a price: since SBC is a funnel through which media traffic flows, SBC’s access link should be sized properly. The control interface between the Proxy and SBC must be protected.

Posted by aswath at January 12, 2004 05:44 PM
Related Posts Widget for Blogs by LinkWithin
If you do not have an OpenID, then please use www.enthinnai.com/unauopenid/anyblog.

 

Comments

Interesting. I'm not 100% sure I follow at what point the NAT addresses get "fixed up" in the SIP headers and SDP with this scheme. Perhaps you can write something up about this idea and post it to the SIP Wiki (http://www.toyz.org/cgi-bin/sipwiki.cgi)?

Posted by: Davd Beckemeyer at January 14, 2004 12:39 PM



Copyright © 2003-2014 Moca Educational Products.