Change:
If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to <del> zero and the "a=msid" line removed. </del> <ins> zero and all "a=msid" lines removed. </ins> <del> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same if they are present in the current description. </del> <ins> 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.  If no "a=msid" line is present in the current description, "a=msid" line(s) MUST be generated according to the same rules as for an initial offer. </ins> Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as

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).