### 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>
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [x] Related to issue #3602
#### Description
Added missing code for database backend to work. Tested basic scenarios locally for all db modes.
DB schema could be tweaked according to my thoughts in issue #3602, but that also applies to several other modules which are done in the same matter. Because of that, I didn't consider such a change now.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3603
-- Commit Summary --
* ims_dialog: Add support for database backend
-- File Changes --
M src/modules/ims_dialog/dlg_db_handler.c (9)
M src/modules/ims_dialog/dlg_handlers.c (52)
M src/modules/ims_dialog/dlg_hash.c (5)
M src/modules/ims_dialog/doc/ims_dialog_admin.xml (93)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3603.patchhttps://github.com/kamailio/kamailio/pull/3603.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3603
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3603(a)github.com>