Re: The uniqueness of track IDs?

On 10/03/2017 04:28 PM, Taylor Brandstetter wrote:
> 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.

The original purpose of track IDs was to make sure a sender and receiver
could communicate (out of band, or via the datachannel) about which
track was which in the case where several were sent, without having to
dig around in SDP to extract suitable identifiers.

To achieve that purpose, the identifiers have to be a) inspectable, b)
identical on both sides, and c) distinct.

This purpose is of course rendered useless if you use addTransceiver to
generate incoming "dummy" tracks (which have IDs) ahead of time (I don't
think we create IDs for incoming tracks when we do (outgoing) addTrack,
but it's been a few months - spec may have changed), and the decision to
make replaceTrack work without changing IDs also means that we've
rendered the original purpose only achievable in the cases where those
other interfaces are not used.

I think the original purpose is still needed. If we make it impossible
using IDs (by not using the incoming track IDs), I think we need to find
some other way of accomplishing it. (such as allowing retrieval of the
MID of the relevant media section using the incoming track - which of
course only works in Unified Plan).

If the WG decides that the original purpose is not needed, the WG might
want to rip out the "id" concept and the MSID spec altogether.

That's a large change.



>
> On Tue, Oct 3, 2017 at 2:15 AM, Harald Alvestrand
> <harald@alvestrand.no <mailto: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.
>
>
>
>