I’m the change management lead for our Genesys Cloud rollout, and I’m getting a lot of confused feedback from agents.
They’re reporting that when they are working from the office or off-VPN at home, their voice calls are instant and clear. But when they are connected to our corporate VPN, they experience a slight audio delay (about 200ms latency). I spoke to our network team, and they mentioned something about ‘Media Bypass failing and falling back to the Edge server’.
I want to create a clear, simple FAQ for the agents to explain this without getting too technical into SIP protocols. Can someone confirm exactly what is happening under the hood when Media Bypass fails due to a VPN, so I can accurately translate it for the floor?
I inherited an org with this exact problem and it’s super frustrating.
When ‘Media Bypass’ is on, Genesys tries to send the audio directly from the customer (or the carrier SBC) straight to the agent’s browser, completely bypassing the Genesys Edge servers. It’s the shortest possible path, hence zero delay.
When your agents turn on the VPN, their browser is suddenly hidden behind the VPN firewall. The carrier SBC can’t reach them directly anymore. Genesys detects this failure during the ‘ICE negotiation’ and falls back to a ‘Proxied’ connection. The audio is forced to travel from the customer → to the Genesys Edge Server (in the cloud or your datacenter) → through the VPN tunnel → to the agent. That extra ‘hop’ through the Edge and the VPN is what causes the 200ms delay.
Hey Raj! Junior dev here, but I just had to learn this for a WebRTC script!
Think of it like delivering a package. Media Bypass is the delivery driver handing the package straight to your front door (fast). But when you turn on the VPN, it’s like putting a huge gate around your house. The driver can’t get in, so they have to drop it off at the local Post Office (the Edge server), and then a different truck has to drive it from the Post Office, through the gate, to your door. That extra stop adds delay! That’s how I’d explain it to the agents.
From a planning perspective, this is important to document because that 200ms delay can actually increase Average Handle Time by a few seconds per call due to ‘talk-overs’ (agents and customers accidentally interrupting each other). If the VPN is mandatory, you might need to adjust your AHT forecasts slightly to account for the conversational latency!
The explanation from is exactly what I needed. It makes perfect sense now why the delay only happens on the VPN.
I’m not a technical person, so the “Edge server” talk went right over my head, but the analogy of the traffic route shifting really clicked for me. The main thing for us as supervisors is that this 200ms latency is actually impacting our quality scores. I’ve been reviewing call recordings and noticed agents are interrupting customers more frequently because they can’t hear the slight pause before the customer finishes speaking. It’s creating a lot of friction in conversations.
I’m going to share this simplified explanation with my team today. They need to understand it’s not their internet connection or their headset causing the issue, but a network routing change. This should help reduce the panic and unnecessary IT tickets we get when agents complain about “bad audio.”
One follow-up question for the group: Since we can’t turn off the VPN requirement for security reasons, are there any agent-side settings we can adjust in the Genesys Cloud desktop app to help mitigate this? I know I can adjust coaching plans to account for the longer handle times, but I’d rather fix the root cause if possible. I don’t have access to the admin console, so I’m relying on the tech teams to tell me if there’s a quick fix for the agents themselves.