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

[Bogdan-Andrei Iancu]

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