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
