[SR-Users] issue tracking dialogs with db_redis in kamailio 5.2

Daniel-Constantin Mierla miconda at gmail.com
Mon Nov 26 10:46:11 CET 2018


Hello,

On 22.11.18 13:10, David Escartín wrote:
>
> hello Daniel
>
> Yes. it's how you say, i see records for a dialog once it's connected. 
> I did not check with another DB driver, but i guess it would be the same. I will try anycase if you think it worths it.
> However, we would be looking for a scenario where the dialogs are stored at the DB just when created (dlg_manage) or when the intial invite is processed. 
> We would like to track them in early state, so if there is a switchover to another kamailio instance or a kamailio instance reset, a reply for example could be processed in the same dialog context, so we could apply the proper 
> features to it (rtpengine answer, custom dlg_var assigned during the initial invite treatment, etc).
>
> This would be really useful in case a switchover for example to avoid OWA issues in our environment.
>
> Do you think that could be feasible?

it is open source, so sure it is feasible. But as it was designed in the
first place, the module is writing the dialog record on 200ok for
initial INVITE. I have some items related to dialog in my todo list for
quite some time (unique id refactoring, removing dependence on tm
module, ...), but I am not sure when I get to them, hopefully in couple
of months, before development for 5.3 release series ends.

All the best,
Daniel


>
> best regards
> david
>
> On 20/11/18 16:16, Daniel-Constantin Mierla wrote:
>>
>> Hello,
>>
>> iirc, dialog module is writing to database when the call is answered,
>> before there should be no record in database for that call.
>>
>> Do you experience something different?
>>
>> In other words, if you tried with mysql, is something different in
>> the behaviour for writing to storage when comparing with using db_redis?
>>
>> Cheers,
>> Daniel
>>
>> On 19.11.18 10:53, David Escartín wrote:
>>>
>>> hello all
>>>
>>> using version 5.2.0-rc0 of kamailio, we are trying to track the dialogs of dialog module using db_redis module with this setup
>>> #!define DBURL_DIALOG "redis://127.0.0.1:6390/7"
>>>
>>> # ----- dialog params -----
>>> modparam("dialog", "db_url", DBURL_DIALOG)
>>> modparam("dialog", "enable_stats", 1)
>>> modparam("dialog", "hash_size", 16384)
>>> modparam("dialog", "dlg_flag", 31)
>>> modparam("dialog", "dlg_match_mode", 1)
>>> modparam("dialog", "db_mode", 1)
>>> modparam("dialog", "timer_procs", 1)
>>> modparam("dialog", "db_update_period", 1)
>>>
>>>
>>> # ----- db_redis params -----
>>> modparam("db_redis", "schema_path", "/usr/local/kamailio/share/kamailio/db_redis/kamailio")
>>> modparam("db_redis", "keys", "dialog=entry:hash_entry,hash_id,callid")
>>> modparam("db_redis", "keys", "dialog_vars=entry:hash_entry,hash_id,dialog_key,dialog_value")
>>>
>>>
>>> and we see it works and if a kamailio instance resets in the middle of a dialog it recovers all the dlg_vars and values because we have the db_skip_load to 0 in dialog module.
>>>
>>> But we have noticed that the redis is being written with the information of the dlg_var assigned until that moment when we get a provisional response with SDP, and we dom see a set on the redis with the dialog entry and id untill call is connected.
>>>
>>> Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: INFO: Call-ID 1-1511 at 9.7.8.1: Status 180
>>> Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog' while performing update
>>> Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update():   scan key 0 is 'hash_entry'
>>> Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update():   scan key 1 is 'hash_id'
>>>
>>> on the redis (we only see hmset for dialog_vars key)
>>> 1542374575.721816 [7 127.0.0.1:56858] "HMSET" "dialog_vars:entry::13725:16494:_uac_funew:sip:1231215423 at voda.interconnect.manxtelecom.im" "hash_entry" "13725" "hash_id" "16494" "dialog_key" "_uac_funew" "dialog_value" "sip:1231215423 at voda.interconnect.manxtelecom.im"
>>> 1542374575.722001 [7 127.0.0.1:56858] "HMSET" "dialog_vars:entry::13725:16494:_uac_fu:sip:anonymous at voda.interconnect.manxtelecom.im" "hash_entry" "13725" "hash_id" "16494" "dialog_key" "_uac_fu" "dialog_value" "sip:anonymous at voda.interconnect.manxtelecom.im"
>>> ....
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: INFO: Call-ID 1-1511 at 9.7.8.1: Status 200
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog_vars' while performing update
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update():   scan key 0 is 'hash_entry'
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update():   scan key 1 is 'hash_id'
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update():   scan key 2 is 'dialog_key'
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog' while performing update
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update():   scan key 0 is 'hash_entry'
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update():   scan key 1 is 'hash_id'
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog' while performing update
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update():   scan key 0 is 'hash_entry'
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update():   scan key 1 is 'hash_id'
>>> Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: INFO: Call-ID 1-1511 at 9.7.8.1: ACK received in A-Leg
>>>
>>> on the redis
>>> 1542374585.810520 [7 127.0.0.1:56882] "SCAN" "0" "MATCH" "dialog:entry::*" "COUNT" "1000"
>>> 1542374585.810672 [7 127.0.0.1:56882] "EXISTS" "dialog:entry::13725:16494:1-1511 at 9.7.8.1"
>>> 1542374585.810683 [7 127.0.0.1:56882] "HMGET" "dialog:entry::13725:16494:1-1511 at 9.7.8.1" "hash_entry" "hash_id"
>>> 1542374585.810776 [7 127.0.0.1:56882] "HMSET" "dialog:entry::13725:16494:1-1511 at 9.7.8.1" "state" "4" "timeout" "1542377585" "caller_cseq" "1" "callee_cseq" "0" "caller_contact" "sip:0000123456 at 9.7.8.1:5084" "callee_contact" "sip:50622959898 at 9.70.1.52:5060;transport=udp"
>>> 1542374585.810899 [7 127.0.0.1:56882] "SCAN" "0" "MATCH" "dialog:entry::*" "COUNT" "1000"
>>> 1542374585.810969 [7 127.0.0.1:56882] "EXISTS" "dialog:entry::13725:16494:1-1511 at 9.7.8.1"
>>> 1542374585.810977 [7 127.0.0.1:56882] "HMGET" "dialog:entry::13725:16494:1-1511 at 9.7.8.1" "hash_entry" "hash_id"
>>> 1542374585.811059 [7 127.0.0.1:56882] "HMSET" "dialog:entry::13725:16494:1-1511 at 9.7.8.1" "state" "4" "timeout" "1542377585" "caller_cseq" "1" "callee_cseq" "0" "caller_contact" "sip:0000123456 at 9.7.8.1:5084" "callee_contact" "sip:50622959898 at 9.70.1.52:5060;transport=udp"
>>>
>>>
>>> i don't see a redis set order to update the dialog entry key before the 200OK is received, to create and update state 1, etc. when created with dlg_manage command
>>>
>>> could you please check if we might be missing something?
>>>
>>> thanks a lot and regards
>>> david
>>>
>>>
>>> _______________________________________________
>>> 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.asipto.com
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Kamailio World Conference -- www.kamailioworld.com
>> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181126/f7df4b79/attachment.html>


More information about the sr-users mailing list