Find RTP streams and interpret loss and jitter

Identify the correct stream and direction

Use the final SDP offer and answer plus Wireshark's RTP Streams view to find the relevant addresses, ports, payload mapping and SSRC. Analyze each direction independently. A relaying PBX or SBC can expose separate streams on each call leg with different addresses, sequence spaces, SSRC values, codecs and timing.

If signaling is missing, heuristic decoding or Decode As may identify RTP, but verify the result against the expected endpoints and payload mapping. Do not classify arbitrary UDP as voice merely because its port falls inside a common media range.

Separate sequence evidence from loss claims

RTP sequence numbers normally increment per data packet and can expose gaps, reordering or duplicates. A gap in one trace is not automatically network loss: inspect capture-drop counters, mirror duplication, path visibility, SSRC changes and source restarts. Compare the same synchronized interval at another point or with receiver counters before assigning the gap to a network segment. RTP itself does not reserve resources or guarantee quality of service.

Read jitter and timing in scope

RFC 3550 interarrival jitter estimates variation in relative transit time using the RTP media clock. It is not one-way network delay, round-trip time, playout-buffer depth, mouth-to-ear delay or a universal quality score. RTP timestamps represent media sampling time rather than wall-clock arrival time. Packet-delay variation metrics also depend on the selected reference and observation points, so record the tool, stream, direction and interval with every value.

Inspect bursts, reports and receiver behavior

Whole-call averages can hide a short burst that clips several words. Align the user's complaint with the RTP Stream Analysis graph or interval, then compare packet spacing, gaps, reordering and payload changes. RTCP reception reports, when present, provide receiver-reported loss and jitter for their reporting scope; they do not prove what another receiver heard. Wireshark playback can help with authorized, decodable media, but its decoder and jitter-buffer behavior need not reproduce the endpoint's actual playout.

Corroborate and preserve the boundary

Compare sender-side and receiver-side evidence, RTCP reports, interface counters and endpoint statistics over the same interval. If a packet exists before a firewall but not after it, confirm that both capture points cover the same forwarding path and did not drop mirrored copies.

SRTP is not automatically playable from a packet file. Do not weaken production encryption merely to make an analysis tool's audio control work. A clean stream at one observation point does not establish the next leg, endpoint decode, playout or microphone behavior. Collect and share sensitive audio only when necessary, authorized and access-controlled.

Correlate RTP five-tuples with Asterisk PJSIP address controls

For Asterisk, the wrong-media-address diagnostic compares final SDP, loaded endpoint and transport values, Asterisk's packet source and the peer's observed source before selecting a NAT control.

Correlate Rove handover evidence with RTP

The Rove B4 roaming diagnostic identifies the exact cell transition and SIP dialog before RTP analysis. A radio or synchronization event and a media-path divergence need matching timestamps before either is named causal.

Compare packet evidence with Asterisk channel statistics

The Asterisk RTCP guide distinguishes local received-stream observations, peer-reported outgoing evidence and intervals where direct media can bypass the PBX.

Compare Asterisk runtime addresses with observed packets

The Asterisk RTP diagnostic aligns channel src, dest and direct values with the current SDP exchange and capture interface.

Correlate packet arrival with the effective buffer

The Asterisk choppy-audio diagnostic compares capture timing with channel-scoped RTP and RTCP evidence, buffer placement and decoded audio.

Prove received media on the channel that is waiting

The silence and noise diagnostic keeps RTP arrival, channel frames, DSP classification and downstream dialplan outcome as separate observations.

Bind VoIPstudio RTP evidence to the selected desktop devices

When VoIPstudio Desktop is online but audio fails, the provider-specific diagnostic correlates SDP and packet direction with the client’s distinct microphone and call-output selections. Packets on the host still do not prove application decoding or audible output.

Do not infer SIPTRUNK RTP sources from signaling gateways

The SIPTRUNK guide requires actual SDP and packet evidence for the direct-media path.