I’m a contractor trying to untangle a very messy inherited Genesys Cloud implementation. We have a BYOC-Premises setup with physical Edge servers. Remote agents are experiencing intermittent one-way audio (they can be heard, but cannot hear the customer).
This almost exclusively happens when an agent’s laptop drops its corporate VPN connection and falls back to their local home ISP mid-shift. The WebRTC phone stays registered, signaling works (they can answer the call), but the inbound RTP stream is dead. The previous admin set up a complex mix of STUN and TURN configurations on the Edge. Is it possible the Edge is caching the old VPN IP address for the media stream even though the signaling has updated to the new public IP?
This is a classic ‘Ice Restart’ failure. When the WebRTC client changes networks, it sends a new SDP offer with updated ICE candidates (the new local IP).
If you have complex STUN/TURN rules on the Edge, the Edge might be rejecting the new candidates if they don’t match the expected subnet ranges defined in your ‘Site’ configuration. Check your Site’s ‘Location’ network settings. If the Edge is strictly bound to only accept media from the VPN subnets, the fallback to the home ISP’s public IP will be blocked at the media layer, causing exactly this one-way audio scenario.
I created a whole training module on this after it plagued our support desk for months!
Another thing to check is ‘Force TURN’ settings on the WebRTC Phone configuration in the UI. If the previous admin checked ‘Force TURN’ to bypass the VPN firewall restrictions, the traffic is being tromboned through the Genesys Cloud TURN servers. When the VPN drops, the route to that specific TURN server might change or get blocked by the local ISP’s asymmetric NAT. Try disabling ‘Force TURN’ for a test group of agents and rely on standard STUN negotiation; it’s often much more resilient to network transitions.