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 <[email protected]> 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 >> <[email protected]> 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 [email protected] > > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 > -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 _______________________________________________ Kamailio (SER) - Development Mailing List To unsubscribe send an email to [email protected]
