Asterisk AMI dialplan extension is missing, stale or wrong

Freeze the exact key and symptom

Record the installed branch, dialplan engine and owner, source revision, last reload or generation, manager identity and permissions, ActionID, context, extension including any caller-ID suffix, priority, application, application data, Replace value, raw response and expected call behavior.

Classify the symptom first: absent from loaded view, action rejected, unexpected replacement, over-broad removal, present but not selected, selected but failed, corrected until reload, or correct signaling with a bad media or business outcome.

Compare owned source with loaded scope

Inspect the exact context and extension with ShowDialPlan; avoid an unscoped full dump unless its capacity cost is understood. Compare the result with the actual configuration owner, not merely a convenient file. Retain both records and their timestamps.

If source is correct but loaded state is stale, investigate the reload or generator boundary. If loaded state differs after a runtime action, do not rewrite source blindly; decide which representation is authoritative and plan convergence.

Reconstruct the add or replacement transaction

For DialplanExtensionAdd, verify all target fields and whether the context already existed. If the exact context–extension–priority key existed and Replace was not true, failure is the documented protective outcome. If replacement was intended, compare the retained before-image with the new application and data.

Keep a hint priority separate from numeric execution priorities. Also retain caller-ID matching after /; dropping it during comparison can make the wrong extension appear to be the target.

Audit removal scope before recovery

For DialplanExtensionRemove, determine whether Priority was supplied. Its absence requests removal of every priority under that extension, while its presence narrows the operation. Re-inspect the target and adjacent priorities before adding anything back.

Restore from the approved source or retained before-image, using non-replacing add semantics first. Verify the exact loaded key and do not claim recovery until the durable owner and reload behavior agree.

Prove why a channel selected another path

Record the channel entry context, dialed digits and caller ID. Check exact extensions, matching patterns, includes and switches in documented search order, then verify the priority sequence. A loaded row can remain unused because the caller entered a different context or a more specific route won.

If the row is selected, inspect application availability, arguments, return behavior and the next priority. A manager success response neither executes that row nor proves that the full extension is internally coherent.

Test reload survival and call outcome independently

After the controlled correction, capture a scoped loaded view, one authorized test call and the resulting channel and application evidence. Separately test the platform-approved reload or regeneration and confirm the same key again. Fix the first boundary that diverges.

Signaling progress, answer, two-way media and business outcome remain later checks. A successful AMI mutation does not prove any of them. No PBX, module, manager session, configuration file, loaded dialplan, channel, packet, media stream or live call was inspected or tested for this diagnostic.

Check the durable owner before converting a runtime fix

The AMI configuration diagnostic traces source, destination, includes, templates and reload without assuming one file owns the dialplan.