Trying to understand why our outbound campaigns in the Singapore region are experiencing intermittent pauses, specifically affecting dialing efficiency metrics, even when all 15 BYOC trunks show green status in the admin console.
- Region: Asia/Singapore (SG)
- Platform: Genesys Cloud (SaaS)
- Trunk Type: 15x BYOC (Bring Your Own Carrier) via SIP trunking
- API Endpoint:
GET /api/v2/analytics/conversations/details/query - Recent Change: Updated outbound campaign rules to prioritize specific carrier failover logic
- Symptom: Campaign dialing rate drops to near zero for 2-3 minute intervals, then recovers without manual intervention. No SIP 408 or 503 errors logged during these windows.
The issue is particularly frustrating because the SIP registrations remain stable throughout the outage windows. We have verified that the carrier side is not throttling calls, as the concurrent call count on the carrier portal remains well below the licensed capacity. The Genesys Cloud UI shows the trunks as “Registered” and “Healthy,” yet the outbound dialer stops initiating new calls.
When querying the conversation analytics API during these pause events, we see a sudden spike in status: "queued" conversations that never transition to status: "attempted". This suggests the issue lies within the Genesys Cloud outbound dialing logic or the trunk selection algorithm rather than a carrier-side rejection. We have attempted to adjust the “Max Concurrent Calls” settings and tweaked the failover thresholds, but the problem persists.
Is there a known limitation or configuration nuance regarding how Genesys Cloud handles trunk health checks for high-volume outbound campaigns in the SG region? We are looking for specific logging endpoints or diagnostic steps to pinpoint whether this is a false negative health check or a resource contention issue within the Genesys Cloud dialing engine. Any insights into similar behaviors with BYOC trunks would be appreciated.