A hospital's WLAN carries VoIP calls for on-call physicians alongside general web browsing on the same SSID, and staff report choppy, dropped-sounding calls specifically during peak browsing hours. The team wants voice traffic to get priority over bulk web traffic on that shared airtime. What is the correct approach?

Voice calls are latency- and jitter-sensitive in a way bulk web traffic is not, so the fix is traffic classification: marking voice packets with QoS priority (such as WMM access categories mapped from DSCP) so the access point schedules them ahead of best-effort traffic during contention, directly addressing choppy calls without needing more bandwidth overall. Raising the minimum data rate changes which clients are permitted to associate at all based on PHY rate, which can shed some slow clients but does nothing to make the network distinguish a voice packet from a web packet once both are on the air competing for the same queue. Band steering nudges dual-band clients toward 5 GHz to balance load between radios, but it doesn't classify or prioritize traffic types, so voice and web packets on the same band would still contend equally once steered. Disabling QoS removes the exact mechanism that solves this problem, treating every packet as equally urgent, which is precisely the condition producing the choppy calls the team is trying to fix. Caveat: QoS markings only help if they are honored consistently end to end, including on any wired segment and the calling device itself, or priority can be lost partway through the path. A concrete check is confirming voice packets actually carry the expected priority marking and land in the correct access category when captured during a busy period.