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