Could someone clarify why the BYOC trunk utilization metrics appear inconsistent when queried via the Analytics API?
Background
Managing fifteen BYOC trunks in AP-SE-2 requires precise visibility into carrier-specific performance. The current setup involves multiple carriers with distinct SIP registration behaviors and failover logic configured in Architect. We rely on the /api/v2/analytics/voice/conversations/details/query endpoint to generate custom reports for carrier SLA compliance.
Issue
When querying for conversation data filtered by specific BYOC trunk IDs, the returned duration and queued_duration fields often sum to values that do not match the total call volume reported in the standard Genesys Cloud dashboard. Specifically, calls routed through our primary carrier show a 15% discrepancy in successful connection counts compared to the raw SIP signaling logs captured at our edge. The API returns a 200 OK, but the data integrity seems compromised for high-volume trunk groups.
Troubleshooting
- Verified trunk registration status; all 15 trunks show ‘Registered’ in Admin.
- Cross-referenced timestamps with AP-SE-2 local time (UTC+8) to rule out timezone drift in the query parameters.
- Tested with a smaller date range (24 hours); the discrepancy persists.
- Checked for SIP 408 or 503 errors during peak hours; none correlate with the missing records.
Is there a known latency or aggregation issue with BYOC trunk reporting in this region?