Original text:
both <start-time> and <stop-time> SHOULD be set to zero, e.g. "t=0 0". <del> An "a=msid-semantic:WMS" line MUST be added, as specified in I- D.ietf-mmusic-msid, Section 4. </del>  The next step is to generate m= sections, as specified in RFC4566 Section 5.14, for each MediaStreamTrack that has been added to the "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. </del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. mmusic-sctp-sdp, Section 4.1. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", <del> "a=ice-options", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc- datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del>  Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST The first step in generating an initial answer is to generate session-level attributes.  The process here is identical to that <del> indicated in the Initial Offers section above. </del>  The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> If the "trickle" ICE option is present in the offer, an "a=ice- options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4. </del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. match the fields in the offer. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", <del> "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc- datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del>  If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> TODO: msid-semantic, identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level. </del>  Once all the session-level lines have been parsed, processing continues with the lines in media sections. 5.8.  The following steps are performed at the media engine level to apply a remote description. ICE components in each BUNDLE, and begin muxing these m= sections accordingly.  [TODO: ref] <del> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. </del> 6. It is possible to change elements in the SDP returned from

Reviewer comments:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.

Revised text:
both <start-time> and <stop-time> SHOULD be set to zero, e.g. "t=0 0".  <ins> An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. </ins> The next step is to generate m= sections, as specified in RFC4566 Section 5.14, for each MediaStreamTrack that has been added to the "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4.  An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. mmusic-sctp-sdp, Section 4.1. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",  <ins> "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp- port" line referencing the SCTP port number as defined in I-D.ietf- mmusic-sctp-sdp, Section 4.1. </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST The first step in generating an initial answer is to generate session-level attributes.  The process here is identical to that  <ins> indicated in the Initial Offers section above, except that the "a=ice-options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4 is only included if such an option was present in the offer. </ins> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4.  An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. match the fields in the offer. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",  <ins> "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.  <ins> TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level. </ins> Once all the session-level lines have been parsed, processing continues with the lines in media sections. 5.8. <ins> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. </ins> The following steps are performed at the media engine level to apply a remote description. ICE components in each BUNDLE, and begin muxing these m= sections accordingly.  [TODO: ref]  6. It is possible to change elements in the SDP returned from