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

On 26 Jan 2024, at 15:00, Alex Balashov abalashov@evaristesys.com wrote:

There are some real risks with taking dialog state transitions into your own hands via this rather crude method.

The life cycle of a transaction, and therefore a dialog (insofar as a dialog depends on the outcome of one or more transactions), can proceed, and transition from stage to stage, in a wide variety of ways, some obvious and some not. A lot of them are edge cases that the maintainers of the `dialog` module have diligently hunted for over a decade. It might be a little naive to think that you can imitate this work by spot-checking a few SIP status codes. :-)

...

On 26 Jan 2024, at 14:05, Stefan-Cristian Mititelu via sr-dev sr-dev@lists.kamailio.org wrote:

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 sr-dev-leave@lists.kamailio.org

-- 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 hw@gilawa.com 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.comhttps://gilawa.com/

From: Stefan-Cristian Mititelu via sr-dev sr-dev@lists.kamailio.org Sent: Freitag, 26. Januar 2024 20:06 To: Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org Cc: Stefan-Cristian Mititelu stefan-cristian.mititelu@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