Hi Daniel,<br>
<br>
I just tested this version and what I could notice is:<br>
<br>
with the first kamailio node comming up and doing some test calls the<br>
dialog records in the DB are not deleted after the call end.<br>
<br>
On kamailio node failover (call in progress, and new node up with<br>
hangup on client side) I've got this logs:<br>
``` 4(85) NOTICE: <script>: [f:0409828030-t:0039040123123<br>
id:NBr3x4WAap6jOlpzbz5KKIUkQfG8fGq- | BYE] Foreign dialog detected for<br>
Call-ID: NBr3x4WAap6jOlpzbz5KKIUkQfG8fGq-<br>
 4(85) WARNING: dialog [dlg_db_handler.c:246]: create_socket_info():<br>
non-local socket <udp:172.16.234.95:5060>...ignoring<br>
 4(85) WARNING: dialog [dlg_db_handler.c:246]: create_socket_info():<br>
non-local socket <udp:172.16.234.95:5060>...ignoring```<br>
<br>
Also I can confirm that in this case the dialog in the msgdb is also<br>
present after the call end!<br>
<br>
All the dialog values are correctly retrieved by the function and upon<br>
call end we can correctly bill with cgrates.<br>
<br>
What I do expect is that the dialogs are deleted (native and the ones<br>
restored with dlg_db_load_callid() function) once the call has ended.<br>
<br>
Kind regards,<br>
--<br>
Aleksandar Sosic<br>
mail: alex.sosic@timenet.it<br>
skype: alex.sosic<br>
cell: +385 91 2505 146<br>
<br>
<br>
On Wed, Apr 4, 2018 at 9:52 AM, Daniel-Constantin Mierla<br>
<notifications@github.com> wrote:<br>
> I just committed the config (and kemi) function dlg_db_load_callid(val),<br>
> which should load dialog record from database by matching on callid (it<br>
> loads also associated variables).<br>
><br>
> While not tested yet given lack of proper environment to simulate such<br>
> scenario (hopefully you can do it), there is still an issue that needs to be<br>
> sorted out. Respectively a high potential of having conflicts for internal<br>
> dialog id. The internal id is made from two integers, hash entry and hash id<br>
> (h_entry, h_id). h_entry is the index of the slot in the hash table used to<br>
> store the dialog structure, computed by hashing over call id. h_id is an<br>
> incremented integer specific for each hash table slot.<br>
><br>
> So, when loading a new record from database, if its h_id is not conflicting<br>
> with an existing dialog on the same hash table slot, all is ok, otherwise<br>
> the module is not going to work properly with two dialogs having same h_id.<br>
><br>
> Among solutions I thought of:<br>
><br>
> have the servers generating non conflicting h_id, by having a start value<br>
> different per server and an increment step larger than the number of<br>
> servers. Iirc, here was at some point a similar attempt, but somehow didn't<br>
> make it. Let's say one has two servers, first server starts allocating h_id<br>
> from 1 and increments by 2 (e.g: 1, 3, 5, ...) and the seconds start from 2<br>
> and increments with 2 (2, 4, 6, ...). Those values can be set via mod<br>
> params, eventually with an option to rely on server_id.<br>
><br>
> This should be the least intrusive in the other modules built on top of<br>
> dialog. But it is rather rigid, with the example above, if one adds an extra<br>
> server, it needs to reconfigure the old ones, so each server starts from<br>
> either 1, 2 or 3 and increment by 3. Of course, one can set increment step<br>
> to a larger value, like 100, and then has flexibility to deploy up to 1<br>
> hundred servers before having to reconfigure in case there is need for more<br>
> server.<br>
><br>
> add server_id as the third field in the dialog id. It will require review of<br>
> other modules using dialog and eventual code updates in those modules. One<br>
> column to store the server_id needs to be added to dialog db tables.<br>
><br>
> switch from this conflicting id system to something like string unique ids,<br>
> similar to what we have in usrloc records. This will require coding in other<br>
> modules, changes to database schema, etc., so more work comparing with the<br>
> above two, but could be the best in long term.<br>
><br>
> Most likely I am going to push code for option 1) for now, but it would be<br>
> good to see opinions from other devs, if they would prefer other option or<br>
> propose other variants.<br>
><br>
> —<br>
> You are receiving this because you authored the thread.<br>
> Reply to this email directly, view it on GitHub, or mute the thread.<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you commented.<br />Reply to this email directly, <a href="https://github.com/kamailio/kamailio/issues/1274#issuecomment-379219662">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AF36Zdm0N9uhocFeLkwRMmNiswEsEeVxks5tl0nLgaJpZM4QAl53">mute the thread</a>.<img src="https://github.com/notifications/beacon/AF36ZesFrSNl36EZB0tpctQZDaE2hOKPks5tl0nLgaJpZM4QAl53.gif" height="1" width="1" alt="" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/kamailio/kamailio/issues/1274#issuecomment-379219662"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/kamailio/kamailio","title":"kamailio/kamailio","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/kamailio/kamailio"}},"updates":{"snippets":[{"icon":"PERSON","message":"@alexsosic in #1274: Hi Daniel,\n\nI just tested this version and what I could notice is:\n\nwith the first kamailio node comming up and doing some test calls the\ndialog records in the DB are not deleted after the call end.\n\nOn kamailio node failover (call in progress, and new node up with\nhangup on client side) I've got this logs:\n``` 4(85) NOTICE: \u003cscript\u003e: [f:0409828030-t:0039040123123\nid:NBr3x4WAap6jOlpzbz5KKIUkQfG8fGq- | BYE] Foreign dialog detected for\nCall-ID: NBr3x4WAap6jOlpzbz5KKIUkQfG8fGq-\n 4(85) WARNING: dialog [dlg_db_handler.c:246]: create_socket_info():\nnon-local socket \u003cudp:172.16.234.95:5060\u003e...ignoring\n 4(85) WARNING: dialog [dlg_db_handler.c:246]: create_socket_info():\nnon-local socket \u003cudp:172.16.234.95:5060\u003e...ignoring```\n\nAlso I can confirm that in this case the dialog in the msgdb is also\npresent after the call end!\n\nAll the dialog values are correctly retrieved by the function and upon\ncall end we can correctly bill with cgrates.\n\nWhat I do expect is that the dialogs are deleted (native and the ones\nrestored with dlg_db_load_callid() function) once the call has ended.\n\nKind regards,\n--\nAleksandar Sosic\nmail: alex.sosic@timenet.it\nskype: alex.sosic\ncell: +385 91 2505 146\n\n\nOn Wed, Apr 4, 2018 at 9:52 AM, Daniel-Constantin Mierla\n\u003cnotifications@github.com\u003e wrote:\n\u003e I just committed the config (and kemi) function dlg_db_load_callid(val),\n\u003e which should load dialog record from database by matching on callid (it\n\u003e loads also associated variables).\n\u003e\n\u003e While not tested yet given lack of proper environment to simulate such\n\u003e scenario (hopefully you can do it), there is still an issue that needs to be\n\u003e sorted out. Respectively a high potential of having conflicts for internal\n\u003e dialog id. The internal id is made from two integers, hash entry and hash id\n\u003e (h_entry, h_id). h_entry is the index of the slot in the hash table used to\n\u003e store the dialog structure, computed by hashing over call id. h_id is an\n\u003e incremented integer specific for each hash table slot.\n\u003e\n\u003e So, when loading a new record from database, if its h_id is not conflicting\n\u003e with an existing dialog on the same hash table slot, all is ok, otherwise\n\u003e the module is not going to work properly with two dialogs having same h_id.\n\u003e\n\u003e Among solutions I thought of:\n\u003e\n\u003e have the servers generating non conflicting h_id, by having a start value\n\u003e different per server and an increment step larger than the number of\n\u003e servers. Iirc, here was at some point a similar attempt, but somehow didn't\n\u003e make it. Let's say one has two servers, first server starts allocating h_id\n\u003e from 1 and increments by 2 (e.g: 1, 3, 5, ...) and the seconds start from 2\n\u003e and increments with 2 (2, 4, 6, ...). Those values can be set via mod\n\u003e params, eventually with an option to rely on server_id.\n\u003e\n\u003e This should be the least intrusive in the other modules built on top of\n\u003e dialog. But it is rather rigid, with the example above, if one adds an extra\n\u003e server, it needs to reconfigure the old ones, so each server starts from\n\u003e either 1, 2 or 3 and increment by 3. Of course, one can set increment step\n\u003e to a larger value, like 100, and then has flexibility to deploy up to 1\n\u003e hundred servers before having to reconfigure in case there is need for more\n\u003e server.\n\u003e\n\u003e add server_id as the third field in the dialog id. It will require review of\n\u003e other modules using dialog and eventual code updates in those modules. One\n\u003e column to store the server_id needs to be added to dialog db tables.\n\u003e\n\u003e switch from this conflicting id system to something like string unique ids,\n\u003e similar to what we have in usrloc records. This will require coding in other\n\u003e modules, changes to database schema, etc., so more work comparing with the\n\u003e above two, but could be the best in long term.\n\u003e\n\u003e Most likely I am going to push code for option 1) for now, but it would be\n\u003e good to see opinions from other devs, if they would prefer other option or\n\u003e propose other variants.\n\u003e\n\u003e —\n\u003e You are receiving this because you authored the thread.\n\u003e Reply to this email directly, view it on GitHub, or mute the thread.\n"}],"action":{"name":"View Issue","url":"https://github.com/kamailio/kamailio/issues/1274#issuecomment-379219662"}}}</script>