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 <[email protected]> on behalf of Malte
<[email protected]>
*Date: *Friday, April 10, 2026 at 5:33 AM
*To: *[email protected] <[email protected]>
*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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
