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 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