Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Submitted By: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db
While using the presence module, I run this scenario:
a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)
b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)
c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).
What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem.
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.
>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:25
I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
I will fix this soon.
Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23
I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:
(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs
the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:
line 919: DBG:core:parse_msg: method: <PUBLISH>
everything looks okay BUT:
line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:[hidden email] for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog