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