<div dir="ltr">I can confirm the bug is still present with a SIGTERM shutdown.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 May 2016 at 10:52, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<tt>Hi Pete,<br>
<br>
By doing kill -9, you completely kill ALL opensips processes, so
there is no cleanup/flush during shutdown. On crashes, the worker
processes crashes - the attendant cannot crash (as it is not doing
anything), so this process can do the shutdown in a proper way.<br>
<br>
Can you try to see if the call is properly recover if you do
normal restart (no SIGKILL, but SIGTERM) ? If it does, please take
a snapshot of the db entry (for that call) while opensips is down
- one for KILL, one for TERM; and let's see the differences -
maybe some dialog data gets flushed only during shutdown.<br>
<br>
Regards,<br>
</tt><span class="">
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre>
</span><div><div class="h5"><div>On 18.05.2016 10:53, Pete Kelly wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Yes exactly - in fact I did not restart opensips, I
waited until the call is established, and until dialog had
flushed to DB and then killall -9 opensips to simulate a crash.
<div><br>
</div>
<div>Upon restart the dialog was loaded in from database</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 17 May 2016 at 18:18, Bogdan-Andrei
Iancu <span dir="ltr"><<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> <tt>Hi Pete,<br>
<br>
No, this is not a know bug, nor an intended behavior.
So, simply restarting opensips during a TH call will
lead to this error ? no special setup, just a proxy
between 2 end points, right ?<br>
<br>
Regards,<br>
</tt>
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre>
<div>
<div>
<div>On 17.05.2016 16:36, Pete Kelly wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">I am seeing something interesting
with topology_hiding + dialog on 2.1. If I let the
dialog flush to the DB and kill opensips, opensips
loads back in the dialog info on startup as
expected.
<div><br>
</div>
<div>However any new in dialog requests (e.g. BYE)
do not proxy - it looks like Via, Call-ID and
Contact are restored but ruri is not - which
makes OpenSIPS loop the request back to itself. <br>
</div>
<div><br>
</div>
<div>For reference, to "enable" topology hiding, I
am simply calling topology_hiding("C") then in
has_totag() I am calling topology_hiding_match()</div>
<div><br>
</div>
<div>If I perform the same test without topology
hiding, the in-dialog requests continue to proxy
as normal.</div>
<div><br>
Is this a known bug/quirk, is it likely I am not
performing some check or test that i need to? </div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>