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