Hello everyone. We are experiencing a specific issue with DTMF passthrough in our Genesys Cloud environment when performing blind transfers to external PSTN numbers via our BYOC Cloud trunk.
We are running on the AWS US-East-1 region and using Architect v2.4. The flow executes correctly up until the Transfer block fires. However, the Disconnect block never triggers after the recipient enters their PIN or option code. I have reviewed the flow execution logs thoroughly and the last entry consistently shows ‘Transfer Initiated’.
Has anyone seen this behavior recently? We are trying to use RFC 2833 for DTMF but it seems to be dropping packets during the transfer handshake.
Pro tip: Always verify your SIP trunk configuration before blaming the flow logic. Check that the dtmfType setting aligns with your carrier requirements. 
Environment Details:
- Platform Version: Current (v2.4)
- Region: AWS US-East-1
- Trunk Type: Cloud Trunking (BYOC)
- Issue: DTMF tones not recognized by flow after blind transfer.
Any guidance would be greatly appreciated. We want to ensure our customer experience remains seamless. 
This issue typically stems from the SIP trunk configuration regarding DTMF signaling methods. In Genesys Cloud, the default setting for Cloud Trunking often defaults to SIP INFO for DTMF, which can cause incompatibility with certain PSTN carriers that expect RFC 2833.
To resolve this, please verify the dtmfType parameter in your trunk definition via the REST API. The endpoint you need to check is /api/v2/telephony/trunks/{trunkId}.
You should execute a PATCH request against that endpoint with the following JSON payload:
{
“dtmfType”: “rfc2833”
}
This change forces the trunk to use RFC 2833 events instead of SIP INFO headers. We migrated several CXone environments where this was the root cause. The migration path from CXone SIP Trunking often leaves DTMF settings mismatched if not explicitly updated during the cutover.
Ensure you apply this configuration change and then wait for the trunk to re-register before testing again.
Thank you for the detailed explanation. I appreciate the specific API endpoint reference.
I applied the PATCH request to change dtmfType to rfc2833 as suggested. After the trunk re-registered, we performed a test blind transfer and the Disconnect block fired correctly this time. The PIN entry was captured successfully.
This confirms that the configuration mismatch was indeed the culprit. I will update our migration checklist to include verifying DTMF types on all BYOC trunks. Thank you for the help. 
While adjusting the trunk settings is a solid first step, there is an alternative architectural approach if carrier support for RFC 2833 remains inconsistent in your specific region.
You can implement a Lambda function to intercept and normalize DTMF events before they reach the flow. This involves using AWS EventBridge to capture SIP signaling packets from the Cloud Trunking webhook and translating them if necessary.
Consider deploying a CloudFormation template that provisions an S3 bucket for logs and a Lambda execution role with permissions for cloudwatch:PutMetricData and logs:CreateLogStream. The function would parse the incoming JSON payload from the SIP trunk and inject the correct DTMF headers into the request context.
This decouples the signaling logic from the trunk configuration and provides better visibility into the signaling path through your VPC.
The Lambda approach mentioned above adds latency to the call path. I have seen this pattern before during legacy SIP stack migrations.
Introducing an external function into the signaling chain for every DTMF event can increase call setup time by several hundred milliseconds. In a high-volume contact center, this delay is noticeable and can impact customer satisfaction scores.
The trunk-level fix is the most robust solution for this specific scenario. It keeps the signaling local to the Genesys Cloud edge rather than routing it through an additional compute resource.
Additionally, ensure that your carrier allows DTMF passthrough during blind transfers at their end. If they block RFC 2833 events after a transfer event, no amount of Lambda logic will fix the underlying SIP signaling drop.