Client-side .pcap / .pcapng packet inspector — no upload, no server, no backend.
if_tsresol option isn't parsed yet). No TCP stream reassembly /
"follow stream", no TLS decryption, and no attempt at the hundreds of other application-layer dissectors
real Wireshark ships — this is a lightweight reader, not a Wireshark replacement. Very large captures
(hundreds of MB) may be slow since the whole file is parsed in memory; the packet list also caps rendering
at 2000 rows at a time — use the filter to narrow down.
a=rtpmap, RFC3551 statics as fallback). RTP is identified either by matching a
SDP-declared endpoint (reliable) or, if the capture starts mid-call with no signaling, by a conservative
content heuristic (RTP version bits + zero CSRC count + a plausible payload type — shown as
"unassociated" in the stream table, since there's no SDP to back the match). Only audio SDP media
(m=audio) is parsed — video RTP is not analyzed. RTCP dissection reads only the first
reception-report block of a Sender/Receiver Report (conference calls with multiple report blocks per
packet only get the first one). Jitter (RFC3550) and loss/out-of-order are computed from captured packets
directly; the RTCP-reported figures shown alongside are the endpoint's own self-reported numbers, for
cross-checking, not the primary measurement. The MOS estimate is illustrative — a single-point
capture can't measure true one-way network latency without clock-synced endpoints, so a fixed 80 ms
assumption stands in for it (see the caveat next to the stream table). No RTP audio decode/playback and
no TLS-encrypted SIP (SIPS) support — signaling has to be visible in the capture to correlate media.