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

[alexsosic]

Hi Daniel,

I just tested this version and what I could notice is:

with the first kamailio node comming up and doing some test calls the
dialog records in the DB are not deleted after the call end.

On kamailio node failover (call in progress, and new node up with
hangup on client side) I've got this logs:
``` 4(85) NOTICE: <script>: [f:0409828030-t:0039040123123
id:NBr3x4WAap6jOlpzbz5KKIUkQfG8fGq- | BYE] Foreign dialog detected for
Call-ID: NBr3x4WAap6jOlpzbz5KKIUkQfG8fGq-
 4(85) WARNING: dialog [dlg_db_handler.c:246]: create_socket_info():
non-local socket <udp:172.16.234.95:5060>...ignoring
 4(85) WARNING: dialog [dlg_db_handler.c:246]: create_socket_info():
non-local socket <udp:172.16.234.95:5060>...ignoring```

Also I can confirm that in this case the dialog in the msgdb is also
present after the call end!

All the dialog values are correctly retrieved by the function and upon
call end we can correctly bill with cgrates.

What I do expect is that the dialogs are deleted (native and the ones
restored with dlg_db_load_callid() function) once the call has ended.

Kind regards,
--
Aleksandar Sosic
mail: alex.sosic at timenet.it
skype: alex.sosic
cell: +385 91 2505 146


On Wed, Apr 4, 2018 at 9:52 AM, Daniel-Constantin Mierla
<notifications at github.com> wrote:
> 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:
>
> 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.
>
> 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.
>
> 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 authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1274#issuecomment-379219662
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180406/4134cd4d/attachment.html>