Discrepancy in WebRTC Session Duration Metrics vs. Voice Queue Handle Time

Voice & Telephony
1

Stuck on reconciling the session duration metrics reported by the WebRTC softphone integration with the standard Handle Time (HTime) displayed in the Genesys Cloud Performance dashboard for our primary voice queue.

We have recently migrated a significant portion of our Paris-based contact center agents from traditional desk phones to the WebRTC softphone client (version 10.0.45) to support remote work flexibility. While the connectivity is stable, the performance metrics are diverging. The WebRTC client reports a session duration that includes the initial ring time and post-call wrap-up, whereas the Performance dashboard’s HTime metric for the same queue appears to exclude the wrap-up period entirely, aligning with the legacy voice queue behavior. This inconsistency is causing confusion in our weekly service level reports, as the operational efficiency metrics derived from the dashboard do not match the agent-level data pulled from the softphone logs.

The environment is configured as follows:

environment:
 region: eu-west-1
 softphone_version: 10.0.45
 queue_config:
 name: "Primary_Voice_FR"
 wrap_up_required: true
 max_wrap_up_seconds: 60
 metrics_source:
 dashboard_view: "Agent_Performance"
 custom_report: "WebRTC_Session_Logs"

Could someone clarify the precise definition of Handle Time when WebRTC sessions are involved? Specifically, does the system treat the WebRTC session teardown differently from SIP trunk disconnections regarding the inclusion of after-call work in the HTime calculation? We need to ensure our service level agreements (SLAs) are calculated consistently across all agent channels. Any insight into whether this is a known limitation of the WebRTC metric reporting or a configuration issue within the queue settings would be greatly appreciated. We are aiming to standardize our reporting framework by the end of the quarter.

2

This is caused by…

Hey there! This discrepancy usually stems from how WebRTC calculates “connected time” versus the queue’s handle time logic. In Zendesk, we relied on ticket status updates, but Genesys Cloud tracks media stream activity. Ensure your WebRTC client settings align with the queue’s hold time configuration. The softphone might be dropping idle sessions faster than the queue registers them. Check the “WebRTC Connection Timeout” in the user profile settings. It often defaults to 60 seconds, while the voice queue might allow longer silence before marking the call as handled. Aligning these two values should sync the metrics.

3

The documentation actually says WebRTC metrics often diverge from voice queue handle time due to differing idle thresholds. Be careful with shift swaps during these audits.

  • Check the “WebRTC Connection Timeout” in user profiles.
  • Verify the queue’s hold time configuration matches the softphone settings.
  • Ensure no agents are on break when swaps occur.

This prevents WFM forecasting errors.

4

Have you tried aligning the WebRTC idle timeout with the queue’s hold time configuration? The divergence often stems from mismatched thresholds where the softphone terminates the media stream while the queue still counts handle time. This breaks WFM forecasting models because the API reports different values for the same interaction.

resource “genesyscloud_user_setting” “webrtc_timeout” {
user_id = var.agent_id
setting = “WebRTC_Connection_Timeout”
value = “300000”
}

resource “genesyscloud_routing_queue” “voice_queue” {
name = “Paris_Voice_Queue”
hold_time = “300000”
wrap_up_time = “60000”
enable_hold = true
}

The documentation states that digital handle time includes wrap-up by default, which conflicts with WebRTC stream activity tracking. If the softphone drops idle sessions faster than the queue registers them, the metrics will diverge. Ensure the hold_time in the queue matches the WebRTC_Connection_Timeout in the user profile settings. This prevents duplicate processing on retries and keeps the analytics consistent.

A common fix is to force a custom metric calculation in the reporting dashboard. Use the HandleTime = TalkTime + WaitTime + WrapUpTime formula explicitly. This bypasses the default API behavior that includes wrap-up in digital handle time. Check the raw JSON in the analytics response to verify the values. If the discrepancy persists, strip null values from the payload before sending to the reporting API. The outbound API rejects them even if optional, causing 422 Unprocessable Entity errors. This approach ensures accurate WFM forecasting and prevents shift swap errors during audits.