20 Feb
2012
20 Feb
'12
1:03 p.m.
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