11 Oct
2023
11 Oct
'23
7:51 a.m.
### Description
I've been looking at the ims_dialog module and notice that the documentation states
that db storage is not yet supported.
According to the source code that only partial true. Not sure if it's residues from
the other dialog module, or some unfinished work.
After some initial testing and small adjustments, the main issue seems to that for my use
the "Dialog-iD"/did is not filled. I can not see this being set for calls that
are not "concurrently confirmed".
The field in the database for this id is NON NULL, so the insert fails. It's also used
as WHERE-criteria when restarting and fetching the dialog_out entries, belonging to each
dialog_in, so it needs to be set for this to work.
This is not really a feature request. It's more about a confirmation that my
assumptions are correct, before trying to do the proposed changes.
### Expected behavior
I do assume that this "did"-field should be or be linked to the same did added
as Record-Route parameter, identifying each dialog.
#### Actual observed behavior
kamcmd dlg2.list displays NULL for Dialog-ID.
```
kamcmd dlg2.list
{
Size: 4096
Dialogs: {
Dialog: {
Entry: 1096
Id: 8069
RURI: sip:+4791500025@10.111.64.16;user=phone
From: sip:+4746180445@10.111.64.16;user=phone
Call-ID: 34c5d9f15ff42a0564f809cb35e19c75@10.111.64.16:5060
Caller Contact: sip:+4746180445@10.111.64.16:5060
Caller Route Set: <null string>
Dialog-ID: <null string>
From Tag: as4df55540
State: Confirmed
Ref: 2
dlg_outs: {
dlg_out: {
Entry: 2680
Id: 0
}
}
}
}
}
```
### Possible Solutions
Always set this did field when a new dialog is created.
I've also been studying the DB schema. All operations for the dialog_in table are done
using hash_entry and hash_id as keys. Why are they not used as primary key instead, which
would be much more efficient?
Also, having an integer with auto_increment as primary key would make this stop when the
integer hits max value, if it's not reset regularly. I can not see this field used
anywhere in the code either, so it could probably just be removed.
The same applies to dialog_out, but this one should have an index on the did field used
for looking up the corresponding entries too.
Altering this could have negative impact if there are old entries from a previous running
process laying around. A duplicate key on an insert should be handled, and updated
instead. The current behaviour would mean that Kamailio instead updates two records with
the same values.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
master
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04,
CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
CentOS 7.9
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3602
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3602(a)github.com>