How to handle removing and re-adding remote streams/tracks - possible ID collisions?

[henbos]

Let's say you do this... (see code snippet) Will we end up with the same stream and track objects as after the first SRD call or will we end up with new stream and track objects that have the same ID as the original ones?

var initialTrack;
pc.ontrack = function(e) {
  console.log(e.track.id);
  initialTrack = e.track;
}
pc.setRemoteDescription() such that stream x with track y is added
pc.setRemoteDescription() such that stream x with track y is removed
pc.ontrack = function(e) {
  console.log(e.track.id);
  console.log(e.track == initialTrack);
}
pc.setRemoteDescription() such that stream x with track y is added

Should the log be "y y true" or "y y false"?

The processing of the addition/removal of remote tracks says "For each MSID in msids, unless a MediaStream object has previously been created with that id for this connection, create a MediaStream object with that id." This would suggest we reuse streams, but the context here is adding and removing streams from the pc, it's unclear if this should apply to streams created in the past that no longer are part of the pc.

As for the tracks, step 8.2. of setting a session description describes trying to reuse existing inactive transceivers but if it doesn't find a transceiver, creating a new transceiver means creating a new track with the given ID. Are transceivers guaranteed to be reused such that we get no ID collision?

In any case with multiple RTCPeerConnection objects we could end up with streams and tracks that have colliding IDs with streams and tracks created by other PCs. I suspect this could lead to behavior where multiple stream/track objects behave as if they are the same by APIs looking at their IDs but they could have different states.

[stefhak]

It's pretty clear that we can get ID collisions, and the result in your example would be "y y false".
There is also a discussion on not signaling the (or not use the signaled) track ID, but instead generate local IDs - if adopted we could ensure there is no collision.

[henbos]

I agree. Feel free to close this or clarify processing the addition/removal of remote tracks.

Related question: How should IDs of senders be generated? I believe Chrome uses the track ID which will become problematic when senders and tracks are decoupled.

[stefhak]

Related question: How should IDs of senders be generated?

I may have missed something - there is no ID for senders currently in the spec, did we say we would add one?

[henbos]

Caveat: I'm no expert on SDP, but...

I'm talking about a=msid "track IDs", but considering replaceTrack(), these IDs no longer necessarily correspond to the remote endpoint's MediaStreamTrack.id, and it's possible to send the same track multiple times - the announced IDs have to be unique to the sender/receiver(/receiver's track).

As of now, it makes more sense to think of these as sender/receiver IDs, and it does not make sense to use the ID of whatever track was used when the sender was first announced, as this may lead to multiple "tracks" having the same ID even within a single blob of SDP.

But perhaps I'm speaking out of turn, care to weigh in @taylor-b?

[taylor-b]

I agree it makes sense to think of things in terms of sender/receiver IDs. Basically, the ID of an RTCRtpReceiver's track corresponds to a single RTCRtpSender on the other side. Which may have been created by addTransceiver, in which case it may not even have a track in the first offer/answer cycle. And some ID (the "sender ID") needs to be generated, to put in the "a=msid" line. I believe that's what @henbos is talking about.

[henbos]

That is exactly what I'm talking about.

So there's the addTransceiver case where you start with a null track but you still have to negotiate for a receiver to be created at the other end. There's also this case:

senderA = pc.addTrack(track);  // a=msid with track.id
O/A
senderA.replaceTrack(null or something else);
senderB = pc.addTrack(track);  // a=msid with...?

I'll create a separate issue.

[stefhak]

@henbos please create a PR as well, it will be easier to see what you actually propose in that way!

Regarding

senderA = pc.addTrack(track);  // a=msid with track.id
O/A
senderA.replaceTrack(null or something else);
senderB = pc.addTrack(track);  // a=msid with...?

as the spec is currently written the last comment should read // a=msid with track.id. This may be changed though as part of the discussion to always generate new track id's at the receiving end.

[henbos]

I filed #1718. Closing this one.

[mdjamilaj]

It is possible for the same track to belong to multiple streams by providing multiple streams to addTrack(), on the remote end a receiver is created with a track, and that track is added to all corresponding streams.

In the case of multiple senders the remote end gets multiple receivers and tracks, even if the senders all send the same track, so each sender describes a unique track-stream relationship for the receiver side.

I think this is as it should be and tangential to this discussion about ensuring transceivers have unique IDs.