[OpenSIPS-Users] Nested reply_routes
Malte
spce at lard.at
Tue Apr 14 07:44:32 UTC 2026
It's about ISUP signalling. In my request route I'm doing quite a bit of
manual bit mappings for some ISUP parameters (for example "Generic
number"). This really bloated my script, so I moved those parts to a
ADD_ISUP route. The onreply reply is not so bad, I do not need to do bit
mappings, but still wanted to adhere to this style.
In this case the peer needs to receive a 183 with diversion information
in the ISUP body instead of a 181, thus change_reply_status must be used.
Best Regards,
Malte
On 13/04/2026 15:38, Richard Robson wrote:
>
> 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
>
> _______________________________________________
> 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/20260414/2d2fd0bf/attachment-0001.html>
More information about the Users
mailing list