[SR-Users] Evil SBC/B2BUA, was Re: uac_replace_from recovery with modified header

[Andreas Granig]

Hi,

On 01/24/2013 06:35 PM, Daniel-Constantin Mierla wrote:
>> What cool extensions would that be? I guess the sems guys would be
>> happy to fix it, if it breaks something unexpectedly.
>
> well, see, you just hit your (business) head! Why I should share with
> the sems guy the ideas about my cool features? Did
> google/twitter/facebook/... had to do disclose anything about their
> ideas to apache devs?!?
>
> With proxy architecture/kamailio new extensions just works fine -- it
> needs to look at r-uri, route headers and just few other stuff. I can
> have anything in other headers and in sdp/body, including new brand
> request methods. It is an open innovation environment.

Let me put it in another way: I'd be very surprised if you can come up 
with something that you can NOT pass through sems. Since you claim that 
your cool stuff gets broken, I'd appreciate you to come forward with an 
example, otherwise it's plain FUD.

> The SBC is an anchor in the past, just a pstn element brought to IP to
> keep RTC evolution slow, in the hope the telcos will control everything
> and milk a bit more cash on allowing and charging voice minutes only.
> Their era is pretty much gone, proper RTC platforms will emerge soon
> from real IP companies that'll give the freedom to build new services on
> top as needed...

Future RTC platforms from real IP companies will (and already do) 
provide web APIs, where you can build fancy applications using HTML5/JS 
on top. There is even no need for SIP at all to do so, as long as you 
stay in your walled garden, so there is also no need for a SIP proxy. 
Just saying.

However, if you care about interoperability, you'll also in the future 
use SIP or XMPP. And then again, you always have the choice in the proxy 
whether to engage a b2bua/sbc or not, depending on policies and/or 
particular needs (e.g. for being able to actively engage in established 
sessions on a signalling- and/or media level).

> As said in the past, I can understand from the business perspective of
> "it's what the customer demands", but there is no added value, just more
> complexity and another point of failure. Transcoding or other media
> services (e.g., ivr) are the roles of voice application servers.

That has nothing to do with a business perspective, we're still talking 
on a technical level. What you're referring to is an approach where 
people get hammered into their heads from marketing people that 
regardless of what an RTC system is supposed to do or how it actualy 
looks like, you need an expensive SBC (coming in a big fancy separate 
box) in front of it. That's ridiculous, and I'd agree with you here.

However, you've a radical opinion on that, obviously rejecting 
everything which is not a proxy. From a functional perspective, it makes 
perfect sense to split call legs in certain scenarios with a b2bua 
(which is essentially what sbcs are), because it allows to actively 
engage in established dialogs, which in turn is what you want or need 
for server-side voice applications. And this is why proxies and sbcs (or 
b2buas, or however you want to call them) can perfectly work together in 
a SIP system.

In the end, it just matters which tool you choose for what. Kamailio is 
a great piece of software, but I'd refrain from using it for just 
everything, which inevitably results in horrible hacks. For example, why 
(as a provocative question) would a proxy need a dialog module, if it 
could just route traffic on a stateless and/or transactional basis, and 
store additional stuff in Route headers? This module was full of issues 
for years and still has its shortcomings, because the whole proxy 
architecture is not designed from the ground up to handle these cases 
(e.g. it's always tied to tm module). A b2bua on the other hand does 
just that. There is no need to do routing decisions, because that's what 
the proxy is there for, so its main purpose is to handle call state 
information and (re)act on it accordingly.

Andreas