Treat deprecation and current availability as separate evidence
Asterisk 22 documents VALID_EXTEN() as deprecated in favor of DIALPLAN_EXISTS(). The current Asterisk 23 function index lists DIALPLAN_EXISTS() but not VALID_EXTEN(), and the current upstream func_dialplan source registers DIALPLAN_EXISTS().
Those sources establish a migration direction, not the state of one installed PBX. Before editing, record the running Asterisk version, package source, loaded function list, active dialplan owner and every call site that still invokes the older name.
Do not perform a blind name replacement
The older VALID_EXTEN(context,extension,priority) page says context defaults to the current context and priority defaults to 1. The current DIALPLAN_EXISTS(context,extension,priority) reference declares context explicitly and the implementation can test a context alone, an extension at priority 1, a positive numeric priority or a named label.
Make context, extension and priority or label explicit at each migrated call site. A text substitution that preserves omitted fields can change the question being asked or produce an invalid invocation.
Define the target contract before evaluating it
Separate four questions: whether a context exists, whether an extension has priority 1, whether a positive numeric priority exists and whether a named label resolves. Store one DIALPLAN_EXISTS() result and branch on that captured value instead of evaluating a moving target several times.
A return value of 1 proves only that the requested dialplan target resolved for that observation. It does not prove that a caller will select it, that downstream applications will succeed or that the destination is authorized.
Preserve pattern and caller-dependent routing evidence
Asterisk pattern matching chooses among exact and pattern extensions by specificity, and the implementation supplies the current channel caller number when checking a target. Preserve the literal extension, context, caller identity and loaded include or switch topology used by the original decision.
Use dialplan show extension@context to see matching loaded entries. A positive lookup for one target does not demonstrate that normal call processing chooses the same entry when several patterns or includes are available.
Verify the running function and loaded dialplan
Use core show functions and core show function DIALPLAN_EXISTS on the intended node. Online documentation and a package version do not prove what that process compiled and registered. Confirm the loaded context with dialplan show, after the deployment system has generated and reloaded its configuration.
On FreePBX or another generator-managed system, change the supported custom source or module owner rather than editing generated output that will be overwritten.
Migrate with bounded parity and rollback evidence
In an authorized staging path, capture the old result where the older function still exists, add the explicit new check, and compare context-only, exact extension, numeric-priority, label, missing-target and pattern cases. Preserve the expression result and the later selected priority separately.
Deploy the smallest supported change, reload through the owning workflow, repeat known-good and known-missing controls, and keep rollback material. No PBX, module, package, generated configuration, dialplan, channel, lookup or live call was inspected or tested; this guide is documentation-derived.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 22 VALID_EXTEN function and deprecation notice ↗
- Asterisk 23 DIALPLAN_EXISTS function ↗
- Asterisk 23 dialplan-function index ↗
- Asterisk func_dialplan implementation ↗
- Asterisk dialplan-function availability and syntax ↗
- Asterisk CLI syntax and function-help commands ↗
- Asterisk dialplan reload and show workflow ↗
- Asterisk dialplan pattern matching ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.