[OpenSIPS-Users] [pua/pua_dialoginfo] BLF stuck after calls - orphan presence records due to missing etag fallback

[Bogdan-Andrei Iancu]

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 
> <bogdan at opensips.org> 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
>     > Users at lists.opensips.org
>     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20260126/968964df/attachment.html>