Council VoIP handsets drop calls when SNR is poor even though the phone still shows one signal bar and stays associated. What does that teach about voice needs?
Select an answer to reveal the explanation.
Short Explanation
One lonely bar with awful SNR is like being 'connected' to a whisper through a concrete wall—you are associated, but the call still dies. Voice cares about usable signal quality, not just a checkbox that says joined. Check SNR/RSSI against voice needs.
Full Explanation
Council VoIP handsets that drop calls when SNR is poor—even though the phone still shows one signal bar and stays associated—teach that voice and video need adequate SNR and RSSI quality, not merely an associated state. Association can persist at marginal SNR while retries soar and codecs fail, producing drops and garbled audio in civic chambers. Technicians must validate RF quality metrics against voice requirements rather than trusting a connected icon alone on clerk or dais handsets.
Association alone does not guarantee toll-quality audio regardless of SNR. Signal bars are vendor-relative indicators, not a universal absolute dBm meter certified identically on every device. Voice codecs do not ignore RF quality and fail only when DHCP pools are exhausted; poor SNR is a classic cause of one-way audio and drops on municipal voice WLANs.
Exam caveat: for voice, measure RSSI and SNR against design targets—association is necessary but not sufficient. Operational check: survey handset RSSI and SNR at clerk desks and dais positions during a mock session, remediate coverage or interference where margins fail voice thresholds, and retest calls before the next council meeting with results attached to the change record.