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

[Anca Vamanu]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120220/22d91f3d/attachment.htm>