version: kamailio 5.5.2 (arm6/linux) 55e232 raspberry pi 3b
I initially stated that I was running on 5.5.3 but I was mistaken. However I checked the 5.5.3 source and it appears to be the same.
I think that there is a bug in the tm module with respect to the "tm:local-response" event route. In the "t_reply.c" file, there is a static variable called '_tm_local_response_set_lookup'. This variable is initialized at load time to zero. It is checked in the '_reply_light()' routine and will initiate a local callback from the config script if "armed". The problem as I see it is that if the callback is readied, the variable is set to one. But it is never reset.
So the observed behavior is as follows. A REGISTER is received and the request_route arms the callback. The REGISTER requires an authorization (local database sqlite). After the 401 is sent back, the callback via the event route is called as expected. All good except that the event route script fragment is never executed again after the first call... ever, even if it's a new REGISTER request. I would think that somewhere in the tm module, the variable should be reset to zero so that subsequent transactions can initiate the event route again. Or maybe the variable ought to live somewhere in the transaction cell???
. . . t_on_reply ("MY_FRAG"); t_on_failure ("MY_FRAG"); . . . event_route [tm:local-response] { xlog ("L_NOTICE", IN tm:local-response\n"); my_function(); } . . .
So 'my_function()' is only called once.
This appears to be occurring in 5.6, 5.7, and devel- branch as well. Simple example config:
``` #!KAMAILIO
loadmodule "pv" loadmodule "tm" loadmodule "xlog"
route { xinfo("[$rm $ci-$cs] Src:[$si:$sp] RURI:[$ru] To:[$tu] From:[$fu]\n");
t_send_reply("404", "Not Found"); exit; }
event_route[tm:local-response] { xcrit("[$rm $ci-$cs] tm:local-response replied locally\n"); } ```
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Will have a look if it can be still reproduced.
Hey @dpaape and @whosgonna,
A PR has opened to fix this. Can you help and verify whether this solved the problem?
Thanks!
I'll try to get around to this. It was pretty simple to test if memory serves.
I pushed an alternative commit to master branch, to avoid event route lookup every time on replies (more comments in PR #3687). Should master fail to work, it has to be investigated further. If ok, commit will be backported.
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #3064 as completed.
There was a PR proposed and an alternative implementation added. So this should be fixed, close.