Predictive outbound bombing with SIP 487 on Ohio BYOC trunks

Kicked off a predictive dialing campaign against the Ohio BYOC trunks this morning. Console shows the campaign hitting a SIP 487 Request Terminated on roughly 60% of the INVITEs before the carrier even rings. Trunk utilization is sitting at 30%, so it’s not a congestion issue. Checked the SIP signaling logs in Genesys Cloud v2023.11 and the platform is sending a Contact header with the wrong outbound proxy IP. Carrier SBC expects the Virginia failover endpoint but the routing rule is pointing to the Ohio primary. Tweaked the outbound routing group to force the secondary SIP URI, but the predictive engine keeps reverting to the primary after a 10 minute reset window. SDK v2.1.4 calls to /api/v2/routing/outboundcampaigns return fine, yet the actual SIP trunks drop the connection. Agent queue is doing jack all while the campaign spins. Logs show a Retry-After: 0 header attached to every drop. Carrier support says their SBC is just rejecting the mismatched Via header. Console won’t let me override the proxy binding on the trunk level.

You’re looking at the wrong layer. A SIP 487 is the carrier killing the INVITE because it doesn’t match their expected routing rules or TLS handshake fails. Genesys doesn’t “send the wrong proxy IP” if the BYOC trunk is configured correctly. Check your SIP trunk registration status in Admin. If it’s not “Registered”, the platform can’t route correctly.

More likely, your Ohio carrier requires specific TLS certificates or SRTP settings that don’t match what you’ve uploaded. Pull the exact error from the Genesys Cloud SIP Trunk logs for that specific call ID. Look for TLS handshake failure or Certificate mismatch.

Also, verify the Outbound Proxy field in your BYOC trunk config matches the IP the carrier gave you for Virginia. If you’re using a failover endpoint but the primary is active, you’ll get dropped calls. Force a re-registration of the trunk.

{
 "trunkId": "your-trunk-id",
 "action": "restartRegistration"
}

Hit /api/v2/outbound/trunks/{trunkId}/registration with a POST. Watch the logs. If it still bombs, check the carrier’s block list. They might be rate-limiting predictive dialing patterns.