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

[Richard Brady]

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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121026/d645db31/attachment.htm>