VoIP phones are plug-and-play. VoIP call quality is not. The phone will register and make calls out of the box. Whether those calls hold up when everyone is on the phone at once depends entirely on the network underneath. Here's a practical guide to getting that network ready before you deploy.
For a 10-user office, bandwidth is rarely the bottleneck. Budget roughly 100 kbps per active call. Ten simultaneous calls on G.711 need about 1 Mbps of dedicated capacity, with 1.5 Mbps recommended for headroom. If you're on a 100 Mbps fibre connection, bandwidth is not your problem.
Latency, jitter, and packet loss are your problems. The targets are: one-way latency under 150 ms, jitter under 30 ms, and packet loss under 1%. These numbers matter more than raw speed. A 50 Mbps connection with low jitter will outperform a 500 Mbps connection with high jitter every time.
If you configure nothing else, configure a voice VLAN. This lets one switch port carry tagged voice traffic and untagged data traffic simultaneously: the phone tags its own voice packets, and the PC behind the phone sends untagged data.
The benefit is simple: voice traffic gets its own broadcast domain, its own QoS policies, and its own troubleshooting lane. When calls sound bad, you know to look at the voice VLAN, not the entire network.
On a Cisco switch, the configuration is minimal:
```
interface GigabitEthernet1/0/1
switchport mode access
switchport access vlan 10
switchport voice vlan 20
mls qos trust cos
spanning-tree portfast
```
This tells the switch: untagged traffic (the PC) goes to VLAN 10; tagged voice traffic goes to VLAN 20; trust the QoS markings the phone applies.
QoS is not optional. Without it, a large file upload can starve a voice call of bandwidth and turn a conversation into a stuttering mess.
The standard marking for voice is DSCP EF (Expedited Forwarding, value 46) for RTP media and CS3 (value 26) for SIP signalling. At Layer 2, this maps to 802.1p CoS 5. Trust these markings at every hop. A VLAN alone does not enforce prioritisation: you need a QoS policy to actually give voice traffic strict priority queuing.
On a Cisco switch, a basic voice QoS policy looks like this:
```
class-map match-all VOICE
match access-group name VOICE-RTP
policy-map QOS-POLICY
class VOICE
priority percent 30
set dscp ef
class class-default
fair-queue
```
This gives voice traffic 30% of the interface bandwidth with strict priority, and everything else shares the rest.
When a phone boots, it needs to know where its provisioning server is. Instead of configuring each phone manually, use DHCP Option 66 or 150 to point phones at the TFTP or HTTP server that holds their configuration files. When you add a new employee, you plug in the phone, it grabs its config automatically, and you're done.
There are three firewall settings that break VoIP more often than anything else.
SIP ALG. Turn it off. It rewrites SIP packets in ways that break registration, cause one-way audio, and drop calls. Every VoIP provider's troubleshooting guide says the same thing.
UDP timeout. Extend it to at least 90 seconds. VoIP runs on UDP, which has no handshake. Routers can't tell when a call has ended, so a short timeout kills live calls mid-conversation.
Double NAT. Eliminate it. If your ISP router and your firewall are both doing NAT, put the ISP device in bridge mode and let your firewall handle the public IP.
Connect desk phones with Ethernet cables. Wi-Fi adds variables a cable doesn't: device count, real-world available bandwidth, and protocol differences (G, N, AC and AX all perform differently under load). If a phone must be wireless, put it on a dedicated SSID with QoS enabled, and accept that it will never be as reliable as a cable.
Your VoIP phones will work out of the box. They will also fail during your busiest hour if the network underneath them isn't configured. A voice VLAN, a QoS policy and three firewall settings are the difference between a phone system that works and a phone system that works when it matters.