26 Jan
2024
26 Jan
'24
9 p.m.
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(a)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(a)lists.kamailio.org
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800