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

Asterisk AMI DTMF, MF and hook-flash control: channel and direction evidence

Use PlayDTMF, PlayMF and SendFlash without confusing action acceptance, receive emulation, signalling family, channel leg or downstream effect.

Reviewed 2026-10-25Current branch-23-generated and Asterisk 22 PlayDTMF, PlayMF and SendFlash action references, the current DTMFBegin event reference and res_pjsip configuration reference were reviewed October 25, 2026; installed release, loaded app_senddtmf or app_mf module, manager permission, channel technology, live channel identity, bridge topology, direction, negotiated media, DTMF mode and downstream application behavior remain deployment specific; no PBX, channel, manager session, action, digit, hook flash, signalling frame, packet, media stream, endpoint, IVR, carrier or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze the exact channel leg and intended signal

Record the Asterisk node, installed release, loaded module, manager identity, Channel, Uniqueid, Linkedid, bridge membership, caller and connected line, direction, requested action, digit, duration and timestamp. Resolve identity from one bounded observation window rather than a broad channel-name match.

The AMI actions target one channel. A linked call, bridge or endpoint may contain several legs with different signalling paths, so a correct digit on the wrong leg is still the wrong operation.

Use PlayDTMF with an explicit direction model

The current PlayDTMF reference places the action in app_senddtmf, requires Channel and Digit, and offers Duration in milliseconds. By default it sends DTMF out on the selected channel; Receive: true instead emulates receiving DTMF on that channel.

Treat those as different tests. Sending toward a peer, injecting into Asterisk application processing and observing DTMF on another bridge leg are not interchangeable outcomes.

Keep DTMF transport separate from core events

For a PJSIP endpoint, record the configured dtmf_mode: rfc4733, inband, info, auto or auto_info. Then preserve negotiated SDP or SIP INFO evidence, audio evidence when in-band applies and relevant DTMFBegin or end events at the Asterisk boundary.

An accepted manager response does not prove that RFC 4733 telephone events, SIP INFO, in-band tones or core DTMF frames reached the intended consumer. Each is a separate boundary.

Do not substitute PlayMF for PlayDTMF

The current PlayMF reference places the action in app_mf, requires Channel and Digit, and accepts optional duration. It generates multifrequency signalling, not DTMF.

Use only the digit vocabulary and timing supported by the documented MF operation and the authorized receiving system. Do not use PlayMF to work around a DTMF-mode or negotiation defect.

Treat SendFlash as channel-specific and version-gated

The generated SendFlash page places the action in app_senddtmf, takes a channel and dates availability from Asterisk 20.3.0 and 18.18.0. Confirm the running action inventory, loaded module and channel technology before use.

A hook flash on a selected channel is not a universal SIP endpoint flash key, transfer command or carrier feature. Action acceptance does not prove that another leg, gateway or service recognized it.

Verify the first observable boundary without broad retries

Correlate one unique ActionID with the raw AMI response, exact channel identity, direction, DTMF or MF event evidence, signalling or audio evidence and the intended IVR, gateway or application result. Stop at the earliest divergence.

Use a dedicated least-privilege manager identity, a controlled call and a harmless test input. Do not spray digits or flashes across channels, and do not claim endpoint or carrier compatibility from documentation alone. No PBX, channel, signal, endpoint or call was tested for this guide.

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 interface documentation reviewed September 30, 2026; implementation must be checked against the installed branch and integration library

Asterisk AMI, ARI and AGI: choose the control boundary

Separate management events, synchronous dialplan work and application-owned call control before exposing an integration.

Read guide →
Guide · Asterisk branch-23-generated and branch-22-generated ListCommands references plus official AMI syntax, v2 specification, manager-command, change/versioning, permission, module-loader and network-security documentation reviewed October 16, 2026; installed branch and maintenance release, build, package and module set, manager user, read and write authorizations, session mask, action registration, request framing, parameters, target objects, response, related events and service outcome remain deployment specific; no PBX, module, package, manager user, manager session, request, response, event, configuration file, channel, packet, media stream or live call was inspected or tested

Asterisk AMI command inventory and permission evidence

Use ListCommands and the administrator CLI to distinguish the actions visible to one manager user from the actions registered by the running Asterisk instance.

Read guide →
Guide · Current Asterisk Latest API CHANNEL_EXISTS, CHANNELS and CHANNEL references, CLI channel-operation and Local-channel optimization documentation, AMI CoreShowChannels surfaces and the upstream func_channel implementation were reviewed October 19, 2026. The generated API pages reported branch 23; installed branch, loaded modules, channel drivers, names, unique IDs, linked IDs, Local optimization, permissions, timing and call outcomes remain deployment specific. No PBX, module, dialplan, channel, bridge, manager session, packet, media stream or live call was inspected or tested

Asterisk channel inventory, identity and lifetime

Treat a channel list as a changing observation, distinguish name from unique identity, and revalidate the exact leg before an authorized operation.

Read guide →
Guide · Asterisk 22 res_pjsip, logging and troubleshooting references plus RFC 4733 and RFC 6086 reviewed October 7, 2026; no Asterisk host, endpoint, trunk, IVR, bridge, RTP event, SIP INFO request, audio tone, digit, packet capture, media stream or live call was inspected or tested

Asterisk PJSIP DTMF: mode, negotiation and call-leg evidence

Keep RFC 4733 events, in-band tones and SIP INFO separate on each PJSIP leg, then prove what Asterisk received and sent.

Read guide →
Guide · Current first-party Asterisk 22 ARI DTMF event, Channels REST API, bridge-mixing, ARI configuration and PJSIP DTMF-mode documentation reviewed October 9, 2026; no HTTP server, ARI identity, WebSocket, Stasis application, channel, bridge, endpoint, SIP message, RTP event, audio tone, digit, playback, application state or call was inspected or tested

Asterisk ARI DTMF: events, bridges and digit injection

Handle received digit events and outbound digit injection as separate operations, preserving channel identity, transport, bridge decoding, duration and application state.

Read guide →
Guide · Current Asterisk PJSIP_DTMF_MODE, PJSIP_ENDPOINT, CHANNEL, Dial, res_pjsip and AMI DTMF event documentation reviewed October 13, 2026; PJSIP_DTMF_MODE is documented since Asterisk 13.18.0, 14.7.0 and 15.1.0, while installed branch, maintenance release, loaded channel driver, endpoint configuration, channel ownership, negotiated SDP, received and transmitted digits, downstream IVR behavior and media remain deployment specific; no PBX, endpoint, channel, dialplan, SIP message, RTP event, audio stream, digit or call was inspected or tested

Asterisk PJSIP_DTMF_MODE: channel override, signaling method and proof

Read or change the DTMF mode on one PJSIP call leg without confusing endpoint policy, channel ownership, advertised telephone events or a downstream IVR result.

Read guide →
Protocol reference

DTMF over VoIP: why menus sometimes miss digits

Separate in-band tones, RTP telephone events and signaling-based methods across each call leg.

Read guide →
Guide · Operational guidance; Asterisk 22 / FreePBX 17 where applicable

Least privilege for PBX users and integrations

Separate the right to register, place calls, administer the PBX and read sensitive data.

Read guide →
Troubleshooting · Current branch-23-generated and Asterisk 22 PlayDTMF, PlayMF and SendFlash action references, the current DTMFBegin event reference and res_pjsip configuration reference were reviewed October 25, 2026; installed release, loaded app_senddtmf or app_mf module, manager permission, channel technology, live channel identity, bridge topology, direction, negotiated media, DTMF mode and downstream application behavior remain deployment specific; no PBX, channel, manager session, action, digit, hook flash, signalling frame, packet, media stream, endpoint, IVR, carrier or live call was inspected or tested

Asterisk AMI PlayDTMF, PlayMF or SendFlash hits the wrong leg or has no effect

Find the first divergence across action availability, channel identity, direction, signalling, Asterisk events and downstream behavior before retrying control input.

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 →
Troubleshooting · Asterisk 22 res_pjsip, logging and troubleshooting references plus RFC 4733 and RFC 6086 reviewed October 7, 2026; no Asterisk host, endpoint, trunk, IVR, bridge, RTP event, SIP INFO request, audio tone, digit, packet capture, media stream or live call was inspected or tested

Asterisk receives DTMF but the far IVR ignores or doubles it

Correlate one digit across ingress receipt, bridge ownership, egress representation and the far application before changing endpoint modes.

Read guide →