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" <abalas...@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 > -- Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
_______________________________________________ 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
