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: [cid:image001.png@01D98F15.CD07DCB0] 500: [cid:image002.png@01D98F15.CD07DCB0]
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.
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: sr-users@lists.kamailio.org 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: [cid:image001.png@01D98F20.A6562850] 500: [cid:image002.png@01D98F20.A6562850]
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.
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 john.hardiman@missionlabs.co.uk 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: sr-users@lists.kamailio.org 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 sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Alex Balashov -
John Hardiman