After a controller push for the county voice WLAN, what should the technician verify locally on the AP related to QoS?
Select an answer to reveal the explanation.
Short Explanation
Controller said it pushed QoS—great, now look with your own eyes on the AP. Open the AP GUI or status page and confirm WMM actually landed as enabled. Trust, but verify, especially on voice day.
Full Explanation
After a controller push for the county voice WLAN, the technician should verify locally on the AP that WMM shows enabled in the GUI or status view. Controller intent and AP operational state can drift after templates, overrides, or partial joins. Confirming WMM on the civic AP closes the loop between design, controller policy, and the radio that actually serves softphones.
Preferring Telnet over HTTPS for management is a security downgrade unrelated to QoS verification. Requiring every SSID to use WEP for consistency reintroduces broken cryptography and does not validate WMM. Forcing band steering off for all dual-band clients may be a separate design question and is not the local QoS check after a voice push.
Exam caveat: verify the QoS feature that voice depends on—WMM—on the AP itself after controller changes. Do not substitute unrelated management or cipher changes for that check.
Operational check: open the AP status after the county voice push, confirm WMM enabled, place a test call on the voice SSID, and screenshot the WMM state for the change record. Municipal technicians document the verified setting in the as-built packet so the next shift inherits a known-good civic configuration rather than tribal knowledge.