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

Asterisk dynamic feature code is missing or runs on the wrong channel

Prove the loaded mapping, per-leg DYNAMIC_FEATURES value, received digits, bridge context and self-or-peer execution before changing feature codes.

Reviewed 2026-10-19Current Asterisk custom-feature documentation, the branch-23 features.conf reference, built-in feature guidance, the features overview, upstream sample configuration and implementation, the branch-23 Dial reference and channel-variable inheritance documentation were reviewed October 19, 2026. Installed branch, modules, configuration ownership, reload behavior, bridge technology, channel topology, variable values, DTMF transport, feature-code collisions, media anchoring and application outcomes remain deployment specific. No PBX, module, generated configuration, channel, bridge, DTMF event, media path, feature invocation or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one failed attempt and both call legs

Record timestamp and timezone, Asterisk node and version, configuration owner and reload event, application-map item or feature group, configured and effective DTMF sequence, channel names, Uniqueid and Linkedid values, bridge membership, who pressed the digits, DYNAMIC_FEATURES on each leg, DTMF mode, expected execution leg, observed application output and later call state.

Classify the symptom: item absent, item present but unauthorized, digits missing, partial or colliding code, wrong leg authorized, self or peer misunderstood, mapped application rejected, application completed with the wrong scope, or media behavior changed.

Prove the loaded mapping and effective feature group

Inspect the authoritative features.conf source and the running configuration after the supported reload path. Confirm the item name, DTMF sequence, self or peer, application and arguments. If DYNAMIC_FEATURES names a feature group, resolve every group member and any DTMF override.

Do not treat a file on disk as proof of the active mapping. Also inventory built-in feature codes and other custom items for exact and prefix collisions within the configured digit timeout.

Inspect DYNAMIC_FEATURES on each channel

Capture the variable on both bridged channels immediately before feature use. An item in [applicationmap] is not automatically accessible. The current contract is the item or group name in DYNAMIC_FEATURES on the channel allowed to activate it.

If the outbound leg lacks the value, verify where it was set, whether one or two leading underscores were intended, and whether a pre-dial handler set the child channel explicitly. Do not use the obsolete ActivatedBy field as current permission evidence.

Trace DTMF delivery before feature execution

Confirm the endpoint DTMF setting, offered and negotiated mode, received digits, timing and bridge participation. RFC 4733 events, in-band tones and SIP INFO are different delivery paths. A correct mapping cannot activate when the PBX or relevant bridge feature hook does not receive the sequence.

If the first digits overlap another feature or extension, capture the full sequence and timeout behavior. Do not change several codes at once; use one authorized, low-impact test item and a noncolliding sequence.

Resolve self and peer from the activator

Identify which channel actually entered the digits, then interpret self as that channel and peer as the opposite bridged channel. Caller and callee labels can become stale after transfer, Local-channel optimization or bridge replacement.

Log the application start and completion with channel identity. A feature firing does not prove it ran on the desired leg, and a mapped Set or media application can legitimately affect only the execution channel.

Correct the earliest demonstrated boundary and retest

Correct only the first proven divergence: inactive config, wrong item or group name, missing per-leg authorization, inheritance mistake, DTMF transport, collision or timeout, reversed self or peer, unsupported flow application, quoting error or application failure. Reload through the configuration owner.

Repeat authorized and unauthorized-leg controls, exact and colliding-code controls, both activation directions where intended, and known-good DTMF. Confirm the final bridge and RTP path separately, then remove temporary tracing. No PBX, module, generated configuration, channel, bridge, DTMF event, media path, feature invocation or live call was inspected or tested.

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 Asterisk custom-feature documentation, the branch-23 features.conf reference, built-in feature guidance, the features overview, upstream sample configuration and implementation, the branch-23 Dial reference and channel-variable inheritance documentation were reviewed October 19, 2026. Installed branch, modules, configuration ownership, reload behavior, bridge technology, channel topology, variable values, DTMF transport, feature-code collisions, media anchoring and application outcomes remain deployment specific. No PBX, module, generated configuration, channel, bridge, DTMF event, media path, feature invocation or live call was inspected or tested

Asterisk custom dynamic features and DTMF authorization

Define applicationmap actions, authorize them per channel with DYNAMIC_FEATURES, and keep DTMF delivery, execution leg and media effects as separate evidence.

Read guide →
Troubleshooting · Current Asterisk 22 res_pjsip DTMF-mode, logging, Background, WaitExten and special-extension documentation reviewed September 28, 2026; no endpoint, trunk, codec, RTP event, SIP INFO request, audio tone, IVR, digit or live call was tested

DTMF digits are ignored by an IVR

Locate a mismatch between audio tones, RTP events and the receiving call leg.

Read guide →
Guide · Current Asterisk variable-inheritance guidance and Asterisk 22 Set, CHANNEL, MASTER_CHANNEL, LOCAL, LOCAL_PEEK, VARIABLE_EXISTS and IMPORT documentation reviewed October 15, 2026; channel creation, inheritance depth, Gosub stack frames, master-channel lifetime, cross-channel access and loaded dialplan remain deployment specific; no PBX, channel, variable, subroutine, transfer, Local-channel path or live call was inspected or tested

Asterisk channel-variable scope and inheritance

Choose channel, child-depth, Gosub-frame, master-channel or explicit cross-channel scope before using a variable to control a call.

Read guide →
Guide · Current Asterisk feature-transfer architecture, Asterisk 22 features, FEATUREMAP, BlindTransfer and AttendedTransfer references plus AMI and CEL transfer-event specifications reviewed October 6, 2026; no PBX, endpoint, phone, channel, bridge, dialplan destination, feature code, DTMF sequence, native SIP transfer, recording, identity, media path or call was inspected or tested

Asterisk call transfers: blind, attended and bridge evidence

Separate core feature-code transfers, native SIP or phone behavior and dialplan transfer applications, then preserve the original bridge, consultation leg, destination and final bridge as distinct evidence.

Read guide →
Guide · Current Asterisk CLI, logging, PJSIP troubleshooting and call-identifier documentation reviewed September 30, 2026; CLI commands are not shell commands; no PBX, trace, call or media tested

Asterisk CLI and PJSIP logging for one failed call

Bind one failed call to the loaded PJSIP objects, dialplan decision and short signaling trace, then prove diagnostic cleanup.

Read guide →
Guide · RFC 3264 and current Asterisk 22 res_pjsip, NAT, CHANNEL and PJSIP troubleshooting references reviewed October 7, 2026; no Asterisk host, FreePBX system, endpoint, trunk, bridge, NAT device, offer, answer, request, response, packet path, media stream, compatibility, availability or live call was inspected or tested

Asterisk PJSIP direct media: policy, re-INVITE and final RTP path

Separate loaded direct-media policy from the mid-dialog offer/answer and the RTP path that each endpoint actually adopts.

Read guide →