Packet capture and analysis, TUI and desktop GUI. https://srdusr.com/git/packeteer/atom?h=main 2025-11-19T19:18:00+00:00 2025-11-19T19:18:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2025-11-19T19:18:00+00:00 urn:sha1:2d010c9f851ea4eb851179db012c8977ce6e4bd5 Architecturally different from every other protocol added so far: RTP has no fixed well-known port at all - it's negotiated per call via SDP/SIP/WebRTC signaling this project doesn't parse - so L7Registry's port-keyed dispatch doesn't apply. Handled instead as a fallback tried only when a UDP packet's normal port-based lookup finds nothing, with every match labeled "?" (e.g. "RTCP? SR") to mark it as inferred from packet shape rather than certain - the same honesty Wireshark itself applies to heuristic dissection, which is off by default there for exactly this reason. The two heuristics aren't equally trusted, and the code says so: RTCP checks a narrow packet-type range (200-204) plus an exact self-declared length, both unlikely to occur by chance; RTP leans mostly on the 2-bit version field, since its other structural checks are trivially satisfied whenever those bits happen to be zero, the common case even for unrelated traffic. Shipped anyway - a labeled guess on real RTP/RTCP traffic is more useful than silence - but this is the first place in the project where a match doesn't mean certainty. Live-verified against genuine media traffic: ffmpeg streaming a real RTP video test pattern to loopback, correctly decoded with incrementing sequence numbers and a consistent SSRC across the stream, plus a real RTCP Sender Report ffmpeg sent alongside it.