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:

CentOS 7.9

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.