Thanks for the update. Working on making peace with it :P, moving some stuff around has resolved my immediate issue.
On Mon, Nov 2, 2020 at 5:45 PM Alex Balashov abalashov@evaristesys.com wrote:
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