Asterisk module is loaded but its capability is missing

Freeze the missing capability and first symptom

Record branch and build, package source, module directory, exact shared object, expected capability, modules.conf policy, manager identity and permissions, ActionID, action type and raw response, relevant logs and first failed command or behavior. Distinguish a missing module from a missing application, function, driver, AMI action, endpoint, transport or other object.

Do not begin with refresh. A broad lifecycle change can erase the evidence that separates packaging, loading, registration, parsing and runtime failure.

Confirm package and target syntax

Verify the shared object exists in the configured module directory and belongs to the expected Asterisk build and packaging source. Use the name without an extension for ModuleCheck; use the .so module name for a module target in ModuleLoad. Preserve the difference so a syntax mismatch is not mistaken for an absent feature.

Compare ModuleCheck with module show like at the same time. The empty documented Version field does not identify the binary build.

Reconstruct the lifecycle action

Classify whether the request used load, unload, reload or refresh, and whether the target was a module or reload-only subsystem identifier. Check the raw response and logs for dependency, symbol, configuration or registration errors rather than stopping at the AMI response.

If no module was supplied for a reload, account for the documented all-module scope. If recursive refresh was requested, include every dependent module it attempted to cycle.

Compare runtime state with startup policy

Inspect autoload, preload, require, preload-require, noload and explicit load entries in the effective modules.conf owned by the deployment. A runtime load can succeed while policy still prevents the same state after restart; conversely, a required module failure can stop startup.

Check the service manager and package upgrade history before changing policy. Repair the durable owner rather than layering an AMI-only workaround.

Prove registration and configuration independently

Query the narrow surface that should expose the capability: the dialplan application or function registry, channel or resource command, AMI command list, module-specific object list or configuration status. Then inspect parser logs and the exact loaded object. A loaded row can coexist with a failed registration, missing dependency, rejected option or absent object.

Prefer a supported targeted reload only after identifying which configuration and registration stage diverged. Do not use force-unload options as a diagnostic shortcut.

Test one behavior and retain rollback evidence

Run one authorized acceptance case that exercises the expected capability and capture the minimum signaling, media and application evidence needed to show the outcome. If it still fails, keep package, load, registration, configuration and behavior findings separate and roll back through the true configuration owner.

Do not widen AMI permissions, expose the manager port or disrupt active calls to gain evidence. No PBX, module, package, manager session, configuration file, channel, packet, media stream or live call was inspected or tested for this diagnostic.

Use the manager registry for a missing AMI capability

The AMI missing-action diagnostic separates server-side action registration from manager-user authorization.

Rule out branch and build mismatch before changing configuration

A loaded module can still differ by branch, point release, dependency, build selection or registration result. Follow the version/build diagnostic when documentation and runtime inventories disagree.

Verify the registered function, not just the module row

The VALID_EXTEN upgrade diagnostic checks CLI function help and loaded dialplan before assigning the failure to a package.