QoS for voice and video

Quality of service (QoS) tells network equipment which traffic to send first when links get busy. Voice and video are sensitive to delay, jitter and loss, while file downloads and backups are not, so QoS puts real-time traffic at the front of the queue. It only works if traffic is marked consistently and every device along the path, wired and wireless, honours those marks.

Why voice and video need priority

A network link can only send one packet at a time. When traffic arrives faster than a link can send it, packets wait in a queue. A large file transfer can fill that queue and delay the small, steady packets of a phone call. The call does not need much bandwidth, but it needs its packets on time.

Common planning targets for good voice quality are:

• One-way delay under about 150 milliseconds, the figure in ITU-T recommendation G.114
• Jitter low enough for the phone's jitter buffer to smooth out, often quoted as under about 30 milliseconds
• Packet loss well under 1 percent

Video conferencing has similar needs and uses much more bandwidth, so it needs its own planning. Treat these figures as guidance and check your phone system and conferencing platform's own requirements.

How QoS works

1. Classify: identify traffic as voice, video, signalling or general data.
2. Mark: label each packet so other devices know its class. On IP networks this is the DSCP value in the packet header.
3. Queue: on each link, put marked traffic in the right queue, with a strict-priority queue for voice and a guaranteed share for video.
4. Police and shape: limit each class so priority traffic cannot starve everything else, and shape traffic to match the real speed of slower links.

Typical markings

These are widely used conventions. Your phone system or conferencing vendor may recommend different values; what matters is that the whole network uses the same scheme.

Keep the number of classes small. Four to eight classes is typical for a business network; a scheme with a dozen classes is hard to maintain and rarely performs better. Document the scheme so that whoever configures a new switch, access point or firewall applies the same rules.

The trust boundary

Any device can mark its own traffic as high priority, including a laptop downloading a large file. Switches therefore decide whose markings to trust. A common approach trusts markings from IP phones and conferencing systems, re-marks or ignores markings from general user ports, and classifies softphone traffic by application or port. Setting the trust boundary carefully stops QoS from being undone by misbehaving or misconfigured devices.

QoS on WiFi

WiFi uses WMM (WiFi Multimedia), which maps traffic into voice, video, best effort and background access categories. Voice gets shorter waiting times to transmit. For this to work, DSCP markings must map correctly to WMM categories on access points and controllers, and devices must mark their own traffic. Good WiFi QoS also depends on good design: enough signal, low channel utilization and fast roaming. See WiFi roaming and handoff and high-density WiFi design.

Checking that QoS works

• Capture packets at several points and confirm markings survive end to end
• Check switch and router queue statistics for drops in the priority queue
• Run test calls while the network is under heavy load
• Use your phone system's call quality reports to find problem sites or users
• Review QoS after network changes, firmware updates or new applications

QoS cannot fix a link that is simply too small, or a network with cabling faults. Bandwidth, design and QoS work together. For the bigger picture, see VoIP explained.

A typical case: choppy calls at a branch office

A branch office reports that calls break up most afternoons, while the head office is fine. Both sites use the same hosted phone system. A structured check usually finds the cause:

1. Find the pattern. Pull call quality reports from the phone platform. If poor calls cluster at certain times, compare with internet link usage at those times. Afternoon backups or large cloud file syncs are common culprits.
2. Check the internet edge. If the link is close to full when calls break up, queuing is happening somewhere. Without shaping, it happens in the provider's equipment, where your voice packets wait with everything else.
3. Check markings. Capture traffic from a phone at the switch port and at the firewall. Confirm voice is marked EF at the phone and still marked EF at the edge. A switch port set not to trust the phone, or a firewall that clears markings, undoes QoS.
4. Apply shaping and priority at the edge. Shape outbound traffic slightly below the measured link speed and give voice a priority queue there. If the platform's media servers are known, inbound traffic can sometimes be managed too.
5. Look at the rest of the path. If calls on WiFi are worse than wired calls, review WMM mapping and the wireless design. If one desk is worse than others, test that cable and port.
6. Retest at the busy time. Run test calls during the afternoon peak and compare the quality reports for a week before and after.

Sizing the priority queue

A strict-priority queue must be large enough for all the voice it will carry, but limited so it cannot starve other traffic. To size it:

• Estimate the peak number of simultaneous calls over each link, from call records if you have them
• Multiply by the bandwidth per call for the codec in use, including packet overhead; your phone vendor publishes these figures
• Add a margin for growth and for signalling traffic
• Reserve a separate share for video based on the number of rooms and users likely to be on video calls at once
• Check that the remaining capacity still serves general data acceptably at the busiest time

If the numbers do not fit, the link is too small, and QoS alone will not solve it.

How ehZee can help

Our VoIP design and build service includes checking the network that calls will travel over, designing QoS across switches, WiFi and the internet edge, and testing call quality before cutover.

Common questions