22 Nov
2018
22 Nov
'18
7:10 a.m.
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(a)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@voda.interconnect.manxtelecom.im"
"hash_entry" "13725" "hash_id" "16494"
"dialog_key" "_uac_funew"
"dialog_value""sip:1231215423@voda.interconnect.manxtelecom.im"
1542374575.722001 [7 127.0.0.1:56858]
"HMSET""dialog_vars:entry::13725:16494:_uac_fu:sip:anonymous@voda.interconnect.manxtelecom.im"
"hash_entry" "13725" "hash_id" "16494"
"dialog_key" "_uac_fu"
"dialog_value""sip:anonymous@voda.interconnect.manxtelecom.im"
....
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: INFO:
Call-ID1-1511(a)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(a)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@9.7.8.1"
1542374585.810683 [7 127.0.0.1:56882]
"HMGET""dialog:entry::13725:16494:1-1511@9.7.8.1"
"hash_entry" "hash_id"
1542374585.810776 [7 127.0.0.1:56882]
"HMSET""dialog:entry::13725:16494:1-1511@9.7.8.1" "state"
"4" "timeout" "1542377585" "caller_cseq"
"1" "callee_cseq" "0"
"caller_contact""sip:0000123456@9.7.8.1:5084"
"callee_contact""sip:50622959898@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@9.7.8.1"
1542374585.810977 [7 127.0.0.1:56882]
"HMGET""dialog:entry::13725:16494:1-1511@9.7.8.1"
"hash_entry" "hash_id"
1542374585.811059 [7 127.0.0.1:56882]
"HMSET""dialog:entry::13725:16494:1-1511@9.7.8.1" "state"
"4" "timeout" "1542377585" "caller_cseq"
"1" "callee_cseq" "0"
"caller_contact""sip:0000123456@9.7.8.1:5084"
"callee_contact""sip:50622959898@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(a)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