No idea why this is happening, the Answering Machine Detection (AMD) logic fails specifically when traffic routes through our secondary BYOC carriers in the Asia/Singapore region. The primary trunks handle AMD perfectly, but once failover triggers, the amd field in the /v2/interactions/voice payload often returns unknown instead of machine or human, causing our Architect flows to route to the wrong IVR branch.
This inconsistency breaks our compliance recording triggers and leads to agents receiving calls from voicemail systems that should have been filtered. The issue is isolated to the secondary SIP endpoints provided by our regional carriers.
Environment details:
- Region: AP-SE-2 (Asia/Singapore)
- Trunks: 15 BYOC trunks, primary (Carrier A) vs secondary (Carrier B/C)
- SDK: Genesys Cloud SDK v2.1.4
- Architect Flow: Standard AMD check using
Get Interaction→Conditiononamdattribute - Error: No HTTP error, but logical mismatch in interaction metadata
Has anyone seen carrier-specific quirks where the secondary provider’s SIP signaling delays or modifies the initial ringback tone, confusing the cloud-side AMD engine? We suspect the secondary carriers are not sending the correct early-media indicators required for accurate detection.