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

[Andrew Yager]

Hi all,

I've been tracking down an issue where BLF (Busy Lamp Field) gets
stuck showing busy/ringing state after calls end. After some detailed
log analysis, I've identified what appears to be a bug in the pua
module's handling of etags when called from pua_dialoginfo's dialog
callbacks.

I've opened a GitHub issue with full details:
https://github.com/OpenSIPS/opensips/issues/3801

Summary:

When pua_dialoginfo publishes dialog state changes via the dialog
callback (`__dialog_sendpublish` → `dialog_publish()`), it doesn't
provide an etag in the `publ_info_t` structure. The pua module's
`send_publish()` correctly finds the existing presentity record in its
hash table, but then doesn't use that record's etag when the
caller-provided etag is NULL.

This causes the "confirmed" state (on 200 OK) to create a new presence
record instead of updating the existing "early" record (from 180
Ringing). When the call ends, only the "confirmed" record gets
terminated - the "early" record is left orphaned and gets republished
by the pua cleanup timer.

The problematic code in modules/pua/send_publish.c:

if(publ->etag)
    pres.etag= *publ->etag;

Probably needs to be changed to something like:

if(publ->etag)
    pres.etag= *publ->etag;
else if(presentity)
    pres.etag = presentity->etag;

This would allow the pua module to use the found presentity's etag
when the caller doesn't provide one, which is (what I think) the
expected behaviour when `dialog_publish()` is called with
`UPDATE_TYPE` flag set.

The issue exists in both 3.2.x and 3.4.x (we upgraded hoping it might
have been fixed).

Happy to provide any additional logs or testing if needed.

Cheers,
Andrew