20 Feb
2012
20 Feb
'12
12:43 p.m.
On 20.02.2012 10:40, Anca Vamanu wrote:
Hi Klaus,
On 02/20/2012 10:47 AM, Klaus Darilion wrote:
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
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.