Why does this setting in the WebRTC softphone configuration cause significant audio jitter and packet loss specifically when we execute a manual failover across our 15 BYOC trunks in the AP-SE-2 region?
We are observing a distinct degradation in audio quality only during the transition window. The SIP registration remains stable, and the carrier failover logic completes successfully within 2 seconds. However, the WebRTC agents report a 200-500ms delay and noticeable choppy audio for approximately 15 seconds post-failover. Outbound PSTN calls are unaffected, which suggests the issue is isolated to the browser-based media path.
Our environment consists of Genesys Cloud Engage (v2023.02) with BYOC trunks managed via our internal SIP proxy. We have recently updated our outbound routing to prioritize latency-based selection. The problem persists regardless of the browser (Chrome 114, Edge 114) or the agent’s local network conditions.
Here is the relevant segment of our WebRTC configuration YAML, which defines the codec preferences and ICE handling:
webrtc_config:
codec_priority:
- opus
- g722
- pcma
ice_policy:
turn_servers:
- url: "turn:turn.ap-southeast-2.genesis.cloud.com:443?transport=udp"
credential: "secure_cred_123"
candidate_gathering_timeout: 5000
jitter_buffer:
initial_size: 80
max_size: 200
The candidate_gathering_timeout is set to 5000ms to accommodate our complex NAT traversal requirements. We suspect that during failover, the ICE candidates are not being refreshed quickly enough, or the jitter buffer is not adapting to the sudden change in media path characteristics. The SIP logs show no errors, but the WebRTC stats indicate a spike in packetsLost and jitterBufferDelay immediately after the failover event.
Has anyone encountered similar behavior when managing multiple BYOC trunks in the AP-SE-2 region? We are looking for best practices on tuning the WebRTC settings to handle these transient network changes without impacting agent experience. Any insights on whether the turn_servers configuration needs to be dynamic during failover would be greatly appreciated.