<div dir="ltr"><div dir="ltr">Apologies for not having included the sr-users in the previous email. Anyhow, the solution suggested by Social Boh indeed worked, as a side effect of which we would not run into the issue described. <div><br><div><b>NOTE:</b> There was a peculiar configuration in keepalived with keeping both the nodes as BACKUP and setting the 'nopreempt' flag only in the actual MASTER(one with higher 'priority') side to make the keepalived thing to work properly.</div><div><br><div>However, I was wondering if someone could confirm if this issue has been fixed inside the source code itself as I am using an older release v5.3.2</div><div><br></div><div>Regards,</div><div>Harneet Singh</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 17, 2020 at 9:52 PM harneet singh <<a href="mailto:hbilling@gmail.com">hbilling@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Social Boh,<div><br></div><div>I will investigate this possibility and if it does work in our case, that should circumvent the issue.</div><div>In addition, is there a fix known to the SR-Users which could be available inside the Dispatcher module to cause syncing just like the syncing is there in the Dialog module via DMQ. I wanted to check this as I am using v5.3.2 and unaware if new releases could have fixed this issue?</div><div><br></div><div>Regards,</div><div>Harneet Singh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 16, 2020 at 10:46 PM Social Boh <<a href="mailto:social@bohboh.info" target="_blank">social@bohboh.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Maybe a option is leave the secondary like primary when primary
go up newly.</p>
<p>Example: Primary go down, Secondary is the new Primary. Primary
came back up but Secondary still is the VIP and still process the
calls.<br>
</p>
<p>Only if Secondary go down, primary is the new VIP.</p>
<p>The keepalived parameter for this behaviour is:<br>
</p>
<p style="margin-bottom:0cm" align="justify">
<font face="Times New Roman, serif"><font style="font-size:12pt" size="3"><span style="font-style:normal"><b>nopreempt</b></span></font></font></p>
<pre cols="72">---
I'm SoCIaL, MayBe</pre>
<div>El 16/12/2020 a las 11:57 a. m.,
harneet singh escribió:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi All,
<div><br>
</div>
<div>I am using Kamailio in HA mode with Keepalived providing
the VIP(Virtual IP) functionality, and have run into a rather
peculiar issue.</div>
<div><br>
</div>
<div><u>Setup:</u></div>
<div>
<div><br>
</div>
<div>Caller ------------ KamailioVIP(<b>Primary </b>and <b>Secondary</b>
Kamailio)------- Callee</div>
<div><br>
</div>
<div> HA provided by Keepalived</div>
<div> DMQ is used between the Primary and Secondary
Kamailio for dialog sync</div>
<div><br>
</div>
<div><b><i><u>Issue Seen:</u></i></b></div>
<div><b><i><u><br>
</u></i></b></div>
<div><b><i><u>Suppose the Primary Kamailio has been
brought down</u></i></b> and the Secondary one is
actually active and tied to the VIP.</div>
<div><br>
</div>
<div>When a call is fired from the Caller, it traverses
through the Secondary Kamailio and lands onto the callee.
The dialogs are updated properly. At this point, the Primary
Kamailio is brought up, and dialog state is synced due to
the DMQ module.</div>
<div>The Keepalived will now attach the VIP to the Primary
Instance. If the caller hangs up the phone at this point,
the BYE sip message traverses through the Primary Kamailio
instance to the callee and the call is cleared, but there
are two issues here.</div>
<div><br>
</div>
<div> 1. The Primary Kamailio throws an error in <b>ds_load_remove()
</b>saying that it cannot find the load for the specific
call id. This is apparently due to the fact that the
dispatcher data is not synced between the two modules but
dialog data is. So dialog wise, things are fine. Can this be
fixed somehow?</div>
<div><br>
</div>
<div> 2. The above is still as grave a problem as the dialogs
are cleared. BUT, if we check the '<b>kamcmd dispatcher.list</b>'
on the <b>SECONDARY</b> kamailio even well after the call
is cleared, the <b>DLGLOAD</b> shows 1. Since we are using
the <b>Call Load based distribution</b> for the
dispatching, this is effectively one call stuck on the
dispatcher, which leads to resource leak.</div>
<div><br>
</div>
<div>Is this a known issue, and if so, do we have a way to
circumvent this? </div>
<div><br>
</div>
<div>Regards,</div>
<div>Harneet Singh </div>
-- <br>
<div dir="ltr">"Once you eliminate the
impossible, whatever remains, no matter how improbable, must
be the truth" - Sir Arthur Conan Doyle<br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Kamailio (SER) - Users Mailing List
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">"Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle<br></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">"Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle<br></div></div>