Using app_stack.so module instead of app_macro.so in FreePBX

Hello!

So. Asterisk devs made the app_macro.so module deprecated, so it’s not included to the default configuration (menuselect). But it seems that FreePBX still sets extensions up to work with it. As a result, one gets the “no application ‘Macro’ for extension” error while trying to make a local call.

And I couldn’t find the setting, that would let use more progressive app_stack.so for extensions in the FreePBX panel.

Is there a way to set it up? Not counting editing an extension config manually.

Thanks!

1 Like

Macro() is deprecated, has been for many, many years. GoSub is the recommended replacement for Macro(). As of Asterisk 16 Macro() is now noload just like Chan_SIP will be in Asterisk 17. That means they still exist but you have to enable them to use them. Since FreePBX requires Macro(), it’s enabled for the installs.

app_stack.so is for handling the stacking of routines such as Macro() and GoSub. Macro() could never have a depth (stacked) of more than 7 calls before it would lose its mind. GoSub doesn’t have those issues.

Before you decide that you need to rewrite FreePBX you should have an understanding of how it works first.

So now the big question, did you install the Distro (which would have all this enabled) or did you do a Manual Install which would require you to enable this stuff for it to work?

No, I compiled Asterisk with needed parameters myself, and Macro() was disabled in the menuselect by default. I had to recompile to enable it.

But it’s not that that’s the problem. I have no issues with recompiling and etc. My question isn’t about that. As you noted yourself, Macro() is deprecated, but it’s used in FreeBPX nonetheless.

So the question is how do I make FreePBX use app_stack.so instead? And what’s the official stance, since FreePBX continues to use a module that was deprecated ‘for many, many years’?

I explained this, app_stack.so is for stacking routines. Macro() and GoSub() are routines. The recommended replacement for Marco() is GoSub(). You don’t use or call app_stack from the dialplan.

Understand this, you can’t just make this change without re-writing FreePBX code unless you’re going to completely do things via _custom.conf files and ignore the entirely generated dialplan of FreePBX.

Macro is used extensively in FreePBX. It is one of those technical debts that requires a lot of dev time. For now you have to enable macro in your menuselect. This is unlikely to change any time soon.

Thanks, guys. Now I’ve got a bit clearer understanding.

Yeah, it was announced five years ago Marco() was deprecated and made well known that it was going noload in 16. So what’s another five years after being pushed to noload, right?

Here’s a quote from Andrew from 10 months ago:

Well one should just build app macro :slight_smile: you still can do this. To be honest the Asterisk development team warned us about this for quite a long time and FreePBX never did anything about it

I agree with this statement but perhaps not in the same way as you meant it. While this is a technical debt, it is pretty much bad debt that is accruing interest. If your last statement of it not happening anytime soon is accurate then this debt is going to be rather large.

The longer this is not addressed the longer that means new things must use deprecated routines and thus require more things to be modified/touched and this brings the debt up to an even higher cost.

Nothing new is (was) being written with app macro. As part of the process when working on code where you run across it you update it. So the usage is NOT increasing. It is slowly going away. What I was saying as of my last day as a staff developer there was nobody exclusively working on touching all 120+ modules to remove use.

This like all other things is open to community contributions. If anyone feels the desire to work through some of the modules they could. Realistically for 75% of the people there is no advantage/disadvantage to macro over gosub. That said on some larger systems you can have issues with stack size. The majority though is generally fine. Overall there was over the last 5 years no urgency because it is not big issue.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.