Architect Ignoring DTMF Inputs Despite RTP Packets Arriving

Hey guys, we are having a bizarre issue with our main IVR menu. I am a network engineer and usually deal with SIP and voice quality, but the routing team asked me to look at this. When customers call our toll-free number, the Architect flow asks them to ‘Press 1 for Sales or 2 for Support’. For about twenty percent of callers, Architect just completely ignores their key presses and loops the menu again. I ran a packet capture on our edge server and I can see the RTP packets containing the DTMF tones coming in perfectly fine! Why is Architect ignoring the DTMF inputs if the edge server is receiving them?

Hey man, I run into weird browser and extension issues all the time, and usually when things randomly drop like that, it is a payload mismatch somewhere in the chain. Even though your packet capture shows the DTMF arriving, Genesys Cloud Architect is super picky about the DTMF payload type! Check your external trunk settings and see what DTMF method you have configured. If your carrier is sending RFC2833 but your trunk is expecting Inband audio, the edge server will see the RTP packets but Architect will not understand them as keypad digits!

I have been a certified architect for seven years and this exact issue still makes my blood boil every single time I deploy a new SIP trunk. It is almost guaranteed to be a payload type mismatch on RFC2833. By default, Genesys Cloud expects the DTMF payload type to be 101.

However, many older carriers or session border controllers will negotiate payload type 96 or 100 during the SIP INVITE. You need to open your External Trunk configuration, go to the Media section, and explicitly map the DTMF payload type to match what your carrier is sending in the SDP offer.

If the SDP says 100 and your trunk says 101, Architect just ignores the key presses entirely and acts like the customer is completely silent. It is incredibly frustrating to debug.