What is the standard approach to reconcile the failover success rates reported in the real-time trunk monitoring dashboard against the aggregated data returned by the Analytics API for BYOC trunks?
We are managing 15 BYOC trunks across APAC regions, specifically leveraging Genesys Cloud’s carrier failover logic to maintain uptime during peak hours in Singapore and Jakarta. The architecture relies on strict SIP registration states to trigger failover to secondary carriers when primary links exhibit jitter or packet loss exceeding defined thresholds.
Recently, we observed a significant divergence in reporting. The real-time dashboard indicates a 99.9% success rate for failover events during the last maintenance window. However, when querying the Analytics API endpoint POST /api/v2/analytics/conversations/details/query with a filter for mediaType equal to voice and routingType equal to queuing, the aggregated results show a higher failure rate than expected. Specifically, the dispositionCode for failed attempts does not always map cleanly to the carrier-specific error codes we are tracking in our custom reporting pipeline.
“The Analytics API aggregates data based on conversation completion status and may not reflect transient SIP registration failures or immediate failover triggers that occur before a conversation is fully established in the queue.”
This documentation snippet suggests a latency or aggregation issue, but the discrepancy persists even when querying data for windows closed for several hours. We are using the standard SDK for data retrieval, ensuring all pagination tokens are handled correctly. The concern is that our automated alerts, which rely on the API data for historical trend analysis, are triggering false positives regarding carrier reliability.
Is there a specific filter combination or a different endpoint, perhaps within the trunks analytics category, that provides a more granular view of SIP-level failover events? We need to ensure our reporting accurately reflects the carrier-specific quirks and failover logic without being skewed by incomplete conversation records. Any insights on aligning these two data sources would be appreciated, as we are currently unable to trust the API data for our quarterly carrier performance reviews.