Validate IDs and labels of remote audio and video tracks

[youennf]

No description provided.

[henbos]

Stream IDs are communicated in SDP and are always accurate.

Track IDs are... a bit of a mess. When you addTransceiver or addTrack it creates the RTCRtpReceiver including its MediaStreamTrack, prior to negotiating, so your remote track ID might not match what the track is on the other side, or you can replaceTrack later or the first time you negotiate maybe sender track is null etc etc.

The track ID being present in SDP is just for backwards compatibility, it's not something you can rely on

[henbos]

IIRC if the receiver was created in response to SDP from the other side and that other side happened to have the track set by the time the m-section was formed for the first time, then the track identifier will probably match, otherwise it will probably not match

[henbos]

It would be less foot-gunny if we never had the track ID match just to avoid people depending on this, but I don't want to change anything that is already de facto standard... ramble ramble. WPTs are good.

[alvestrand]

The WEBRTC spec claims that the track IDs are uncorrelated - this was a result of the discussion around the decision to incorporate ReplaceTrack as a function not requiring a new offer/answer. (The stream IDs are carried over).

The msid spec RFC claims (I think) that the track ID will be set from the MSID attribute - this was locked down as an RFC before we decided to change the way track IDs behaved in the WEBRTC spec, I believe.

[alvestrand]

https://w3c.github.io/webrtc-pc/#rtcrtpreceiver-interface says

Let track be a new MediaStreamTrack object [GETUSERMEDIA]. The source of track is a remote source provided by receiver. Note that the track.id is generated by the user agent and does not map to any track IDs on the remote side.

If the IDs are random, the test will occasionally fail; if the IDs are obeying the older rule, they will collide.
Not sure if the test is appropriate or not.

[youennf]

if the IDs are obeying the older rule, they will collide.

That is what we want to test.
I can remove it from now, or update the test to create 10 connections with the same track ID on the local track and verify that at lease one of the remote track has a different ID.

If the IDs are random, the test will occasionally fail

Most likely, UUIDs will be used, at which point the collisions are very unlikely.
Maybe the spec should say so.

[youennf]

Test updated.

[youennf]

FWIW, the compat issue we identified was related to remote track labels.

We haven't identified a compat issue related to the the track ids, but it seems best to converge there as well.
Only Firefox is implementing IDs correctly at the moment.

[youennf]

As per my reading of the spec, MediaStreamTrack.id isinitialized to a newly generated unique identifier string.
So the past version of the test was correct. I'll file a spec issue to see whether we should clarify this in webrtc-pc.

[youennf]

I filed w3c/webrtc-pc#3084