4 Mar
2016
4 Mar
'16
10:37 a.m.
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(a)evaristesys.com> wrote:
On 03/03/2016 01:58 PM, Charles Chance wrote:
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users