<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="monospace">Hi Andrew,<br>
<br>
I went thru your report and it is quite odd why you get so short
expire time when calculating based on fr_timer. Especially if you
say the 180 is quite fast.<br>
<br>
As you are able to reproduce the issue, could you print (before
line 295) the `t->uac[branch].request.fr_timer.time_out` and
`get_ticks()` values ?<br>
<br>
Regards,<br>
</font>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="https://www.opensips-solutions.com">https://www.opensips-solutions.com</a>
<a class="moz-txt-link-freetext" href="https://www.siphub.com">https://www.siphub.com</a></pre>
<div class="moz-cite-prefix">On 23.01.2026 05:49, Andrew Yager
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEX38CP7FMsZe7cGdnrf=bJ5Fw6ZmfTVN+w8FZLBV7+-PAenhQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.opensips-solutions.com</a><br>
<a href="https://www.siphub.com" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">Users@lists.opensips.org</a><br>
> <a
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>