<div dir="ltr"><div>Hi Bogdan,</div><div><br></div><div>Just wondering if you've had a chance to look at this? We're at a week of this fix working well with no ill observed side effects; so I'm pretty happy that this is a solution, but I need to work out whether I want to compile my own apt package for this module to pin my changes :)</div><div><br></div><div>Thanks,</div><div>Andrew</div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 16 Jan 2026 at 23:44, Bogdan-Andrei Iancu <<a href="mailto:bogdan@opensips.org">bogdan@opensips.org</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">Hi Andrew,<br>
<br>
Thanks for the analysis and the detailed explanations. Let me review in <br>
the next days and come back to you<br>
<br>
Regards,<br>
<br>
Bogdan-Andrei Iancu<br>
<br>
OpenSIPS Founder and Developer<br>
   <a href="https://www.opensips-solutions.com" rel="noreferrer" target="_blank">https://www.opensips-solutions.com</a><br>
   <a href="https://www.siphub.com" rel="noreferrer" target="_blank">https://www.siphub.com</a><br>
<br>
On 16.01.2026 12:08, Andrew Yager wrote:<br>
> Hi,<br>
><br>
> Following up on my last BLF getting stuck on "early/ringing" state<br>
> after calls end, the cause of the bug I thought was wrong. But I have<br>
> found the cause and have a proposed fix, but I have some questions<br>
> about the timer behavior that I'd appreciate input on.<br>
><br>
> When pua_dialoginfo publishes dialog state via the TM callback (for<br>
> 180 Ringing responses), it calculates the presence record lifetime as:<br>
><br>
>      expire = t->uac[branch].request.fr_timer.time_out - get_ticks();<br>
><br>
> In our environment (OpenSIPS 3.4.16, mid-registrar config,<br>
> fr_timeout=30, fr_inv_timeout=180), this was returning values as low<br>
> as 1 second, causing the presence record to expire before the dialog<br>
> callback could update it with "confirmed" or "terminated" states. This<br>
> leaves orphan "early" presence records that cause BLF to remain stuck.<br>
><br>
> I've tested a fix that replaces the FR timer calculation with<br>
> DEFAULT_CREATED_LIFETIME (3600 seconds) at lines 269 and 295 in<br>
> pua_dialoginfo.c. This aligns the TM callback with the dialog<br>
> callback, which already uses dlg->lifetime for CONFIRMED/TERMINATED<br>
> states. The fix works - I've verified it by applying the fix,<br>
> reverting to original code (bug returns), and re-applying the fix<br>
> (works again).<br>
><br>
> I'v re-submitted the bug report for this at<br>
> <a href="https://github.com/OpenSIPS/opensips/issues/3802" rel="noreferrer" target="_blank">https://github.com/OpenSIPS/opensips/issues/3802</a> but what I don't<br>
> fully understand is why the FR timer remainder is so short in the<br>
> first place. With fr_timeout=30, I'd expect around 29 seconds<br>
> remaining if 180 Ringing arrives within a second of the INVITE.<br>
> Instead we're seeing around 1 second. I'm wondering if this is related<br>
> to mid-registrar mode having multiple transactions, or perhaps the<br>
> timer is in some transitional state when the callback reads it.<br>
><br>
> Does anyone know if there was a specific reason for using the FR timer<br>
> remainder as the presence lifetime? And in mid-registrar<br>
> configurations, which transaction's timer is actually being referenced<br>
> here?<br>
><br>
> Happy to submit a PR with the fix, but wanted to check if I'm missing<br>
> something about the original design first.<br>
><br>
> Thanks,<br>
> Andrew<br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
</blockquote></div>