I just committed the config (and kemi) function `dlg_db_load_callid(val)`,
which should load dialog record from database by matching on callid (it loads
also associated variables).
While not tested yet given lack of proper environment to simulate such scenario
(hopefully you can do it), there is still an issue that needs to be sorted out.
Respectively a high potential of having conflicts for internal dialog id. The
internal id is made from two integers, hash entry and hash id (h_entry, h_id).
h_entry is the index of the slot in the hash table used to store the dialog
structure, computed by hashing over call id. h_id is an incremented integer
specific for each hash table slot.
So, when loading a new record from database, if its h_id is not conflicting
with an existing dialog on the same hash table slot, all is ok, otherwise the
module is not going to work properly with two dialogs having same h_id.
Among solutions I thought of:
1) have the servers generating non conflicting h_id, by having a start value
different per server and an increment step larger than the number of servers.
Iirc, here was at some point a similar attempt, but somehow didn't make it.
Let's say one has two servers, first server starts allocating h_id from 1 and
increments by 2 (e.g: 1, 3, 5, ...) and the seconds start from 2 and increments
with 2 (2, 4, 6, ...). Those values can be set via mod params, eventually with
an option to rely on server_id.
This should be the least intrusive in the other modules built on top of dialog.
But it is rather rigid, with the example above, if one adds an extra server, it
needs to reconfigure the old ones, so each server starts from either 1, 2 or 3
and increment by 3. Of course, one can set increment step to a larger value,
like 100, and then has flexibility to deploy up to 1 hundred servers before
having to reconfigure in case there is need for more server.
2) add server_id as the third field in the dialog id. It will require review of
other modules using dialog and eventual code updates in those modules. One
column to store the server_id needs to be added to dialog db tables.
3) switch from this conflicting id system to something like string unique ids,
similar to what we have in usrloc records. This will require coding in other
modules, changes to database schema, etc., so more work comparing with the
above two, but could be the best in long term.
Most likely I am going to push code for option 1) for now, but it would be good
to see opinions from other devs, if they would prefer other option or propose
other variants.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1274#issuecomment-378512827
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
