[SR-Users] [OT] the role of SBCs

[Andreas Granig]

Hi Rupert,

The interesting thing is that the arguments you brought up are exactly
the same in every big corporation we've worked with. They're perfectly
valid, also taking into account the decision making process, which
department takes responsibility for what, and it's also of course
politically and policy driven.

Still, all of it can be solved quite easily with proper sip proxies and
b2buas and efficient mediaproxies, see below.

On 08/30/2012 09:58 PM, rupert.organ at bt.com wrote:
> I have only ever deployed SER behind SBC. SBC is the most expensive component. 

And there, the thinking often goes like "it's the most expensive
component, so it must be the most secure one", and nobody got fired for
buying an Acme SBC so far. SBCs are marketed as "firewalls for VoIP",
and security people love this idea.

> I am not involved with security, but I would not be allowed by my organisation to deploy something like SER, with mysql details of usernames and password on an internet address. 

In our systems we've a stateless kamailio instance running as load
balancer as single ingress/egress point in front of the proxies, b2buas,
app servers etc, and it only has a very small dbtext db for the
dispatcher table. No credentials of any kind exposed, and you can put it
on a separate node if you want.

> The SBC hides my addressing and only opens temp pinholes for both sip and rtp. The main USP of the SBCs is the power to route many rtp streams simultaneously. This also allows guard timers to check rtp streams dying so no overcharging takes place. I don't think the hardware on a conventional server will scale to the number of rtp streams i want to deal with. 

Our mediaproxy tells the b2bua internally via XMLRPC to tear down a call
if all streams of a call time out. Media relaying is done directly in
the kernel, you can handle thousands of parallel calls on a conventional
machine with a proper NIC, and you can add as many new nodes as you
like/need.

>I guess u might say, why route all the rtps through a single  point of failure... there are other mechanisms to avoid overcharging,and also  can hide SER behind NAT... I agree, but SBC suppliers have moved along the value chain....header manipulation for interworking, eNum lookup, codec manipulations....again all things that can be done on SER.... it comes down to a philosophy and "way we do things"...The other main thing SBC does is prevent attacks. i.e. SIP signalling attacks result in instant filtering from that address and thereby protects the service. I wouldn't know how to protect my SER if it was exposed to the internet, ...maybe there is a way...I just don't know it.

We do NAT handling on the kamailio lb instance, we do header
manipulation and codec filtering on an open source sbc (sems), and we do
DoS/DDoS protection also in kamailio lb, quite similar as described
here: http://kb.asipto.com/kamailio:usage:k31-sip-scanning-attack

The reason for us to use SBCs is really just to provide B2BUA features
like doing session timer handling, header/codec filtering, clean
topology hiding, and media stuff like music-on-hold and transcoding
etc., which all has been mentioned in different threads.

We still have customers who put an Acme SBC in front of all this, and
well, if they're comfortable with this and feel better, it's perfectly
fine. It more sometimes turns out though that the SBC behaves
incorrectly in quite a few scenarios, and then time-to-fix is most much
faster in an open source system rather than an expensive SBC appliance.

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120831/726821de/attachment.pgp>