Adding phones to a branch office seems simple, until calls start dropping during busy periods or audio quality degrades for no obvious reason. Most VoIP problems trace back to decisions made before a single handset is installed: how many concurrent calls the connection can support, whether latency and jitter are low enough to preserve voice quality, and whether the WAN has genuine headroom once other traffic is factored in. This guide shows you how to make sure each of these aligns with your business needs.

Start with concurrent call capacity

The foundation of VoIP capacity planning is calculating how many simultaneous calls your branch link needs to support at peak usage. This is not the same as the total number of phones installed; at any given moment, only a fraction of users are on a call at once. For a branch office of twenty people, peak simultaneous calls might be four to six. For a call center environment with the same headcount, that number could approach twenty.

To estimate peak concurrent calls accurately, look at the busiest hour of the workday across several typical days, count active calls during that window, and add a 20–30% buffer to account for growth and unexpected peaks. This figure becomes your baseline requirement for the rest of the capacity calculation.

Calculate actual bandwidth per call, including codec overhead

A single VoIP call consumes more bandwidth than its audio payload alone. The G.711 codec, which is the standard for enterprise VoIP and produces toll-quality audio, uses approximately 64 kbps for the audio itself. When you add the IP, UDP, and RTP packet headers that wrap every voice packet, total bandwidth per call rises to approximately 80 to 87 kbps, depending on packet size and header compression settings.

The G.729 codec compresses audio more aggressively and uses approximately 8 kbps for the payload, with total per-call bandwidth around 24 to 32 kbps. The tradeoff is a slight reduction in audio quality and higher processor load on the endpoints. For branch offices with limited WAN bandwidth, G.729 substantially reduces the bandwidth requirement, but this needs to be evaluated against the audio quality standard the business expects.

The practical calculation: multiply your peak concurrent call estimate by the per-call bandwidth for your chosen codec, then double it to account for both directions of each call. A branch expecting six simultaneous G.711 calls needs approximately 1 Mbps reserved for voice traffic. Six G.729 calls need approximately 380 kbps.

Measure WAN headroom under real load

The bandwidth actually available for voice traffic is often far lower than the headline speed of your WAN connection. Cloud applications, video conferencing, backups, file synchronization, and general web traffic all compete with voice during business hours. A link that shows 50 Mbps in an idle speed test may have only 5 to 10 Mbps genuinely available during peak working hours.

To measure real WAN headroom, capture throughput during the busiest period of the working day, not during a quiet moment. Network monitoring tools can provide this view over days or weeks, which is more reliable than a single-point measurement. The gap between total link capacity and peak non-voice consumption is your available voice headroom. If voice capacity requirements exceed that headroom, traffic prioritization or a link upgrade is needed before deployment.

Test latency and jitter

Voice traffic is uniquely sensitive to two network characteristics that matter far less for data applications: latency and jitter. Latency is the one-way delay of a packet traveling between two endpoints. Jitter is the variation in that delay from packet to packet. Both affect call quality in distinct ways.

For acceptable voice quality, one-way latency should be below 150 milliseconds. End-to-end round-trip latency as measured by a ping should therefore be below 300 ms for a branch office calling through a cloud VoIP platform. Latency above 150 ms one-way produces the conversational awkwardness of talking over someone, because the slight pause between speaking and being heard exceeds the threshold of natural conversation.

Jitter above approximately 30 to 40 milliseconds introduces audible distortion, clicking, and choppy audio, because voice packets are arriving with enough variation in timing that the jitter buffer on the receiving endpoint cannot fully smooth out the irregularity. Most business-class WAN links have acceptable jitter, but links routed over multiple carriers or consumer-grade connections may not. Test with a tool that measures jitter specifically rather than relying on latency alone.

Test packet loss

VoIP uses UDP for transport, which means dropped packets aren’t retransmitted. A packet loss rate above approximately 1% is audible as clicks, gaps, or garbled audio on an active call. Above 5%, calls become difficult to follow. Packet loss is often intermittent rather than constant, so testing at different times of day and under load conditions gives a more accurate picture than a single measurement at an idle moment.

Test the system end to end before go-live

Calculations and pre-deployment measurements provide a reliable prediction, but they are not a substitute for live testing. Before the branch VoIP system goes live, test inbound and outbound calls from the branch during peak hours while other applications are running normally. Verify call quality under real network load, confirm that voicemail, call transfers, and any hunt groups or queues behave correctly, and document the baseline performance metrics so that future degradation can be identified accurately.

Planning a VoIP deployment for a branch office or evaluating whether your current link can support more phones? Our team can run the measurements, model the capacity requirements, and design a setup that performs under real working conditions. Reach out to start the planning conversation.