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