Hi Daniel, i believe in many setups (including mine and the Sipwise Systems) a SBC is always used as you described: Behind a Proxy.

The Proxy does Flood-detection, advanced logic, Loadbalancing and so on and the SBC works only as simple B2B-UA for Transcoding and Topology hiding. Kind regards, Carsten 2012/8/30 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:

I have only ever deployed SER behind SBC. SBC is the most expensive component.

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.

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.

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.

Good discussion! In most, but not all, cases it's a political/business decision outside of the scope of the technichal specifications. A commercial SBC delivers a cloud of magic dust that makes some people feel better and more secure. I have audited several SBC installations that are totally insecure, where the local techies lack knowledge on how to operate it. Management people think the SBC is secure by design. I can't blame the vendors here - it's more correct to blame the decision process. You can always build an SBC with Kamailio plus a media server like sems, Asterisk or FreeSwitch in combination with IPtables. It requires experience and knowledge, but it is propably a better longterm to invest in local knowledge for security instead of relying on outside companies without building local knowledge... Another problem is the architecture issue. SIP took off as a PSTN replacement. The design of the SIP network and a traditional switch/PBX network is radically different, so SIP networks was built with non-SIP design, with heavy media servers (b2bua) controlling every call. This put a severe limitation in the service set and forced a big dependency into the design, that wasn't there in the original SIP design. In order for SIP to get anywhere beyond G711 calls we need to rip that apart. Trying to do that is hard, since the endpoints are more and more designed for this design. Normal phone services like music-on-hold and call parking are hard to deliver without support from the phones. That forces many design to move back to a PBX design. It takes time to change people's mindset. We need to prove that we can build better and interoperable solutions. I can't get SIP presence to work across vendors. That's bad for the industry, bad for us and hurts the trust in new designs and solutions. Which moves people back to the old trustworthy and reliant PBX vendor. And the SBC, because that's what gartner group and similar institutes tell them is the proper design. The battle isn't over. We need to prove our vision. Andreas and SIPwise is doing great work here, as is AG Projects. And, of course, the whole Kamailio community and excellent developer team. /O * The new Edvina SIP Masterclass - Stockholm Oct, Miami, FL Dec 2012 http://edvina.net/training/new-sip-masterclass/ _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

31 aug 2012 kl. 11:04 skrev Tayeb Meftah <tayeb(a)vobradio.org>rg>: That's been done both with Asterisk and Kamailio (and propably SEMS) for a very long time. /O _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 08/31/2012 11:10 AM, Olle E. Johansson wrote: a very long time. For SEMS it's a commercial module, same goes for the Sipwise mediaproxy for seemless RTP stream fail-over. That's still where open source people earn their money :) Andreas _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Commercial SBCs are quite featureful, but their feature set is extremely static, and often depends on vendor consulting and expertise to be approachable. Nobody claimed the open-source solutions are simple to support or don't require expertise. They're not free, either, as everyone well knows. In my view, the real value of something like Kamailio - where it's not merely a money-saving measure but can achieve truly spectacular multiplier effects in technological leverage - is in its integration paths (MI and sercmd/binrpc), HTTP client/server, database connectors, integrated servers, etc. The ability to develop new kinds of applications and services that rely on making disparate components talk to and interoperate with each other in novel ways, as well as to make better, more economical use of existing technology through those same kinds of facilities, is where the real power truly lies. Some commercial products powered by proprietary stacks have APIs too, but they're light years behind the open-source world in this regard; they are far too bureaucratic and inflexible. This is where our customers typically see massive payback of using something like Kamailio, aside from the any savings on licensing costs (both of the core network element and potential dependencies).

When I first got into VoIP, my knowledge was less than stellar. The main decision make and I had believed that if we hired quality (and not cheap) SME we would be given great information and the money spent would pay for itself. We ended up working with a broadsoft system and an acme packet sbc. We were really sold that this would be the creme de la creme-- no nat issues, failover media, security, stability. Crap. Problems galore, especially with residential NAT users. Despite having 2 acme's in a failover, an outage from the main isp resulted in a crippling thundering herd when connection was restored. Immediately, and know with some decent knowledge, I started working with (at the time) openser. We deployed it within 2 weeks. There was no feature lost. In fact, we had only gains. All the NAT problems suddenly went away. We purposely tried to kill the openser with a thundering herd. Couldn't do it. There was a learning curve, but when is there not a learning curve? Honestly, at that time... the savings (which were incredible) wasn't an issue. If it were more than an acme, we would have paid it. We needed something that worked, and the best product we could find was openser. Since then, I've been a strong supporter. With the recent modifications (do we still consider anti_flood recent?), there's really no other choice for me. Yes, it takes programming, customization, and set-up. So does a commercial product. It's life. When I first deployed kamailio, I didn't consider it an SBC. I considered it an SBC replacement. With best regards, Fred http://qxork.com On Aug 31, 2012, at 3:47 AM, Olle E. Johansson wrote: of the scope of the technichal specifications. A commercial SBC delivers a cloud of magic dust that makes some people feel better and more secure. I have audited several SBC installations that are totally insecure, where the local techies lack knowledge on how to operate it. Management people think the SBC is secure by design. I can't blame the vendors here - it's more correct to blame the decision process. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users