### 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/3...@github.com>_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
