[SR-Users] Using lock() correctly
Sebastian Damm
damm at sipgate.de
Wed Jun 28 13:39:07 CEST 2017
Hi,
for a project I need to make sure, I have a setup where I get
mirror-traffic into Kamailio which has to do something with it. To
work correctly, I need to make sure, the initial INVITE is processed
correctly before any reply to the same call. So I thought I use lock()
and unlock() for it.
This is what the relevant kamailio.cfg part looks like:
request_route {
xlog("L_INFO", "Got new packet $rm: $si => $Ri\n");
route(li);
}
onreply_route {
xlog("L_INFO", "Got new packet $rm: $si => $Ri - Reply Code $rs\n");
route(li);
}
route[magic] {
lock("$ci");
xlog("L_INFO", "Obtained lock, calling lua...\n");
if(!lua_run("handle_packet")) {
xlog("L_ERR", "SCRIPT: failed to execute lua function!\n");
}
unlock("$ci");
xlog("L_INFO", "Lua finished, released lock...\n");
drop;
exit;
}
And this is what the log says:
Jun 28 13:27:04 busch /usr/sbin/kamailio[18836]: INFO: <script>: Got
new packet INVITE: 172.20.21.247 => 172.20.21.4
Jun 28 13:27:04 busch /usr/sbin/kamailio[18836]: INFO: <script>:
Obtained lock, calling lua...
Jun 28 13:27:04 busch /usr/sbin/kamailio[18836]: INFO: app_lua
[app_lua_sr.c:98]: lua_sr_log(): some logging
Jun 28 13:27:04 busch /usr/sbin/kamailio[18837]: INFO: <script>: Got
new packet INVITE: 172.20.21.4 => 172.20.21.247 - Reply Code 407
Jun 28 13:27:04 busch /usr/sbin/kamailio[18837]: INFO: <script>:
Obtained lock, calling lua...
Jun 28 13:27:04 busch /usr/sbin/kamailio[18837]: INFO: <script>: Lua
finished, released lock...
Jun 28 13:27:04 busch /usr/sbin/kamailio[18836]: INFO: app_lua
[app_lua_sr.c:98]: lua_sr_log(): some more logging
As far as I understand the documentation, the second packet should
wait for the lock on the Call-ID before executing the lua function. So
process 18836 should finish its lua execution before 18837 can do
anything further. Did I completely misunderstand the lock() function?
I'm using Kamailio 5.0.2.
Thanks for helping me understand what Kamailio is doing here.
Best Regards,
Sebastian
More information about the sr-users
mailing list