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.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.