### Description
While debugging an issue in Kamailio 5.4, I compiled/installed master to see if the issue persists. However, I immediately ran into multiple issues with dialog in master:
#### Using enable_dmq=1
With dmq enabled, I receive the following log lines which did not appear when running 5.4:
``` CRITICAL: dialog [dlg_timer.c:129]: insert_dlg_timer(): Trying to insert a bogus dlg tl=0x7fa0bc21fc80 tl->next=0x7fa0bbf46ba8 tl->prev=0x7fa0bbf46ba8 CRITICAL: dialog [dlg_dmq.c:314]: dlg_dmq_handle_msg(): Unable to insert dlg timer 0x7fa0bc21fc20 [2687:66928] ```
#### Using database
When using database persistence (sqlite and db_mode=3 (SHUTDOWN)), dialogs are not persisted across restarts (which was working in 5.4). There are no obvious log lines, except when I end the call after restarting Kamailio I receive a "unable to find dialog for BYE" message which would be expected if the dialog did not persist.
### Troubleshooting
- I ran the same configuration using 5.4 and neither issue occurred. - I attempted to identify the troublesome commit by checking out/compiling older commits based on the commit history of the dialog module, but could only go so far back until builds started failing with `module not found: modules/siprepo`. As such I was not able to identify when the behavior changed.
#### Reproduction
DMQ issue: Use dialog module with dmq enabled and start a call that has `dlg_manage();` in the path. My configuration has the following settings:
``` modparam("dmq", "server_address", SERVER_ADDRESS_DMQ) modparam("dmq", "notification_address", "redacted") modparam("dmq", "notification_address", "redacted") modparam("dmq", "num_workers", 6) modparam("dialog", "default_timeout", 14520) modparam("dialog", "profiles_with_value", "group") modparam("dialog", "enable_dmq", 1) modparam("dialog", "h_id_start", 0) modparam("dialog", "h_id_step", 16) ```
DB issue: Use dialog module with db enabled. Start a call that has `dlg_manage();` in the path and keep the call open. Observe `kamcmd dlg.list` shows the dialog. Restart kamailio. Observe `kamcmd dlg.list` no longer lists any dialogs. My configuration has the following additional settings:
``` modparam("dialog", "db_url", "sqlite:////kamailio/kamailio.sqlite") modparam("dialog", "db_mode", 3) ```
### Additional Information
**Kamailio Version**
``` version: kamailio 5.7.0-dev0 (x86_64/linux) f1dcb6 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: f1dcb6 compiled on 23:18:23 Aug 15 2022 with gcc 8.3.0``` ```
**Operating System**
``` Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster ```
Thanks for the report. It probably make sense to focus on one topic before investigating the other. Regarding the git compile tests and the siprepo issue - maybe it was created from some commit before, and you can just delete it in the modules directory for the further tests.
Thanks for the tip to delete the failing module directory when building.
I found the DMQ log lines appear to start with commit 80beb29ac0204697a8964231b441ac37866a4a1c. This hinted me to the fact that perhaps `insert_dlg_timer` was being called twice, and the problem might be due to my config self-referencing the local server in dmq.notification_address. For example:
``` modparam("dmq", "server_address", "sip:LOCAL_ADDRESS") modparam("dmq", "notification_address", "sip:LOCAL_ADDRESS") modparam("dmq", "notification_address", "sip:REMOTE_ADDRESS_1") modparam("dmq", "notification_address", "sip:REMOTE_ADDRESS_2") ```
I did this as my config file is dynamically generated based on shared metadata and it was easier to script. Just a note that the output of `kamcmd dmq.list_nodes` is the same with or without the self-referenced notification_address, so I assumed the self-reference was OK/ignored. My bad!
I've removed the self-reference in my config and the errors have disappeared. I'd put the DMQ errors down to user error.
The DB persistence problem remains with the above fix to my config, so I'll continue exploring and update here.
I've determined the commit where dialog with db_mode SHUTDOWN started not working is 1ff86ffceede46c7a67fec92c8319c34c916a545.
I have submitted PR #3221 with additional details for consideration.
Closed #3218 as completed.