I'm not aware of such mechanism existing already, although I may have overlooked something. It's likely easier though in my opinion, and more beneficial to the project overall, to add replication directly within the tm module - similar to that which exists in htable, with a flag to enable/disable it.
Seems to me the most appropriate solution all round.
Alternatively, if a function is made available to update transaction state manually on the receiving node, you may then be able to use dmq_bcast_message() to relay the information yourself with some custom payload.
Best, Charles On 3 Mar 2016 7:00 pm, "Alex Balashov" abalashov@evaristesys.com wrote:
On 03/03/2016 01:58 PM, Charles Chance wrote:
Hi Alex,
The function was primarily intended for onward replication of successful REGISTERs, rather than transactional state.
Assuming the function was available for replies, how do you anticipate handling them on the standby node(s)?
Some mechanism would be needed to drop them, e.g. in a stateless default onreply_route.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users