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

Daniel-Constantin Mierla miconda at gmail.com
Thu Jan 24 23:52:21 CET 2013


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

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
  - http://conference.kamailio.com -




More information about the sr-users mailing list