Re: [SR-Users] xcap server - http load–balancer: xcap authentication problem

Hello Laura, Thank you for your email and providing the full test-case. You are right, there is a certain issue (that is also mentioned in another thread  - "DB_ONLY mode in presence module"). The thing is, that there are two caches  - a subscription hashtable, maintaining information about active subscripions  - a presentity hashtable, maintaining information about presence entities (presentities, entities that send PUBLISH requests) The db_only mode acts only on the first type of cache - subscriptions. It really makes sense having the db_only mode act also on the second cache (the presentity cache), hence your usecase is very common. There are some cases when you only need a db_only mode only for subscriptions (like when PUBLISH requests are generated precisely on each presence server machines) but of course I think it is a good compromise to disable caching also for the "presentity" table when running in db_only mode. I will make a patch this evening with this change, and commit it on the master branch. If anyone has other suggestions, please let me know. Cheers, Marius ________________________________ From: laura testi <lau.testi(a)gmail.com> To: Henning Westerholt <henning.westerholt(a)1und1.de>de>; "Bucur, Marius Ovidiu" <marius.bucur(a)1and1.ro> Cc: "sr-users(a)lists.sip-router.org" <sr-users(a)lists.sip-router.org> Sent: Wednesday, July 20, 2011 2:11 PM Subject: Re: [SR-Users] xcap server - http load–balancer: xcap authentication problem Hi Marius, Thank you very much for your explanations. I see your answer only in the list. Here I copy to here for the convenience: ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hello, In the DB_ONLY mode, every SUBSCRIBE request will trigger a database operation immediately (either insert or update). Also, the SUBSCRIPTION will always be matched from the database. It behaves exactly as the name implies (write-through). If it doesn't then that is a bug. Can you please tell me more about the scenario you are using? Is there any usecase in which you can see the subscription in memory but not in the active_watchers table? Regards, Marius --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The scenario wehave tested is like that we have multiple presence servers and a share DB in the separate DB server. The incoming SIP/SIMPLE traffic are dispatched with the Dispatcher. The problem we found is that the write-through mechanism guarantee the active_watchers cache is synched to DB immediately when it change like your explanation; but not vice versa. For example, when the active_watchers table in DB is changed by one presence server via the same write-through mechanism, it seems there is not possible to populate the changes in DB back to cache of another presence server. That means the cache in the different presence servers are not synchronized. It will required complex replications to have cache in synched. I'll try to explain it by the following use case we have tested: Test Environments: - SIP clients: (jitsi)   - user1 (has user2 as a contact, user 2 is watcher of user1 with the state=1)   - user2 (has user1 as a contact, user 1 is watcher of user2 withe the state=1) - SIP server (kamailio3.1.4)   - 1 x dispatcher (routing based call id)   - 2 x presence servers (PS1 and PS2) - DB server:   - 1 x backend DB server for SIP servers Test Case (user2 is already login and the subscription to user1 is in one of the 2 PS cache and in DB): 1) when user1 login, it send SUBSCRIBE presence event of user2 to the Dispatcher, and Dispatcher forward it to PS1     - PS1 write the subscription (user1->user2 with CSEQ=1) to active_watchers cache       then active_wacthers table in DB immediately (write-through)     - PS1 send the NOTIFY of the user2 presence status to user1 and increase the CSEQ by 1 (becomes 2) to       both cache and DB (write-through) 2) user1 receive the NOTIFY and check the CSEQ (the first time), and update the user2's status 3) user2 change it's presence status and send the PUBLISH to the dispatcher, and Dispatcher forward it to PS2   - PS2 call handle_publish, it look-ups to the local cache for the active subscription and not found,     then fallback to DB and found it, it increase the CSEQ by 1 (becomes 3 in DB) and send the NOTIFY     to user1 with CSEQ=3 (here is the problem, the CSEQ of the same subscription in the PS1's cache is still equal 2) 4) the user1's client receive the NOTIFY and check the CSEQ if it's greater than the previous one, it's,     then update the Presence Status of user2 5) user2 change it's presence status again, this time the Dispatcher forward the PUBLISH to PS1   - PS1 call handle_publish, it look-ups to the local cache for the active subscription and found it with CSEQ=2!     It increase the CSEQ by 1 (becomes 3 in the cache and update the value to DB), and send the NOTIFY     to user1 with CSEQ=3 again. 6) user1's client receive the NOTIFY and check the CSEQ if it's greater than the previous one, it's not,   then it ignore it, the presen status of user2 is not updated in the user1's client! This problem can be solved if we have pure DB mode only. In that case, the CSEQ is always increased for the successive NOTIFY of the same subscription. It would be nice  to keep the new Write-Through DB Mode in the presence module, and add a Pure DB mode, just like the usrloc module? Just in case, in usrloc module, it miss the fallback to DB mode but has write-through and pure db mode ;-) Best Regards, Laura On Fri, Jul 15, 2011 at 4:58 PM, Henning Westerholt <henning.westerholt(a)1und1.de> wrote: _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users