Re: [webrtc-pc] "a=msid" line should contain sender/receiver IDs, not track IDs

> 3.1 Is the same id is reflected on remote end receiver (readonly attribute)?
> 3.2 Is the same id is reflected on remote end track, or would that have a locally generated id?

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 `id` or have an receiver `[IdInternalSlot]` does not matter unless we think there is a risk future changes to the spec might want to replace receiver's track as well. (An internal slot would be more future-proof.)

Or, rather, in accordance with @fippo's jsep quote...

> For RtpTransceivers that are not stopped, the "a=msid" line(s) MUST stay the same if 
> they are present in the current description, regardless of changes to the
> transceiver's direction or track

...the `[IdInternalSlot]` belongs to the transceiver, since in all cases we have both a sender and receiver.


In response to the other options:

> 1. leave things as they are (with a=msid used to carry the track id over to the track created at the remote side)

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 `replaceTrack` or `addTransceiver`.

> 2. redefine so that the id of the remotely created track is generated there (i.e. no correlation with the sender at all). Not clear what we do about a=msid.

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.

GitHub Notification of comment by henbos
Please view or discuss this issue at using your GitHub account

Received on Thursday, 4 January 2018 13:03:45 UTC