In route block I call t_on_failure, t_on_branch_failure, and t_on_branch. If branch route fails like this:
Dec 15 08:52:19 box /usr/bin/sip-proxy[84346]: ERROR: tm [ut.h:284]: uri2dst2(): failed to resolve "foo.tutpro.com" :unresolvable A or AAAA request (-7) Dec 15 08:52:19 box /usr/bin/sip-proxy[84346]: ERROR: tm [t_fwd.c:1738]: t_forward_nonack(): failure to add branches
failure_route or tm:branch-failure event_route is not executed. Is there a way to catch such a failure?
-- Juha
Hello,
t_relay() should return negative (false) in such case, but I am not sure it returns a specific value for it -- this can be a variant to add if needed.
Cheers, Daniel
On 15.12.19 08:27, Juha Heinanen wrote:
In route block I call t_on_failure, t_on_branch_failure, and t_on_branch. If branch route fails like this:
Dec 15 08:52:19 box /usr/bin/sip-proxy[84346]: ERROR: tm [ut.h:284]: uri2dst2(): failed to resolve "foo.tutpro.com" :unresolvable A or AAAA request (-7) Dec 15 08:52:19 box /usr/bin/sip-proxy[84346]: ERROR: tm [t_fwd.c:1738]: t_forward_nonack(): failure to add branches
failure_route or tm:branch-failure event_route is not executed. Is there a way to catch such a failure?
-- Juha
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
t_relay() should return negative (false) in such case, but I am not sure it returns a specific value for it -- this can be a variant to add if needed.
Yes, t_relay() returns false, but the branch flags I set in the branch route are lost and I don't know what happened there so that I could undo things. For example, if branch route called rtpengine_offer, I would need to know that.
-- Juha
But is there ever a situation where t_relay() immediately fails out of hand yet TM state hooks like failure_route are invoked?
I think the idea is to deal with the problem right then in the original request route — having full access to variables and other initially available state — and re-initiate t_relay(). Right?
— Sent from mobile, with due apologies for brevity and errors.
On Dec 16, 2019, at 3:00 AM, Juha Heinanen jh@tutpro.com wrote:
Daniel-Constantin Mierla writes:
t_relay() should return negative (false) in such case, but I am not sure it returns a specific value for it -- this can be a variant to add if needed.
Yes, t_relay() returns false, but the branch flags I set in the branch route are lost and I don't know what happened there so that I could undo things. For example, if branch route called rtpengine_offer, I would need to know that.
-- Juha
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Alex, check my message below. If t_relay fails in request route, there must be a means to find out in request route , what happened in the failed branch route.
-- Juha
On December 16, 2019 5:18:06 PM GMT+09:00, Alex Balashov abalashov@evaristesys.com wrote:
But is there ever a situation where t_relay() immediately fails out of hand yet TM state hooks like failure_route are invoked?
I think the idea is to deal with the problem right then in the original request route — having full access to variables and other initially available state — and re-initiate t_relay(). Right?
— Sent from mobile, with due apologies for brevity and errors.
On Dec 16, 2019, at 3:00 AM, Juha Heinanen jh@tutpro.com wrote:
Daniel-Constantin Mierla writes:
t_relay() should return negative (false) in such case, but I am not
sure
it returns a specific value for it -- this can be a variant to add
if
needed.
Yes, t_relay() returns false, but the branch flags I set in the
branch
route are lost and I don't know what happened there so that I could undo things. For example, if branch route called rtpengine_offer, I would need to know that.
-- Juha
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
So, what is the conclusion on this? It is not good if information about failed branch route gets lost. Would it be possible to return some internal error reply and make t_relay() always succeed?
-- Juha
-
Alex Balashov -
Daniel-Constantin Mierla -
Juha Heinanen