Preserve one failed attempt and the digits the phone actually sent
Choose one authorized internal extension and one intended feature. Record the user-visible code, feature name, source extension, phone model, active account, timestamp and exact result: no request leaves the phone, Asterisk returns a response, another destination answers, the feature announces success but state does not change, or the action works while its lamp stays wrong. These outcomes belong to different owners.
Capture the endpoint's outbound INVITE or a short Asterisk PJSIP trace and retain its Request-URI and Call-ID. A speed-dial label or printed quick-reference card is not proof of the digits sent. Local digit maps, a Send key, interdigit timeout, star-code handling and the selected account can change or withhold the request before FreePBX receives it.
Confirm the effective FreePBX code, status and owning module
In Admin → Feature Codes, find the exact feature and record its enabled state, default code and effective user-defined code before changing anything. Sangoma documents that modules provide feature codes and that administrators can enable, disable or reassign them; a familiar star code is therefore not a universal constant. Confirm the installed module that owns the feature is present and enabled, and Submit and Apply Config only through the supported interface.
Keep the action code separate from any BLF subscription address. Sangoma documents that custom device-state support can create related subscription codes, but the dial action and the lamp's monitored hint are not necessarily the same string or state path. A correct action with a stale lamp is a subscription or provisioning investigation, not proof that the action code failed.
Search the whole numbering plan for a collision
Compare the effective code with extensions, direct-to-voicemail prefixes, ring groups, queues, parking, paging, call-flow controls, custom destinations and outbound dial patterns. Sangoma's deployment guidance explicitly warns that extension numbers can conflict with feature codes and that direct-dial voicemail commonly uses a star prefix. Preserve every matching pattern and its context rather than changing several codes together.
A collision can be exact or pattern-based. Also compare what the endpoint sends after any local transformation. Do not solve the symptom by globally stripping a star, widening an outbound pattern or exposing an internal feature from an inbound context; those changes can redirect unrelated calls or expand access.
Inspect the generated dialplan without editing its output
After one controlled Apply Config, use the running Asterisk CLI to inspect the code in the source extension's effective context. Asterisk documents dialplan show <context> as a way to verify what the running dialplan loaded. Record whether the exact extension or a competing pattern exists, the included context that supplied it and the application path selected.
FreePBX owns its generated dialplan. Do not edit generated configuration to make a temporary result look correct; the next Apply Config can replace it and leave the GUI out of agreement with runtime behavior. If the expected entry is absent, return to module status, code status and the Apply Config result before reloading Asterisk or restarting services.
Follow the selected feature's own state and permissions
Once the dialplan selects the intended application, continue with that feature's own inputs. Call forwarding needs a target and scope; DND and call-flow controls have device or extension state; pickup needs the intended group or call; parking retrieval needs the live lot and slot. An announcement can confirm only the application step it describes. Verify the resulting state independently.
Test from the intended internal context and authorization boundary. A code available to a trusted extension should not automatically be reachable from an inbound route, public IVR or untrusted tenant. Features that place calls, change forwarding or expose mailbox access need explicit abuse and toll-fraud review.
Retest the action, state indication and rollback
Correct only the demonstrated owner: endpoint digit map, effective Feature Codes value, numbering collision, owning module, generated configuration or feature-specific state. Retest the original phone, a second authorized extension, the action result, any BLF indication and one unrelated neighboring number. Then reprovision or restart only the component whose persisted state requires it.
Record the old and new code, module and FreePBX versions, generated-dialplan evidence, affected phone templates, user instructions and rollback. No phone, PBX, feature, dialplan, BLF, call, security boundary or emergency workflow was tested for this guide.
core show version
dialplan show <feature-code>@from-internal
pjsip set logger on
# Place one authorized test from the affected extension; retain its Call-ID and Request-URI.
pjsip set logger offClassify a Misc Application before changing the generic code
If the code belongs to Misc Applications, retain its enabled record, description, exact code and selected destination. Confirm whether the intended workflow is an internal user dialing a code; do not confuse it with a Misc Destination selected by another module or a Custom Destination that registers custom dialplan. The Misc Applications guide preserves those ownership boundaries.
A correct app-miscapps or equivalent loaded match proves only the handoff generated by the installed module. Continue into the selected IVR, DISA, Time Condition, queue or other target and validate its own authorization and caller context. Do not expose an internal code to an inbound route merely to make the diagnostic pass.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma: Feature Codes module ↗
- Sangoma: Asterisk and FreePBX deployment questionnaire ↗
- FreePBX: Feature Code Admin class ↗
- Asterisk: creating and inspecting dialplan extensions ↗
- Asterisk: PJSIP troubleshooting evidence ↗
- Sangoma Misc Applications user guide ↗
- Sangoma Misc Applications overview ↗
- Sangoma Misc Destinations user guide ↗
- FreePBX Misc Applications release/17.0 metadata ↗
- FreePBX Misc Applications release/17.0 dialplan source ↗
- Asterisk contexts, extensions and priorities ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.