RTCRtpReceiver.track needs to be nullable

[adam-be]

What else can it be when a call to RTCPeerConnection.addTrack creates a new RTCRtpTransceiver object?

[taylor-b]

I thought RtpReceivers would always have tracks, even when created through addTransceiver/addTrack. That's what allows an application to connect a track to a

[adam-be]

The spec is rather unclear about this to say the least. :)

Already having a track in that case would prevent the remote side from, e.g, setting the id of the track. Currently the spec describes that procedure here [1].

[1] https://w3c.github.io/webrtc-pc/#dispatch-receiver

[taylor-b]

If I recall correctly, this was brought up at TPAC, and people seemed ok with the ID being randomly generated in this situation. Of course, if the transceiver is created as a result of setRemoteDescription, the track's ID could be populated from "a=msid". I can't find this discussion in the minutes, however, so I guess we should have it again.

Also, I think the section of the spec referenced is somewhat incomplete. For example, one step is "Fire an event named track with transceiver" but it doesn't explain where that transceiver comes from, or what happens if it's an existing transceiver with a sender/receiver.

[adam-be]

What's the benefit of creating the receiver track when we don't have any information from the remote peer? In our "p2p with warm-up" example we render as a result of the "track" event.

Regarding the alien transceiver in the dispatch-reciver steps, I've created an issue for it: #563

[taylor-b]

It's not the "p2p with warm-up" example that this relates to; it's the "media before signaling" example.

The sample code includes:

var audioSender = pc.addTrack(stream.getAudioTracks()[0], stream);
remoteStream.addTrack(findReceiver(audioSender.mid).track);

The example expects addTrack to create a transceiver with a receiver, and expects that receiver to have a track.

[adam-be]

I see. I assume the track will be muted initially. And in the "media before signaling" case, the track will be unmuted before the "track" event.

It's a bit unfortunate that we will get a random track id every time a transceiver is created by addTrack even if the app is prepared to wait for the "track" event. It would be great to isolate the non-ideal behaviour to the special case where it's required.

Can't we have a null track id and update it as part of firing the "track" event? That way an app waiting for the "track" event would never have to deal with a random (or null) track id.

[taylor-b]

I don't think you could attach a track with a null id to a media element. Maybe the id could be null until you try to read it? A Schrodinger's track. :)

I don't see that a random track id causes any fundamental issues, though. If an application is signaling the track id along with some metadata, in order to help the peer identify the track, it can just switch to signaling the "mid" instead.

[stefhak]

I have not heard of that a track with a null id can't be attached to a media element, so perhaps there is no need for Schrodinger's track, at least not for that reason :)

[adam-be]

I think the track source, that needs to be synchronously created and usable right away, is a bigger implementation challenge than the null track id. :)

I'm thinking about how to document the track id for developers. It will be hard to use the track id in a meaningful way when it's not easy to tell if the value is just randomly generated or actually reflects what the other peer has.

[adam-be]

Let's close this issue and file a new one about how the receiver.track id should work. Thanks for your comments @taylor-b

[alvestrand]

Closing issue; Adam will take the issues raised forward.