<p>I don't think this is a DMQ issue specifically, but more a question of what should happen in <em>any</em> replicated situation (including shared DB).</p>
<p>Perhaps the solution is, indeed, for nathelper to compare the received socket on the contact against the local socket(s) and either send or not send the keepalive accordingly. I'm not sure if this is already the case since I haven't checked the code, but I assume not given the observed behaviour.</p>
<p>Alternatively, given that functionality already exists in nathelper for filtering on server_id in DB mode, we should also add the server_id to the contact in memory and include it in the replicated copy.</p>
<p>The question remains, however, in the event of a node going down, which node is going to take over the keepalives and how will it know to do so? Again, this applies to shared DB as much as it does in-memory/DMQ.</p>
<p>Either way, I'm happy to add any necessary mods to dmq/dmq_usrloc modules.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/kamailio/kamailio/issues/1299#issuecomment-341713760">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AF36ZWqAugCLxmwMNsUi6fmyxg214iOcks5syx8VgaJpZM4QPgdU">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AF36Zd1QFsABIgjrr7PgaX1oD0qFUkELks5syx8VgaJpZM4QPgdU.gif" width="1" /></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/1299#issuecomment-341713760"></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":"@charlesrchance in #1299: I don't think this is a DMQ issue specifically, but more a question of what should happen in *any* replicated situation (including shared DB).\r\n\r\nPerhaps the solution is, indeed, for nathelper to compare the received socket on the contact against the local socket(s) and either send or not send the keepalive accordingly. I'm not sure if this is already the case since I haven't checked the code, but I assume not given the observed behaviour.\r\n\r\nAlternatively, given that functionality already exists in nathelper for filtering on server_id in DB mode, we should also add the server_id to the contact in memory and include it in the replicated copy.\r\n\r\nThe question remains, however, in the event of a node going down, which node is going to take over the keepalives and how will it know to do so? Again, this applies to shared DB as much as it does in-memory/DMQ.\r\n\r\nEither way, I'm happy to add any necessary mods to dmq/dmq_usrloc modules."}],"action":{"name":"View Issue","url":"https://github.com/kamailio/kamailio/issues/1299#issuecomment-341713760"}}}</script>