A retailer's voice calls are dropped because the voice class is too small, and those drops are already being alerted. What should the recommendation be?
Select an answer to reveal the explanation.
Short Explanation
Giving the noisy room a louder alarm does not make the room bigger. You change quality of service so the voice class can hold the calls that are being dropped at the retailer. Another alert on the same drops, a renamed dashboard, or another test that only records the drops leaves the class too small.
Full Explanation
The drops are already explained: voice is landing in a class that is too small for the branch calls, and an alert already reports those drops. The recommendation that changes the outcome is a quality-of-service change that gives the voice class enough room for the calls being dropped. Adding another alert pages again for the same pain. The retailer can already see the drops, and a second rule does not enlarge the class. Renaming the voice dashboard changes the title on the existing view. The calls still fall out of an undersized class, and a new title is not a configuration change. Collecting the same drop data with a new test, while leaving topology, configuration, and quality of service unchanged, duplicates evidence the team already used to name the class. More samples of the same drops do not carry additional calls. Keep the current alert so the drops stay visible, and hand the network team a class change sized to the voice that is being discarded. Exam caveat: a capacity recommendation has to name the topology, configuration, or quality-of-service change, not a new notification for a known shortage. Operational check: confirm the drops sit in the voice class and that the proposed change enlarges that class rather than only re-alerting the counter.