Looking for some advice on troubleshooting this discrepancy between real-time SIP registration logs and the aggregated analytics data for our BYOC trunks in AP-SE-2. We are currently managing 15 BYOC trunks across multiple carriers, all configured with strict failover logic in Architect. The environment is running SDK v2.14.0.
The issue manifests when the primary carrier experiences a SIP registration failure, triggering the failover to the secondary trunk. While the SIP logs clearly show the registration switch occurring within 2 seconds, the /api/v2/analytics/conversations/summary endpoint reports a significant delay in call initiation times for conversations routed during this transition window. Specifically, the totalDuration metric includes an unexpected 3-5 second lag that does not appear in the raw SIP message traces. This lag is consistently observed when the failover involves carriers with specific digest authentication requirements.
We have verified that the outbound routing rules are correctly prioritizing the secondary trunk based on carrier status. The SIP credentials and registration state are stable post-failover. However, the analytics aggregation seems to be capturing the time spent in the failover logic evaluation rather than just the actual media path establishment. This results in inflated latency metrics in our WEM reports, which are critical for our SLA calculations.
Has anyone encountered similar latency inflation in analytics when using BYOC trunks with aggressive failover policies? We are trying to determine if this is a known limitation of the analytics engine in AP-SE-2 or if there is a configuration tweak in the trunk settings that can align the reported duration with the actual SIP transaction time. Any insights into how the analytics engine handles the timestamping of calls during trunk state transitions would be greatly appreciated.