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

SourceForge.net noreply at sourceforge.net
Mon Feb 23 18:38:55 CET 2009


Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Comment added) made by oren_k
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: Oren K (oren_k)
Date: 2009-02-23 12:38

Message:
Thanks for your help Anca. I updated my sources from SVN and recompiled but
unfortunately the bug is still not resolved. I am still getting a crash
from opensips-mi-proxy, its the same one as on my previous comment from
Date: 2009-02-20 13:22

exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 08:57

Message:
Hi Oren,

I have fixed the problem with 'transformations' node. Please update and
test again.

Thanks,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07: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-19 18: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 11: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 11: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-06 19: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 13: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 11:41

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

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10: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 06: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