The function is only available to request route right now - it's been a while so I don't recall the exact reasons behind it, however the same restriction applies to t_replicate().

I can take a closer look later and let you know for sure.

Charles

On 3 March 2016 at 16:31, Alex Balashov <abalashov@evaristesys.com> wrote:
On 03/03/2016 11:29 AM, Charles Chance wrote:
In the first instance, you could use dmq_is_from_node() to determine if
the message is a replicated one and if so, don't relay.

There's no specific function to check the state of other nodes, although
it would be a simple addition. If I understand your question correctly,
however, if the message has just been replicated by the primary server
then it's safe to assume it's in service, right?

 I would think in almost all imaginable modes of operation, yes.

How are replies handled? Can these be dmq_t_replicated() too, so that the transaction is properly aged through its life cycle on the other nodes, too?


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