Looking for advice on a persistent data discrepancy in our analytics reporting pipeline.
- Environment: Genesys Cloud PureCloud, Asia/Singapore Region
- Infrastructure: 15 BYOC Trunks via SIP, Carrier A (Primary), Carrier B (Failover)
- Tools: Analytics API (v2), Python SDK 3.2.1, Custom Data Actions
- Issue Scope: Inbound Call Quality & Trunk Utilization Reports
We are observing a significant lag and data omission in the inbound call quality reports specifically for calls routed through our failover trunks. When primary Carrier A experiences a SIP 408 Request Timeout, our failover logic correctly routes traffic to Carrier B. However, the subsequent calls appear in the inbound report view with a null value for the trunk_id field, or occasionally map to a deprecated trunk identifier that was decommissioned six months ago.
This is problematic for our capacity planning. We need accurate trunk utilization metrics to negotiate bandwidth contracts with our carriers. The standard GET /api/v2/analytics/details/inbound endpoint returns these records, but the trunk object is either missing or contains stale metadata. We have verified that the SIP registration status for all 15 trunks is registered and healthy via the GET /api/v2/telephony/providers/edges/{edgeId}/trunks endpoint, so this is not a registration failure issue.
Is there a known delay in the analytics ingestion pipeline for failover events in the Asia/Singapore region? Or is this a configuration issue within the outbound routing rules where the failover leg is not properly tagging the call context? We have tried forcing a data refresh using the Analytics API, but the data remains inconsistent. Any insights into how the platform tags failover legs in the reporting engine would be appreciated. We are also seeing intermittent 502 Bad Gateway errors when querying large date ranges, which might be masking the issue, but the null trunk IDs are the primary concern.