<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span>Hello Laura,</span></div><div><span><br></span></div><div>I made a patch with the changes required for a pure DB_ONLY mode.</div><div>You can find it on master branch.</div><div>Any feedback is very welcomed.</div><div><br></div><div>Regards,</div><div>Marius</div><div><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> Thursday, July 21, 2011 11:08 AM<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 for your answer. It would e nice if you can provide a pure<br>DB mode that disable completely subscription hashtable and presentity<br>hashtable in cache but only working with DB. Otherwise it can be still<br>problematic with our test case. Because when the one presence server<br>receives a PUBLISH from one presentity, it will looks-up the local<br>subscription hastable then DB for the active watchers's contact to<br>send notify and update the CSEQ in the subscription hastable/DB. But<br>if there is any subscription of this presentity is in the remote<br>subscription hashtable (another presence server) , the CSEQ of this<br>subscription in hashtable
will not be updated.<br><br>Thanks!<br><br>Best Regards,<br>Laura<br><br><br>>Hello Laura,<br><br>>Thank you for your email and providing the full test-case.<br>>You are right, there is a certain issue (that is also mentioned in another thread - "DB_ONLY mode in presence module").<br>>The thing is, that there are two caches<br><br> >- a subscription hashtable, maintaining information about active subscripions<br> >- a presentity hashtable, maintaining information about presence<br>entities (presentities, entities that send PUBLISH requests)<br><br>>The db_only mode acts only on the first type of cache - subscriptions.<br>>It really makes sense having the db_only mode act also on the second cache (the presentity cache), hence your usecase is >very common.<br>>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.<br><br>>I will make a patch this evening with this change, and commit it on the master branch.<br>>If anyone has other suggestions, please let me know.<br><br>>Cheers,<br>>Marius<br><br>On Wed, Jul 20, 2011 at 1:11 PM, laura testi <<a ymailto="mailto:lau.testi@gmail.com" href="mailto:lau.testi@gmail.com">lau.testi@gmail.com</a>> wrote:<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>_______________________________________________<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>