Hello,

On 8/30/12 8:26 PM, Carsten Bock wrote:

Hi Daniel,

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

yes, I do the same when I need a media server/b2bua for transcoding, etc

I'm trying to figure out what drives the other type of topology, with the SBC in front.

Of course, if anyone has good arguments against an front-end SBC, speak here as well, it may help other people to take the right decision. I pretty much listed mine in the initial message.

Cheers, Daniel

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@gmail.com:

...

Hello,

based on the outcome of the discussion carried in the thread:

http://lists.sip-router.org/pipermail/sr-users/2012-August/074480.html

I am looking again the clarify some aspects out there in the VoIP world.

So, as mainly dealing with proxy/sip signaling deployments, it's very often to be the first one hit by support issues claiming things don't work. Then you investigate and end up in conclusions like in the above thread:

"The problem was at the SBC, __where I did not expect it__."

The underlined part heats me up a bit, because I never understood from where it comes this perception that SBC is a MUST-TO-HAVE and the PERFECT (never mistaken or breaking things) node in a VoIP networks.

To some extent, the SBC is just a very costly SIP ALG, and a SIP ALG is there to break the things.

I don't want to start like a flame war, but is it something that I am obviously missing in regards to what benefits a SBC can bring? I see only inconveniences:

• another point of failure
• it is a b2bua, therefore very unlikely to offer the same performances of a

proxy

• if transcoding is needed, a media server can be used behind the proxy,

properly protected of attacks by the proxy and eventually deployed as a farm load balanced by the proxy

• if topology hinding is wanted in the b2bua fashion (not the proxy fashion

with encoding headers), then the b2bua can be behind the proxy, properly protected of attacks by the proxy and eventually deployed as a farm load balanced by the proxy

• nat traversal was solved long time ago in proxy environment, being

scalable by deploying a farm of rtp proxy

I don't want to go to other features, including the transport layer, it's a clear win of the proxy in my experience (ok, being deep involved in this project).

Then, what makes the SBC so desirable in many companies/voip deployments? If any SBC user here that can share, what was the reason to buy such a device? Any conceptual functionality that cannot be achieved with the proxy as the first hop in front of the (wild) clients?

Cheers, Daniel

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

Hello Sbc also ofer a propritary way of failover for itself If node1 die node2 will replace it

Envoyé de mon iPhone

Le 31 août 2012 à 11:47, "Olle E. Johansson" oej@edvina.net a écrit :

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Yep Freeswitch too But go tel bt or any big carrier

Envoyé de mon iPhone

Le 31 août 2012 à 13:11, "Olle E. Johansson" oej@edvina.net a écrit :

31 aug 2012 kl. 11:04 skrev Tayeb Meftah tayeb@vobradio.org:

...

Hello Sbc also ofer a propritary way of failover for itself If node1 die node2 will replace it

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

I think for a lot of customers its as much about commercial support from vendors (basically the same story for all open source vs. commercial solutions), as it is about technical choice.

SBCs are seen as a fix all perimeter control for VoIP. I think as we all know there are many ways to solve a problem and architectural solutions for VoIP "interconnect" can also be solved by placing the SBC infront of an infrastructure (perimeter control) or as a border defence behind a proxy/load-balancer.

In some instances its about simplicity. For example I deal with hosted contact Centre environments built around commercial VoIP contact centre solutions from Oracle and CosmoCom, for these it is simpler to place a commercial SBC such as Acme, Sonus or even Cisco "CUBE" facing a carrier SIP trunk interconnect. My customers have the assurance of vendor support and I as a SME, I don't have put a significant amount of time and effort in to supporting an Open Source solution. (Please don't flame me on this last point). Whilst I would like to place Open Source products in this mix (OpenSER/SER, SEMS, Asterisk, Freeswitch, etc) for some of my customers they just don't want to go down that route.

Neill

Neill Wilkinson Aeonvista Ltd

On 31 August 2012 10:52, Andreas Granig agranig@sipwise.com wrote:

On 08/31/2012 11:10 AM, Olle E. Johansson wrote:

...

...

Sbc also ofer a propritary way of failover for itself If node1 die node2 will replace it

That's been done both with Asterisk and Kamailio (and propably SEMS) for

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Also, Kamailio's procedural route script language is a major asset of its particular methodology.

While it can sometimes be a pain for newbies trying to do relatively simple, canonical kind of things, the flexibility it affords in scripting SIP outcomes on a very granular level, and providing a powerful state machine within that programmatic framework, are both hugely important to "non-trivial" endeavours.

The feature set of something like an Acme Packet NetNet SD is essentially static; it does what it does, and not one bit more. It may have a lot of capabilities, but those capabilities are all a matter of configuration, not of customisation or extension. It is in something like Kamailio (or Asterisk or Freeswitch) that you can truly *extend* the functionality, allow it to interface with other open-source and proprietary components, build complex middleware and business layers, etc.

On 08/31/2012 08:13 AM, Alex Balashov wrote:

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).

A bit late to dig up this old conversation but my thoughts:

The simplest SIP relationship is from one UA to another UA without proxies.

I love proxies, I really do, they are so powerful. But putting a proxy between UAs (or B2BUAs) places higher interoperability requirements on them. For example take record routing. In a simple UA to UA scenario there is no requirement for either to support record routing. But as soon as there is a proxy in place, they need to support record routing and/or the configuration of an outbound proxy and/or the proxy dropping out of the dialog.

So if you are a pragmatic ITSP and you want to support many types of SIP UAs behind many types of routers, including badly broken ones with missing or poorly implemented features, you will benefit from putting a B2BUA right on the edge.

It's a sorry state of affairs, but I think it's why there is some method to the SBC madness.

On 31 August 2012 13:25, Fred Posner fred@teamforrest.com wrote:

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:

...

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.

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users