24 Jan
2013
24 Jan
'13
9:27 p.m.
Hi,
On 01/24/2013 06:35 PM, Daniel-Constantin Mierla wrote:
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.
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. 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