24 Jan
2013
24 Jan
'13
4:22 p.m.
Hi,
This is a question for kamailio 3.0.x and I'm still trying to reproduce
this issue somehow for latest stable, but maybe it was a known issue
anyways which got fixed in newer versions, so I don't have to dig deeper
into this:
There is an INVITE "A -> kamailio -> B", and kamailio does
uac_replace_from() to replace the display- and user-part (leaving the
domain-part untouched).
When there's a BYE "B -> kamailio -> A", then From/To are switched, so
the replaced From of the INVITE becomes the replaced To of the BYE.
Kamailio gets that one right and tries to recover (in auto-mode) the To.
However, in this BYE, B changes the domain-part of the To, which should
be valid, as elements are only supposed to inspect the tags of From/To,
right? The problem though is that when recovering the To, kamailio
inserts garbage into the domain part. The vsf-Parameter in the Route of
the BYE is definitely ok though, so that doesn't seem to be the issue.
Here's an example:
In the INVITE,
From: "ab12345"<sip:ab12345@192.168.0.12;user=phone>;tag=948a3340
gets rewritten to
From: "12345"<sip:12345@192.168.0.12;user=phone>;tag=948a3340
And in the BYE,
To: "12345"<sip:12345@1.2.3.4>;tag=948a3340
gets rewritten to
To: "12345"<sip:ab12345<@-%:68*0.0%12;user=phone>;tag=948a3340
Note that the received To in the BYE has a different host-part than what
got sent out in the From of the INVITE, and when kamailio recovers the
To, it doesn't recover the Display-part (not sure though if this is
intended behaviour anyway), but it only party recovers the domain-part.
You can still see some artefacts of the original domain (like the "68"
from the second "168" octet, and the "12" from the last octet).
Has anyone encountered this issue before?
Andreas
24 Jan
24 Jan
4:55 p.m.
Hello,
I got in a similar situation quite recently. I checked the code and the
way it was designed, leads to this behavior (because the inital value
and the new one are XOR'ed, iirc). If it is changing the domain part, is
not much to do. In my case was adding a useless uri parameter and I
thought of updating the module to work only on the domain part. But it
wouldn't have been safe in all cases, like changing also the domain
part, so ultimately I just went for replacing the URI in first INVITE to
present the wanted URI when ringing and for the rest of requests in
dialog I replaced with anonymous both To and From. It worked fine for
that case.
The latest version has support for using dialog to store the From/To
values, so no masking within rr param. It should work fine in your case,
I guess.
For earlier version, you can achieve more or less the same by storing
from/to values in htable, indexed by call-id.
Cheers,
Daniel
On 1/24/13 3:22 PM, Andreas Granig wrote:
Hi,
This is a question for kamailio 3.0.x and I'm still trying to
reproduce this issue somehow for latest stable, but maybe it was a
known issue anyways which got fixed in newer versions, so I don't have
to dig deeper into this:
There is an INVITE "A -> kamailio -> B", and kamailio does
uac_replace_from() to replace the display- and user-part (leaving the
domain-part untouched).
When there's a BYE "B -> kamailio -> A", then From/To are switched,
so
the replaced From of the INVITE becomes the replaced To of the BYE.
Kamailio gets that one right and tries to recover (in auto-mode) the To.
However, in this BYE, B changes the domain-part of the To, which
should be valid, as elements are only supposed to inspect the tags of
From/To, right? The problem though is that when recovering the To,
kamailio inserts garbage into the domain part. The vsf-Parameter in
the Route of the BYE is definitely ok though, so that doesn't seem to
be the issue.
Here's an example:
In the INVITE,
From: "ab12345"<sip:ab12345@192.168.0.12;user=phone>;tag=948a3340
gets rewritten to
From: "12345"<sip:12345@192.168.0.12;user=phone>;tag=948a3340
And in the BYE,
To: "12345"<sip:12345@1.2.3.4>;tag=948a3340
gets rewritten to
To: "12345"<sip:ab12345<@-%:68*0.0%12;user=phone>;tag=948a3340
Note that the received To in the BYE has a different host-part than
what got sent out in the From of the INVITE, and when kamailio
recovers the To, it doesn't recover the Display-part (not sure though
if this is intended behaviour anyway), but it only party recovers the
domain-part. You can still see some artefacts of the original domain
(like the "68" from the second "168" octet, and the "12"
from the last
octet).
Has anyone encountered this issue before?
Andreas
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
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 -
5:34 p.m.
Hi Daniel,
On 01/24/2013 03:55 PM, Daniel-Constantin Mierla wrote:
The latest version has support for using dialog to
store the From/To
values, so no masking within rr param. It should work fine in your case,
I guess.
For earlier version, you can achieve more or less the same by storing
from/to values in htable, indexed by call-id.
Thanks for the explanation.
This issue actually happens on our very first SPCE version (2.1), which
just runs one kamailio as proxy without any load-balancer and sbc in
between the proxy and the called party.
Since 2.2 we use sems as sbc between proxy and lb on the way out to the
called party b, so in that case if B sends something odd in the To,
it'll be discarded and replaced by the To (or From, depending on the
direction) which had been passed from the proxy to the sbc in the
initial INVITE.
So that's for example a very good scenario where it pays off to have an
SBC in your system :)
Andreas
5:49 p.m.
Hello,
On 1/24/13 4:34 PM, Andreas Granig wrote:
Hi Daniel,
On 01/24/2013 03:55 PM, Daniel-Constantin Mierla wrote:
there is no need for an sbc and break the call in two legs
and drop my
cool extensions I have in my softphone.
htable does it very well in this case if you want to store initial
values and if the device are rfc3261 compliant and look only at the
tags, you can put what so ever crap there.
The comparison is more like: it's better to have an airplane instead of
a car to drive on highway because can be done without wearing safety
belt, which is required only for take off, landing and turbulence :-).
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 -
The latest version has support for using dialog
to store the From/To
values, so no masking within rr param. It should work fine in your case,
I guess.
For earlier version, you can achieve more or less the same by storing
from/to values in htable, indexed by call-id.
Thanks for the explanation.
This issue actually happens on our very first SPCE version (2.1),
which just runs one kamailio as proxy without any load-balancer and
sbc in between the proxy and the called party.
Since 2.2 we use sems as sbc between proxy and lb on the way out to
the called party b, so in that case if B sends something odd in the
To, it'll be discarded and replaced by the To (or From, depending on
the direction) which had been passed from the proxy to the sbc in the
initial INVITE.
So that's for example a very good scenario where it pays off to have
an SBC in your system :)
6:25 p.m.
Hi,
On 01/24/2013 04:49 PM, Daniel-Constantin Mierla wrote:
there is no need for an sbc and break the call in two
legs and drop my
cool extensions I have in my softphone.
What cool extensions would that be? I guess the sems guys would be happy
to fix it, if it breaks something unexpectedly.
The comparison is more like: it's better to have
an airplane instead of
a car to drive on highway because can be done without wearing safety
belt, which is required only for take off, landing and turbulence :-).
An SBC is rather like an airbag. If done right, you don't even recognize
it and in case of an issue it might save your ass. If done wrong, it
will blow up in your face while driving 100mph on the highway.
Andreas
7:35 p.m.
Hello,
On 1/24/13 5:25 PM, Andreas Granig wrote:
Not quite,
airbag is a passive element in the process, it does not help
to drive correct or better. I haven't seen airbags on airplanes (bikes,
fast trains, hoovers or other transportation engines) :-) and they won't
save any*bodypart on real issues there...
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...
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.
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 -
Hi,
On 01/24/2013 04:49 PM, Daniel-Constantin Mierla wrote:
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.
there is no need for an sbc and break the call in
two legs and drop my
cool extensions I have in my softphone.
What cool extensions would that be? I guess the sems guys would be
happy to fix it, if it breaks something unexpectedly. The comparison is more like: it's better to
have an airplane instead of
a car to drive on highway because can be done without wearing safety
belt, which is required only for take off, landing and turbulence :-).
An SBC is rather like an airbag. If done right, you don't even
recognize it and in case of an issue it might save your ass. If done
wrong, it will blow up in your face while driving 100mph on the highway.
9:27 p.m.
New subject: Evil SBC/B2BUA, was Re: uac_replace_from recovery with modified header
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
25 Jan
25 Jan
12:52 a.m.
New subject: Evil SBC/B2BUA, was Re: uac_replace_from recovery with modified header
Hello,
On 1/24/13 8:27 PM, Andreas Granig wrote:
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.
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, ...).
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.
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.
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. 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.
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. 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 -
1:54 p.m.
New subject: Evil SBC/B2BUA, was Re: uac_replace_from recovery with modified header
Hi,
On 01/24/2013 11:52 PM, Daniel-Constantin Mierla wrote:
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.
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.
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.
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 ... 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... 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? 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
3:51 p.m.
New subject: Evil SBC/B2BUA, was Re: uac_replace_from recovery with modified header
Hello,
I expected from the previous email that the conversation makes no sense,
because it is somehow a clear misunderstanding. In the initial topic of
updating some headers you come up with the idea that (quoted):
"So that's for example a very good scenario where it pays off to have an
SBC in your system"
It was not my case in the past 12 years, really, not for such thing, no
matter how you want to put it, not even as possible scenario, not at all
as a very good one.
And if you suggest that is 'the solution' for fraud preventions, then I
am SIP blind, not short sighted. Terminology like saves a*ses, plain FUD
or short sighted does not have anything to do with technical arguments,
its for throwing in a no-arguments discussion. I guess sems guys are
happy coding already...
You divert easily to different use cases of kamailio, which don't have
anything to do anymore with "a SBC for updating headers" or "SBC as
b2bua". Suddenly is also about gateways between protocols and breaking
out, what SBC have to do with these specific elements? Can't there be
fraud between two pure IP RTC providers?!?! I know also a sbc can run on
separate box with linux, that can provide ssh tunneling if needed, or
other value added features such as a web server, which can be a must in
a specific operator business plan.
But I said that I refer to proper SIP SBC as the function, not to a
specific application/system as a whole which can do something else, ivr,
voicemail, etc... or what so ever system that does port forwarding. Now,
you come to say that one can interpolate or do derivatives to the
application and could get a space shuttle, but it is no more a SBC.
I am really more than happy sems gets what you need and how you wanted,
is a cool application, I never said something else. You can ask for
license fee refund if you got kamailio for a sbc function and is not :-)
Besides SIP blindness, I am getting also speechless - "any b2bua-like
element in general is bad because it limits innovation as a whole is
just wrong" - maybe one can explain me how an UA can use any
functionality that is not supported in the b2bua, when is in a session
with the 1/2 of the b2bua.
No sense for more, back to testing 4.0.0...
Cheers,
Daniel
On 1/25/13 12:54 PM, Andreas Granig wrote:
Hi,
On 01/24/2013 11:52 PM, Daniel-Constantin Mierla wrote:
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.
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.
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.
--
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 -
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 ... 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... 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? 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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 
3:54 p.m.
New subject: Evil SBC/B2BUA, was Re: uac_replace_from recovery with modified header
On 01/25/2013 08:51 AM, Daniel-Constantin Mierla wrote:
No sense for more, back to testing 4.0.0...
Maybe so, but I for one thought it was quite an interesting discussion. :-)
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
4:01 p.m.
New subject: Evil SBC/B2BUA, was Re: uac_replace_from recovery with modified header
On 1/25/13 8:54 AM, Alex Balashov wrote:
On 01/25/2013 08:51 AM, Daniel-Constantin Mierla
wrote:
I'm more interested in the refund idea. I think I finally found the best
way I can contribute to the project; refund administrator.
--
fred
http://qxork.com
No sense for more, back to testing 4.0.0...
Maybe so, but I for one thought it was quite an interesting discussion.
:-)
4:05 p.m.
New subject: Evil SBC/B2BUA, was Re: uac_replace_from recovery with modified header
On 01/25/2013 09:01 AM, Fred Posner wrote:
I'm more interested in the refund idea. I think I
finally found the best
way I can contribute to the project; refund administrator.
I'm afraid the Kamailio license I sold you is nonrefundable.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
4319
days inactive
4320
days old
12 comments
4 participants
participants (4)
-
Alex Balashov -
Andreas Granig -
Daniel-Constantin Mierla -
Fred Posner