Name the transition that breaks audio
Start with the event immediately before sound disappears: hold, resume, transfer, a long idle period, a network change or a call to a particular destination. Record which person can still hear whom. “Intermittent audio” is too broad to choose a useful capture.
Collect a short successful example and a failing example using the same endpoints where possible. Keep the call direction, codec, access network and trunk constant so the comparison answers one question.
Paired observations help locate a change or loss. Account for clock offset, NAT and capture drops before attributing a difference to the network.
Compare the negotiated media before and after
Inspect the complete offer/answer exchange around the transition. SDP can change an address, port or stream direction during a session. Compare the active audio stream before the change with the accepted parameters afterward, including any hold or resume direction.
If a PBX creates separate call legs, examine each leg independently. The destination seen by the phone does not have to be the destination seen by the carrier. Match each packet stream to the SDP negotiated for that leg.
Find the first boundary that loses packets
Use authorized captures at both sides of the suspected boundary. Determine whether the sender changed its destination and whether packets reached the next receiver. If audio disappears only after idle time, correlate the failure with transport or firewall state rather than assuming the codec became incompatible.
If packets arrive at the correct endpoint but are not played, investigate decoding, encryption, stream selection and the audio device. An arrival trace narrows the fault but does not prove the user heard the media.
Retest the exact failing action
Correct only the unsupported address, policy or endpoint behavior supported by the evidence. On managed FreePBX systems, use the configuration controls that own the generated settings. Preserve a way to restore the previous state.
Repeat the same hold/resume or transfer action, then test the ordinary call path and a sufficiently long idle interval. A fresh call immediately after a restart is a weak acceptance test for an issue that only appeared later. Save the paired observations and the successful transition in the incident record.
Watch the explanation
Explains how the problem determines where to capture, including switch mirroring and paired client/server observations. A useful first step before collecting a VoIP trace.
Read applicability and editorial notes →Watch this video here
Recorded in 2021; capture-placement principles remain useful. Exact operating-system and switch controls vary. Review used the available transcript and primary references; audio and screen readability remain unverified.
The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.
Compares an intact RTP capture with a copy containing deliberately removed packets. The stream list and detailed analysis show how gaps become loss indicators and how burst patterns differ from scattered loss.
Read applicability and editorial notes →Watch this video here
A 2024 Wireshark demonstration; menu placement can change. The second capture is a teaching fixture with simulated loss. Review used the available transcript and primary references; audio and screen readability remain unverified.
The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3264: modifying the negotiated session ↗
- Wireshark: RTP stream identification and analysis ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.