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
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
On 29.03.20 14:49, Juha Heinanen wrote:
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.
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 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/50b0e5398b0ce698b287818d2c6fe426...
and exists when I build 5.3 at this commit:
https://github.com/kamailio/kamailio/commit/9ff491a881f326b5ee6eee4fd40c427f...
So looks like the latter broke something.
-- Juha
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:
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/50b0e5398b0ce698b287818d2c6fe426...
and exists when I build 5.3 at this commit:
https://github.com/kamailio/kamailio/commit/9ff491a881f326b5ee6eee4fd40c427f...
So looks like the latter broke something.
-- Juha
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
On 30.03.20 07:09, Juha Heinanen wrote:
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
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
On 30.03.20 09:24, Daniel-Constantin Mierla wrote:
On 30.03.20 07:09, Juha Heinanen wrote:
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
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...
I pushed two commits on master and branch 5.3 to skip reusing tcp connection id. See if it solves your case.
Cheers, Daniel
On 30.03.20 12:24, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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.
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 writes:
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...
Yes, it is in contact branch route:
lookup() => t_load_contacts() => t_next_contacts() => t_on_branch() => t_relay)()
-- Juha
On 30.03.20 12:16, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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...
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 -
Juha Heinanen