[VOIPSEC] RE: SBC functions

[Pankaj Shroff]

We just went through a rather thorough vendor analysis for an SBC
purchase at my company and reached similar conclusions as Geoff. Most
SBC's (at least the market leaders) had comparable latencies on RTP
packet relay - on the order of 50microSeconds. None of them do
in-the-box transcoding (i.e. G.711 to G.729 and back) otherwise their
delays would be prohibitive. I dont have much experiene with Midcomm
protocols, but it seems that it would only add another element that
could fail or have errors. Security ought to be your primary goal when
evaluating an SBC. The primary function of the SBC is to serve,
basically, as a SIP aware NATing Firewall. As long as the device keeps
latencies low and scales uniformly on both media and signalling side,
there is no need to split the media and signalling functionality.

On the other hand, for more complex operations on the media stream
such as transcoding and silence detection/suppression/insertion one
must consider a secondary DSP farm that can be controlled by the SBC.
This is because the concentration of DSP resources in a separate
device helps keep SBC device prices low and only those business that
need the transcoding capability and only when they need it can
purchase such capability.

The idea of splitting the two functions is akin to the telecom worlds
advances common channel signalling which is parallel to TDM circuitry.
Common channel signalling (SS7, ISDN) is a way to split the signalling
messages over a different network (all digital) and leaving the
circuits in the traditions POTS network. The problem is that the SBC
is an edge device on an IP network not a core device. Splitting
signalling and media works well at the core of the network, which is
exactly what is accomplished by technologies such as MPLS.

Pankaj.


On 6/3/05, Geoff Devine <gdevine at cedarpointcom.com> wrote:
> My opinion:
> On the media stream function, you're dealing with wire speed admission
> control, packet inspection, and traffic shaping issues.  If you're a
> service provider charging money for your service, you probably want this
> function to be redundant.  It's a carrier-class NEBS box with lots of
> network processors or other dense CPU MIPS and multiple Gig-E, OC-48, or
> 10Gig-E interfaces.
> 
> The signaling stream function handles far less packets per second but
> runs much longer code paths.  In many cases, you're performing security
> functions on this interface (TLS, DTLS, IPSec,...).  You need the exact
> same attributes for the box.  Redundant, NEBS, hardened.
> 
> As long as you can scale both functions at different rates within the
> same chassis, I don't see the motivation for splitting the functions.
> If you have a poor internal architecture where this isn't possible, I
> suppose your PowerPoint deck is going to talk about splitting the
> functions.  As an operator (an ILEC or MSO), I think I'd want
> geographical diversity for my SBCs, not one huge SBC cluster where a
> failure kills my whole service.  If you're trying to use an SBC in the
> network to traverse a corporate firewall, it's easier to administer the
> firewall if you know you're only talking to one SBC, or, at least, to
> one sub-network.
> 
> The only counter-argument for this is mobility.  If the signaling SBC is
> aware of the true IP network topology, it could direct media streams to
> a media SBC that is as close as possible to the subscriber.  This
> minimizes delay and makes better use of IP network resources.
> 
> Use cases with mobility:
> An IMS/3GPP sort of environment where the user is a 3G cell phone
> 
> A WiFi/WiMax mobility sort of environment
> 
> 3GPP doesn't use SBCs but the P-CSCF (similar to a signaling SBC since
> it polices the SIP signaling from the user agent) is allocated
> dynamically based on proximity to the radio base station.  You could
> achieve the same sort of thing with integrated SBCs by dynamically
> redirecting the SIP signaling to another SBC.
> 
> Geoff
> 
> ----------------------------------------------------------------------
> 
> From: "Nhut Nguyen" <nnguyen at sta.samsung.com>
> Subject: [VOIPSEC] SBC functions
> To: <Voipsec at voipsa.org>
> Message-ID:
> 
> <AD84624F3AF21A45875222FCBAD10BA984E774 at mx1.telecom.sna.samsung.com>
> Content-Type: text/plain;       charset="us-ascii"
> 
> Hello All,
> 
> 
> 
> In a recent webinar, it was said that ultimately SBC functions will be
> decomposed to two parts: media and signaling, with one signaling
> function box will control multiple media function boxes, using a MIDCOMM
> protocol (e.g. H.248, COPS, SNMP). So what people think about these
> questions?
> 
> 
> 
> 1.      What are the good, bad and ugly things about this?
> 2.      Any potential major performance issues with this architecture?
> 
> 
> 
> Any thought?
> 
> 
> 
> Nhut
> 
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 


-- 
Pankaj Shroff
shroffG at Gmail.com