[OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when using fallback2db

SourceForge.net noreply at sourceforge.net
Fri Feb 20 13:25:00 CET 2009


Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&group_id=232389

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.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

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).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root@localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


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.

Regards,
Oren K.

----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:25

Message:
Hi Oren,

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
reported :). 
I will fix this soon.

Thanks and regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 01:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23

Message:
Hi Anca,

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:user2 at openims.summit-tech.ca 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

..suddenly there are no subscribers?

Thanks.


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&group_id=232389



More information about the Devel mailing list