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

[Andreas Granig]

Hi,

On 01/24/2013 11:52 PM, Daniel-Constantin Mierla wrote:
>> 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 ...

Your reasoning goes like this: A proxy allows to pass through any kind 
of method and any kind of headers and bodies, and is therefore open and 
good. An sbc blocks unknown methods and headers and bodies and messes 
with the messages, and is therefore bad.

This is simply not true. Just because the default kamailio config allows 
this openness doesn't mean that's how all kamailio configs are deployed. 
It's straight forward to limit message types and to filter messages, and 
in fact lots of people do this. Now does this make kamailio suddenly 
bad? At the same time, it's easy to let an sbc pass through unknown 
message types and not filter the messages, and thus in no way limit the 
end-to-end communication. Is it then still bad?

In the end, it's the use case that matters. If you're bashing 
telco-style operators because they're providing PSTN break-outs and bear 
the risk of getting victims of fraud and therefore are protecting this 
line of signalling, then this seems a bit short-sighted.

>> 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...

Fully agree. But compared to email, you've different networks in RTC, 
like SIP, XMPP, SS7, ISDN etc. As long as it stays all-IP and nobody 
holds up his hands to collect money for such transits or terminations, 
it's all good, and you as an operator don't have to care about someone 
abusing your service (it's an annoyance which you better stop at some 
point, but it doesn't cost you thousands of dollars per 
hour/day/whatever). However, these business models charging for such 
communications won't go away any time soon, and I as an end-user 
actually appreciate to be able to call also mobile numbers, even though 
the feature set is limited to what we had for the last 100 years. The 
whole world is going through a transition period from circuit switched 
networks to packet switched networks, and during this period, you as an 
operator better protect your assets as long as you get charged for it 
from up-stream.

But again, this is just ONE use case of an sbc, and it doesn't mean your 
end-to-end communication gets stripped down to the bare basics by definiton.

>> 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?

Methods for secure end-to-end communication do exist, it's a matter of 
providing endpoints which properly implement them and let the users know 
if the operators tinkered with their communication channel.

This is not specific to sbcs though, as you can engage in a dialog with 
kamailio as well (like dialog/uac for example). It's a matter of how far 
you want to push your proxy to do certain tasks. And for some tasks, a 
b2bua element is better suited than a proxy by design. This doesn't mean 
you can't do things both ways.

As an operator, it comes down to knowing your scenarios and choosing the 
right tools for the right job. Saying that an sbc or any b2bua-like 
element in general is bad because it limits innovation as a whole is 
just wrong.

> 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 ...

The big telco operators have a much different agenda than small and 
innovating startups. Just because the big telcos use sbcs doesn't mean 
that sbcs prevent innovation. It's their mind and business plan which 
does, you can't blame it on technology.

Andreas