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

Thu Nov 22 13:10:15 CET 2018

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?

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-ID1-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-ID1-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-ID1-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181122/8812e3b9/attachment.html>