Stop using the "appdata" field in "a=msid".

[taylor-b]

Fixes #842.

And also w3c/webrtc-pc#1718.

Since introducing transceivers, replaceTrack, early media, etc., the
definition of a MediaStreamTrack has changed and track ID signaling has
become somewhat pointless. In many cases, "sender.track.id" on one side
will not match "receiver.track.id" on the other side; endpoints must use
MIDs or m= section indices or some other means to identify which track
is which.

Thus this PR just removes track ID signaling altogether and the
lingering problems it causes.

[henbos]

Now that we only use the stream ID, "a=msid:{streamId}", I just want to verify that I understand this correctly:

• If I do addTrack(track) without any streams, "a=msid" is completely omitted.
• If I do addTrack(track, stream1, stream2, ...) with multiple streams, I get one "a=msid" line per stream.

Is this correct?

[henbos]

Or is "a=msid" mandatory in which case I would have to do "a=msid:-" in the case of no stream?

[alvestrand]

FWIW, I missed this discussion, and do not agree with the change.
It is a significant, breaking protocol change introduced very late in the process, and has not (AFAIK) been discussed on the mailing list. So by IETF consensus rules, there's no basis for ruling that the change has consensus in the WG.

[henbos]

Before this change, "a=msid" was broken e.g. w3c/webrtc-pc#1718 and w3c/webrtc-pc#2005. The track ID is only surfaced to JavaScript if the answerer does not have any transceivers to match with the offer. Relying on "mid" or MediaStream IDs are clearly the better alternative, because they have a reliable behavior that works not just in edge-cases and are not misleading in all other cases.

An argument can be made for keeping track IDs, but I suspect the argument would be for backwards compatibility reasons or for people who want to parse SDP to figure out ID information (information which, by the way, would have been easier to carry through streams). In either case, JSEP and MSID specs contradict themselves.

As I recall from testing, while Chrome surfaces track IDs in some edge-cases, Firefox does not. If we can survive the switch to Unified Plan without track ID related breakages, as Firefox did, then I see little reason to try to save the sinking ship that is "a=msid". This is a remnant of the track/stream way of thinking.

To be discuss at TPAC. There is a slide for the issues referenced.

[fippo]

a=msid is still relied on to create streams with synchronized tracks -- LS groups haven't made it to any implementation afaik.

[ibc]

AFAIK tracks synchronization in receiver is based in RTCP CNAME rather than msid. msid is just an artifact to tell the app whether different tracks should be grouped within the same MediaStream, but that's just a hint and a unfortunate remnant of the "stream based API" that shouldn't be part of WebRTC itself.

[henbos]

Anyone who is sad to not be able to rely on MediaStreamTrack.id could though, because of "a=msid", do this :)

pc1.addTrack(track, new MediaStream(track.id));
...
pc2.ontrack = e => {
  remoteTrackIdsMap.set(e.track, e.streams[0].id);
}

[juberti]

@henbos a=msid is not mandatory, and can be omitted if there are no streams.

[alvestrand]

discoveries when updating -msid to allow for this:

• omitting a=msid will lead to a default stream (legacy behavior)
• the way to signal that a track is no longer present is by omitting msid after it has been present
• so the only way to signal "one track no stream" is to send a=msid:-
• -msid used to allow for sending one track into multiple recipient streams.With a=msid:- it can no longer do so.

PR is up. alvestrand/rtcweb-msid#17