On 03/03/2016 11:09 AM, Charles Chance wrote:

Yes, you are correct. It simply wraps the standard t_replicate()
function, replicating the original request to every other node (first
appending a new branch for each). Use case is essentially the same as
the original but having the benefit of not having to define
destination(s) statically in config, since that part is handled by DMQ.

I see! Thank you.

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.

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?

-- Alex

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