Change:
If the RtpTransceiver has a sendrecv or sendonly direction: <del> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. </del> <ins> For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.  If a MediaStreamTrack is attached to the transceiver's RtpSender, the "a=msid" lines MUST use that track's ID.  If no MediaStreamTrack is attached, a valid ID MUST be generated, in the same way that the implementation generates IDs for local tracks. If no MediaStream is associated with the transceiver, a single "a=msid" line with the special value "-" in place of the MediaStream ID, as specified in I-D.ietf-mmusic-msid, Section 3.  The track ID MUST be selected as described above. </ins> If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more

Discussion:
and Suggesting the same thing as mediacapture-streams, which is to generate UUIDs using the forms in section 4.4 or 4.5 of RFC4122.
About the reference: would it be preferable to reference mediacapture-streams directly, or reference RFC4122 (what I did here)? Also, is there any established ordering scheme for the references?
So two concerns on this ... 1) if multiple things are created with no track, I think it would be better to add them all to the same default track instead of creating separate tracks for them. 2) these are pretty big and there is no need for a globally unique track name. So I wonder if we could solve this by when the track is null setting the MSID to the string "NULL" or "DEFAULT". It seems like if we use the system in 4.5, if an app got a fixed node ID, that would end up in the UUID which might be sent in the clear in RTP SDES headers in some cases. This would allow correlation of different calls as being from the same node by on path attackers which seems to create some other privacy issue. So if we do go with the UUID, I'd rather restrict it to just the section 4.4 UUID and drop the 4.5 version.
Your suggestion to drop 4.5 UUIDs sounds fine to me. As for using the same track ID for multiple "m=" sections: That seems likely to cause problems. This ID is what's used to create the remote MediaStreamTracks when is called, so this means you'd get multiple tracks with the same ID, which may break the assumptions of applications that deal with MediaStreamTracks.
MSIDs (not MIDs) don't appear on the wire IIUC. Right?
I agree the trackID need to all be different - disregard previous comment, I was thinking about a default stream not track.
Hello, I totally agree with you in creating an msid "If no MediaStreamTrack is attached". Actually, we have already implemented this in our stack. Moreover, I would like to say that due to the msid can be generated internally, we should expose a way of getting this msid to can attach metainfo at application level like "The msid XYZ is the front-camera, and the msid TUV is the screen-share".

I propose to add a readonly property in RtpSender that will have the value of the first MediaStreamTrack's msid or the value autogenerated internally as proposed in: URL We also have this implemented in our stack. I hope this can be useful ;) Best!!
Ready for another review. I also noticed that '"a=msid" line' was singular in some places where there may be multiple lines, so I fixed that as well.
On URL o For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same if they are present in the current description. and then in the same section, on URL o For RtpTransceivers that are still present, the "a=msid" line MUST stay the same. This needs to be unified. It might also be a good idea to mention that a=msid stays the same regardless of direction or track changes, and that a=msid can be added if it was not present in the previous description (i.e. because the transceiver was recvonly).