Re: The uniqueness of track IDs?

The original purpose is now fulfilled by the MID, which *is* readily
accessible. The track event includes the transceiver, which has the MID as
an attribute.

True, it only works in Unified Plan, but the rest of the API is also
designed around Unified Plan, and hopefully Chrome will be there soon
enough.

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

> 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>
> 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.
>>
>>
>>
>>
>
>