VoIP.infoThe independent guide to business communications.
VoIP.info Troubleshooting

FreePBX Dynamic Route picks the wrong destination or drops the call

Find the first mismatch among module state, caller input, variable substitution, lookup source, returned text, exact entry match, invalid branch, default destination and generated dialplan.

Reviewed 2026-10-14Current Sangoma Dynamic Routes module, user-guide, example, support-classification and Module Admin documentation plus the FreePBX project article and contributed-module repository reviewed October 14, 2026; the module page says installations since FreePBX 15 can obtain Dynamic Routes from the Unsupported repository while the current category page describes these modules as community supported and not maintained by the core PBX Engineering team, so installed version, signature, support entitlement, lookup dependencies, generated dialplan, credentials, returned values and live routing remain deployment specific, and no PBX, module, database, ODBC source, URL, AGI script, channel, DTMF input, dialplan, destination or call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one call and its expected branch

Record timestamp and timezone, FreePBX and Dynamic Routes module versions, module signature and state, route name, generated configuration revision, inbound source or prior destination, caller and DID in redacted form, DTMF length and validation result, lookup type, saved-variable names, substitution state, sanitized lookup fingerprint, returned text, configured entries, invalid destination, default destination and the first wrong or missing handoff.

Classify the first divergence as module unavailable, stale generated dialplan, input rejected, variable missing, unintended substitution, lookup failure, malformed result, exact-match miss, wrong entry, invalid branch, default branch or downstream destination failure.

Prove the installed module and loaded route

Confirm the module is installed, enabled and signed according to the selected repository policy, then verify that the intended Dynamic Route exists in the GUI and is referenced by the upstream call flow. Apply configuration through the normal change process and identify the loaded dialplan revision before reproducing.

Do not infer runtime state from the repository or documentation. A saved GUI form, enabled module and loaded dialplan are three separate observations, especially after a restore, module update or failed Apply Config.

Trace input, validation and substitutions

For DTMF routes, compare received digits with the configured maximum length, timeout, validation rule, retries and invalid destination. Then inspect saved input and result names on the same channel. A caller timeout, rejected format and accepted value must not be collapsed into one empty result.

Compare the stored lookup template with the rendered expression. If literal square brackets are present, confirm whether substitutions were intentionally disabled. If substitutions are expected, prove the referenced DYNROUTE_ value exists on that exact channel before the lookup runs.

Test the selected lookup source as its own boundary

Identify whether the route uses MySQL, ODBC, URL, AGI or an Asterisk variable. Capture a credential-safe request or query fingerprint, start and finish time, transport or function result, returned value and error class from the same execution window.

For URL sources, the guide requires text output rather than HTML, XML or JSON. For AGI, prove the script executed and set the configured result variable. For ODBC, prove the intended function and data source. Do not rotate unrelated credentials or expose raw requests until the failing source is known.

Compare returned text with exact entries and fallback

Preserve the returned value exactly and compare it with every configured Dynamic Route entry. The documented routing match is exact, so case, formatting, unexpected wrappers or a different token can explain a miss even when the upstream lookup succeeded.

If no entry matches, follow the configured default destination. The guide warns that lookup failure or an unmatched result can drop the call when no default is defined. Distinguish that behavior from an explicit Terminate Call destination and from a downstream destination that receives the call but then fails.

Correct the first boundary and test all four outcomes

Change only the first demonstrated mismatch: module or loaded state, input rule, variable name, substitution setting, source configuration, result contract, entry value, invalid destination or default destination. Repeat the original call plus one valid match, invalid input, failed lookup and unmatched result.

Retain the pre-change configuration and external-system owner for rollback, and remove sensitive captured data after the evidence is recorded. No PBX, module, database, ODBC source, URL, AGI script, channel, DTMF input, dialplan, destination or call was inspected or tested for this diagnostic.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Guide · Current Sangoma Dynamic Routes module, user-guide, example, support-classification and Module Admin documentation plus the FreePBX project article and contributed-module repository reviewed October 14, 2026; the module page says installations since FreePBX 15 can obtain Dynamic Routes from the Unsupported repository while the current category page describes these modules as community supported and not maintained by the core PBX Engineering team, so installed version, signature, support entitlement, lookup dependencies, generated dialplan, credentials, returned values and live routing remain deployment specific, and no PBX, module, database, ODBC source, URL, AGI script, channel, DTMF input, dialplan, destination or call was inspected or tested

FreePBX Dynamic Routes: bounded lookup-to-destination routing

Turn one documented DTMF, ODBC, URL, AGI or channel-variable lookup into an exact destination match while preserving support status, input, substitution, result, default path and external-system evidence.

Read guide →
Guide · FreePBX 17 / Debian 12; module UI varies

FreePBX module administration and updates

Inventory module state, preview dependencies and signatures, change the smallest intended set, and prove reload and call behavior before closing the window.

Read guide →
Guide · FreePBX 17 on Debian 12; route semantics cross-checked against Sangoma PBX GUI 13 guides and current FreePBX Blacklist 17.0.1.2 release/17.0 source on October 11, 2026; exact installed modules, generated or loaded route hooks and calls were not tested

FreePBX inbound and outbound routes

Follow the incoming number and outgoing dial pattern as two separate routing decisions.

Read guide →
Guide · FreePBX CallerID Lookup release/17.0 repository, module metadata, generated-dialplan source and configuration class plus current Asterisk caller-ID, party-ID, internal-database and TXTCIDNAME documentation reviewed October 12, 2026; repository metadata reports module 17.0.1.1 and FreePBX 17.0 support but does not establish the installed module, saved source, inbound-route assignment, generated or loaded dialplan, database value, external response, channel identity, endpoint display or call result; no PBX, module, source, credential, database, cache, route, call or endpoint was inspected or tested

FreePBX Caller ID Lookup Sources: route, source, cache and displayed-name evidence

Follow one incoming number through the matched inbound route, selected lookup source, returned value, optional AstDB cache, channel caller name and final endpoint display.

Read guide →
Guide · Sangoma Custom Destinations, Misc Applications and Misc Destinations guidance; FreePBX Custom Applications 17.0.1 and Misc Applications 17.0.3 release/17.0 metadata and current dialplan sources; and current Asterisk Goto, Gosub, Return and dialplan documentation reviewed October 11, 2026; older screen guides establish concepts rather than an exact FreePBX 17 field map, and no installed module, code, application, destination, generated or loaded dialplan, caller path or call was inspected or tested

FreePBX Custom Destinations: publish custom dialplan without losing ownership

Register a reviewed context, extension and priority as a managed destination, choose transfer or subroutine behavior deliberately, and keep source, generated state and call results separate.

Read guide →
Guide · FreePBX 17 on Debian 12; Bulk Handler 17.0.7.1 release/17.0 metadata and Sangoma Bulk Handler workflow reviewed October 11, 2026; repository state does not prove the installed module or runtime, and no import or Apply Config operation was tested

FreePBX changes: submit, apply and verify

Keep GUI settings, generated configuration and runtime behavior aligned during routine administration.

Read guide →
Troubleshooting · FreePBX inbound-route and example documentation plus current Asterisk PJSIP troubleshooting and res_pjsip references reviewed October 5, 2026; exact FreePBX 17 module fields, generated dialplan and provider delivery format require runtime verification

FreePBX inbound route mismatch: trunk identity, DID, CID and destination proof

Trace one inbound call from the accepted trunk through delivered number and caller identity to the selected FreePBX destination.

Read guide →
Diagnostic · Current Sangoma fwconsole and Asterisk CLI, dialplan and PJSIP troubleshooting documentation reviewed September 27, 2026; no FreePBX, Asterisk or call path lab tested

FreePBX Apply Config failed: isolate generation from reload

Preserve the failed change, capture the supported fwconsole reload error and prove which generated object reached Asterisk before attempting repair.

Read guide →