Regarding "a=msid"

[henbos]

JSEP Section 5.2.1 and 5.2.2 says:

• For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section 2. If a MediaStreamTrack is attached to the transceiver's RtpSender, the "a=msid" lines MUST use that track's ID. If no MediaStreamTrack is attached, a valid ID MUST be generated, in the same way that the implementation generates IDs for local tracks.
• If no MediaStream is associated with the transceiver, a single "a=msid" line with the special value "-" in place of the MediaStream ID, as specified in [I-D.ietf-mmusic-msid], Section 3. The track ID MUST be selected as described above.

MSID Section 2 says:

There may be multiple msid attributes in a single media description. This represents the case where a single MediaStreamTrack is present in multiple MediaStreams; the value of "msid-appdata" MUST be identical for all occurences.

Multiple media descriptions with the same value for msid-id and msid-appdata are not permitted.

It sounds to me that the following, while clearly intended to be permitted, is not permitted:

pc.addTransceiver(track);
pc.addTransceiver(track);

Because one spec says we MUST use the track's ID and stream ID "-" for both "a=msid" lines and the other say having two identical "a=msid" lines is not permitted.

What both Chrome and Firefox does is the second track will get a random "a=msid" value. Doesn't this go against the spec? @jan-ivar
On the other hand, if you supply media streams the combination is no longer unique, and the following would allow you to reuse the track ID:

pc.addTransceiver(track, {streams:[new MediaStream()]});
pc.addTransceiver(track, {streams:[new MediaStream()]});

Because it would show up in SDP as "a track belonging to multiple streams". However current implementations (at least Chrome?) still generate a new ID.

Proposals

1. Clarify JSEP or MSID specs to generate if already listed or permit duplicates.
2. Clarify webrtc-pc to say that if the track ID has already been listed, generate a random one.
3. Clarify webrtc-pc to say that duplicates are permitted, but that goes against MSIDs.
4. Stop supporting "a=msid", it only adds confusing, the 1.0 way is to rely on "transceiver.mid", not track IDs.

For related bug info, including code snippet to test this, see https://crbug.com/894231.

[fippo]

didn't we conclude that track ids are meaningless? This seems to be blocked on rtcweb-wg/jsep#842

transceiver.mid still doesn't allow defining a stream relationship between different mediasections?

[henbos]

addTrack says the MSID of the track added will be listed in future offers/answers. Other than that I think MSIDs are only used to signal MediaStream IDs as far as webrtc-pc is concerned. No calls to "Create an RTCRtpReceiver" actually pass an ID as an argument, meaning they MUST all be randomly generated and if any browser uses "a=msid" to be nice for backwards compatibility they're doing it wrong.

Edit: Sorry, "from the media description" probably means to pass the ID.

[henbos]

The remote track survives removeTrack. Its id will match MSID only ~25% of the time. Why signal MSID?

Maybe even 0% of the time unless we update the spec :)

[ibc]

Why do we need MediaStreams and msid at all?

[shampson]

I like option 1. or 2. here. We need "a=msid ..." lines to signal that a given sender/track is associated with a given MediaStream ID.

No calls to "Create an RTCRtpReceiver" actually pass an ID as an argument
Do you mean a track ID or stream ID? It seems to me that we can't currently rely on track ID, but the stream ID can still be useful. Is that correct? In that case I would prefer to either allow duplicates or just generate a random track ID if there is a duplicate (as opposed to generating a random stream ID).

Do we know why duplicates aren't allowed?

[steveanton]

Yes, they decided in JSEP to remove the track ID from a=msid. There's even a pull request to change the language, but it doesn't appear that anyone has looked at it yet: rtcweb-wg/jsep#850

[henbos]

We could remove it or we could allow duplicates. ("Do we know why duplicates aren't allowed?" I personally don't.)

Why do we need MediaStreams and msid at all?

I was tempted to say that we don't, but I'm curious if this is still useful in order to signal which track is which without mapping mids.

Track IDs are no longer guaranteed to match, but stream IDs are. Associating a track with a stream is a way to carry information about which track is which inside of the SDP, at the same point in time as you previously would have cared about track IDs.

Using MIDs on the other hand requires SLD/SRD to have been performed. With streams you'd know the ID right there before the answer.

I have heard developers confused and frustrated about not being able to rely on track IDs anymore. Though I don't understand why they have a problem with simply using the MIDs... someone was creating a bunch of dummy transceivers because they didn't know how many tracks would be carried in the answer but thought they needed the MIDs before that or something?

[henbos]

Related issue: #1718

[juberti]

We are working on landing the PR in jsep - there wasn't an opportunity to do so before because the doc had gone past Last Call, but now are updating the doc again and can take this PR.

[henbos]

The JSEP PR has merged; track IDs are no longer signaled with "a=msid", only stream IDs.

[henbos]

The decision on TPAC was to "Stop saying anything about track.id mapping".

From what I can find, we mention track IDs in these places:

• addTrack: "... and add the MSID of the track added ...", this should probably say "of the streams added" instead since that is the only thing signaled with MSID.
• replaceTrack: "To avoid track identifiers changing on the remote receiving end when a track is replaced, the sender MUST retain the original track identifier and stream associations and use these in subsequent negotiations."
• NOTE under 5. RTP Media API: "... whether the IDs end up matching depends on the relative ordering of calls to addTrack, addTransceiver and setRemoteDescription, and which side generates the offer ..." and so on (it says more).
• setRemoteDescription: "Create an RTCRtpReceiver, receiver, from the media description." where in create an RTCRtpReceiver: "If an id string, id, was given as input to this algorithm, initialize track.id to id. (Otherwise the value generated when track was created will be used.)"

JSEP has been updated not to signal track IDs, which means "from media description" would not involve a track ID. But what if you're communicating with an endpoint that does signal the track ID? We'll have to either say "use that track ID if it is not already in-use" if we want to avoid duplicate IDs, or remove the track ID from the creation steps such that it is always random no matter what was signaled.

[henbos]

OK, JSEP says when parsing m= sections:

If present, "a=msid" attributes MUST be parsed as specified in [I-D.ietf-mmusic-msid], Section 3.2, and their values stored, ignoring any "appdata" field.

So track ID is always ignored even from remote SDP, so track ID is always N/A.