[sr-dev] git:master: modules_k/presence Fixed DB Storage Modes

[Klaus Darilion]

On 20.02.2012 10:40, Anca Vamanu wrote:
> Hi Klaus,
>
>
> On 02/20/2012 10:47 AM, Klaus Darilion wrote:
>> Hi Anca!
>>
>> From the README:
>>
>> subs_db_mode (int):
>> 3 - DB-Only scheme. No memory cache is kept, all operations being
>> directly performed with the database. The timer deletes all expired
>> subscriptions from database. The mode is useful if you configure
>> more servers sharing the same DB without any replication at SIP
>> level. The mode may be slower due the high number of DB operation.
>>
>> You mention replication at SIP level - I wonder how you can replicate
>> subscriptions on SIP level?
>>
>  From kamailio you could call t_replicate() to send the Subscribe or
> Publish to another destination. But this is not enough. First, you
> should take care that that destination will not be allowed to send the
> reply for Subscribe or the Notifies out. Then, you should replicate the
> 200Ok for Notifies received from the clients to that destination to be
> sure the destination updates correctly the local Cseq. Currently in
> kamailio there isn't a way to replicate replies. I had worked for a
> solution with a distributed presence server with replication like this,
> but some custom patches were needed to make this possible.

Hi Anca, that sounds like an awful hack ;-)

Just to be sure that I really understand the hack - for example presence 
server p1 and backup presence server p2.

p1 receives SUBSCRIBE: local handle_subscribe() and t_replicate() to p2

p1 sends back 200 OK and stores dialog.

p2 sends back 200 OK to p1, but using a different to-tag thus having 
another dialog. Thus, NOTIFYs by p2 have a different Via branch-id and a 
different from-tag. Thus, I wonder how failover to the backup-node 
should work and how the backup node will accept a faked NOTIFY-response 
if branch-param and from-tag are different ???

thanks
Klaus