SIP Trunk Call Duration Mismatch in Performance Dashboard

Voice & Telephony
1

Trying to make sense of why the Average Handle Time on the queue performance view diverges from the raw SIP trunk logs during peak hours in Europe/Paris. The dashboard shows a 15-second inflation in talk time, but the telephony logs indicate immediate hangup.

Is there a known latency in how Architect flow analytics sync with real-time telephony events, or does the dashboard include post-call work in the AHT calculation by default?

2

The discrepancy usually stems from how Genesys Cloud calculates Average Handle Time (AHT) versus how SIP trunks log call duration. The dashboard includes wrap-up time and any post-call dispositioning, while SIP logs only track the active media stream. This 15-second gap often indicates that agents are leaving the call state but not immediately closing the interaction in the Architect flow.

Check the Architect flow for the specific queue. If the flow uses a “Close Call” block that triggers before the agent hangs up, the dashboard might still count the agent as “on call” until the WebSocket disconnects fully. Here is a quick JMeter script snippet to verify if the API response time for POST /api/v2/interactions contributes to this latency under load:

// JMeter HTTP Request Sampler for Interaction Closure
// Endpoint: POST /api/v2/interactions/{id}/close
// Headers: Authorization: Bearer ${access_token}
// Body: {"state": "closed", "reason": "agent_hangup"}

To isolate the issue:

  • Review Architect Flow Logic: Ensure the “Close Call” block is not delayed by unnecessary script blocks or API calls. The flow should close the interaction immediately upon agent hangup.
  • Check Wrap-Up Time Configuration: Verify if the queue has a mandatory wrap-up time configured. Even a 15-second wrap-up will inflate the AHT compared to SIP logs.
  • Analyze WebSocket Latency: During peak hours in Europe/Paris, check if the WebSocket connection between the agent desktop and the Genesys Cloud edge is experiencing packet loss. High latency here can delay the “call ended” event in the dashboard.
  • Compare Raw Logs: Export the raw interaction logs from Genesys Cloud for the specific time window. Look for the state_change events. If the closed state is recorded 15 seconds after the SIP hangup, the issue is likely in the flow logic or agent client latency.

This approach helps distinguish between a platform calculation difference and a genuine performance bottleneck in the telephony stack.

3 
{
 "groupBy": ["conversation.id"],
 "metrics": ["conversation.duration", "interaction.duration"],
 "filter": {
 "type": "voice",
 "dateRange": {
 "start": "2023-10-01T00:00:00Z",
 "end": "2023-10-31T23:59:59Z"
 }
 }
}

You need to isolate conversation.duration from interaction.duration in the analytics query. The dashboard aggregates the full interaction lifecycle, including wrap-up, while SIP logs reflect only media stream time. This specific filter configuration separates the two, confirming the 15-second gap is post-call work rather than latency.

4

If I remember correctly, this 15-second gap is often less about SIP latency and more about how WFM adherence metrics interact with post-call dispositioning. When agents are under strict schedule adherence pressure, they sometimes rush the wrap-up phase, but the Architect flow might still be holding the interaction open for compliance checks or IVR confirmations. This creates a mismatch between the SIP stream end and the logical conversation end.

To verify this, check the following:

  • Audit the Architect flow for any “Wait” or “Play Prompt” blocks after the agent disconnects.
  • Ensure the “Close Call” block is configured to immediately terminate the interaction upon agent hangup.
  • Review the WFM schedule adherence reports for that specific time window to see if agents were logging off early while calls remained active in the system.

The dashboard aggregates the full interaction lifecycle, including any post-call work or system holds. If the flow isn’t closing cleanly, the AHT will inflate regardless of the SIP trunk status. Aligning the flow termination with the agent’s actual disconnect usually resolves this discrepancy.