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@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