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

Reply via email to