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

[laura testi]

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 at 1und1.de> wrote:
>
> On Friday 15 July 2011, laura testi wrote:
> > we have checked the presence extension for DB_MODE only in the master
> > branch. But it's not complete DB_ONLY mode, it seems that it still uses
> > the cache for active_watchers in write through mode. Is there any reason
> > for it? That can still make problem for the scalability for the multiple
> > presence servers, because if an presence event (either SIP or XCAP) of an
> > active subscription in the cache of one presence server, goes to another
> > presence server, can still cause the problem even the DB is sync with the
> > cache.
>
> Hello Marius,
>
> maybe you can comment a bit on this?
>
> Thanks and best regards,
>
> Henning