In the RTCRTPSendParameters.encodings, the description is:
"A sequence containing parameters for RTP encodings of media"
In "getParameters", it says "encodings is populated based on the RIDs present in the current remote description."
Example 15 says:
This seems to indicate that the spec-writers were thinking in terms of "highest resolution first, lowest resolution last". But this is never written down as a rule anywhere. Neither is the idea that order stays consistent between calls.
The issue came up because one lower level implementation had a built-in assumption that lowest resolution would go first and highest resolution would go last - the opposite of this example.
I think we can start by saying "the order stays consistent", since JSEP says that for subsequent offers, "any "a=simulcast" line MUST stay the same."
And "highest resolution first" is written down as a rule... sort of. draft-ietf-mmusic-sdp-simulcast also does "highest resolution first" in its examples, and says:
Later it also talks about congestion control, saying:
Which actually seems backwards, since we want to drop the high quality encoding first... Unless this is meant to imply "prioritize the last stream"? I'm going to ask the authors if they can clarify.
Regardless, the point is that the order in the simulcast attribute does matter.
However, a wrinkle is that JSEP doesn't explicitly say "the order of the RIDS in
@juberti: Can you clarify whether or not JSEP was intended to preserve the ordering? For example, if I use the reverse of the order in the example:
Should the generated SDP be "a=simulcast:send q;h;f", and should the implementation actually pause the low-resolution encoding first when congestion occurs, contrary to how you'd normally want things to work?
I've been talking with the draft-ietf-mmusic-sdp-simulcast authors, and have learned there are situations where you'd want to pause the low-resolution encoding first. When dealing with a mixer that does transcoding, as opposed to an SFU, the mixer can transcode the high-resolution stream into a low-resolution stream for downlink receivers that don't have enough bandwidth.
Also, it sounds like I've been misinterpreting "proposed order of preference", and this is just referring to the "priority" used for congestion control (as described above).
So in conclusion, I think implementations do need to respect the order if we intend to support different usages of simulcast.
In the current specification, order matters in several aspects:
My advice would be to indicate that no particular ordering is required, but to include a note in
Adding a couple cents.