Asterisk feature or module is missing after a version or build change

Freeze the exact missing capability and change boundary

Name one missing command, application, function, channel driver, resource, module option or AMI action. Record the last-known-good and first-known-bad version, platform, packaging or source owner, exact error, time and one unaffected control. Separate “the documentation page exists,” “the module file is absent,” “the module will not load,” “the module is loaded but not running” and “the capability is not registered.”

Do not reinstall, force-load modules and edit startup policy at once. Preserve the current binary path, service definition, module directory, configuration directory, package transaction or source-build record and rollback point before changing an owner.

Bind the evidence to the exact running version and owner

Confirm the binary used by the service and read the version from the running instance. Compare that with the installed package or source record and the deployment owner: distribution, appliance, FreePBX or controlled source build. A successful upgrade command is not proof that the active service started the new binary, and a new core is not proof that every module binary came from the same build.

Record the operating-system release and compiler or package environment when a build or dependency changed. Official supported-platform guidance covers only a subset of Linux x86 platforms and warns that older branches can stop building after distribution or compiler upgrades.

Match the documentation page to the installed branch

Open the exact branch documentation when available and preserve its URL and review date. A Latest_API page may describe a newer branch; an older branch page may omit a later capability. Compare the documented “Since” or branch context with the running point release without turning documentation presence into availability proof.

If the lifecycle page's displayed status conflicts with its scheduled date, record both as observed. Do not resolve a missing feature by assuming that a dated release, pre-release or support transition has occurred in every package channel.

Trace source, dependency, build and installed-file state

Verify that the selected source or package contains the module, that required libraries and headers were discovered, and that the build selector included it. Then prove that the resulting module file exists in the active module directory and belongs to the intended core build. Missing optional dependencies and disabled build selections can remove a module even when its documentation exists.

Do not copy an old module binary into a new installation as a shortcut. Rebuild or install through the deployment owner, preserve configuration, and keep artifact or package identity attached to the evidence.

Separate load policy, loaded state, running state and registration

Inspect effective modules.conf, includes, autoload, noload, load, require and preload controls before changing them. Use module show like to distinguish absence from a loaded module and to notice a Not Running status; then inspect load errors and missing dependencies. A successful load response is still not proof that the required capability registered.

Use runtime discovery such as help, core show help, application or function inventories, and user-scoped plus administrator-side AMI command inventories as appropriate. Keep configuration validity and one real workflow test separate from registry presence.

Correct one proven owner and retest with rollback

Correct only the demonstrated boundary: branch choice, package channel, source artifact, dependency, build selection, module installation, module-load policy, module configuration or authorization. Restart or reload only through the supported owner and with a preserved rollback path. Repeat the exact registry check and one bounded workflow, then confirm the unaffected control.

Do not claim broad compatibility from one registered command or successful test. No host, artifact, signature, source tree, dependency, package, build, module file, configuration, running process, API, endpoint, packet, audio or call was inspected or tested for this diagnostic.

Check the current branch index and running function inventory

The VALID_EXTEN upgrade diagnostic avoids treating older branch documentation as proof of current availability.