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 _______________________________________________ Kamailio (SER) - Development Mailing List To unsubscribe send an email to [email protected]
