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