Hello,
On 1/24/13 8:27 PM, Andreas Granig wrote:
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.
do you mean out of the box with the sbc'es from any telecom-style deployment or I have to notify them, write code as the vendor, etc ... for each new bit?!?!? I am not the vendor and the SIP/programmer guy in this discussion, but just the average Joe that bought a new cool smartphone or the erlang guy that developed a new extension to its phone app.
Since you claim that your cool stuff gets broken, I'd appreciate you to come forward with an example, otherwise it's plain FUD.
I think you could really come up with a better demand in this discussion, otherwise is clear misunderstanding of the topic and makes no sense for further debate.
Anyhow, for the peace of your soul, alice and bob have a shared password and want to exchange a private token/data carried with each request in a custom header xyz. The body of this header is set as base64 of the value resulted from encryption of the token with a specific encryption algorithm known only by alice and bob, using the shared password, own via branch parameter value, contact uri, call id and from tag. Let me know how a sbc/b2bua will make that work. I let you disclose it to sems guys so they can be happy fixing this extension to work through sems sbc. Or maybe the FUD is coming from the other direction ...
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.
If you speak about the webrtc, it will have a role on online interactions. But I don't see replacing the telephony system. Nobody will stay with the browser open to be reachable (even less open to several providers). So walled gardens rtc will be as an addition feature to existing walled gardens.
However, if you care about interoperability, you'll also in the future use SIP or XMPP.
At some point (I hope) it will end up in a email-servers-like grid. And I won't care about what is the protocol behind that much...
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).
How, me as the caller, do I have to dial a prefix, add a header, ... to chose a session via sbc or not? Any rfc for that?
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.
I didn't know freeswitch, asterisk or even sems are proxies in my deployments and use cases, if yes, then I do agree with you. Otherwise they play nice as voice application servers (voicemail, conferencing, transcoding, ...).
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.
Do you mean, me, as user paying for the RTC service (so we practically talk here about location service, because all is IP), I want the provider to actively engage in my 3d naked hologram call with my doctor? For? Putting pills advertising banners in the middle?
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.
I will definitely not recommend to be used as SBC (b2bua), if you one would need such thing. Also, not for IVR, transcoding, voicemail and few more, but for the rest there it is ... cooking, washing, etc...
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).
Dialog module, seen as call stateful proxy, is not much more than a storage for some attributes of the sip dialog used for matching the signaling requests within dialog (callid, tags) and those needed to route for sending byes (routes, contacts). Then has a timer to fire on max duration of the call. Does not care about content of the session, does not care about extra headers, etc...
It is tied on tm to deal easier with reply matching and sending byes. Might not be the case, but having issues can be also a matter of the developer/this particular module design. I started using it when I wrote first significant bunch of code for it, before (and even now quite a lot) I used db based (sql queries on invite, bye, replies, etc... with tables in memory) or htable based active calls monitoring system.
Not sure how many noticed that dispatcher has also an embedded light weight dialog tracking system (for active calls load distribution). Nobody complained about it because (probably) just works.
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.
A b2bua, as the name says, is two UAs, bridged internally between them. No matter how fancy are at the time of the deployment, the provider will not deploy a new pair next month when I develop a more fancier capability of my UA, or, eventually based on $$$, it will deploy if I ask and disclose what I want to do. As my UA talks to a half of the b2bua, our negotiation ends up to the usage of what both UAs in this leg can do, which sets the list of features I can use with my UA to what the provider's UA can do, even the endpoint I want to talk to has the same UA as mine.
Now, to put it in other words and maybe clarify better. I haven't said that sems (or other media server/pbx/...) is a bad application or cannot be configured/extended to pass through everything know at this moment (which practically then is a proxy architecture, not a b2bua). It can be a better or preferred option to manipulate headers for many, that's great, everyone should use whatsoever they like or feel more confident.
For further clarifications, I used RTC (voice is just a bit there) not Telephony and the SBC is a something built on a b2bua architecture, not some sed-like app used to replace few tokens in headers.
Therefore it's long way to saying I am radical about SBC because I don't see the reasons to use such thing for sip headers manipulation.
At the end, I haven't heard that telephony operators are major players in RTC innovation, but maybe they didn't deployed enough SBCs ... and the baby brother ALGs ...
Cheers, Daniel