[OpenSIPS-Users] Nested reply_routes

[Malte]

I get what you say. I can map my custom logic into request route blocks, 
as long as there is no function which requires execution from a specific 
(non-request) route type. Therefore I have to make sure that every 
function which requires to be executed in a specific (non-request) route 
is still being called in the respective section.

For example if I want to shorten my MAIN onreply_route by moving a part 
of it to another block and referencing it from the main block, I have to 
make sure that reply specific functions do not migrate from the onreply 
route.

This could be done by adjust the logic so it only checks the conditions 
for a operation using non route specific functions, move that code to a 
new route block, refer to that route block from the onreply route, wait 
for the new route block to finish and return to the onreply route block 
and then calling the route specific functions when a certain flag was 
set inside the aforementioned new route block.

incoming reply

-> onreply_route[MAIN]

-> route[CUST_FUNCT]

     - if t_check_status("180") && hdr(xyz) then avp(180xyz) = 1;

-> back to onreply_route[MAIN]

     - if avp(180xyz) then change_reply_status(181, "test");


My initial idea was to shorten my onreply_route to make it more easily 
understandable by my colleagues. Although I like this reinterpretation 
of the route block - how it’s used and how it can be used - I think its 
hard to explain why some reply operations are done in a request route 
and some not. Therefore I for now just keep my block as long as it is, 
but keep the possibilities in mind.


Thank you all for your suggestions!


On 10/04/2026 16:12, Ben Newlin via Users wrote:
> The solution proposed by Richard works and it is working in your case, 
> in the sense that the called route is being executed.
>
> However, this method does not remove any conditions of specific 
> functions on which routes they can be called from, and the called 
> route is not a reply route it is a basic route. So the error is valid.
>
> This mechanism can be used generally to break up processing in large 
> routes, but any functions which require execution from a specific 
> route type cannot be moved to the nested route. What you need is 
> something like this:
>
>
> route[reply_processing_1] {
>     # do general reply processing step 1
>   }
>
> route[reply_processing_2] {
> # do general reply processing step 2
>   }
>
> onreply_route[MAIN] {
>   route(reply_processing_1);
>     # Perform reply_route specific processing here
> change_reply_status(181, "test”);
>
>   route(reply_processing_2);
>   }
>
> Ben Newlin
>
>
> *From: *Users <users-bounces at lists.opensips.org> on behalf of Malte 
> <spce at lard.at>
> *Date: *Friday, April 10, 2026 at 5:33 AM
> *To: *users at lists.opensips.org <users at lists.opensips.org>
> *Subject: *Re: [OpenSIPS-Users] Nested reply_routes
>
> ------------------------------------------------------------------------
>
> Hi,
>
> this approach unfortunately doesn't work. Does somebody else know of a 
> solution to neaten up big reply routes?
>
> My code and the following error:
>
>   367 route[test] {
>   368 xlog("now in test route");
>   369 change_reply_status(181, "test");
>   370 }
>   371
> 372  onreply_route[MAIN] {
>   373        # For fr_inv_timeout handling
>   374     if (t_check_status("180")) {
>   375          $var(180_in_trans)=1;
>   376       route(test);
>   377     xlog("back to reply route");
>   378 }
>
> *CRITICAL:core:yyerror: parse error in 
> /etc/opensips/opensips.cfg:369:29-30: Command <change_reply_status> 
> cannot be used in the block*
>
> Doing it in a reply route:
>
>   367 onreply_route[test] {
>   368 xlog("now in test route");
>   369 change_reply_status(181, "test");
>   370 }
>   371
>   372 onreply_route[MAIN] {
>   373 # For fr_inv_timeout handling
>   374 if (t_check_status("180")) {
>   375 $var(180_in_trans)=1;
>   376 t_on_reply("test");
>   377 xlog("back to MAIN reply route");
>   378 }
>
> *ERROR:sipmsgops:change_reply_status_f: the class of provisional or 
> positive final replies cannot be changed*
>
> Jump to secondary reply route via proxy route:
>
>   367 route[test] {
>   368 xlog("now in test route");
>   369 t_on_reply("test");
>   370 }
>   371
>   372 onreply_route[test] {
>   373 xlog("now in test reply route");
>   374 change_reply_status(181, "test");
>   375 }
>   376
>   377 onreply_route[MAIN] {
>   378 # For fr_inv_timeout handling
>   379 if (t_check_status("180")) {
>   380 $var(180_in_trans)=1;
>   381 route(test);
>   382 xlog("back to MAIN reply route");
>   383 }
>
> *ERROR:sipmsgops:change_reply_status_f: the class of provisional or 
> positive final replies cannot be changed*
>
> I must note that change_reply_status works flawlessly when executing 
> directly in MAIN reply route.
>
>
> Thanks,
>
> Malte
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20260413/54fc7eb7/attachment.html>