Issue: ------------------------------------------ Asynchronous Route Blocks gets executed as a failure_route, even though there never ever was a failure.
Version: ------------------------------------------ GIT Trunk (dev), not checked earlier versions.
Example Config / how to reproduce ------------------------------------------ I've got the following main route: ``` route { [...] if (is_method("PUBLISH") && search("^(Event|o)([ \t]*):([ \t]*)reg")) { route(PUBLISH); break; }
async_sleep("1"); #Set DLG flag to track dialogs using dialog2 if (!is_method("REGISTER|SUBSCRIBE")) setflag(FLT_DIALOG); [...] } ```
With debugger module enabled, it shows as follows in syslog: ``` Aug 17 15:41:09 ubuntu-2gb-fra1-01 [6968]: ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg] l=397 a=25 n=is_method Aug 17 15:41:09 ubuntu-2gb-fra1-01 [6968]: ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg] l=407 a=16 n=if Aug 17 15:41:09 ubuntu-2gb-fra1-01 [6968]: ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg] l=402 a=25 n=is_method Aug 17 15:41:09 ubuntu-2gb-fra1-01 [6968]: ERROR: *** cfgtrace:request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg] l=407 a=25 n=async_sleep Aug 17 15:41:09 ubuntu-2gb-fra1-01 [6975]: ERROR: *** cfgtrace:failure_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg] l=414 a=16 n=if Aug 17 15:41:09 ubuntu-2gb-fra1-01 [6975]: ERROR: *** cfgtrace:failure_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg] l=410 a=25 n=is_method ```
------------------------------------------
Why is route_type suddenly a failure-route? At a different part of my logic, this leads to unexpected results.
Looking at modules/tm/t_suspend.c (lines 277 ff.), I see the reason:
``` route_type_bk = get_route_type(); set_route_type(FAILURE_ROUTE); /* execute the pre/post -script callbacks based on original route block */ if (exec_pre_script_cb(&faked_req, cb_type)>0) { if (run_top_route(route, &faked_req, 0)<0) LM_ERR("failure inside run_top_route\n"); exec_post_script_cb(&faked_req, cb_type); } set_route_type(route_type_bk); ```
Any particular reason, why the route-type is explicitly set to FAILURE_ROUTE?
Thanks, Carsten
This was done not very long ago, to fix other issues. Practically, a suspend is creating a 'fake' branch that is never sent out, but can time out to close the transaction nicely if the transaction is not resumed. If resumed, the branch is marked anyhow as consumed, the transaction being already created and with a branch not being answered. So, from tm states point of view, is like failure_route rather than pre-transaction request route.
What are the issues you are facing? After resuming, which async module does in this case, you should work in transaction context anyhow.
Thanks for the clarification.
This is basically the scenario, where I've found a bug: - we are calling an unregistered user on our S-CSCF - we are sending an Server Assignment (SAR) to the HSS in order to retrieve the profile for the unregistered user - we trigger the Application Servers according to the users profile (ims_isc)
In the ims_isc module we have the following code:
``` if (is_route_type(FAILURE_ROUTE)) { /* need to find the handling for the failed trigger */ ```
I'll check the ims_isc module for a better fix.
Closed #750.
If helps, we can add a global variable to signal that the route block is executed by t_continue().
Thanks for the offer. I am currently testing a fix on the ims_isc module, so no immediate action needed. If that comes handy at some point, i'll add that flag.