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

laura testi lau.testi at gmail.com
Fri Jul 15 10:26:30 CEST 2011


Hi,
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.


Best Regards,
Laura

On Fri, Jul 1, 2011 at 5:02 PM, Henning Westerholt <
henning.westerholt at 1und1.de> wrote:

> On Thursday 30 June 2011, laura testi wrote:
> > [...]
> > pres_refresh_watchers triggered by xcap message in another presence
> server:
> > with the hashing over to uri in dispacther workaround, it seems solve the
> > first problem for SIP/SIMPLE messages, but we have the same kind of
> > problem for xcap message. For example, a subscription is in a local cache
> > of one server, and the incomming xcap message related to the same
> > subscription goes to another server, and this message trigger the
> > pres_update_watchers pres_refresh_watchers presence functions from the
> > configuration script in the server where there is no subscription in the
> > local cache, then it send the wrong notify message. This can happen when
> a
> > user add/remove a contact, and the SUBSCRIBE goes to one server and XCAP
> > PUT goes to another server. Unfortunately there is no DB mode only in
> > PRESENCE module like REGISTRAR module. The fallback to db can't help
> > either for point 1 or for point 2. Can you help please?
>
> Hi laura,
>
> i can't comment on the other question, but Marius B did some presence
> extensions in master branch a few month ago, that the presence module now
> supports a db_mode module parameter including DB_ONLY. It will be in
> kamailio
> 3.2, maybe you can have a look to the master branch and backport it, if you
> need it faster.
>
> Best regards,
>
> Henning
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110715/aa278480/attachment.htm>


More information about the sr-users mailing list