DocumentationVoIP and RTP analysis
The VoIP view brings RTP media measurements, stream detail, and available signaling context into one investigation workflow. Use it to identify which captured stream deserves attention before loading detailed jitter or audio.
Start with the quality overview
When RTP streams are available, PacketSafari compares streams using:
- observed packet count
- lost packets and loss percentage
- mean jitter
- source and destination addresses and ports
- payload or codec label when decoded
The quality plot includes streams that have both loss and mean-jitter measurements. Point size reflects observed packet count. PacketSafari bounds the number of plotted streams, prioritizes streams with higher observed loss and jitter, and keeps the selected stream present when possible. The full stream table remains available below the plot.
The overview also states whether all measurable streams are shown. If loss or jitter is missing, PacketSafari keeps the stream table available rather than inventing a value.
Inspect one RTP stream
Select a point or table row to open stream detail:
- exact endpoints, ports, SSRC, and payload type
- packet count, loss, duration, and mean jitter
- detailed jitter, delta, and skew samples when the RTP analysis tap returns them
- waveform and reconstructed audio when supported payload bytes are available
Use View packets to apply the stream's packet filter in the Analyzer. This is the evidence pivot for checking sequence behavior, timing, payload type, and the limits of the captured viewpoint.
Detailed jitter analysis and audio reconstruction are loaded for the selected stream instead of every stream in the capture. A missing chart or unavailable audio does not mean the stream was healthy; it means the required samples or supported payload were not available for that operation.
Connect media and signaling
When SIP signaling context is available, use Open SIP signaling to move to the Telco calls view. There you can compare media symptoms with dialog state, request/response behavior, correlated call issues, and the signaling sequence.
PacketSafari can also surface observed call-manager candidates, dialed numbers, endpoint roles, and call paths when the capture and indexed evidence provide them. Treat inferred roles and normalized numbers as context to verify, not as identity proof.
Decode UDP traffic as RTP
RTP does not always use a standard port. If PacketSafari detects likely high-port UDP media but no RTP streams are decoded, use Decode as RTP and review the resulting streams. Only apply the override when the traffic and case context support that interpretation; decoding arbitrary UDP as RTP can produce misleading output.
Interpret the measurements responsibly
RTP loss and jitter describe the packets observed at the capture point. They do not establish end-user audio quality or fault ownership on their own.
Consider:
- whether the capture sees one or both directions
- packet drops, slicing, timestamp quality, and capture placement
- codec and payload support
- whether loss occurred before or after the capture point
- SIP negotiation and the expected media endpoints
- healthy calls captured from a comparable viewpoint
Use the stream measurements to select evidence, then confirm a material conclusion with packets, signaling, topology, and operational context.