Hello, I was not the initial author, but the DMQ protocol seems to follow more a "best effort" or "eventual consistency" kind of way regarding the cluster protocol and communication.
We certainly can change the protocol behaviour for the next major version. For example, to introduce an additional state "DMQ_NODE_PENDING" for the situation that you described. After the node received a direct reply from the other side, it could be changed to "DMQ_NODE_ACTIVE", basically delaying the activating a bit. This way we would stay flexible for eventual future extensions. Do you also consider publishing this PENDING status then to other nodes? This should only update the other node from NOT_ACTIVE to PENDING, obviously not from ACTIVE to PENDING. Regarding the change of the startup status to PENDING, we need to verify that it doesn't negatively affect the initial synchronisation, for example for user location. Besides the currently open PRs on the github tracker I am not aware of other extensions in this area. If you want to improve the behaviour, you can just propose a PR with the changes, and it can be reviewed. Cheers, Henning From: Groissenberger David via sr-dev <[email protected]> Sent: Donnerstag, 18. Juni 2026 12:54 To: [email protected] Cc: Yang Jun <[email protected]>; Groissenberger David <[email protected]> Subject: [sr-dev] Question about DMQ node status handling Hello all, we are currently looking into the DMQ module node status handling and would appreciate some feedback before preparing a solution. According to the DMQ module documentation, 'DMQ_NODE_ACTIVE' means that a node is in the DMQ node list and has responded with '200 OK' to a KDMQ message. The documentation also says that, at startup, all nodes are considered active regardless of their actual state. Our concern is about setups with more than two DMQ nodes. In such a setup, one node learns from another node that a third node is 'active', even if the instance has not directly received a successful KDMQ response / '200 OK' from that third node. We are considering the following: * Keep newly discovered remote nodes as 'pending' until they respond with '200 OK' * Ignore advertised 'active' status from remote node lists for existing remote nodes * Still accept non-active/disabled/pending state changes where appropriate * Set a node status to 'active' only in the response callback after a direct '200 OK' We want to make the node status handling more "restrained" and avoid false-positive 'active' states. Before developing this further, I wanted to ask: 1. Is the current version of 'active' status from advertised node lists intentional? 2. Would changing 'active' to mean "directly confirmed by this local node" be acceptable? 3. Are there any known changes around this behavior that have not been merged upstream? Thanks in advance for any help. Best regards, David
_______________________________________________ Kamailio - Development Mailing List -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!
