diff options
| author | srdusr <[email protected]> | 2025-11-19 21:18:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2025-11-19 21:18:00 +0200 |
| commit | 2d010c9f851ea4eb851179db012c8977ce6e4bd5 (patch) | |
| tree | 2cf84d9643df0baba62aac1b230c21f09e4872e0 /src | |
| parent | a8f4866576fd70894ef0080c7797708db664880e (diff) | |
| download | packeteer-2d010c9f851ea4eb851179db012c8977ce6e4bd5.tar.gz packeteer-2d010c9f851ea4eb851179db012c8977ce6e4bd5.zip | |
Add RTP/RTCP as a labeled heuristic fallback for unmatched UDP traffic
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.
Diffstat (limited to 'src')
0 files changed, 0 insertions, 0 deletions