3 Mar
2016
3 Mar
'16
11:14 a.m.
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/