John, I was just about to reply but you figured it out beforehand. :-) Yeah, when there are different parts of the system that operate independently on the same transaction, it is important to use stateful constructs to maintain synchronisation between them. Otherwise, the left hand (TM timeout response 408) doesn't know what the right hand (your stateless replies beforehand) are doing, and the stateless replies do not mutate the state of the transaction so that an automatic 408 is no longer possible.
-- Alex > On May 25, 2023, at 10:50 AM, John Hardiman <[email protected]> > wrote: > > Just an update to this one for anyone with the same issues with multiple > final response codes around 408 and 500 responses: > I neglected to see the stateful nature of what I was trying to do and was > sending a stateless reply. I have changed this after some guidance. > def ksr_failure_manage(self, msg): > # On timeout of invite (2 seconds) send a stateful reply, reclaim RTPengine > port and log the call ID and Sender IP > if KSR.tm.t_any_timeout() : > KSR.tm.t_reply(503, "Timeout to Destination") > KSR.rtpengine.rtpengine_manage("") > KSR.err("Timeout to Invite for %s from IP %s" % > (KSR.pv.get("$ci"),KSR.pv.get("$si"))) > KSR.tm.t_release() > return 1 > else: > # Catch all anything else - same as above - send a stateful reply, reclaim > RTPengine port and log the call ID and Sender IP > KSR.tm.t_reply(msg, 503, "Unknown error failover to next node") > KSR.rtpengine.rtpengine_manage("") > KSR.err("Failed but not timeout for %s from IP %s" % > (KSR.pv.get("$ci"),KSR.pv.get("$si"))) > KSR.tm.t_release() > return 1 > Thanks, > John. From: John Hardiman > Sent: Thursday, May 25, 2023 2:33 PM > To: [email protected] > Subject: Consistent huntable responses based on failure_route question > Hi Kamailio list, > I hope you are all well? > I am looking for some assistance on a specific error I am trying to work > around. > Kamailio 5.5.3 - Ubuntu 20.04 > Kemi Python script (but I think this is more default failure_route behaviour) > Dispatcher module which hunts to a group of FreeSWITCH that I have configured > to send 503 responses on. > My scenario is fairly simple, I am trying to respond back to a carrier for > huntable responses (503 specifically) by calling a failure route below: > def ksr_failure_manage(self, msg): > if KSR.tm.t_any_timeout()>0 : > self.ksr_send_reply_clear_rtpengine(msg, 503, "Timeout to > destination") > KSR.err("Timeout to Invite for %s from IP %s" % > (KSR.pv.get("$ci"),KSR.pv.get("$si"))) > return 1 > else: > self.ksr_send_reply_clear_rtpengine(msg, 503, "Unknown error failover > to next node") > KSR.err("Failed but not timeout for %s from IP %s" % > (KSR.pv.get("$ci"),KSR.pv.get("$si"))) > return 1 > This works and a 503 with the correct message is sent if the invite doesn't > get a response after 2 seconds. (My specific test case here) > # Timers for call setup 2 minutes for any 1xx provisional response received > # If no invite response received in 2 seconds end the call as per failure > route. > KSR.tm.t_set_fr(120000, 2000) > self.ksr_route_relay(msg) > KSR.tm.t_on_failure("ksr_failure_manage") > return -255 > The issue is after a few more milliseconds after my initial 503 a 408 is > sent. Also after the failover if the carrier tries the same Kamailio again it > gets a 500 rather than a 408. > 408:<image001.png>500:<image002.png> My steps to get around this have been > to change the default tm code to 503 below, but this has not changed the > default response and the above behaviour unfortunately: > # ----- tm params ----- > # auto-discard branches from previous serial forking leg > modparam("tm", "failure_reply_mode", 3) > # setting default reason code and response for general errors to allow > failover. > modparam("tm", "default_code", 503) > modparam("tm", "default_reason", "Unknown reason try next node") > My question is: How can I make sure my failure route is the final response > here. Or if I cannot make sure of this, how can I change the default mapped > response to be a consistent SIP response (503 specifically) > Many thanks in advance as I am scratching my head on this one a bit. > John. > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to [email protected] > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
