Trying to understand a significant discrepancy in bot conversation analytics when sessions are routed through our Singapore BYOC trunks. We have configured a standard Architect flow that routes inbound calls from specific carrier trunks to a virtual agent. The flow logic is straightforward: answer call, play greeting, transfer to bot. However, the conversation metrics reported in the CXone analytics dashboard do not align with the raw SIP signaling logs.
Specifically, we are observing that approximately 15% of sessions initiated via the primary SG carrier trunk are recorded as ‘Failed’ or ‘No Answer’ in the bot performance reports, even though the SIP 200 OK is received by the carrier and the audio stream is established. The Genesys Cloud side logs show the session as active, but the bot interaction payload never seems to trigger the correct start event in the analytics engine. This is causing a major issue with our SLA reporting and carrier billing reconciliation.
We are using the standard REST API to fetch these metrics. The endpoint GET /api/v2/analytics/conversations/summary returns a status of failed for these specific cases, citing reason: bot_timeout. However, checking the detailed conversation records via GET /api/v2/conversations/{conversationId} shows the bot was actually engaged. The issue appears isolated to trunks registered with the specific SG carrier that rotates IPs frequently, suggesting a potential metadata mapping issue during the handoff.
Here is the payload structure we are seeing in the failed event logs:
{
"conversationId": "conv_sg_byoc_8842",
"status": "failed",
"reason": "bot_timeout",
"channelType": "voice",
"trunkId": "trunk_sg_primary_01",
"timestamp": "2024-10-27T09:15:00Z",
"botSessionId": null,
"metadata": {
"carrier": "Singtel",
"sipStatus": "200 OK"
}
}
Is there a known latency threshold or specific SIP header requirement for BYOC trunks that triggers this false bot timeout classification? We have verified the clock synchronization on the carrier side, and the delta is within acceptable limits. Any insights on how to force a retry or correct the analytics tagging would be appreciated.