W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2017

Re: The uniqueness of track IDs?

From: Taylor Brandstetter <deadbeef@google.com>
Date: Tue, 3 Oct 2017 07:28:53 -0700
Message-ID: <CAK35n0YXCnG6JcYNPM9Bgr8mQLjkuzJKLXR48+rqi8zSzV1Akw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Henrik Boström <hbos@google.com>, WebRTC WG <public-webrtc@w3.org>
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,"

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>

> 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.
Received on Tuesday, 3 October 2017 14:29:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:52 UTC