29 Mar
2020
29 Mar
'20
3:45 a.m.
I noticed that in 5.3 and master setting $du in branch route has no
effect. It works fine in 5.2 using exactly the same config.
-- Juha
29 Mar
29 Mar
8:49 a.m.
Juha Heinanen writes:
I noticed that in 5.3 and master setting $du in branch
route has no
effect. It works fine in 5.2 using exactly the same config.
This is pretty serious. If someone can point to possible source code
files, where this bug might have been originated from, I can start
digging changes from 5.2.
-- Juha
11:16 a.m.
On 29.03.20 14:49, Juha Heinanen wrote:
Juha Heinanen writes:
The branch route is executed inside t_fwd.c (like 354 in master branch).
You can try to do a diff of tm module between the branches to see if you
can spot something related. I remember I grouped some variables in a
structure at some point, but it should have not impacted old behaviour...
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
I noticed that in 5.3 and master setting $du in
branch route has no
effect. It works fine in 5.2 using exactly the same config.
This is pretty
serious. If someone can point to possible source code
files, where this bug might have been originated from, I can start
digging changes from 5.2.
1:33 p.m.
Daniel-Constantin Mierla writes:
The branch route is executed inside t_fwd.c (like 354
in master branch).
You can try to do a diff of tm module between the branches to see if you
can spot something related. I remember I grouped some variables in a
structure at some point, but it should have not impacted old
behaviour...
The bug does not exist, when I build 5.3 at this commit:
https://github.com/kamailio/kamailio/commit/50b0e5398b0ce698b287818d2c6fe42…
and exists when I build 5.3 at this commit:
https://github.com/kamailio/kamailio/commit/9ff491a881f326b5ee6eee4fd40c427…
So looks like the latter broke something.
-- Juha
4:39 p.m.
Have you tested with tcp/tls or with udp? There was a group of commits
trying to propagate the tcp connection id as much as possible to speed
up connection search, maybe that needs to be reset -- I can look into
it, if you tested for tcp/tls.
Cheers,
Daniel
On 29.03.20 19:33, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
The branch route is executed inside t_fwd.c (like
354 in master branch).
You can try to do a diff of tm module between the branches to see if you
can spot something related. I remember I grouped some variables in a
structure at some point, but it should have not impacted old
behaviour...
The bug does not exist, when I build 5.3 at this commit:
https://github.com/kamailio/kamailio/commit/50b0e5398b0ce698b287818d2c6fe42…
and exists when I build 5.3 at this commit:
https://github.com/kamailio/kamailio/commit/9ff491a881f326b5ee6eee4fd40c427…
So looks like the latter broke something.
-- Juha
30 Mar
30 Mar
1:09 a.m.
Daniel-Constantin Mierla writes:
Have you tested with tcp/tls or with udp? There was a
group of commits
trying to propagate the tcp connection id as much as possible to speed
up connection search, maybe that needs to be reset -- I can look into
it, if you tested for tcp/tls.
This is what has no effect in branch route:
Mar 29 10:19:28 char /usr/bin/sip-proxy[26162]: INFO: ********* du =
sip:127.0.0.1:5090;transport=tcp
-- Juha
3:24 a.m.
On 30.03.20 07:09, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Does this happen after a usrloc location lookup? Trying to figure out
what destination-related processing is done before to see what fields
were set...
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Have you tested with tcp/tls or with udp? There
was a group of commits
trying to propagate the tcp connection id as much as possible to speed
up connection search, maybe that needs to be reset -- I can look into
it, if you tested for tcp/tls.
This is what has no effect in branch route:
Mar 29 10:19:28 char /usr/bin/sip-proxy[26162]: INFO: ********* du =
sip:127.0.0.1:5090;transport=tcp
4:26 a.m.
On 30.03.20 09:24, Daniel-Constantin Mierla wrote:
On 30.03.20 07:09, Juha Heinanen wrote:
I pushed two commits on master and branch 5.3 to skip reusing tcp
connection id. See if it solves your case.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Daniel-Constantin Mierla writes:
Does this happen after a usrloc location lookup?
Trying to figure out
what destination-related processing is done before to see what fields
were set... Have you tested with tcp/tls or with udp? There
was a group of commits
trying to propagate the tcp connection id as much as possible to speed
up connection search, maybe that needs to be reset -- I can look into
it, if you tested for tcp/tls.
This is what has no effect in branch route:
Mar 29 10:19:28 char /usr/bin/sip-proxy[26162]: INFO: ********* du =
sip:127.0.0.1:5090;transport=tcp
7 a.m.
On 30.03.20 12:24, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
OK, thanks for testing and the feedback. Once I get a bit of time, I
will review these changes to see what can be done to make them work
properly, they were useful in some cases.
These commits were pushed to branch 5.3 already.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
I pushed two commits on master and branch 5.3 to
skip reusing tcp
connection id. See if it solves your case.
I tried with master and now setting of
$du in branch route worked OK.
6:16 a.m.
Daniel-Constantin Mierla writes:
Yes, it is in contact branch route:
lookup() => t_load_contacts() => t_next_contacts() =>
t_on_branch() => t_relay)()
-- Juha
Mar 29
10:19:28 char /usr/bin/sip-proxy[26162]: INFO: ********* du =
sip:127.0.0.1:5090;transport=tcp
Does this happen after a usrloc location lookup? Trying to figure out
what destination-related processing is done before to see what fields
were set...
6:57 a.m.
On 30.03.20 12:16, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Yes, it is in contact branch route:
lookup() => t_load_contacts() => t_next_contacts() =>
t_on_branch() => t_relay)()
OK. I wanted to be sure it doesn't come via other execution path and
other past commits need to be analyzed.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Mar 29
10:19:28 char /usr/bin/sip-proxy[26162]: INFO: ********* du =
sip:127.0.0.1:5090;transport=tcp
Does this happen after a usrloc location lookup?
Trying to figure out
what destination-related processing is done before to see what fields
were set...
1739
days inactive
1740
days old
12 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen