Re: [sr-dev] [kamailio/kamailio] Load dialogs from db at runtime, without restarting kamailio (#1274)

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.