Re: The uniqueness of track IDs?

Maybe this is a good time to bring up something we didn't get to finish
discussing at the last virtual interim.

*Should MediaStreamTracks ever use the track IDs from SDP?* We're at a
situation right now where they end up unused most of the time. The *only* time
they're actually used is when you set a remote offer *before* calling
addTrack or addTransceiver.

So, it may be more consistent/less surprising if the remote track IDs were
just always randomly generated. Saying "the msid-appdata field is ignored,"
effectively.

Is there any reason not to do this? People were supportive of the idea
<https://www.w3.org/2017/09/13-webrtc-minutes#item01> at the virtual
interim. It would certainly simplify things. And it would mean the
implementation can ensure that every track ID *is* unique, which may be a
useful fact to take advantage of.

On Tue, Oct 3, 2017 at 2:15 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> On 10/03/2017 10:14 AM, Henrik Boström wrote:
> > When setting a remote description containing audio and video tracks
> > with the same ID, what is the expected behavior?
> > Is this OK, and you have two tracks with the same ID, or should it be
> > rejected?
> >
> > I've previously realized IDs aren't unique in the sense that you can
> > add, remove, and then add again with the same ID and end up with
> > multiple track or stream objects with the same ID, but I had thought
> > that amongst streams and tracks currently in-use the IDs would be unique.
> >
> > Should the audio and video track IDs be considered separate domains?
> > Or should I simply make no assumptions about the uniqueness of track IDs?
> >
> > I'm investigating a crash related to audio and video having the same ID.
>
> The behavior must be well-defined, since the IDs in a remote SDP are
> under the control of external parties (= attackers).
>
> The choices are:
>
> - Permit non-unique IDs
>
> - Reject the SDP
>
> I think we at one point permitted non-unique IDs because of the
> following scenario:
>
> (A connects to B)
>
> A: pcB.addTrack(track)
>
> (negotiation happens)
>
> B: -> pcB.onTrack(track) => { pcB.addTrack(track) }  // Loopback
>
> (negotiation happens)
>
> At the time, we thought A needed to see the track, even though he's
> already got a track with that ID.
>
> I don't know if this is still the case.
>
>
>
>