[OpenSIPS-Users] Nested reply_routes

[Richard Robson]

If you just want the reply_route to read more easily for collegues, then 
just make sure its documented and you have comments where appropriate.
Personally I think jumping to a route block form a reply block is going 
to be more confusing then having a flowing script inside a single 
onpely_route.

is the use case requiring the UAC to receive a 181 instead of a 180?

regards,


Richard

On 13/04/2026 13:42, Malte wrote:
>
> 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
>
> _______________________________________________
> 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/48e66fce/attachment-0001.html>