TL;DR

Your IVR does not hear the keys because tones travel in the wrong format or get mangled in the carrier chain.
Standardise on RFC2833 for DTMF, keep the audio path clean, and avoid codec transcoding.
Voyced trunks and Hosted IPPBX already support RFC2833 end to end. You set your phones or PBX to match and keep in-band off for IVRs.
Result, reliable keypress detection.

“Problem getting accurate DTMF to function in an IVR.”

A quick story

Emma calls a bank IVR.
She presses 2, the system hears 8.
She tries again and it hears nothing.
The call feels broken and trust drops.

Sound familiar?

What is really happening

• Two DTMF methods

  • In-band: tones ride inside the audio stream as beeps

  • RFC2833: tones sent as separate RTP events

• Where it breaks

  • Transcoding or echo control distorts in-band beeps

  • Mixed methods in the path, phone sends in-band, carrier expects RFC2833

  • Payload type mismatch for RFC2833 events

  • Long jitter buffers or packet loss clip events

What Voyced already does

• RFC2833 enabled on trunks and Hosted IPPBX

• telephone-event advertised in SDP with sane defaults

• No forced transcoding on our edge for common codecs

• Clean routing across the EU voice core

You only need to align your side.

What you do on your side

Set one clear method and keep the media path simple.

Phones, ATAs, softphones

• DTMF method: RFC2833 or RTP Events

• In-band: Off for IVR use

• SIP INFO: Off unless a vendor needs it as fallback

• Payload type: leave default if possible, or set to 101

• Codecs: prefer G.711 a-law or u-law for IVR calls

• VAD/AGC: Off when testing DTMF

PBX or SBC

• Force RFC2833 end to end

• Avoid transcoding on IVR legs

• Keep ptime around 20 ms

• Pass telephone-event in both directions

• Do not normalise DTMF to in-band

Router and network

• QoS for voice so DTMF events are not delayed

• Stable NAT, no SIP “helpers” that rewrite RTP

• Wired where possible for key devices

Quick checks you can run now

• Call a known good IVR and press 1-2-3 in a row

• Switch the phone from in-band to RFC2833, test again

• Lock the call to G.711 only, test again

• If you use a PBX, test direct-to-trunk and compare

• Watch your PBX logs for telephone-event being sent and received

What changed the result?

Simple presets by scenario

• Desk phones for IVRs: RFC2833, G.711 only, VAD off

• Softphones: RFC2833, avoid Bluetooth mics for testing

• Analogue adapters: RFC2833, input gain low, echo canceller off during tests

• Contact centres: enforce RFC2833 on the IVR queue and trunk, block in-band

Two fast wins we see often

• A clinic’s IVR missed digits on transfers
  Switched phones to RFC2833, locked to G.711, tones registered first time.

• A support desk heard double digits
  PBX was converting RFC2833 to in-band then back again. Removed conversion, problem gone.

FAQs

Should I ever use in-band
Only with legacy gear that cannot send RFC2833. For IVRs, use RFC2833.

Do I need SIP INFO
Usually no. Keep it off unless a vendor asks for it.

Which codec is safest for IVRs
G.711 a-law or u-law. It avoids extra transcoding steps.

Can Voyced check my path
Yes. We do a short remote session, watch the SDP and RTP events, and help you lock settings.

Make your IVR keys work every time

• Set DTMF fails on IVRs as your focus

• Choose RFC2833 and stick with it

• Keep the audio path clean and avoid transcoding

Fix it with Voyced

Book a quick remote session.

Tell us your phone or PBX model and we will align the settings with you, test live, and document the final setup.