24 Jan
2013
24 Jan
'13
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 :)