<div dir="ltr"><div>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.<div><br></div><div>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?</div><div><br></div><div>Cheers,</div><div>Charles<br></div></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 March 2016 at 16:14, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 03/03/2016 11:09 AM, Charles Chance wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, you are correct. It simply wraps the standard t_replicate()<br>
function, replicating the original request to every other node (first<br>
appending a new branch for each). Use case is essentially the same as<br>
the original but having the benefit of not having to define<br>
destination(s) statically in config, since that part is handled by DMQ.<br>
</blockquote>
<br></span>
I see! Thank you.<br>
<br>
What I've got seems like a good use-case for clustering over DMQ as a transport: a number of Kamailio servers that all answer on the same SIP domain, and a nondeterministic Layer 3 routing topology where some replies occasionally traverse a different Kamailio server to the one that processed the request to which they correspond. For a wide variety of reasons, I need to handle all this statefully, not statelessly.<br>
<br>
So, it seems like I ought to be able to dmq_t_replicate() incoming INVITEs to other nodes and, on those nodes, instantiate the transaction with t_newtran(). But one would also need to devise a mechanism to inform those secondary nodes that the message should not be t_relay()'d unless the primary server for which it was intended (itself difficult to identify due to same SIP domain everywhere) was determined to be out of service. I don't suppose there's some clever shortcut to implementing that kind of conditional logic manually?<div class="HOEnZb"><div class="h5"><br>
<br>
-- Alex<br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
303 Perimeter Center North, Suite 300<br>
Atlanta, GA 30346<br>
United States<br>
<br>
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)<br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div></div></blockquote></div><br><div><br></div>
</div></div>
<br>
<div><font color="gray" style="font-size:10pt;font-family:Helvetica,Arial,sans-serif">Sipcentric Ltd.
Company registered in England & Wales no. 7365592.</font><span style="font-size:10pt;font-family:Helvetica,Arial,sans-serif"> </span><font color="gray" style="font-size:10pt;font-family:Helvetica,Arial,sans-serif">Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.</font></div>