rtc: deliver each sender only its own RTCP report blocks - #438
Merged
Conversation
Append a verbatim copy of an already-parsed RTCP packet into another compound, so a subset of one compound's packets can be reassembled into a new buffer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The listener routed an incoming compound to the sender owning a reported SSRC but handed it the whole shared compound, so every sender re-parsed it and sifted out its own blocks. Reassemble a fresh compound per target instead: the SR/RR reception report blocks naming one of its SSRCs (re-emitted as an RR that keeps the report sender's SSRC), plus the RTPFB/PSFB packets addressed to it. An XR aggregates per-source blocks and has no builder, so it is copied whole to any sender it names. Closes #426 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #413. The listener routed an incoming RTCP compound to the sender that owns a reported SSRC, but handed it the whole shared compound (
s->cbs.rtcp (s->data, buf, s)), so every sender re-parsed the same buffer and sifted out its own blocks — and saw report blocks and feedback addressed to its siblings.#413 deferred this because delivering only the relevant blocks changes what the sender callback receives.
Decision: keep the
RBuffercontractThe issue asked whether the callback should keep taking an
RBufferor move to a decoded view. I keptRBuffer— it is the least disruptive (the receiver side deliversRBuffertoo), and ther_rtcp_buffer_add_*builders make reassembly straightforward.What
Per target sender, the listener now reassembles a fresh compound containing only what concerns it, and delivers that instead of the shared buffer:
A new
net/rtpprimitive,r_rtcp_buffer_add_packet, appends a verbatim copy of a parsed packet — used for the FB/XR copies (and generally useful for reassembling a subset of a compound).Buffers are built while the source is mapped, then dispatched after unmapping so a callback is free to map the buffer it receives.
Tests
rrtcp/add_packet_copies_verbatim— the new builder round-trips a packet byte-for-byte.rrtc/sender_receives_only_own_report_blocks— a two-block RR (one for the sender, one for an SSRC it does not send) is delivered as a single-block RR carrying only the sender's block, with the report sender's SSRC preserved.Existing
sender_receives_rtcp/sender_receives_xr/sender_receives_bare_xrstill pass under the new delivery. Full suite and ASan tier green; the filtering was verified load-bearing by neutering it (the sender then receives both blocks).🤖 Generated with Claude Code