A university voice desk hears choppy calls only while the bulk data class is full, and the path view shows loss on that shared hop during the same intervals. What does the evidence indicate?
Select an answer to reveal the explanation.
Short Explanation
A freight convoy and a line of cars cannot share one narrow bridge without someone stopping. Your voice turns bad only while the data class fills the shared hop, and the path view shows loss there at the same time, so you are seeing contention. Blaming a browser, blaming DNS alone, or opening a wireless ticket walks away from the hop the data already names.
Full Explanation
Loss that appears on a shared hop only while the bulk data class is full is path contention: voice and that data class are competing for the same transmission opportunity, and voice degrades when the class occupies the hop. The path view lines up in time with the audio complaints, so the reading stays on that hop rather than on an application the phones are not using. A browser fault on a web page the handsets never open cannot produce this pattern, because the handsets are not fetching that page and the loss is already recorded on the path. Treating DNS as the only cause skips that recorded loss; a bad lookup can block call setup, but it does not place loss on a hop that is busy with the data class. A wireless ticket for an access point the path view does not name sends the team to a radio hop the evidence does not implicate, while the loss sits on the shared path the view does show. Exam caveat: the time match between the full data class and the voice complaint is what makes contention the reading; a full class with a clean path would send the investigation elsewhere. Operational check: lay the path-loss timeline next to data-class use on that hop and confirm the bad voice intervals sit inside the busy ones.