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 <[email protected]> Sent: Freitag, 26. Januar 2024 20:06 To: Kamailio (SER) - Development Mailing List <[email protected]> Cc: Stefan-Cristian Mititelu <[email protected]> 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
_______________________________________________ Kamailio (SER) - Development Mailing List To unsubscribe send an email to [email protected]
