Video conferencing looks like voice with more bandwidth, and that assumption produces most of the problems. A call adapts: it lowers resolution when the link is congested, freezes when jitter spikes, and sends a burst of data whenever someone shares a screen.
The shapes of video traffic
| Type | Pattern | Sensitivity |
|---|---|---|
| Conferencing (WebRTC, Teams, Zoom) | Adaptive bitrate, 0.5–4 Mbps per stream | Jitter and loss |
| Streaming (recorded) | Buffered, bursty | Throughput |
| Screen sharing | Sharp I-frame bursts on change | Burst bandwidth |
| IPTV / announcements | Constant bitrate multicast | Loss |
Conferencing is the one that matters in a district, and it is the one that behaves best under QoS — because it adapts to what it is given, as long as latency stays low.
Bandwidth planning
| Scenario | Per stream | Notes |
|---|---|---|
| 1:1 video call | 1–2 Mbps | Both directions |
| Classroom session | 2–4 Mbps | Instructor video plus content |
| Screen share | 1–3 Mbps | Spikes when content changes |
| Recorded stream | 3–8 Mbps | Buffered, less time-sensitive |
Thirty classrooms in simultaneous sessions at 2.5 Mbps is 75 Mbps — a meaningful share of a 200 Mbps circuit, and easy to underestimate.
Multicast, and why it usually is not the answer
Classroom video is sometimes delivered as multicast to save bandwidth. In practice:
- Multicast requires end-to-end support, including the wireless network.
- Wi-Fi sends multicast at the lowest basic rate to every client, which is worse than unicast.
- Many conferencing tools do not support it at all.
For a district, multicast-to-unicast conversion on wireless and per-classroom unicast streams are usually simpler and more reliable than a multicast design.
One video wall can saturate an AP
A single 20 Mbps multicast stream transmitted at 24 Mbps basic rate consumes airtime equivalent to many unicast clients. Convert to unicast for wireless, or keep video walls wired.
Marking and queuing
| Traffic | DSCP | Queue |
|---|---|---|
| Conferencing media | AF41 (34) | Low latency, 30% |
| Screen share | AF41 | Same class |
| Recorded streaming | AF21 (18) | Business |
| IPTV multicast | CS1 (8) | Bulk, or separate VLAN |
Video does not need strict priority; it needs a queue that is not starved and not deep. AF41 with a weighted share is the standard answer.
Worked example: 30 classrooms
- Measure one session: 2.4 Mbps up, 2.4 Mbps down per classroom.
- Total: 72 Mbps in each direction at peak.
- Circuit: 200 Mbps, so 36% — acceptable, but not with backups running.
- Policy: AF41 gets 80 Mbps guaranteed; bulk is suspended during 08:00–15:00.
- Wireless: convert multicast, cap video per AP, and keep the 6 GHz band for conferencing devices.
What breaks in production
- Bandwidth planned from a vendor's "recommended" number, which assumes one stream and no overhead.
- Screen sharing spikes that exceed the queue and cause freezes for everyone in the call.
- Wi-Fi multicast, turning one stream into an airtime outage.
- Video marked as EF, competing with voice and losing both.
- No admission control, so the thirtieth classroom degrades all thirty.
Checklist
- Per-stream bandwidth is measured, not assumed.
- Peak concurrent sessions are known.
- Video has its own class, below voice.
- Bulk traffic is suspended or throttled during instructional hours.
- Wireless multicast is converted to unicast.
- Session quality is measured during the busiest period.
Next
The last mile of QoS is often wireless. Continue with Wireless QoS and WMM.