Skip to content

rtc: deliver each sender only its own RTCP report blocks - #438

Merged
haaspors merged 2 commits into
masterfrom
rtcp-per-sender-blocks
Aug 3, 2026
Merged

rtc: deliver each sender only its own RTCP report blocks#438
haaspors merged 2 commits into
masterfrom
rtcp-per-sender-blocks

Conversation

@haaspors

@haaspors haaspors commented Aug 3, 2026

Copy link
Copy Markdown
Owner

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 RBuffer contract

The issue asked whether the callback should keep taking an RBuffer or move to a decoded view. I kept RBuffer — it is the least disruptive (the receiver side delivers RBuffer too), and the r_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:

  • SR/RR — the reception report blocks naming one of the sender's SSRCs, re-emitted as an RR that preserves the report sender's SSRC. (An SR's sender-info describes the remote and is receiver-relevant, so the sender gets an RR.)
  • RTPFB/PSFB — copied to the one sender its media SSRC names.
  • XR — aggregates per-source blocks and has no write builder, so it is copied whole to any sender it names (a small over-share limited to co-located senders on the same transport; noted rather than papered over).

A new net/rtp primitive, 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_xr still 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

haaspors and others added 2 commits August 3, 2026 10:57
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>
@haaspors
haaspors merged commit e5504f6 into master Aug 3, 2026
18 checks passed
@haaspors
haaspors deleted the rtcp-per-sender-blocks branch August 3, 2026 09:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant