Network Readiness Guide for Cloud Contact Centre Deployments

Audience: Customer IT, facilities and operations teams Applies to: BPO and enterprise contact centre sites, remote agents and hybrid workers Version: 1.0

1. Executive summary

Cloud contact centre voice quality is determined almost entirely by the customer's own network, not by the amount of bandwidth purchased. A site with a 1 Gbps circuit and no quality of service (QoS) will regularly deliver worse audio than a site with 100 Mbps that is correctly configured.

There are five requirements that matter more than anything else:

1. Sufficient symmetric bandwidth, sized on concurrent calls rather than headcount. The service uses the G.711 codec, so budget 100 kbps per concurrent call in each direction, plus headroom.
2. QoS enabled on the site router, so that voice is prioritised over video streaming, software updates and general browsing.
3. Wired connections for agent desks. Wi-Fi is the single most common cause of one-way audio, choppy speech and dropped calls.
4. Network quality within target, meaning latency under 150 ms, jitter under 30 ms and packet loss under 1%.
5. Voice traffic must not be forced through a VPN back to a head office or data centre before reaching the internet.

Sites that meet these five conditions typically achieve a mean opinion score (MOS) above 4.0. Sites that miss any one of them tend to generate the majority of quality tickets.

2. Bandwidth sizing

2.1 Per-call bandwidth

The service uses G.711, the uncompressed toll quality codec used throughout the public telephone network. It is chosen because it avoids transcoding at carrier interconnect, adds negligible processing delay and delivers consistent audio quality. It is not adaptive, so its bandwidth consumption is fixed and entirely predictable, which makes capacity planning straightforward.

A single voice call consumes bandwidth in both directions simultaneously. Building the figure up from the packet:

At 50 packets per second, this gives approximately 95 kbps per direction, per call. Secure media (SRTP) adds a small authentication tag, bringing the figure to just under 100 kbps.

Planning figure: use 100 kbps per direction, per concurrent call. This rounds up slightly to absorb signalling, registration keepalives and packet header variation.

Two points that follow from using G.711 and matter for design:

• Bandwidth is constant, not variable. Adaptive codecs reduce their bit rate when they detect congestion. G.711 does not. It will continue transmitting at full rate and packets will simply be dropped, so the network must be provisioned and protected for the full load at all times. This is the main reason QoS is mandatory rather than advisory.
• A-law and mu-law are both 64 kbps and have no bandwidth implication, but a mismatch between the two produces loud distorted audio. Regional defaults are handled by our platform and require no action from you.

2.2 Concurrency assumptions

Contact centre sizing differs from ordinary office sizing. In a typical office you might assume 20% of staff are on a call at once. In a BPO environment, particularly on inbound queues with high occupancy, assume 100% concurrency. If 100 agents are rostered, plan for 100 simultaneous calls.

Where a site runs blended or outbound campaigns with a dialler, concurrency can exceed headcount because the dialler places multiple calls per available agent. In those cases, size against the configured dialler pacing ratio rather than seat count, and speak to us before finalising the circuit.

2.3 Sizing table

The table below assumes 100% concurrency, a 25% headroom allowance on the voice component, and an allowance of approximately 0.5 Mbps per agent for the agent desktop, CRM, browser and general business traffic sharing the same circuit.

2.4 Worked example: a 100 seat BPO site

• 100 agents, all potentially on calls at the same time.
• Voice: 100 calls x 100 kbps (G.711) = 10 Mbps upstream and 10 Mbps downstream.
• Add 25% headroom for signalling, retransmission and burst: 12.5 Mbps each way, reserved and protected by QoS.
• Add business data: agent portal, CRM, ticketing, email, browser: approximately 50 Mbps shared.
• Recommended circuit: 100 Mbps symmetric, with a minimum of 15 Mbps guaranteed to voice through a priority queue.

The voice component is only around 12% of the circuit. That is the point. Voice does not need a large share of bandwidth, it needs a protected share.

2.5 Symmetric circuits and the upstream trap

This is the most frequently missed item in site design.

Consumer and small business broadband is usually asymmetric. A "500 Mbps" service is often 500 Mbps down and only 20 or 30 Mbps up. Voice is symmetric: every agent sends as much audio as they receive.

A 100 seat site needs 12.5 Mbps of upstream for voice alone. On a 500/20 Mbps broadband service, voice would be competing with every file upload, cloud backup and video call for the remaining upstream capacity, and audio would break up under load even though the headline speed looks generous.

Specify a symmetric business circuit, such as fibre with equal upstream and downstream, wherever agent counts exceed a handful of seats.

2.6 Additional traffic to allow for

Add to the sizing above where applicable:

• Screen recording or desktop capture uploaded from site: 0.2 to 1 Mbps per recorded agent, depending on resolution and frame rate.
• Video calls or video contact channels: 1 to 2 Mbps per concurrent session.
• Supervisor live monitoring, whisper and barge: treat each active monitoring session as an additional concurrent call.
• Virtual desktop infrastructure (VDI): if agents work inside a virtual desktop, the display protocol traffic is additional and voice routing needs separate discussion, as media should not be encoded inside the virtual session.

3. Network quality targets

Bandwidth is necessary but not sufficient. The following must be met on the path between the agent and our media edge, measured over a full business day rather than at a quiet moment.

Notes for context:

• Latency causes people to talk over each other. Beyond roughly 300 ms round trip, conversation becomes visibly awkward and agents start apologising for interrupting.
• Jitter is more damaging than raw latency. Consistent 120 ms is usable; latency swinging between 20 ms and 200 ms is not.
• Packet loss is what customers describe as "robotic", "underwater" or "cutting out". G.711 has no forward error correction, so a lost packet is 20 ms of audio that can only be approximated by concealment. Loss becomes audible earlier than it would with an adaptive codec, which is why the target is set at under 1%.
• These figures apply end to end, including the office LAN, the Wi-Fi segment if used, the router, the internet circuit and any VPN in the path. A clean internet circuit does not compensate for a congested access switch.

4. Quality of service on the site router

4.1 Why it is mandatory

An office network is a shared resource. At any moment, staff will be streaming video, downloading operating system updates, syncing cloud storage or joining video meetings. Without QoS, the router treats an agent's voice packets and a background YouTube stream as equally important. Streaming video absorbs whatever capacity is available by design, so voice packets queue behind it and arrive late or not at all.

The result is intermittent and hard to diagnose: audio is fine at 09:00 and breaks up at 14:00 when a large software update rolls out. The circuit graph shows spare capacity on average, because the congestion lasts seconds at a time.

QoS must be enabled on the router or firewall that terminates the internet circuit. This is the point where the fast LAN meets the slower WAN, and it is the only place the queue forms.

4.2 What to configure

• Trust and preserve DSCP markings. Voice media (RTP) is marked EF (DSCP 46). Signalling is marked CS3 or AF31 (DSCP 24 or 26). The router must honour these and must not clear or remap them.
• Mark at the edge if endpoints cannot mark. Where the agent application or handset cannot set DSCP, classify by voice VLAN or by destination and mark on the access switch or router.
• Use a strict priority or low latency queue for EF traffic, with a policed ceiling so a fault cannot let voice starve everything else.
• Shape to approximately 95% of the true circuit rate. If the router sends at line rate, the queue forms in the provider's equipment where you have no control. Shaping slightly below the circuit speed keeps the queue on your side, where your policy applies.
• Deprioritise bulk and recreational traffic. Mark streaming, guest Wi-Fi, backups and update distribution as background or scavenger class (DSCP 8) so they yield automatically under load.

4.3 Worked example: QoS policy on a 100 Mbps circuit at a 100 seat site

Shape the parent policy to 95 Mbps.

4.4 A note on DSCP across the public internet

Most internet providers do not honour customer DSCP markings across their backbone. This does not make QoS pointless. Congestion in a contact centre almost always occurs at the office uplink, which is under your control, not in the provider core. Marking correctly also allows the provider to apply policy where an MPLS, SD-WAN or managed internet service supports it.

Where quality guarantees are contractually important, discuss a dedicated internet access service with a service level agreement covering latency, jitter and loss, rather than best effort broadband.

5. Wired versus wireless

5.1 Recommendation

Agent desks must use wired Ethernet. This is a requirement rather than a preference for production contact centre seats.

Provide Cat5e or better cabling to each desk position, terminated on a managed switch. Gigabit ports are standard and inexpensive. Where laptops lack an Ethernet port, supply a docking station or a USB-C to Ethernet adapter.

5.2 Why Wi-Fi causes problems in contact centres

Wi-Fi is often perfectly adequate for browsing and email while being unsuitable for continuous real time audio, which is why the problem is frequently dismissed during testing.

• The medium is shared and half duplex. All devices on a channel take turns. Thirty agents on one access point means thirty devices contending for airtime, and voice packets that need to arrive every 20 ms wait their turn.
• Retransmission creates jitter. Wi-Fi silently retries lost frames. The packet eventually arrives, but late and out of sequence, which is precisely the pattern that degrades audio.
• Roaming interrupts audio. As an agent walks between access points, the handover typically costs 200 to 500 ms. On a data session this is invisible. On a live call the customer hears a gap or the call drops.
• Interference is uncontrolled. Microwave ovens, neighbouring tenants' networks, wireless presentation systems and Bluetooth devices all share the 2.4 GHz band.
• Slow clients slow everyone. A single device at the edge of coverage negotiating a low data rate consumes disproportionate airtime, degrading every other client on that access point.

A typical symptom pattern: one agent on the far side of the floor reports that customers say she keeps cutting out, but her speed test shows 200 Mbps. Speed tests measure throughput over seconds and are almost useless for diagnosing real time audio.

5.3 If wireless cannot be avoided

For roaming supervisors, floor walkers or temporary seating, apply the following:

• Use 5 GHz or 6 GHz only. Disable 2.4 GHz for agent devices, or place them on a separate SSID.
• Ensure WMM (Wi-Fi Multimedia) is enabled so the access point recognises voice priority.
• Maintain signal strength better than -65 dBm and signal to noise ratio above 25 dB at every agent position.
• Use 20 MHz or 40 MHz channel widths, not 80 MHz or wider, to reduce co-channel interference and increase usable channels.
• Enable 802.11r, 802.11k and 802.11v for fast, assisted roaming.
• Cap concurrent clients per access point, typically 20 to 25 for voice use rather than the vendor's headline figure.
• Disable low data rates so distant clients associate to a nearer access point instead of clinging on.

5.4 Equipment to avoid entirely for agent seats

• Wi-Fi range extenders and repeaters, which halve throughput and add latency.
• Mesh systems using wireless backhaul. If mesh is used, backhaul must be wired.
• Powerline or homeplug Ethernet adapters, which are highly variable and sensitive to electrical noise.
• Unmanaged desktop switches or hubs daisy chained under desks, which defeat QoS trust and VLAN separation.
• Mobile hotspots and USB dongles as a primary connection, though they are acceptable as a documented emergency fallback.

6. Local network design

• Separate voice and data VLANs. This simplifies QoS classification, security policy and troubleshooting, and prevents a broadcast storm on the data network from affecting calls.
• Use managed switches with QoS trust configured on ports carrying voice, so DSCP markings survive the LAN.
• Provide Power over Ethernet where physical SIP handsets are deployed, and size the PoE budget with headroom.
• Avoid oversubscribed uplinks. A 48 port access switch with a single 1 Gbps uplink to the core is a common and avoidable bottleneck on a busy floor.
• Consider dual WAN with automatic failover, ideally from two different providers using diverse physical paths. Take care that voice sessions are pinned to a single path; per packet load balancing across two circuits will reliably destroy call quality.
• Confirm DHCP scope, DNS resolution and NTP are correctly sized and reachable. Clock drift on recording and reporting systems is a recurring and avoidable support issue.

7. Firewall and security appliance settings

• Disable SIP ALG. Application layer gateways for SIP are enabled by default on many routers and firewalls and they routinely corrupt signalling, causing one-way audio, failed transfers and calls that ring but cannot be answered. This is the most common single configuration fault we encounter.
• Allow the required outbound traffic to our platform, including TLS signalling, secure media over UDP, and the STUN or TURN services used for connectivity establishment. We will provide the current address ranges, ports and hostnames during onboarding.
• Set UDP session timeouts to at least 60 seconds so that NAT bindings for media and registration are not torn down mid-session.
• Exclude real time media from deep packet inspection, TLS interception and intrusion prevention. These add per packet latency and, in the case of TLS interception, will break encrypted media.
• Ensure symmetric routing. Media returning on a different path from the one it left on will be dropped by a stateful firewall.
• Whitelist the agent application domains in any web filtering or proxy policy. Real time media must not traverse an HTTP proxy.

8. Remote agents, home workers and VPN

8.1 Do not backhaul voice through a VPN

Where remote agents connect over a full tunnel VPN to a head office or data centre, voice traffic follows a longer path: from the agent's home, to the VPN concentrator, out to our platform, and the reverse on return. This adds latency, adds a congestion point at the VPN headend, and encrypts already encrypted media a second time.

The overhead is measurable. An IPsec tunnel adds roughly 55 bytes to each packet, taking a G.711 call from about 238 bytes to close to 295 bytes on the wire. That is approximately 120 kbps per call instead of 100 kbps, a 20% increase, and it applies at the VPN concentrator as well as at the agent's connection.

Recommendation: use split tunnelling so that contact centre media and signalling traffic goes directly from the agent's device to the internet, while corporate applications continue over the VPN. We will supply the destination ranges to exclude from the tunnel.

Where security policy makes full tunnelling non-negotiable, the VPN concentrator must be sized for the full concurrent voice load, placed geographically close to the agent population, and included in the quality measurement described in section 9.

8.2 Minimum requirements for a home based agent

Practical guidance to include in home worker onboarding:

• Plug into the router with an Ethernet cable. The same reasoning in section 5 applies, and home environments are usually worse: thinner walls are rare, but neighbouring networks, smart devices and family usage are not.
• A single call needs very little bandwidth, but it needs it consistently. The problem is rarely capacity, it is contention. A household member starting a 4K stream or a game console downloading a large update will disrupt calls on a shared connection.
• Enable QoS on the home router if it offers it. Many consumer routers include a simple prioritisation setting that can be pointed at the agent's device.
• Avoid mobile hotspots and satellite broadband as primary connections. Both can show good throughput while producing jitter well outside target.
• Avoid Bluetooth headsets for high volume calling. Wired USB headsets deliver more consistent audio, avoid mid shift battery failure and are not affected by 2.4 GHz congestion.
• Restart the home router periodically. A surprising proportion of degradation reports resolve at this step.

8.3 Agent workstation

• Current version of Chrome or Edge for the browser based agent application.
• 8 GB RAM minimum, 16 GB recommended where agents run a CRM and multiple applications alongside the agent desktop.
• A modern multi core processor. Real time audio encoding and decoding is continuous, and an already saturated CPU produces choppy audio that looks identical to a network fault.
• Discourage large numbers of open browser tabs and background applications during shifts.
• Configure endpoint protection to exclude the agent application from aggressive real time scanning where this is permitted by policy.

9. Pre-deployment assessment and acceptance

Before go live we recommend the following, and we will support you through each step:

1. Run a network assessment from the site for a minimum of five business days, covering peak hours. A short test at a quiet moment will not reveal contention problems.
2. Confirm the assessment results meet the targets in section 3, including at the busiest hour rather than on average.
3. Verify QoS is applied by generating deliberate background load and confirming that voice metrics remain within target.
4. Complete a pilot with a small agent group on the production network before full cutover.
5. Agree an escalation path and the information required for quality tickets: agent identity, timestamp with time zone, call reference, and a description of the symptom.

Once live, we provide continuous call quality monitoring including MOS, jitter and loss per call, which allows quality issues to be attributed to a specific network segment rather than debated.

10. Pre-go-live checklist

11. Quick reference: common symptoms and likely causes

12. Support

Our onboarding team will provide the current platform address ranges, port requirements and assessment tooling, and will review your proposed network design before implementation. Please involve us early: retro-fitting cabling or replacing a circuit after go live is considerably more disruptive than confirming the design in advance.

This document provides general guidance for planning purposes. Specific requirements may vary by deployment region, contact channel mix and integration profile. Your onboarding contact will confirm the details applicable to your service.