-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to handle removing and re-adding remote streams/tracks - possible ID collisions? #1562
Comments
It's pretty clear that we can get ID collisions, and the result in your example would be "y y false". |
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. |
I may have missed something - there is no ID for senders currently in the spec, did we say we would add one? |
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? |
I agree it makes sense to think of things in terms of sender/receiver IDs. Basically, the ID of an |
That is exactly what I'm talking about. So there's the
I'll create a separate issue. |
@henbos please create a PR as well, it will be easier to see what you actually propose in that way! Regarding
as the spec is currently written the last comment should read |
I filed #1718. Closing this one. |
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. |
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?
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.
The text was updated successfully, but these errors were encountered: