### 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 ```