Original text:
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>  If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more 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>  <del> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same if they are present in the current description. </del>  Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are still present, the "a=msid" line MUST stay the same. </del> For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. MUST stay the same. If any RtpTransceiver has been stopped, the port MUST be set to <del> zero and the "a=msid" line MUST be removed. </del>  If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the 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>  Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same. </del>  5.3.3. specified in RFC3605, Section 2.1, but its value is ignored, as this information is superfluous when using ICE. <del> If present, a single "a=msid" attribute MUST be parsed as specified in I-D.ietf-mmusic-msid, Section 3.2, and its value stored. </del>  Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

Reviewer comments:
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).

Revised text:
If the RtpTransceiver has a sendrecv or sendonly direction:  <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 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  <ins> zero and all "a=msid" lines removed. </ins>  <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 m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted.  For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. MUST stay the same. If any RtpTransceiver has been stopped, the port MUST be set to  <ins> zero and all "a=msid" lines MUST be removed. </ins> If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the If the RtpTransceiver has a sendrecv or sendonly direction:  <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> Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted.  <ins> For RtpTransceivers that are not stopped, the "a=msid" line(s) MUST stay the same, 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 answer. </ins> 5.3.3. specified in RFC3605, Section 2.1, but its value is ignored, as this information is superfluous when using ICE.  <ins> If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.