[SR-Users] Presence: Empty reginfo NOTIFY bodies

[Stefan Kohlhauser]

Hey everyone!

Problem:
At startup the presence module for reginfos can get into a state where it is not adding bodies to reginfo NOTIFYs.

Setup:
We are using the pua_reginfo to let the Kamailio (4.2.6) PUBLISH the current registration state to itself. The body is correctly added to the presentity-table in the Postgres.

Analysis:
However, we have identified two cases where after startup the Kamailio can reach a state where he won't add bodies to the NOTIFYs. And this does not fix itself over time.
We are pretty confident that the problem lies in an inconsistency between the presentity table in the DB and the hashtable of the presence module.

Case 1:
The entry for a URI in the DB is expired. On startup of the Kamailio the hashtable remains empty for that URI.
Maybe due to another bug the pua_reginfo occasionally sends PUBLISHes with an expired "SIP-If-Match"-header.
In module/presence/presentity.c::update_presentity() the DB is updated. However, the hashtable is only updated if it is a new request (i.e. no "SIP-If-Match"-header and thus new_t not set).
The hash table is not filled on startup, not on the first PUBLISH as it contains a (wrong) "SIP-If-Match"-header, and not on any subsequent PUBLISH as they contain correct "SIP-If-Match"-headers.

Case 2:
The presentity table contains at least one expired and one non-expired reginfo entry for a URI.
The Kamailio seems to send a NOTIFY with a body within about a minute (probably the default clean period of 100 secs?). But after that short interval only NOTIFYs with empty bodies are sent.
To us it looks like the cleanup function (module/presence/publish.c::msg_presentity_clean()) is cleaning up the expired DB entries correctly. But despite one still valid entry in the DB the entry in the hash table gets removed as well. And it wont get filled again (see case 1).

This only seems to apply to the "reg" event, the "presence" event does not seem to be affected. 

We are aware aware of the publ_cach parameter, but we don't know if this has any performance impact on our system.

If needed we can try to provide more insight on this problem.

Some help on this or a fix would be much appreciated!

BR, Stefan