Why Call Quality Still Fails After Cloud Migration: A Network Readiness and SIP Trunking Guide for Genesys Cloud
Moving contact center calls to the cloud changes where telephony services run. It does not remove the network path between agents, carriers, and the platform. When that path is congested, unstable, or configured incorrectly, calls can still sound choppy, delayed, or one-sided after migration.
For organizations using Genesys Cloud, dependable voice depends on more than platform configuration. Network capacity, Wi-Fi, firewalls, SIP trunk behavior, codec negotiation, and monitoring all affect the experience. A structured readiness plan can reveal problems before they reach customers, and help teams pinpoint the cause when an issue appears after go-live.
1. Why call quality problems survive migration
Cloud migration can move telephony infrastructure out of the office, but calls still depend on local networks and internet connections. An agent’s audio may travel over Wi-Fi, through a corporate firewall or VPN, across an internet service provider, and into Genesys Cloud or a carrier network. Weakness at any point can affect the call.
Common causes include:
Congestion: Voice packets compete with large file transfers, video meetings, backups, or screen recordings.
Unstable connectivity: Packet loss and jitter can vary by location, time of day, and network load.
Wi-Fi interference: Coverage gaps, interference, or heavy wireless usage can disrupt agent audio.
Firewall or NAT issues: Security devices may block required traffic or alter how media is handled.
SIP trunk mismatches: Carrier settings for media, DTMF, routing, or failover may not align with the Genesys Cloud configuration.
Unverified changes: A change to a WAN circuit, VPN, headset, or routing policy can affect voice even if the cloud platform remains unchanged.
For example, a team may report that calls sound good in the morning but become choppy during afternoon peak usage. That pattern points toward congestion or wireless capacity, not necessarily a problem with the Genesys Cloud service.
Actionable takeaway: Map the complete audio path for each agent group, including remote workers, offices, firewalls, VPNs, and carriers. Compare problem calls with their location, time, and network conditions.
2. Assess bandwidth, latency, jitter, and packet loss
A speed test alone does not establish network readiness for voice. Capacity matters, but so do delay, variation in delay, and lost packets.
Genesys Cloud’s customer network readiness guidance recommends planning bandwidth around maximum concurrent calls. For WebRTC and supported managed phones using Opus, Genesys recommends allocating 32–128 Kbps of bidirectional voice bandwidth per expected concurrent call, with an additional 5% of the high voice-bandwidth value for SIP control traffic. Screen recording requires separate capacity; Genesys estimates 150–250 Kbps per monitor in typical cases. Use the Genesys bandwidth calculator and account for other traffic and growth.
For WebRTC, use these practical network-quality targets:
Packet loss: Below 1%
Jitter: Below 30 ms
Average round-trip time (RTT): Below 300 ms, equivalent to about 150 ms one-way latency
These are quality targets, not a substitute for capacity planning. A network can meet them during a quiet test and fail when call volume and competing traffic peak. Measure representative sites and remote-worker connections at different times, including busy periods.
Actionable takeaway: Test each major agent location under realistic load. Record bandwidth, packet loss, jitter, and RTT alongside concurrent call volume and other network activity.
3. Choose and validate the SIP trunking approach
Genesys Cloud supports different carrier arrangements. With BYOC Cloud, the SIP trunk connects a third-party carrier to the Genesys Cloud Edge and Media Tier over the public internet. With BYOC Premises, the carrier trunk terminates at customer-premises Edge appliances. Genesys Cloud Voice is another telephony option. The right design depends on the organization’s carrier relationships, sites, routing needs, and operational requirements.
For BYOC Cloud, verify that the carrier’s public endpoints, signaling, and media paths meet Genesys requirements. For any design, align carrier and platform settings and test real inbound and outbound calls, not just trunk status.
Confirm key interoperability details with the carrier:
SIP transport and endpoint addressing
Supported call capacity, including concurrent calls and calls per second
Caller ID, early media, hold, transfer, and forwarding behavior
Failover behavior and SIP OPTIONS handling, where applicable
DTMF support and codec negotiation
QoS marking preservation, if relevant to the network path
Genesys’ SIP Interoperability Specification states that Genesys Cloud trunks do not support SIP registration. It also specifies support for codecs including Opus, G.711 A-law and μ-law, G.722, and G.729. Genesys’ readiness guidance recommends G.711 for voice traffic between the customer and carrier. Confirm the appropriate codec for the chosen trunk and call flow, and avoid unnecessary transcoding.
For DTMF, RFC 2833/NTE is preferred; SIP INFO for in-call DTMF is not supported. Fax requires G.711 pass-through; T.38 is not supported. These details matter for IVR menus, payment flows, fax, and carrier interoperability.
Actionable takeaway: Use the BYOC Cloud overview and the carrier interoperability specification to build a joint test checklist. Confirm codec, DTMF, media, and failover behavior with the carrier before production traffic moves.
4. Configure QoS and validate the agent network
Quality of Service (QoS) gives real-time media priority when networks are busy. It must be implemented consistently across the devices that handle voice traffic; a marking applied at one switch can be lost or changed farther along the path.
Genesys lists these recommended DSCP values in its readiness guidance:
Voice RTP: DSCP 46 (EF)
Video RTP: DSCP 34 (AF41)
SIP signaling: DSCP 24 (CS3)
Review QoS across LAN, WAN, WLAN, VPN, and internet-edge equipment, and coordinate with circuit or carrier providers where they manage part of the path. Check that routers and firewalls preserve the intended markings and do not prioritize ordinary data above voice.
For wireless agents, assess coverage, interference, and capacity, not just signal strength at a single desk. Where possible, test with agents using their actual headsets and work locations.
Actionable takeaway: Confirm QoS end to end, then test during peak network demand. Validate remote and wireless agents separately from wired office users.
5. Use diagnostics and monitoring to find the fault domain
Genesys Cloud’s standalone WebRTC Diagnostics app tests network connectivity and call quality. It reports packet loss, average RTT, jitter, and an estimated Mean Opinion Score (MOS). Run it from representative agent locations and retain results as a baseline.
Diagnostics are most useful when paired with operational evidence. Track quality by site, agent connection type, time, and call path. Compare agent reports with platform, carrier, and network telemetry. When an issue occurs, determine whether it affects a single user, a location, one carrier route, or all calls. That distinction helps teams focus investigation instead of changing unrelated settings.
Actionable takeaway: Establish baseline test results before go-live, then define who reviews quality data, what triggers investigation, and how carrier or network issues are escalated.
6. Harden voice quality in phases
A phased plan reduces risk and gives teams time to resolve issues before they affect the full contact center.
Assess: Inventory locations, remote agents, peak concurrent calls, carriers, codecs, firewalls, and existing quality issues.
Prepare: Validate capacity, firewall rules, QoS, Wi-Fi coverage, SIP settings, and carrier support against the selected Genesys Cloud design.
Pilot: Test inbound and outbound calls, transfers, hold, IVR DTMF, caller ID, failover, and recording from representative sites and user types.
Go live gradually: Move groups in stages. Monitor quality indicators and user feedback at each stage before expanding.
Operate and improve: Keep a regular review cadence, rerun diagnostics after network changes, and track recurring issues through resolution.
Dunamis Consulting’s cloud migration guidance and remote-work call quality article offer related perspectives on readiness and user connectivity.
Actionable takeaway: Treat voice quality as an ongoing operational responsibility, not a one-time migration checkbox. Assign clear ownership across contact center, network, security, and carrier teams.
Make voice quality a measurable outcome
Cloud telephony can simplify infrastructure and support flexible work, but clear calls depend on a network and SIP design that are measured, tested, and maintained. By checking capacity and quality thresholds, validating carrier interoperability, configuring QoS, and monitoring representative call paths, organizations can identify many problems before customers experience them.
Dunamis Consulting brings 15 years of cloud telephony experience to network and project consultation, flexible staffing, and managed support. Contact Dunamis Consulting to discuss a readiness assessment, project support, or ongoing services for your Genesys Cloud environment.
Comments