-
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
"a=msid" line should contain sender/receiver IDs, not track IDs #1718
Comments
If this seem to make sense to you I can create a PR. |
if you give up the notion of putting the track ids into the sdp even for the most simple cases that do not use replaceTrack at all then you can just rely on the transceiver.mid so the track.id would be something like
|
I think we have a few options in this domain (track/sender/receiver
Remember that I'm somewhat afraid of what ramifications a change would have (thinking about JSEP, msid I-D). |
jsep says this about subsequent offers:
Does the id (which is either the initial track id or a randomly generated one) need to be stored in an internal slot? |
The receiver always has a track, which never changes, so whether we store this ID (same as other endpoint's sender ID, i.e. the "a=msid" line) as the receiver's track's Or, rather, in accordance with @fippo's jsep quote...
...the In response to the other options:
This does not work. In the examples I gave above this would create multiple "a=msid" lines with the same ID or undefined behavior for addTransceiver() with null track. For backwards-compatibility reason, any option we do choose can default to use the track ID as the transceiver ID iff it has not already been used, and generate a new one otherwise. This would not break apps that make assumptions about track IDs that never do
I think it is worth discussing whether the receiver's track ID should match the "a=msid" line or not, but it is clear according to the above jsep quote that it has to correlate to a transceiver. |
(I need to read up on this.) |
This will end up on a different m-line / transceiver.
http://rtcweb-wg.github.io/jsep/#rfc.section.5.2.1 -- If no MediaStreamTrack is attached, a valid ID MUST be generated, in the same way that the implementation generates IDs for local tracks. |
OK cool. Then the only problem is this:
There is no clause for what if the track's ID is already in used by another transceiver (due to replaceTrack or addTransceiver). In that case we must generate an ID too. |
Is something forbidding the use of the track's id? It would be a duplicate, sure, but I'm not sure that's a problem. |
@stefhak good question. ontrack has the transceiver set so one can differentiate. But it gets confusing and will break current assumptions about ontrack |
See also #1702. |
Waiting for action on rtcweb-wg/jsep#842 |
Related question: Why does the ontrack event come with a
If the sender and receive In the other side, I don't understand why we need the |
Actually, the sending side can create a number of (possibly) empty MediaStreams ( |
I meant assuming we no longer generate remote |
But still, |
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. |
If multiple transceivers have the same ID, how would you know which one of them are changing direction, parameters, etc, in a follow-up O/A cycle? |
I think I missed the use case for This WebRTC dependency on the |
You'd typically identify transceivers by their order, or their MID, not the track ID value. So I don't think it's a problem personally. |
I personally don't like order very much for readability but as long as you never remove a transceiver from any future offer it would work. I don't want to bikeshed. |
MID is just an unique identified per m= section:
|
#1567 was merged and reverted at one time? |
I think the resolution was basically "this is a band-aid solution for backwards compatibility, and you can work around it by just parsing SDP, so it's not worth doing". |
Is the conclusion "we don't care about duplicate track IDs or changing them to be sender/receiver IDs because we already have MIDs which is unique per transceiver"? |
track id will go away: 👏 @juberti |
Fixes rtcweb-wg#842. And also w3c/webrtc-pc#1718. Since introducing transceivers, replaceTrack, early media, etc., the definition of a MediaStreamTrack has changed and track ID signaling has become somewhat pointless. In many cases, "sender.track.id" on one side will not match "receiver.track.id" on the other side; endpoints must use MIDs or m= section indices or some other means to identify which track is which. Thus this PR just removes track ID signaling altogether and the lingering problems it causes.
What happened to this? I see the JSEP PR was never merged |
@henbos Let's recap the situation at TPAC 2018 and figure out the next steps. |
With the JSEP PR closed and transceiver already having an ID that does match on both endpoints ("mid") I'm closing this issue. If there are any follow-up discussions let's have them in #2005. |
Traditionally "a=msid" lines indicate tracks and streams by track IDs. With RTP Media API, including
addTransceiver
andreplaceTrack
, it makes more sense to think of these as sender/receiver IDs.On the receiving side, an
RTCRtpReceiver
will be created whose track has the announced ID, and it's receiving media from anRTCRtpSender
on the other side. But the sender canreplaceTrack
, there is no guarantee thatMediaStreamTrack
IDs match on local and remote sides.Traditional case:
pc.addTrack(track); // a=msid with track.id
Here, the local and remote side will get
MediaStreamTrack
s whoseid
match.But what about this?
Or this?
pc.addTransceiver('video'); // track is null by default, a=msid with...?
Proposal: When an
RTCRtpSender
is created we should assign it a unique ID and use that for the "a=msid" line. The onlyMediaStreamTrack.id
we can guarantee something about is the one used by anRTCRtpReceiver
- the receiver and its track can share ID.The text was updated successfully, but these errors were encountered: