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.

1 files changed, 27 insertions, 2 deletions

diff --git a/PLAN.md b/PLAN.md
index 50d4981..a4db288 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -31,8 +31,9 @@ unowned buffers) via a real-world capture pipeline.
 4. [done] Bounded channel + drop-on-backpressure between capture and render
 5. [in progress] L7 dissector interface, add protocols incrementally --
    interface + DNS + HTTP + TLS SNI + mDNS + SSH banner + NTP + DHCP +
-   FTP + SMTP + TFTP + QUIC + SNMP done (packeteer/l7/); ARP/VLAN/IGMP done
-   at the L2/L3 level too (packeteer/net/); more protocols can still
+   FTP + SMTP + TFTP + QUIC + SNMP done (packeteer/l7/); ARP/VLAN/IGMP
+   done at the L2/L3 level too, and RTP/RTCP as a heuristic UDP
+   fallback (packeteer/net/); more protocols can still
    be added incrementally,
    by design
 6. [done] Filtering (-f <expr>, libpcap's own BPF compiler - see Decisions)
@@ -562,3 +563,27 @@ None currently open.
   correctly with matching request-ids across both directions, and a
   real `snmptrap` SNMPv2-Trap on port 162 confirmed the second
   registered port actually gets used, not just the first.
+- RTP/RTCP (net/rtp.hpp, net/rtcp.hpp) - architecturally different
+  from every other L7 protocol here: 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 simply
+  doesn't apply. Handled instead as a heuristic fallback tried only
+  when a UDP packet's normal port-based lookup finds nothing, and
+  every match is labeled with a "?" (e.g. "RTCP? SR") to mark it as
+  inferred from packet shape, not certain the way a port-matched
+  dissector's result is - the same honesty Wireshark itself applies
+  to heuristic dissection (off by default there for exactly this
+  reason). The two heuristics are deliberately not equally trusted:
+  RTCP's is comparatively strong (packet type in a narrow 200-204
+  range unlikely by chance, plus an exact self-declared length field);
+  RTP's leans mostly on the 2-bit version field being 2, since CSRC
+  count/extension/padding consistency checks are trivially satisfied
+  whenever those bits are zero - the common case even for unrelated
+  traffic. Both still ship, since a labeled guess on real RTP/RTCP
+  traffic is more useful than silence, but this is the first place in
+  the project where "matched" doesn't mean "certain."
+  Live-verified against genuine media traffic: `ffmpeg -f lavfi -i
+  testsrc ... -f rtp rtp://127.0.0.1:5004`, captured on loopback,
+  correctly decoded a real RTP video stream (payload type 96,
+  incrementing sequence numbers, one consistent SSRC across the whole
+  stream) and a real RTCP Sender Report ffmpeg sent alongside it.