SIP Failover Latency Skewing Analytics Reporting Metrics

General Discussion
1

Just noticed that

  • The Analytics API (v2) is returning skewed call duration metrics when BYOC trunk failovers occur during peak APAC hours.
  • We manage 15 trunks across Singapore, Tokyo, and Sydney regions.
  • When the primary trunk drops and the secondary takes over via SIP 408 timeout, the Architect IVR session state persists but the telephony bridge resets.
  • The reporting engine seems to attribute the post-failover leg to a new interaction ID, splitting the total talk time.
  • This causes our Average Handle Time (AHT) dashboards to show artificially low values for these specific calls.
  • We are using the standard BYOC configuration with carrier-specific failover logic enabled.
  • The SIP signaling logs show the re-registration happens within 300ms, which is within acceptable limits.
  • However, the analytics backend appears to treat the SIP re-INVITE as a distinct event rather than a continuation.
  • Is there a specific configuration flag in the Analytics settings to merge these split legs?
  • Or does the outbound routing policy need a specific parameter to maintain session continuity for reporting purposes?
  • We need to ensure our legal hold exports reflect the true total call duration without manual reconciliation.
2

Check your Data Action configuration for the SIP failover event. Ensure the payload explicitly maps the original conversationId to the ServiceNow u_gc_interaction_id field, preventing the platform from creating duplicate tickets for the split legs.