Hi Klaus,

It's not quite the way you described it.  In the scenario describe by me, p2 was just a hot stand by, sending nothing outside while in backup mode. In an active - active setup, it is a lot harder to achieve.

First, as Daniel suggested, send() is the best option to use when replicating - forwarding the message as it was received.
Then, p2 should work in a synchronous way - generating the same tag and Via branch as p1. With the Via branch it is easy to achieve with the syn_branch global parameter. With the tag, some coding needs to be done.

P2 should not send anything out, it should be blocked at network layer, or from inside the application. However it will have the impression it had send out the Notifies, so it has to receive the replies for it. This is why p1 must also replicate replies for Notifies.

Regards,
Anca



On 02/20/2012 12:43 PM, 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