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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
