[OpenSIPS-Users] Nested reply_routes

[Ben Newlin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20260410/1077b831/attachment-0001.html>