Hi List

I wonder if some of the devs could look at the dialog code and maybe confirm my observation of this supposed Bug in Kamailio 5.6

Situation:

Two Kamailio, dialog counters synced via DMQ and each node using a local DB as dialog backend.

Goal is to count channel usage per customer.

modparam("dialog", "db_mode", 1 ) modparam("dialog", "enable_dmq", 1) modparam("dialog", "h_id_start", -1) # Use server_id modparam("dialog", "h_id_step", 2) modparam("dialog", "profiles_with_value", "custcallcounter")

If 'JohnDoe' is involved in a call, I do:

set_dlg_profile("custcallcounter","JohnDoe");

To check how many calls are busy by JohnDoe I do:

get_profile_size("custcallcounter","JohnDoe","$var(channel_use)");

Picture this situation:

JohnDoe is initiating a first call via Node1:

Node1 created the dialogue and variables, writes them to the database and replicates the dialog vars to Node2 => IN MEMORY

Nothing about the running dialog is being written to the Database on Node2, but get_profile_size returns the count on Node2.

So while the first call aka dialog is running via Node1, JohnDoe is initiating a second call, this time via Node2.

Node2 creates the dialog and writes this to the database. Then the profile with Name 'JohnDoe' is INCREASED on Node2.

This is when I suddenly find the dialog_vars on the Node2 database containing information about the dialog started on Node1. So I guess writing to a dialog counter triggers the dialog_vars being written to the Database.

When JohnDoe is ending it's first call, then the dialog and dialog_vars are cleaned out of the database on Node1, but NOT on Node2

What I fear happens next: They dialog_vars remaining on the Database of Node 2 accumulate more and more, making the database slower. When a call happens to re use the same hash id and entry, things start going really badly.

Could I be right?