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@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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



--
Daniel-Constantin Mierla - http://www.asipto.com