Asterisk Module Deprecation & FreePBX/PBXact users

FreePBX Development
1

Not sure what section of the forum this should go in but I’ll throw it here for now.

@lgaetz @mbrooks @mattf and anyone else that needs to see this. The FreePBX project needs to be tracking and communicating to its user base about the deprecation and removal of Asterisk modules so they can be aware of what they need to do. While Asterisk v16 saw a number of modules go from automatically being built/installed to you having to enable them during build. Now this isn’t a big deal for most Distro users, you guys are enabling them. I mean you have to, FreePBX is still using a some of them.

However, Asterisk v19 saw many of the modules that have been deprecated for almost a decade be removed. This is a trend that will continue in Asterisk v21, a very important release as this is when pretty much all the deprecated stuff FreePBX is still relying on for a lot of its workload to be completely removed.

As I pointed out in another thread, FreePBX is no longer something that Asterisk users are using to help manage Asterisk. It is now something that non-technical people are using as a solution for their businesses. These users certainly have no idea about Asterisk and they shouldn’t because they are using FreePBX/PBXact as their solution. They aren’t paying attention to the multiple FOSS projects that are being used under the hood of FreePBX/PBXact, they expect FreePBX/PBXact to keep them informed of changes that are happening.

Development in the Asterisk project and how the project handles things (such as deprecation) has changed over the past few years. Deprecated modules are not going to be hanging out in Asterisk for a decade after being deprecated anymore. They will be marked as deprecated and within the next Standard be removed from auto compiling/loading process (like app_macro now) followed by full removal in the next LTS.

This project (and PBXact) needs to make a very, very, very strong effort in educating and informing its user base about these changes that are happening. Because as of Oct 2023 which will see the release of Asterisk v21 the following will be completely removed and no longer usable (highlighting the ones I think are most used in this project by users)

res_monitor
Monitor will be removed. This means anything that uses Monitor for call recordings will no longer function. This includes FOP2, which so far hasn’t updated to MixMonitor. This will also impact other modules/applications such as app_queue that have settings/options for Monitor. Those modules/applications will be impacted by this as well.

chan_skinny
Not sure how much this is used but it is an option for Cisco phones but this will no longer function making Cisco phones using it no longer work.

app_macro
This is a big one as FreePBX has a lot of Macro() calls. Also due to the amount of ancient documentation and long term users never moving to GoSub() (replacement) the use of Macro() is still very high in documentation out in the wild and those following that documentation. This also means any other applications such as app_macro, app_dial, etc that have options to execute/call a Macro() will be impacted as those options will no longer be viable and could break usage.

chan_sip
Probably the most important one. This projects education and push to get people off of chan_sip is dismal, at best. There is still too many “it didn’t work on chan_pjsip but with chan_sip it does so I guess that’s what I’ll use” or those recommending “Well that just works with chan_sip, use that.” happening within this community. There needs to be an active effort to stop that going forward.

At this point there are very little use cases in which Chan_PJSIP cannot replace Chan_SIP but again, that is a very small piece of the pie. The average FreePBX/PBXact user can safely move to Chan_PJSIP without much worry. I’m going to venture to say that 99% of the time someone says “It doesn’t work in Chan_PJSIP but does in Chan_SIP” will be due to a configuration issue and not understanding differences. Which is why this project needs to make a stronger effort (or any really at this point) to educate its base.

Because right now with FreePBX’s new version release schedule being roughly 2 years between major versions and FreePBX 16 being released in Oct 2021 that means by Oct 2023 FreePBX 17 will be out and if that version doesn’t address any of this there is going to be a serious nightmare of problems.

3 Likes
2

Now I know that there are some things still not in Chan_PJSIP that are in Chan_SIP which some people will point to and say “Well I need this so can’t change”. Unfortunately that is due to the fact that either no one has contributed that fix or the use case for that feature is so low that the Asterisk devs put it on the “get to it when we get to it” list. A good example of this was the RFC4235 support for NOTIFY (showing caller/callee info for call pickup). Someone contributed a patch, it worked but they never followed up on making the needed fixes to code/formatting for it to be pushed into mainline. It took me a better part of a year being annoying about that patch and trying to get someone to do something with it that one of the developers just looked at it and went “Oh this is 10 minutes of work to fix it” and they did. It is now in Asterisk 19 and back ported to latest releases of v16 and v18. So this means for the last month or two a huge factor for people not moving to Chan_PJSIP (not having full call details for Call Pickup) has been RESOLVED and not a single peep from this project on that fact to push those holding off for this feature to move.

I know that support for tel URI is still lacking but again that is due to no one making a contribution for it to happen and the fact the use case size for it is small comparatively overall. So if no community member is going to contribute this maybe the FreePBX project should do what is has done in the past, contribute code back to Asterisk to make improvements that benefit the FreePBX project.

3

Keep track of what is being deprecated here:

Asterisk Module Deprecations - Asterisk Project - Asterisk Project Wiki

4

Hey Tom,

This is definitely something that has been on mind, and the up and coming deprecations are things that we’re trying to work through between the Asterisk and FreePBX teams at Sangoma.

Any community efforts though are welcome to assist in migrating old FreePBX code off of deprecated functionality within Asterisk.

The macro to gosub transition for a lot of the dialplan code has been high on my list for a while, but the others are equally interesting and are worth discussion.

I’m guessing most people know my feeling about the chan_sip to chan_pjsip migration at this point, but, if you haven’t seen any of my astricon talks the tldr is - move to PJSIP now. Yesterday even.

Matthew Fredrickson

5

Cool, I might be able to look at code towards the end of the month myself. Just to clarify, I was just tagging people I knew should be part of the discussion in whole. I know you’re a big fan of migration just want more to join our fan club!

1 Like
6

The app_mysql module is removed starting in 19 as well which affects CID lookup:
https://issues.freepbx.org/browse/FREEPBX-23206

I can’t think of any other places in core FreePBX modules that that generate app_mysql config, please update this thread or file a jira if I’ve missed one.

7

This is the code that writes out macros

class ext_macro {
	var $macro;
	var $args;

	function __construct($macro, $args='') {
		$this->macro = $macro;
		$this->args = $args;
	}

	function output() {
		//$callers=debug_backtrace();
		//freepbx_log(FPBX_LOG_UPDATE, "Need to remove Macro from ".$callers[1]['file']." on line ".$callers[1]['line']);
		return "Macro(".$this->macro.",".$this->args.")";
	}
}

If someone wanted to figure out making this convert macro data to gosub data it can be that easy. I haven’t looked on to the effort to do so. In other words you only technically need to fix it on one place, not in every place.

Note the commented code that will log out everywhere it is used on reload

1 Like
8

@mattf Been thinking about this and when I took all the Macro()s generated from the dialplan and converted them to Gosub()s for what I was doing one of the first things I did was make them more flexible because I was no longer limited to using only the s extension and starting at priority 1. So perhaps before a community member just blindly converts as is someone on the development team should review things and determine if using the flexibility of Gosub can benefit some of the existing Macro() calls. Calls that could point to an extension within a context directly instead of going through lines of dialplan checking ARGs for where the call has to jump to for the Macro to complete.

There are also numerous places that are looking for macro based variables like MACRO_EXTEN, MACRO_CONTEXT and MACRO_PRIORITY. Not to mention MACRO_RESULT which is used all over the place and there is the MACRO_DEPTH to keep track of the Macro stack getting too deep. With moving to Gosub you end up with GOSUB_RETVAL and there are no depth limits.

So there are places in the dialplan that are looking for variables generated from Macro()s that will need to be updated. Any place relying on the exten/context/priority variables will need to be adjusted to use different variables and what those variables will be needs to be determined.

There will also be the need to address all the apps calling on Macro. Numerous Dial() calls depend on the M option which needs to be moved to U. There is also an issue of existing Macro and Gosubs having the same names pretty much but doing different things. This is generally around doing call confirmations, there is Marco context [macro-confirm] and a Gosub context [confirm], for example.

This isn’t going to be a case of just redoing the Macro generation into Gosubs and then change Macro() calls to Gosub calls. There are a lot of places within the FreePBX dialplan that is dependent on Macro specific variables that are generated, and those variables are going away.

This is going to require multiple modules to be touched and that is just the open source ones. I would have to go through and see what commercial modules (that I have access to) are generating in their dialplan output too because no one in the community can touch commercial modules that still rely on Macro()'s and its variable output.

2 Likes
9

This was something I aspired to get in to 15 but it was a huge undertaking so it stalled with everything else we were doing. The branch has gotten pretty stale since then. In any case doing this type of change would allow you to also add a class variable such as “supported versions”, or support state etc. Throughout freepbx (less so now that 11 is gone) there are asterisk version conditionals that could be handled by a base class.
This is involved but will heavily improve maintainability and make for easy unit testing of all dialplan generation code

I have also been recently spoiled by modern php. It would be nice now that commercial stuff is on IONCube if FreePBX was maintained against the latest php. 8.1 is practically a real programming language lol

10

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