Re: [webrtc-pc] order of transceivers, senders/receivers?

The reason for the non-ordering of tracks in streams was a long discussion about how it should work - if I remember rightly, the issue is that if the ordering matters, you have to keep it consistent and stable in the face of reordering.
(For tracks in streams, this matters because tracks on a video element (at least at that time) had ordering, so the mapping would have an observable effect.)
This means that you have to define not only whehter stream.add(a); stream.add(b); stream.add(c) produces (a, b, c) or not, but you have to define whether streaam.add(a); stream.add(b); stream.add(c); stream.remove(b) produces (a, <blank>, c) or (a, c) - and if you re-add b, do you get (a, b, c) or (a, c, b)?
Other ideas included sorting on "id" (consistent, but unpredictable).
In the end we decided to abandon the idea of ordering and leave it implementation-defined.

I don't remember a specific decision to not impose order on other sets, but similar arguments may have applied - or the language may have gotten inherited.

The JSEP text seems to require that a specific piece of data is kept with transceivers - addition order. Transceivers in the SDP (the place where ordering matters) can't be removed, or reordered once they're added to the SDP, so the reordering arguments in MedaCapture don't seem to apply as much.
But given the *way* transceivers are added to the SDP, their order won't necessarily be addition order (they're the same for initial offers, but in answers and subsequent offers, they are assigned to "appropriate" m-sections, not assigned in 1-2-3 order), so the create-time ordering and the media-section ordering won't be consistent with each other.

Any ordering requirement constrains implementation. So I would only want to impose ordering if it is a) well-defined for all cases and b) useful.

Does create-time ordering satisfy those criteria?

GitHub Notification of comment by alvestrand
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 22 November 2017 05:56:35 UTC