It will not go back to request_route; you'll have to make peace with that.

Most things are valid in the continued route. A few will doubtless
exhibit quirky behaviour as the state doesn't make it across properly
from the original requet_route. I haven't been adversely impacted by
this in my extensive use of http_async_client(), however.

On 11/2/20 8:42 PM, Brandon Armstead wrote:
> Alex,
>
>     Hey hows it going!
>
> I realize execution continues in ROUTENAME however after this route is
> completed it does not go back to request_route { }.  I suppose I could
> move the config around, just wanted to double check.  Also part of the
> issue here is that I'm finding certain functions i.e. msg_apply_changes
> is not valid in the continued route.
>
> On Mon, Nov 2, 2020 at 5:36 PM Alex Balashov <abalashov@evaristesys.com
> <mailto:abalashov@evaristesys.com>> wrote:
>
>     Correct, this is expected behaviour. Execution will continue in
>     ROUTENAME instead of returning to the calling route.
>
>     On 11/2/20 8:33 PM, Brandon Armstead wrote:
>      > kamailio 5.5.0-dev3
>      >
>      > I'm unsure if this is expected behavior, so thought I would ask...
>      >
>      > When using http_async_query("URI", "ROUTENAME")
>      >
>      > request_route {
>      >      route(AUTH);
>      >
>      >      # this does not get executed below route(AUTH)
>      > xinfo("[$ci][$rm] we hit this line");
>      > }
>      >
>      > route[AUTH] {
>      >      t_newtran();
>      >      http_async_query("URI", "ROUTENAME");
>      > }
>      >
>      > route[ROUTENAME] {
>      >      # do stuff here to check authentication and return
>      >
>      >      if(auth + registration) {
>      >          append_hf("Path....");
>      > msg_apply_changes(); # this fails and errors out about incorrect
>     route
>      >          # ^ invalid usage - not in request route or a reply
>      >          save("location");
>      >      }
>      >
>      >      if(auth + invite) {
>      >          # route to pstn
>      >      }
>      > }
>      >
>      > Expected behavior: to be able to obtain some processing /
>     information
>      > gathering about authentication with the call and additional
>     information
>      > possibly and return to normal routing.  As-is now I've to move the
>      > actions all into ROUTENAME for kamailio to continue processing,
>     it does
>      > not go back to request_route { }.
>      >
>      > # this does not get executed below route(AUTH)
>      >
>      > Is this expected behavior, or am I missing something?
>      >
>      > If I do catch route(AUTH) with a hash table and prevent its
>     execution
>      > after first run, the avp's from the transaction created are not
>      > available in request_route that were set in ROUTENAME.
>      >
>      > _______________________________________________
>      > Kamailio (SER) - Users Mailing List
>      > sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>      > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>      >
>
>     --
>     Alex Balashov | Principal | Evariste Systems LLC
>
>     Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>     Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
>     _______________________________________________
>     Kamailio (SER) - Users Mailing List
>     sr-users@lists.kamailio.org <mailto: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
>

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users