In Asterisk, modules can take one of three supported states. These states include:
The definition of the various states is described in the following sections.
Most modules in Asterisk are in the Core state, which means issues found with these modules can freely be reported to the Asterisk issue tracker, where the issue will be triaged and placed into a queue for resolution. Core modules are supported by both Sangoma and the community.
This module is supported by the Asterisk community, and may or may not have an active developer. Some extended modules have active community developers; others do not. Issues reported against these modules may have a low level of support. For more information about which extended support modules have an active developer supporting them, see Asterisk Open Source Maintainers. Extended modules receive no bug fix support from Sangoma. Sangoma will try to ensure they continue to build and investigate security issues, but that is the extent of support.
The module will remain in the tree, but there is a better way to do it. For module deprecation policy and process please see Module Deprecation. Deprecated modules receive no bug fix support from Sangoma. Sangoma will try to ensure they continue to build and investigate security issues, but that is the extent of support.
At the top of modules there is the ability to set meta information about that module. Currently we have the following tags:
The meta data added to MODULEINFO in the module causes data to be generated in menuselect. For example, when you use <defaultenabled>no</defaultenabled> the module will not be selected by default. We would use the <defaultenabled> tag for deprecated modules so that they are not built unless explicitly selected by an Asterisk administrator.
Adding New Metadata
On top of the existing tags, we would add two additional tags to communicate via menuselect that a module was extended or deprecated (and what module supersedes the deprecated module). These tags include:
- Example: <support_level>deprecated</support_level> -- This module would be deprecated. Maintenance of this module may not exist. It is possible this module could eventually be tagged as deprecated, or removed from the tree entirely.
- Example: <replacement>func_odbc</replacement> -- The replacement for this module is the func_odbc module. This is used when the <support_level> is set to deprecated.
The following two images show the suggested menuselect output based on the addition of the <support_level> and <replacement> tags. This would be a new line that has not been used before, and therefore would be added to menuselect as that new line.
If the deprecated value is used, then the value between the <replacement> tags will replace the value of app_superQ as shown in the image below. The text surrounding app_superQ would be static (same for all modules that used deprecated).
If the <support_level> tag is used, then the value of extended would cause the additional text of ** EXTENDED ** to be displayed.
Display in menuselect-newt for supported modules. If no <support_level> is specified, then it is assumed the module is supported:
Display in menuselect-newt for extended modules:
Display in menuselect-newt for deprecated modules:
Besides the "
make menuselect" menus themselves, here's a quick way  to list the support levels for various Asterisk loadable modules  from the
.csource files :
/usr/src/asterisk-X.X.X # grep -rP '^\t<support_level>' $(find . -name '*.c') | sed -re 's#</?support_level>##g' | sort > module-support-states.txt
 This may not be POSIXly correct. It works with Bash and GNU
 This excludes other Asterisk components such as
 This assumes that a module's support state will not differ based on menuselect options for other modules.