VoIP.info Guide

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.

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

Separate definition, authorization, delivery and outcome

A custom feature is first defined in the [applicationmap] section of features.conf. That definition does not make it available to every bridged party. Current Asterisk documentation says access is controlled per channel through the DYNAMIC_FEATURES variable, whose value is a #-separated list of application-map item names or feature-group names.

Keep five boundaries distinct: the item exists, the intended channel authorizes it, the bridge receives the DTMF sequence, Asterisk invokes the mapped application on the intended leg, and the application produces the intended result. Evidence for one boundary does not prove the next.

Authorize the channel that may press the code

The historical ActivatedBy field is no longer honored. Current documentation says activation depends on which channel carries a DYNAMIC_FEATURES value containing the item. If the two legs need different permissions, set the variable on the appropriate channels, commonly with a Dial pre-dial handler for the outbound leg.

Single-underscore and double-underscore variable inheritance have different child-channel behavior. __DYNAMIC_FEATURES can propagate to outbound channels, but inheritance is not global authorization. Capture the actual value on both bridged legs.

Interpret self and peer from the activating channel

ActivateOn accepts self or peer. self runs the application on the same channel that entered the DTMF sequence; peer runs it on the opposite bridged channel. Those terms are relative to the activator, not fixed caller and callee roles.

Document the full channel names, linked call identity, bridge membership, the leg that supplied the digits and the leg on which the application ran. Transfers, Local channels and changing bridges make role labels alone unreliable.

Use feature groups without hiding the effective code

A feature group can collect several application-map items and can override an item’s DTMF sequence. The effective trigger therefore comes from the selected group when an override exists, not necessarily from the original item definition.

Inventory built-in feature codes, custom items, groups, overrides and inter-digit timeout together. FEATURE() and FEATUREMAP() are documented for built-in feature settings; they do not replace DYNAMIC_FEATURES authorization for custom application-map items.

Choose applications that fit the execution context

Asterisk warns that application-map actions execute outside the PBX core, so applications that depend on dialplan flow—such as Goto, Background or WaitExten—do not fit this context. Gosub and the legacy Macro exception must complete before the call continues.

Keep arguments, comma quoting, music-on-hold behavior and application completion bounded. A parsed mapping does not prove the application is safe, available or successful on either channel.

Account for DTMF and media-path consequences

The custom-feature documentation notes that enabling stream-DTMF features keeps the PBX in the media flow and prevents media redirection when DTMF is sent in the media stream. Treat that as an architectural input, not proof of the final RTP path or call quality.

Verify endpoint DTMF mode, SDP negotiation, observed RTP events or SIP INFO, bridge feature participation and the application result separately. On FreePBX, place changes in a supported custom configuration owner rather than editing regenerated output. 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.

Separate definition, authorization, delivery and outcome

Authorize the channel that may press the code

Interpret self and peer from the activating channel

Use feature groups without hiding the effective code

Choose applications that fit the execution context

Account for DTMF and media-path consequences

Sources & applicability

Continue your research

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

Asterisk call transfers: blind, attended and bridge evidence

Asterisk channel-variable scope and inheritance

DTMF over VoIP: why menus sometimes miss digits

DTMF digits are ignored by an IVR

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