Hi,
If I understand the DMQ documentation correctly, when a SIP request is distributed to other Kamailio instances via dmq_t_replicate(), it is not merely sent as a payload in a novel way, but actually "rehydrated" by the receiver into a mock request on the other end and processed as through it were a "real" message that came into the request_route[] in the natural way.
Is this an accurate assumption?
-- Alex
Hi Alex,
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.
Cheers, Charles
On 3 March 2016 at 15:37, Alex Balashov abalashov@evaristesys.com wrote:
Hi,
If I understand the DMQ documentation correctly, when a SIP request is distributed to other Kamailio instances via dmq_t_replicate(), it is not merely sent as a payload in a novel way, but actually "rehydrated" by the receiver into a mock request on the other end and processed as through it were a "real" message that came into the request_route[] in the natural way.
Is this an accurate assumption?
-- 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
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
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?
Cheers, Charles
On 3 March 2016 at 16:14, Alex Balashov abalashov@evaristesys.com wrote:
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
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?
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
Charles,
If replication for replies is not available, how would a replicated transaction transition through its life cycle on a standby cluster node?
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)?
Cheers, Charles On 3 Mar 2016 17:33, "Alex Balashov" abalashov@evaristesys.com wrote:
Charles,
If replication for replies is not available, how would a replicated transaction transition through its life cycle on a standby cluster node?
-- 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
On 03/03/2016 01:58 PM, Charles Chance wrote:
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.
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@evaristesys.com wrote:
On 03/03/2016 01:58 PM, Charles Chance wrote:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
Charles Chance