Softphones at the utility call center mark voice packets DSCP EF on the wired LAN, yet airtime traces show those frames competing in best-effort WMM queues after they hit the AP edge. What end-to-end fix is required?
Select an answer to reveal the explanation.
Short Explanation
DSCP EF is a sticky note that says “voice—handle carefully.” If the AP peels that note off or maps it wrong, Wi-Fi treats the call like bulk downloads. Keep EF mapped to AC_VO from the switch edge through the SSID.
Full Explanation
Softphones at a utility call center may mark voice as DSCP EF on the wired LAN, yet frames can still compete in best-effort WMM queues after the AP edge if DSCP↔WMM mapping is inconsistent or markings are stripped. The end-to-end fix is ensuring DSCP EF maps to WMM AC_VO across the wired edge and WLAN so priority survives into the correct access category on the air. Stripping all DSCP at the access switch so Wi-Fi ignores QoS markings destroys the very signal needed for correct queuing. Enabling only AC_VI and blocking AC_VO mis-classifies telephony into video or denies the proper queue entirely. Increasing AP transmit power cannot compensate for missing QoS classification; RF power does not create EDCA priority. Exam caveat: wired DSCP correctness does not imply wireless AC correctness—map and trust boundaries must be verified hop by hop. Operational check: inject EF-marked test voice through the call-center path, observe ToS/DSCP at the AP and the WMM AC used on air, then lock controller/switch policies so municipal softphones stay in AC_VO under load. Softphone quality for utility callers depends on that hop-by-hop consistency during shift peaks when AC_BE contention is highest. Record the verified mapping in the municipal QoS design so future switch ACL or controller upgrades do not silently remark EF into best effort again.