[sr-dev] [kamailio/kamailio] callout from event_route [tm:local-response] only occurs once (Issue #3064)

dpaape notifications at github.com
Thu Mar 24 15:31:01 CET 2022


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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3064
You are receiving this because you are subscribed to this thread.

Message ID: <kamailio/kamailio/issues/3064 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20220324/6bc47fa8/attachment.htm>


More information about the sr-dev mailing list