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

Name the three representations before choosing a mode

Asterisk 22 documents six endpoint values for dtmf_mode: rfc4733, inband, none, info, auto and auto_info. RFC 4733 carries named telephone events as RTP payloads outside the encoded audio, while in-band DTMF is part of the audio stream. SIP INFO is a signaling request and must be interpreted in the context of the peer's supported INFO usage.

RFC 4733 obsoletes RFC 2833, even though provider interfaces may still use the older label. Treat the configured name, SDP telephone-event offer and actual packets as separate evidence rather than normalizing every label into a successful implementation.

Record policy independently on both PJSIP legs

A phone-to-trunk call normally gives Asterisk a phone-facing endpoint and a trunk-facing endpoint. Record the loaded endpoint object and effective dtmf_mode for each leg. The two modes can differ; a correct inbound event does not prove Asterisk emitted the representation expected by the far side.

auto selects RFC 4733 when supported and otherwise in-band, while auto_info falls back to SIP INFO. That documented selection rule is not evidence that a peer truly processes the selected method. none deliberately disables DTMF transmission and reception for the endpoint and should not be treated as a generic troubleshooting reset.

Use SDP and messages to prove the selected method

For RFC 4733, preserve both SDP bodies, the negotiated telephone-event payload mapping and event range, then match them to the observed RTP event packets. Dynamic payload numbers are call-specific identifiers and must not be copied from another trace. RFC 4733 defines event identity, end indication and duration fields; a packet's arrival alone does not prove the receiver accepted one complete digit.

For SIP INFO, preserve the exact request, content type, digit representation and response on the same dialog. RFC 6086 provides the INFO package framework, but a successful generic SIP method response does not by itself establish that an unnegotiated legacy DTMF body drove the far application.

Treat in-band tones as an audio-path dependency

In-band DTMF depends on the tones surviving capture, codec, gain, packet loss, transcoding, mixing and playback across the exact path. Hearing a local keypad tone proves nothing about the far channel. Record the codec on each leg and whether Asterisk is decoding or transcoding before selecting in-band operation.

Direct media can also change which component observes RTP. If endpoints exchange media directly, Asterisk may be unable to inspect or regenerate media-carried events for features that depend on interception. Preserve the completed offer/answer and final RTP destinations instead of toggling direct media from a mode label alone.

Separate digit receipt, forwarding and application consumption

Use a narrowly bounded log window and one authorized test call. First prove whether Asterisk records each intended digit once and in order on the ingress channel. Then prove what representation leaves on the egress leg. Only after those steps should an IVR, feature code, application timeout or destination mapping be investigated.

A digit can be received correctly but consumed by the wrong channel, duplicated by parallel representations, delayed until after an application timeout or sent correctly to a peer that ignores it. Do not enable multiple methods simultaneously as a blanket repair; that can turn one intended keypress into duplicate events.

Change one owner and keep a rollback record

On standalone Asterisk, change the configuration source that owns the loaded endpoint and verify reload or restart requirements for the exact release. On FreePBX, use the supported managed setting and Apply Config; do not patch generated PJSIP files. Keep the previous value and a bounded rollback step.

Retest digits during the prompt, after the prompt, repeated digits, a short multi-digit sequence, hold or transfer where relevant and both call directions. Preserve ingress receipt, egress representation and application result separately. No host, endpoint, trunk, IVR, bridge, event, tone, digit or call was tested for this guide.

Continue from received DTMF into menu dispatch

Once the channel has received the correct key, use the BackGround and WaitExten diagnostic to prove interrupt options, destination context, match order and timing. A DTMF event does not itself prove the IVR branch executed.

Inspect or override one live PJSIP leg

The runtime DTMF mode guide adds PJSIP_DTMF_MODE() ownership and timing to this endpoint, negotiation and call-leg model.

Follow received digits into the effective conference menu

The ConfBridge menu diagnostic continues from negotiated DTMF mode and received frames into sequence matching, role checks and action evidence.