<html><body>
<p>Hi,<br>
<br>
While looking at another feature (see patch upload <tt>3058434</tt>) I came across a strange behavior and traced it down to a section of presence code.<br>
<br>
Given an subscription (via SUBSCRIBE) and an existing presentity (via PUBLISH) for event "presence", opensips send different NOTIFY PIDFs documents depending upon if the presentity is expired via timeout vs an explicit PUBLISH with Expires=0 header. In the first case (timeout), the NOTIFY PIDF is completely missing the original presentity (and the body may be empty if no other tuples). In the second case (unpublish), the NOTIFY PIDF has an edited copy of the original presentity (with basic status set closed). This occurs when the presentity hash tables are enabled and fallback2db is disabled.<br>
<br>
I doubt this is a really a bug (the behavior when presentities go away is not defined by the RFCs as far as I can tell). But I suspect this is a change in behavior introduced by the hash table code. Since some clients react very differently to no-body NOTIFY messages compared to ones containing 'closed' status, this can (and did) lead to strange system behavior.<br>
<br>
The root cause of the different behavior is that during message cleaning, the presentity is deleted from the hash tables before the notification is generated. In more detail, the call sequence is:<br>
<br>
<font face="Courier New"> publish.c msg_presentity_clean() calls</font><br>
<font face="Courier New"> notify.c: publ_notify() calls</font><br>
<font face="Courier New"> notify.c: get_p_notify_body() calls</font><br>
<font face="Courier New"> notify_body.c: pres_agg_nbody()</font><br>
<br>
The etag of the expiring presentity (or its body index) is passed down the above call chain. The last function attempts to "edit" the expiring presentity, setting the basic status to 'closed' prior to sending out the NOTIFY.<br>
<br>
But the stale presentity is deleted from the hash table before the above call sequence, thus it never shows up in the list of presentities queried by get_p_notify_body() and is not edited to indicate closed.<br>
<br>
Probably msg_presentity_clean() calling publ_notify() with the expiring etag doesn't serve any purpose, at least with fallback2db disabled, and is potentially misleading since it doesn't do what one would expect.<br>
<br>
Regards,<br>
Kennard<br>
</body></html>