[SR-Users] Using lock() correctly

Sebastian Damm damm at sipgate.de
Mon Jul 3 10:30:41 CEST 2017


Hi,

yes, it is. I'm really bad in fixing my configuration for the mailing
list or the bugtracker. But those two route calls do call
route[magic].

Best Regards,
Sebastian

On Mon, Jul 3, 2017 at 10:23 AM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Hello,
>
> first a quick check: is route[li] supposed to be route[magic]? Otherwise
> it is missing from your example.
>
> Cheers,
> Daniel
>
> On 03.07.17 10:04, Sebastian Damm wrote:
>> Hi again,
>>
>> since there really isn't much to find about the lock() function, can
>> somebody tell me if my assumptions about how it should work are wrong?
>> Daniel?
>>
>> Best Regards,
>> Sebastian
>>
>> On Wed, Jun 28, 2017 at 1:39 PM, Sebastian Damm <damm at sipgate.de> wrote:
>>> 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
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - www.asipto.com
> Kamailio World Conference - www.kamailioworld.com
>



More information about the sr-users mailing list