sdp: order simulcast rids by the a=simulcast attribute, not a=rid line order - #3472
Open
StefanoD wants to merge 1 commit into
Open
sdp: order simulcast rids by the a=simulcast attribute, not a=rid line order#3472StefanoD wants to merge 1 commit into
StefanoD wants to merge 1 commit into
Conversation
JoTurk
requested changes
Jul 17, 2026
JoTurk
left a comment
Member
There was a problem hiding this comment.
Thank you, once you fix the parser issue we can merge this.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3472 +/- ##
==========================================
- Coverage 86.18% 86.03% -0.15%
==========================================
Files 81 81
Lines 10442 10456 +14
==========================================
- Hits 8999 8996 -3
- Misses 1007 1021 +14
- Partials 436 439 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
getRids returned the simulcast rids in a=rid line order, consulting a=simulcast only to mark "~" paused streams. RFC 8853 §5.2 says the a=simulcast send list "suggests a proposed order of preference, in decreasing order"; the a=rid line order is not significant. When a peer lists its a=rid lines in a different order than its a=simulcast:send list, the resulting encodings — and the a=simulcast:recv list echoed in the answer — followed the a=rid order instead of the offered preference. Sort the rids by their first position in the a=simulcast attribute (stable, so any rid absent from the attribute keeps its a=rid declaration order at the end). Browsers emit both in the same order, so this is latent in practice, but an SFU or another client may not. Also parse the send list per RFC 8853 §5.1: it is a ";"-separated list of simulcast streams, each a ","-separated list of alternative rids. The previous code split on ";" only, so a value like "send f,h;q" treated "f,h" as one opaque token, breaking both the reorder and the "~" paused detection. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Stefano Di Martino <stefano.d@posteo.de>
StefanoD
force-pushed
the
simulcast-order-by-attribute
branch
from
July 17, 2026 18:02
686a3cd to
145e1e8
Compare
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.
Description
getRidsreturned the simulcast rids ina=ridline order, consultinga=simulcastonly to mark~paused streams. Per RFC 8853 §5.2, thea=simulcastsend list — not thea=ridline order — carries the stream preference:When a peer lists its
a=ridlines in a different order than itsa=simulcast:sendlist, the resultingRTPReceiveParameters.Encodings/Tracks()order — and thea=simulcast:recvlist echoed in the answer — followed thea=ridorder instead of the offered preference.This stable-sorts the rids by their first position in the
a=simulcastattribute; any rid absent from it keeps itsa=riddeclaration order at the end.Latent in practice — browsers (Firefox 152, Chrome) emit both in the same order, and demux is by RID string — so this is a SHOULD-level alignment, not a spec violation: §5.2 "suggests" the order (non-normative), and §5.3.2 only mandates reversing send↔recv (
SHALL) and forbids adding streams (MUST NOT); it does not itself require preserving order.Closes #3471 (full reproduction and impact analysis there).
Test plan
TestGetRIDsOrderFollowsSimulcast: an offer whosea=ridlines are in the opposite order (q,h,f) toa=simulcast:send f;h;q.getRidsreturns[q, h, f]before this change and[f, h, q]after.go build ./...,go vet .,gofmt, andgolangci-lint run(v2.10.1,--new-from-rev=main) are all clean.