Re: The uniqueness of track IDs?

I agree with Taylor that MIDs solve the original purpose.   I am in favor
of just having locally generated track IDs and removing them from signaling
and making the behavior of track IDs consistent.

It doesn't seem like that large of a spec change.  The only downside seems
to be that it may surprise many existing apps, but, as Taylor pointed out,
apps will probably be surprised anyway eventually by one of the cases he
outlined.

On Fri, Oct 6, 2017 at 9:31 AM Taylor Brandstetter <deadbeef@google.com>
wrote:

> I'm not proposing removing the ID from tracks (#1), just from the
> "msid-appdata" field in SDP (#2), since currently the two will mismatch
> most of the time. Maybe some examples would be fitting.
>
> Here are situations where the remote track ID will *not* match the
> msid-appdata field::
>
>    - Creating transceiver, then sending offer.
>       - addTransceiver, createOffer, SLD(offer), SRD(answer)
>    - Adding track, then sending offer.
>       - addTrack, createOffer, SLD(offer), SRD(answer)
>    - Creating offer to receive without sending a track.
>       - createOffer({offerToReceiveAudio: true}), SLD(offer), SRD(answer)
>    - Adding a track, then receiving an offer.
>       - addTrack, SRD(offer), createAnswer, SLD(answer)
>
> Here are situations where they *do* match:
>
>    - Receiving offer, then adding track.
>       - SRD(offer), addTrack, createAnswer, SLD(answer)
>    - Receiving offer without adding any track.
>       - SRD(offer), createAnswer, SLD(answer)
>
> So, given that they won't match most of the time, why make them match
> *any* of the time? It just seems to make things more confusing. A
> developer may get used to the IDs matching, then change something about the
> signaling flow and find they don't match any more, and be surprised. That's
> the motivation for my suggestion.
>
> On Fri, Oct 6, 2017 at 2:06 AM, Stefan Håkansson LK <
> stefan.lk.hakansson@ericsson.com> wrote:
>
>> 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.
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>