Re: The uniqueness of track IDs?

Den 12. okt. 2017 18:15, skrev Peter Thatcher:
> 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.

We can probably figure out who looks at the IDs using an use counter.
It's not that it may surprise existing apps, it's that it will break
them if we use it for its intended purpose.

I wonder if the right approach is to add "id" as a constructor parameter
(so that a non-privilleged process such as an SDP shim written on top of
ORTC can set them if they feel like it), and make everything else in the
system ignore the "id". Just like datachannel's "label".

Then the only backwards compatibility misfeature is the little piece of
code that smacks ID into msid and vice versa.


> 
> On Fri, Oct 6, 2017 at 9:31 AM Taylor Brandstetter <deadbeef@google.com
> <mailto: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.
>           o addTransceiver, createOffer, SLD(offer), SRD(answer)
>       * Adding track, then sending offer.
>           o addTrack, createOffer, SLD(offer), SRD(answer)
>       * Creating offer to receive without sending a track.
>           o createOffer({offerToReceiveAudio: true}), SLD(offer),
>             SRD(answer)
>       * Adding a track, then receiving an offer.
>           o addTrack, SRD(offer), createAnswer, SLD(answer)
> 
>     Here are situations where they /do/ match:
> 
>       * Receiving offer, then adding track.
>           o SRD(offer), addTrack, createAnswer, SLD(answer)
>       * Receiving offer without adding any track.
>           o 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
>     <mailto: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>
>         > <mailto: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>
>         >>     <mailto: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 Thursday, 12 October 2017 16:27:07 UTC