As an aside: - A 180 (or any non-100 1xx message) doesn't inherently cause an early dialog to come about; the distinguishing feature of a dialog-forming response is a To-tag; - A 200 response does not cause a dialog to be confirmed; it tentatively causes it to be established, pending an end-to-end ACK to confirm it. What if the e2e ACK never shows up? What if some element of the e2e ACK doesn't match the dialog attributes? What if a 2xx response never arrives? What if there is a 200-CANCEL race? What if the BYE doesn't match an established dialog? What about spirals? I don't know that you've really thought this through. :-) This is the hard work the dialog module does. -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

Thank you for all the feedback. Definitely I have to give this subject a second thought. --- Stefan ________________________________ From: Henning Westerholt &lt;hw(a)gilawa.com&gt; Sent: Saturday, January 27, 2024 10:00:26 AM To: Kamailio (SER) - Development Mailing List Cc: Stefan-Cristian Mititelu Subject: RE: Make dlg_dmq_replicate_action() available from config 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 &lt;sr-dev(a)lists.kamailio.org&gt; Sent: Freitag, 26. Januar 2024 20:06 To: Kamailio (SER) - Development Mailing List &lt;sr-dev(a)lists.kamailio.org&gt; Cc: Stefan-Cristian Mititelu &lt;stefan-cristian.mititelu(a)1and1.ro&gt; 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