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

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to