Genesys Cloud Performance Tuning in 2026: Voice Quality, Latency, and the Cloud Telephony Metrics That Decide ROI

A cloud telephony deployment can be technically available and still deliver a frustrating call experience. Congested links, jitter, packet loss, or a suboptimal media route can make voices sound choppy and delay conversations. Those problems matter beyond call quality: they can also weaken the audio that virtual agents and speech analytics depend on.

For organizations running or evaluating Genesys Cloud, performance tuning is therefore an operational and financial discipline. The aim is to identify where media quality degrades, correct the network or configuration issue, and measure whether the change improves customer and agent outcomes.

1. Start with voice-quality measures, not vague complaints

“Calls sound bad” is a useful signal, but not a diagnosis. Establish a baseline with measures that can be compared across locations, networks, devices, and time periods.

Key metrics include:

• Mean Opinion Score (MOS): A voice-quality rating from 1 to 5. Genesys Cloud classifies 4 as good, 3 as fair, and 5 as excellent. For calls with multiple legs, the overall interaction score reflects the lowest MOS among them.

• Packet loss: The share of transmitted voice packets that do not arrive. Genesys recommends keeping it below 1% for voice.

• Jitter: Variation in packet arrival time. Genesys WebRTC diagnostics recommends less than 30 ms.

• Round-trip time (RTT): Time for a network signal to travel to a destination and back. The Genesys WebRTC diagnostic target is below 150 ms between the client location and the Genesys Cloud AWS region.

These are useful thresholds, not a substitute for checking the full call path. A client-to-cloud test and a phone-to-Edge media path are different measurements. Genesys’ network readiness guidance gives distinct targets: external phone calls should have under 150 ms one-way latency and under 1% packet loss; internal calls between a phone and an Edge on the same LAN should have under 75 ms one-way latency and under 1% packet loss.

Recommendation: Track MOS, packet loss, jitter, and latency by site and endpoint type. Treat recurring MOS scores of 3 or lower as a reason to investigate the affected call leg rather than as an isolated complaint.

2. Make network readiness part of capacity planning

A WAN link can have high advertised bandwidth and still perform poorly for real-time voice. The more useful question is whether it can handle expected concurrent calls while keeping delay and packet loss within acceptable bounds.

Genesys recommends allocating 32–128 Kbps of bidirectional network voice bandwidth per expected or supported concurrent call for agent WebRTC phones using the adaptive Opus codec. The required allocation depends on expected quality and network conditions. Genesys also recommends allowing an additional 5% of the high voice-bandwidth value for SIP control traffic. For endpoints that do not support Opus, size bandwidth based on the configured codec.

For example, 80 concurrent WebRTC calls at the 128 Kbps planning value amount to 10.24 Mbps of allocated voice capacity, plus approximately 0.51 Mbps for SIP signaling. Use the Genesys bandwidth calculator and confirm how capacity applies to each direction and network segment in your design. Include other real-time traffic in the calculation: a single screen recording typically uses 150–250 Kbps, and multiple monitors can increase that requirement.

Also review the paths that carry calls:

• Check the WAN and Internet connection during busy periods, not only during quiet hours.

• Look for congestion, interface errors, speed or duplex mismatches, and weak Wi-Fi coverage.

• Where private circuits are constrained, ask the carrier to support diverse paths and voice prioritization.

• For Wi-Fi, Genesys recommends 802.11n or better and the 5 GHz band; survey the site for coverage gaps.

Recommendation: Size links against realistic peak concurrency and all traffic sharing the path. Validate the result under load before expanding agent capacity.

3. Configure QoS end to end

Quality of Service (QoS) can prioritize real-time traffic when links become busy. It must be applied consistently across the network devices that carry the traffic; a DSCP value set on one switch does not guarantee that intermediate routers or carrier links preserve it.

Genesys’ readiness guidance identifies these DSCP values:

Traffic	Protocol	DSCP
Voice	RTP	46 (EF)
Video	RTP	34 (AF41)
Signaling	SIP	24 (CS3)

Confirm that routers, switches, VPNs, and WAN providers preserve the intended markings and map them to the appropriate queues. Genesys Cloud does not natively provide QoS for WebRTC phones; instead, it provides MOS as a voice-quality measure. Network-side prioritization and Genesys-side quality monitoring serve different purposes.

Recommendation: Test QoS with real calls while the network is busy. Verify the marking and queue behavior at each hop rather than assuming configuration alone is proof of priority.

4. Match codecs to endpoints and trunks

A codec affects how voice is encoded and how much bandwidth it uses. Genesys Cloud WebRTC uses Opus, which adapts its sampling rate as network conditions vary. SIP trunks and other phones may support a different set of codecs.

Genesys Cloud lets administrators configure a Preferred Codec List for external and phone trunks. Genesys recommends matching that list to the codecs supported by the SIP provider. The platform’s available options include Opus, G.722, G.729, and G.711 (PCMU/PCMA). G.711 is commonly used for carrier voice traffic, and Genesys’ network-readiness guidance recommends it for traffic between the Edge and carrier.

Codec choices should be tested across the actual endpoints and trunk, not made in isolation. An unsupported codec or avoidable transcoding can complicate interoperability and affect media quality or capacity.

Recommendation: Inventory endpoint and carrier support, remove unsupported options from the preferred list, and validate call quality and interoperability after changes. See Genesys’ preferred codec configuration guide.

5. Review media regions against real user locations

For WebRTC calls that require relay services, media-region configuration can affect the route taken by audio. Genesys Cloud’s Global Media Fabric lets administrators add and prioritize media regions for a site. If the preferred region cannot process a call, Genesys proceeds through the configured priority list. Relay/TURN behavior and firewall rules also influence which routes are available.

Choose regions based on where agents actually work and test the resulting media path. A region that is geographically close is not automatically the lowest-latency choice for every user or network route. Genesys’ Global Media Fabric guide explains region priority and Geo-Lookup options. Check the firewall allowlist requirements before changing TURN behavior.

Recommendation: Review region settings by site and agent location. Use diagnostics and call results to confirm that routing changes improve performance rather than relying on geographic assumptions.

6. Monitor in Genesys Cloud and connect quality to ROI

For WebRTC agents, the built-in Genesys Cloud WebRTC Diagnostics app checks connectivity and audio and reports MOS, packet loss, RTT, and jitter. Run it on representative devices and networks, including remote-worker setups. Genesys also makes MOS available in interaction views, which can help teams connect quality measures to specific calls.

Audio quality affects more than the human conversation. Virtual agents rely on intelligible audio to recognize speech and respond to callers; speech analytics depends on usable recordings to identify words, topics, and interaction signals. Noise, clipping, missing audio, or excessive delay can undermine those inputs. Quality monitoring does not replace evaluation of AI accuracy, but it helps teams identify when the audio itself may be a contributing factor.

To evaluate the financial impact, compare a defined period before and after a tuning change. Track:

• MOS and the share of calls with packet loss or jitter above target

• Repeat calls, transfers, and call abandonment

• Average handling time and agent-reported audio issues

• Virtual-agent recognition failures or requests to repeat

• Speech analytics transcription quality on sampled calls

Do not attribute every change in these outcomes to network tuning. Compare similar queues and periods, document other changes, and calculate benefits using your own operating costs and volumes.

Recommendation: Pair technical measures with customer-service measures. Use the evidence to prioritize fixes with the clearest operational impact.

7. Genesys Cloud performance-tuning checklist

• Establish a baseline for MOS, packet loss, jitter, RTT, and concurrency by site.

• Run WebRTC diagnostics on representative agent devices and network paths.

• Compare busy-period bandwidth use with concurrent-call and screen-recording requirements.

• Check LAN, Wi-Fi, WAN, VPN, and Internet paths for congestion, errors, and coverage gaps.

• Verify QoS markings and prioritization end to end.

• Match the trunk codec list to endpoint and carrier support; test after changes.

• Review media-region priorities and firewall access for relevant locations.

• Compare technical and business outcomes after each change.

Performance tuning is not a one-time launch task. It is a repeatable way to protect voice quality and make cloud telephony investment work harder. Organizations that need help reviewing network readiness, sizing project support, or planning Genesys Cloud improvements can explore Dunamis Consulting’s cloud telephony guidance or contact Dunamis Consulting to discuss their requirements.