We have recently moved 60 agents to work-from-home using the Genesys Cloud WebRTC softphone in Chrome. About 20 of these agents report intermittent choppy audio during calls - the customer hears the agent fine but the agent hears the customer voice cutting in and out every few seconds.
The affected agents are distributed across different ISPs and locations, so it does not seem to be a single network issue. Their home internet connections range from 50Mbps to 200Mbps download, which should be more than sufficient for voice.
I have asked them to run speed tests and they all show good bandwidth. But when I look at the WebRTC statistics in the Genesys Cloud interaction detail, I see concerning metrics on the affected calls:
- Packet loss: 3-8% (inbound stream only)
- Jitter: 40-80ms
- Round trip time: 150-250ms
The agents who do not experience audio issues show packet loss under 0.5% and jitter under 15ms on the same queue and same call types.
We are using Genesys Cloud Voice (not BYOC). Region is ap-southeast-2. Is there something specific about the WebRTC implementation that makes it more sensitive to network quality than a traditional desk phone?
The answer is yes - WebRTC is significantly more sensitive to network quality than a traditional SIP desk phone, and the reason is the jitter buffer implementation.
A hardware SIP phone typically has a 60-80ms adaptive jitter buffer that can absorb moderate network jitter without audible impact. The Chrome WebRTC implementation uses a much smaller jitter buffer (typically 20-40ms) to minimize latency. This means anything above 40ms jitter causes audible artifacts.
The 3-8% packet loss you are seeing is the real problem though. For VoIP, anything above 1% packet loss causes noticeable degradation. The fact that it is only on the inbound stream (customer-to-agent) strongly suggests the agents’ home routers are the bottleneck.
Here is what is likely happening: the agent’s home router is doing SPI (Stateful Packet Inspection) or has an undersized NAT table. During peak home usage (streaming video, gaming, IoT devices), the router drops inbound UDP packets because it prioritizes TCP traffic. The outbound stream (agent-to-customer) is fine because the router handles outbound packets first.
Three fixes in priority order:
-
Have agents enable QoS on their home router and prioritize UDP traffic to the Genesys Cloud media IP ranges (documented in the network requirements page).
-
If the router does not support QoS, have agents connect via ethernet cable instead of WiFi. WiFi adds 5-20ms of jitter on its own due to contention-based channel access.
-
For persistent cases, deploy the Genesys Cloud Desktop App instead of the browser-based softphone. The desktop app uses a dedicated media engine with a larger jitter buffer than Chrome WebRTC.
Excellent diagnostic framework above. Let me add the network infrastructure perspective from managing voice quality across 15 BYOC trunks.
The Genesys Cloud network requirements page lists the specific IP ranges and ports that need to be whitelisted and prioritized. For the ap-southeast-2 region, the media traffic uses UDP ports 16384-32768 to the following CIDR blocks:
169.150.106.0/24
167.234.48.0/20
136.245.64.0/18
Many consumer-grade routers have a “gaming mode” or “media prioritization” feature that can be configured to prioritize UDP traffic to these ranges. This is functionally equivalent to QoS for a non-enterprise router.
Additionally, if your agents are using VPN connections for accessing corporate resources, verify that the VPN is configured for split tunneling. If all traffic goes through the VPN, the media packets are encrypted, routed through the VPN concentrator, and then sent to the Genesys Cloud media servers. This adds 50-100ms of latency and the VPN concentrator becomes a bottleneck for UDP traffic.
The Genesys Cloud softphone does not require VPN access - it communicates directly with the Genesys Cloud infrastructure over the public internet using DTLS encryption. Split tunnel the VPN to exclude the Genesys media IP ranges listed above.
From a compliance and monitoring perspective, I would recommend implementing proactive voice quality monitoring rather than waiting for agent complaints.
Genesys Cloud provides MOS (Mean Opinion Score) data for every call via the Analytics API. You can build a daily report that flags any call with MOS below 3.5:
POST /api/v2/analytics/conversations/details/query
{
"interval": "...",
"segmentFilters": [{
"predicates": [{
"dimension": "mediaType",
"value": "voice"
}]
}],
"order": "asc"
}
In the response, check metrics[].emitDate and metrics[].mos for each conversation. Any call consistently below 3.5 MOS should trigger a network assessment for that agent.
For regulated environments like banking, call recording quality directly impacts our ability to meet compliance requirements. If the audio quality is degraded, the recording may not be admissible for dispute resolution. We flag calls below 3.0 MOS for manual review and re-recording if the interaction involved any financial transaction.