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(a)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(a)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(a)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
Principal Consultant
Evariste Systems LLC
Web:
https://evaristesys.com
Tel: +1-706-510-6800