Hello,
I haven't added the branch failure event route and not worked much with it,
but I guess it works like adding a new branch in a parallel forking,
instead of serial forking that is done with failure_route.
I will look at the code when I get a chance, the workaround for now should
be enforcing the reply code inside a failure_route, eventually by setting
some flag inside event route so you know you handled the redirect reply.
Cheers,
Daniel
On Wed, Aug 1, 2018 at 5:46 PM, Marco Capetta <mcapetta(a)sipwise.com> wrote:
Hello,
we have a problem of final reply code in case of 302 and then 486 busy.
This is our scenario:
A, B and C are subscribers.
A ----------> Kamailio ----------> B
Kamailio <---302---- B
Kamailio -----------------------> C
Kamailio <---486----------------- C
A <---302---- Kamailio
Expected behavior: Kamailio should reply to A with 486, as C was busy, and
not 302.
We have kamailio v5.1.4
In the call to B we set both failure and branch_failure:
t_on_failure("failure_route");
t_on_branch_failure("failure_redirect");
in order to handle the 302 redirect per branch with:
event_route[tm:branch-failure:failure_redirect]
{
if($T_reply_code == 301 || $T_reply_code == 302)
{
do redirect ...
}
}
and the final failure with:
failure_route[FAILURE_ROUTE_LOCAL]
{
do something ...
}
Since we have 'modparam("tm", "failure_reply_mode", 3)' my
expectation is
to get the winning reply from the branch of last step.
Is there any configuration I'm missing?
Since we manage the redirect with a branch-failure, is the winning reply
calculated in a different way?
Thanks
Marco
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -
http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda