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!
2 Likes
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.
2 Likes
i’m not an architect guy, so take this with a grain of salt, but if the packets are hitting the edge and the payload type is correct, the issue might be in how the data is being processed or cached downstream. we cache a lot of API responses in redis to handle burst traffic, and sometimes stale data causes weird routing behaviors.
check if you’re hitting any rate limits on the analytics or interaction endpoints that feed into your routing logic. if the system is throttled, it might drop inputs. here’s a quick check using our python client to see if the trunk is actually reporting active sessions without errors:
from purecloudplatformclientv2 import PlatformApi, TrunkApi, configuration
config = configuration.Configuration(
host="https://api.mypurecloud.com",
client_id="YOUR_CLIENT_ID",
client_secret="YOUR_SECRET"
)
with PlatformApi(config) as platform_api:
auth_result = platform_api.login()
with TrunkApi(config) as trunk_api:
trunks = trunk_api.get_trunks()
for t in trunks.trunks:
if t.name == "Main SIP Trunk":
print(f"Trunk Status: {t.status}")
print(f"DTMF Type: {t.media_config.dtmf_type}")
if the DTMF type matches what the carrier is sending, look at the redis cache for your interaction service. sometimes a cached “busy” state persists even after the call is dropped. flush the relevant keys and see if the DTMF starts working again. also, check the logs for any 429 responses on the interaction API calls.
1 Like
payload type 101 is the default, but if the SBC is sending 96, the edge drops it. i’ve seen this exact 20% failure rate when the negotiation fails on older carriers.
in go, you can verify the active media capabilities by polling the interaction. if the dtmfPayloadType in the response doesn’t match what your trunk is sending, that’s your culprit.
import "github.com/mypurecloud/platform-client-sdk-go/v125/platformclientv2"
func checkMedia(ctx context.Context, client *platformclientv2.Client, interactionID string) error {
analyticsAPI := platformclientv2.NewAnalyticsApi(client)
// Check if the interaction has valid media details
_, resp, err := analyticsAPI.GetAnalyticsConversationsDetails(ctx, interactionID, "")
if err != nil {
return err
}
// Inspect resp.Body to see actual negotiated codecs
return nil
}
don’t just trust the trunk config page. check the actual SIP INVITE/200 OK exchange in the pcap. look for the a=rtpmap line. if it says 96 telephone-event, your trunk needs to accept that or you’re stuck with inband audio which is unreliable.