Hello Stefan,
Alex already provided some background why its not that easy and probably not a good idea.
If you want to access lower level DMQ functions, there are dmq_send_message(..) and
similar functions available already. There is also always the possibility to implement a
more simple tracking htable (dmq replication) modules. Just keep in mind that this will be
not 100% accurate, due to some possible race conditions in the DMQ processing.
If there are some limitations in the DMQ module dialog replication, they should probably
be addressed instead of providing some manual workarounds. As mentioned, some of the
limitations might be caused from the intricacies of the TM module state. As you observed
in your previous e-mail, if the dialog is going e.g. in state 4 or state 5, this should be
replicated.
Cheers,
Henning
--
Henning Westerholt -
https://skalatan.de/blog/
Kamailio services -
https://gilawa.com<https://gilawa.com/>
From: Stefan-Cristian Mititelu via sr-dev <sr-dev(a)lists.kamailio.org>
Sent: Freitag, 26. Januar 2024 20:06
To: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Cc: Stefan-Cristian Mititelu <stefan-cristian.mititelu(a)1and1.ro>
Subject: [sr-dev] Make dlg_dmq_replicate_action() available from config
Hello,
I am thinking of making dlg_dmq_replicate_action() available to be called from config, so
one can do the following on the DMQ peer node:
def ksr_reply_route(self, msg):
if KSR.tm.t_check_trans() < 0:
if KSR.dialog.is_known_dlg():
if KSR.pv.get("$rs") == "180":
KSR.dialog.dlg_dmq_replicate_action(DLG_STATE_EARLY, dlg, 0, 0)
else if KSR.pv.get("$rs") == "200":
KSR.dialog.dlg_dmq_replicate_action(DLG_STATE_CONFIRMED, dlg, 0, 0)
Similar for BYEs, but I have to check that:
KSR.dialog.dlg_dmq_replicate_action(DLG_STATE_DELETED, dlg, 0, 0)
Is this a good idea? Or someone can see some issues with that?
Thanks,
Stefan