Change:
Also fix a bunch of TODOs and a few places where text was obsolete. NAME NAME
I suspect we might need to say a bit more in this section this but this all looks good good so LGTM

Discussion:
The "s=" and "t=" lines MUST stay the same. <del> Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above.  [TODO: update profile UDP/TCP per default candidate] </del> <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 described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </ins> Each "a=mid" line MUST stay the same.

The createOffer method takes as a parameter an RTCOfferOptions object.  Special processing is performed when generating a SDP <del> description if the following constraints are present. </del> <ins> description if the following options are present. </ins> 5.2.3.1.

5.3.2. <ins> When createAnswer is called a second (or later) time, or is called after a local description has already been installed, the processing is somewhat different than for an initial answer. If the initial answer was not applied using setLocalDescription, meaning the PeerConnection is still in the "have-remote-offer" state, the steps for generating an initial answer should be followed, subject to the following restriction: The fields of the "o=" line MUST stay the same except for the <session-version> field, which MUST increment if the session description changes in any way from the previously generated answer. If any session description was previously supplied to setLocalDescription, an answer is generated by following the steps in the "have-remote-offer" state above, along with these exceptions: The "s=" and "t=" lines MUST stay the same. Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in RFC5245, Section 4.3.  Note, however, that the m= line protocol need not match the default candidate, because this protocol value must instead match what was supplied in the offer, as described above.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is enabled in the answer.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described in the initial answer section above. Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. Within each m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather- overview), an "a=candidate" line MUST be added, as specified in RFC5245, Section 4.3., paragraph 3.  If candidate gathering for the section has completed, an "a=end-of-candidates" attribute MUST be added, as described in I-D.ietf-mmusic-trickle-ice, Section 9.3. For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same. </ins> 5.3.3. The createAnswer method takes as a parameter an RTCAnswerOptions <del> object.  Special processing is performed when generating a SDP description if the following constraints are present. </del> <ins> object.  The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the OfferToReceiveAudio, OfferToReceiveVideo, and IceRestart options mentioned in sec.options- handling1 are meaningless in the context of generating an answer, as there is no need to generate extra m= lines in an answer, and ICE credentials will automatically be changed for all m= lines where the offerer chose to perform ICE restart. The following options are supported in RTCAnswerOptions. </ins> 5.3.3.1. <del> Handling of the "VoiceActivityDetection" option in answers is the same as is indicated for offers in sec.voiceactivitydetection1. </del> <ins> Silence suppression in the answer is handled as described in sec.voiceactivitydetection1. </ins> 5.4.

Remove or reorder codecs (m=) <del> The following parameters may be controlled by constraints passed into </del> <ins> The following parameters may be controlled by options passed into </ins> createOffer/createAnswer.  As an open issue, these changes may also be be performed by manipulating the SDP returned from createOffer/ createAnswer, as indicated above, as long as the capabilities of the