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.