Quick question, has anyone seen this weird error? with our AppFoundry integration that bridges custom IVR logic via a SIP trunk to the Genesys Cloud PSTN Gateway. We are deploying a premium app that requires precise DTMF capture for routing decisions, and we have configured the SIP trunk to use RFC 2833 (RTP out-of-band) for DTMF transmission, as per the recommended best practices for modern VoIP integrations. However, when a caller enters a multi-digit extension, the Genesys Cloud side consistently rejects the SIP INVITE with a 488 Not Acceptable Here response, citing an unsupported media type for the application/sdp packetization. This occurs specifically when the payload type mapping for RFC 2833 is set to 101, which is standard in our Asterisk PBX configuration. We have verified that the SDP offer from the Genesys Cloud gateway includes the a=fmtp line for payload type 101 with the correct parameters (0-16), yet the handshake fails during the initial SDP negotiation phase. Our logs show that the Genesys Cloud gateway is stripping the RFC 2833 capability from the SDP answer, forcing a fallback to SIP INFO, which our current AppFoundry webhook listener is not optimized to handle in real-time without introducing significant latency. We are using the latest version of the Genesys Cloud API SDK for Java and have ensured that the SIP trunk configuration in the Architect allows for custom headers, but the 488 error persists regardless of the retry logic implemented in our backend service. The environment is production, and this issue is blocking a critical client deployment scheduled for next week. We have tested with IN-BAND DTMF, which works but introduces unacceptable audio quality issues and false triggers. Is there a specific configuration in the Genesys Cloud SIP Trunk settings that explicitly disables RFC 2833 acceptance, or is this a known limitation with the PSTN Gateway’s SDP parser that requires a workaround via the API?
I normally fix this by switching the DTMF mode to SIP INFO instead of RFC 2833, as the PSTN Gateway parser can be strict with RTP payload types. Ensure your carrier also supports SIP INFO before making the change, or you will lose DTMF entirely.