diff options
Diffstat (limited to 'PLAN.md')
| -rw-r--r-- | PLAN.md | 29 |
1 files changed, 27 insertions, 2 deletions
@@ -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. |