<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Kennard,<br>
<br>
Yes, you are right, I should not delete the htable entry before calling
the publ_notify function. I will fix this. Thanks for pointing out.<br>
<br>
Regards,<br>
<pre class="moz-signature" cols="72">--
Anca Vamanu
<a class="moz-txt-link-abbreviated" href="http://www.voice-system.ro">www.voice-system.ro</a></pre>
<br>
<br>
On 09/03/2010 02:37 AM, <a class="moz-txt-link-abbreviated" href="mailto:Kennard_White@logitech.com">Kennard_White@logitech.com</a> wrote:
<blockquote
cite="mid:OF44EDBA90.7FC61AEF-ON88257792.007E08A3-88257792.0081C6EA@logitech.com"
type="cite">
<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
</p>
</blockquote>
</body>
</html>