DTMF over VoIP: why menus sometimes miss digits

Digits can travel in different forms

An IVR may receive keypad input as audio tones, as RTP telephone events or through a supported signaling method. Both sides need a compatible arrangement. RFC 4733 specifies RTP payloads for telephone events and supersedes the older RFC 2833 reference still found in many interfaces.

Hearing a tone locally does not prove the remote menu received the expected event. A handset can produce local feedback while sending a different representation on the call.

Inspect negotiation before changing codecs

For RTP events, check the negotiated event format and payload mapping on the relevant leg. Dynamic payload numbers are negotiated identifiers, not a universal fixed value to copy between systems. A PBX can translate or renegotiate behavior across legs.

In-band tones depend on the audio path and can be affected by codec processing. Do not assume compressed audio will preserve every tone reliably.

Reproduce a small menu test

Call a known authorized test menu and enter one digit at a time. Record whether digits are missing, doubled or ignored only on a particular route. Compare an internal IVR with an external one and compare two endpoints to locate the boundary.

If the problem appears after transfer, inspect the later media negotiation rather than only the initial call setup.

Fix the mismatched leg

Align the endpoint, PBX and carrier settings with their documented capabilities. Change one side only when you understand its peer. Re-test multiple digits, repeated digits and the transferred-call path. Avoid enabling every DTMF method simultaneously, which can create duplicate input in some configurations.

Apply the protocol model to Asterisk PJSIP

For an Asterisk bridge, use the PJSIP DTMF guide to keep the phone-facing and trunk-facing modes and dynamic payload mappings separate. The focused diagnostic follows one received digit to its far-side representation without enabling every mode.

Keep Announcement matching separate from DTMF transport

When a FreePBX Announcement ignores, repeats or skips on a keypress, the Announcement diagnostic binds transport evidence to the specific repeat or skip branch. A digit received by Asterisk, a matching Announcement key and the final destination are three separate checks.

Apply digit evidence to dial-by-name search

A directory search can fail even when the caller hears keypad tones. Use the FreePBX Directory diagnostic to bind transmitted digits, Asterisk reception, name matching, result selection and the final dial target without changing trunk-wide DTMF settings first.

Map the Asterisk channel mode to protocol evidence

The Asterisk PJSIP runtime guide compares one channel mode with RFC 4733 events, SIP INFO or in-band tones without treating the configured label as delivery proof.

Observe Localphone DTMF instead of assuming the example

Localphone’s older Asterisk example specifies RFC 2833 DTMF. The Localphone service record requires negotiated telephone-event mappings and decoded digit evidence on the authorized call path.

Separate Asterisk DTMF frames from external signaling

The FRAME_TRACE diagnostic uses DTMF_BEGIN and DTMF_END as channel-internal observations while preserving RFC 4733, in-band and SIP INFO evidence on their external legs.

Keep MicroSIP local tone playback outside DTMF delivery evidence

MicroSIP 3.22.19 describes improved DTMF playback and suppressing local tones during calls. The MicroSIP guide separately preserves the configured method, SDP mapping or SIP INFO, transmitted event, timing and remote IVR outcome.

Separate digit transport from feature authorization

The dynamic-feature diagnostic proves negotiated delivery and per-channel DYNAMIC_FEATURES independently.