A voice-ready network delivers consistent, low-delay connectivity from every phone or app to its voice platform. Bandwidth matters, but stability, queueing, packet loss, Wi-Fi design, power and firewall behaviour usually matter more than a headline speed-test result.
What good voice needs
- Low packet loss: missing voice packets cause gaps and distortion.
- Consistent latency: excessive delay makes conversation awkward.
- Low jitter: irregular packet arrival can overwhelm the receiving jitter buffer.
- Available upload capacity: saturated upstream links can delay voice badly.
- A stable media path: firewalls and NAT must preserve the required sessions without unsafe blanket rules.
- Reliable power: phones, PoE switches, routers and access-network equipment all need power.
Estimate capacity
Calculate expected simultaneous calls, not just the number of users. Codec payload, packet interval and IP/Ethernet overhead determine the bandwidth per call. Add design headroom and consider other real-time traffic. Your provider or platform should document supported codecs and practical bandwidth estimates.
Measure during genuine busy periods in both directions. A fast download result can hide upload saturation, intermittent loss or a congested Wi-Fi channel.
Use QoS deliberately
QoS controls how managed network equipment treats competing packets. Common designs classify signalling and media separately, mark them and provide expedited queueing to voice media. RFC 4504 describes configurable DiffServ markings for SIP devices and recommends expedited forwarding for RTP when a device is not otherwise provisioned.
QoS is effective only where you control the queues. Confirm that markings are trusted and preserved at the appropriate boundaries, and shape traffic at the real bottleneck. Do not assume an internet provider honours your internal markings.
Decide whether to use a voice VLAN
A voice VLAN can improve segmentation, addressing, policy and troubleshooting. It is not automatically more secure or higher quality: switches, DHCP, routing, access controls and phone pass-through ports must still be configured correctly. Document how phones discover the VLAN and how a device connected through a phone is treated.
Check PoE and physical infrastructure
Confirm that each switch has enough PoE budget for the connected phones, expansion modules and conference devices—not merely enough PoE-capable ports. Check cabling, switch uplinks, rack power, UPS runtime and environmental conditions. A cloud PBX cannot compensate for an unpowered access switch.
Treat Wi-Fi voice as a mobility system
Good data coverage does not necessarily mean good calling. Validate signal strength, channel utilisation, interference, roaming behaviour, authentication delays and capacity with the actual handsets or mobile devices. Test while moving between access points and while the network is busy.
Configure firewalls from platform requirements
Use the exact destinations, ports, transports and session requirements published by the phone-system provider. Avoid broad port forwarding and disabling security controls as a first response. SIP application-layer gateways can help in specific designs but often alter signalling unexpectedly; follow the platform vendor’s guidance.
Remember that signalling and media may use different hosts and ports. Successful registration proves only that one part of the path works.
Create an outage design
- UPS protection for routing, switching, phones and access-network equipment
- A second access path with tested—not assumed—failover
- Provider-side diversion or continuity rules
- Charged mobile phones and documented emergency procedures
- Configuration backups, monitoring and clear support ownership
A pre-deployment test plan
- Inventory the physical and logical path from endpoints to the voice service.
- Measure latency, jitter, loss and utilisation during busy periods.
- Place concurrent test calls in both directions.
- Test hold, transfer, conference, voicemail and DTMF—not only a basic call.
- Test remote users and Wi-Fi roaming separately.
- Fail the primary internet service and power source under controlled conditions.
- Confirm monitoring detects the failure and the support process works.
- Record a baseline so future faults can be compared with known-good performance.
Frequently asked questions
How much bandwidth does a VoIP call use?
It depends on the codec, packet interval and network overhead. Use the platform’s documented figure, multiply by expected concurrent calls in each direction and add headroom. Bandwidth alone does not predict quality.
Will QoS fix bad VoIP?
QoS can manage congestion on links you control. It cannot repair packet loss caused by faulty cabling, poor Wi-Fi, an unstable access service or congestion elsewhere on the internet.
Why do calls have one-way audio?
Common causes include blocked or incorrectly translated media traffic, incorrect advertised addresses, asymmetric routing and mismatched firewall rules. Trace signalling to identify the negotiated media addresses, then verify both RTP directions.