Re: The uniqueness of track IDs?

On 04/10/17 00:36, Taylor Brandstetter wrote:
> 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.

I agree to that MID can fulfill the original purpose, but even /if/ we 
would decide that track ID's are not really needed we would need to 
decide how far we take it, e.g.:

1. We remove Id from tracks all together
2. We keep Id on tracks, but it is always generated locally

(I think so far at least we have assumed that we keep syncing the Id of 
streams, so draft-ietf-mmusic-msid would still be needed to be used.)

I think 1. is out of the question, it would affect mediacapture-main and 
a lot of apps using the Id.

//Stefan

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

Received on Friday, 6 October 2017 09:06:42 UTC