Original text:
Section 6.2, with a "send" simulcast stream description that lists each desired encoding, and no "recv" simulcast stream description. The m= section will also include an "a=rid" attribute for each <del> encoding, as specfied in I-D.ietf-mmusic-rid, Section 4; the use of </del>  RID identifiers allows the individual encodings to be disambiguated even though they are all part of the same m= section. transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and createAnswer.  Note that setCodecPreferences does not directly affect <del> which codec the implemtation decides to send.  It only affects which codecs the implementation indicates that it prefers to receive, via the offer or answer.  Even when a codec is excluded by </del>  setCodecPreferences, it still may be used to send until the next offer/answer exchange discards it. followed: The port value is set to the port of the default ICE candidate for <del> this m= section, but given that no candidates have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </del>  To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the Section 5). The m= line MUST be followed immediately by a "c=" line, as specified <del> in RFC4566, Section 5.7.  Again, as no candidates have yet been gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </del>  I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates <del> have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </del>  The <proto> field MUST be set to exactly match the <proto> field for the corresponding m= line in the offer. Section 5). The m= line MUST be followed immediately by a "c=" line, as specified <del> in RFC4566, Section 5.7.  Again, as no candidates have yet been gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </del>  If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription.  If precise control over <del> the SDP is needed, the aformentioned createOffer/createAnswer options or RTPSender APIs MUST be used. </del>  Note that the application MAY modify the SDP to reduce the capabilities in the offer it sends to the far side (post-

Reviewer comments:
NAME I fixed this.
Section 5.2.1 CreateOffer "given that no candidates have yet been gathered" - when people remember the pre-gathered candidate pool, this can be confusing. Suggest adding a note at the top of this section saying that CreateOffer doesn't cause candidate gathering and does not take candidates from the pre-gathered pool, and thus, no candidates are available at the initial call to CreateOffer. All subsequent references to "no candidates have yet been gathered" in this section should be replaced with "no candidates are available". This also affects section 5.3.1 CreateAnswer.
lgtm

Revised text:
Section 6.2, with a "send" simulcast stream description that lists each desired encoding, and no "recv" simulcast stream description. The m= section will also include an "a=rid" attribute for each  <ins> encoding, as specified in I-D.ietf-mmusic-rid, Section 4; the use of </ins> RID identifiers allows the individual encodings to be disambiguated even though they are all part of the same m= section. transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and createAnswer.  Note that setCodecPreferences does not directly affect  <ins> which codec the implementation decides to send.  It only affects which codecs the implementation indicates that it prefers to receive, via the offer or answer.  Even when a codec is excluded by </ins> setCodecPreferences, it still may be used to send until the next offer/answer exchange discards it. followed: The port value is set to the port of the default ICE candidate for  <ins> this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </ins> To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the Section 5). The m= line MUST be followed immediately by a "c=" line, as specified  <ins> in RFC4566, Section 5.7.  Again, as no candidates are available yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </ins> I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates  <ins> are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </ins> The <proto> field MUST be set to exactly match the <proto> field for the corresponding m= line in the offer. Section 5). The m= line MUST be followed immediately by a "c=" line, as specified  <ins> in RFC4566, Section 5.7.  Again, as no candidates are available yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </ins> If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription.  If precise control over  <ins> the SDP is needed, the aforementioned createOffer/createAnswer options or RTPSender APIs MUST be used. </ins> Note that the application MAY modify the SDP to reduce the capabilities in the offer it sends to the far side (post-