Original text:
5.2.3.1. If the "OfferToReceiveAudio" option is specified, with an integer <del> value of N, the offer MUST include N non-rejected m= sections with media type "audio", even if fewer than N audio MediaStreamTracks have been added to the PeerConnection.  This allows the offerer to receive audio, including multiple independent streams, even when not sending it; accordingly, the directional attribute on the audio m= sections without associated MediaStreamTracks MUST be set to recvonly.  If this option is specified in the case where at least N audio MediaStreamTracks have already been added to the PeerConnection, or N non-rejected m= sections with media type "audio" would otherwise be generated, it has no effect.  For backwards compatibility with pre- standard versions of this specification, a value of "true" is interpreted as equivalent to N=1. </del>  5.2.3.2. If the "OfferToReceiveVideo" option is specified, with an integer <del> value of N, the offer MUST include N non-rejected m= sections with media type "video", even if fewer than N video MediaStreamTracks have been added to the PeerConnection.  This allows the offerer to receive video, including multiple independent streams, even when not sending it; accordingly, the directional attribute on the video m= sections without associated MediaStreamTracks MUST be set to recvonly.  If this option is specified in the case where at least N video MediaStreamTracks have already been added to the PeerConnection, or N non-rejected m= sections with media type "video" would otherwise be generated, it has no effect.  For backwards compatibility with pre- standard versions of this specification, a value of "true" is interpreted as equivalent to N=1. </del>  5.2.3.3.  If the "VoiceActivityDetection" option is specified, with a value of "true", the offer MUST indicate support for silence suppression in the audio it receives by including comfort noise ("CN") codecs for receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. <del> 5.2.3.4. If the "IceRestart" option is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC5245, Section 9.1.1.1.  If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated).  Similarly, if the ICE configuration has changed, this option has no effect, since new ufrag and pwd attributes will be generated automatically.  This option is primarily useful for reestablishing connectivity in cases where failures are detected by the application. </del> 5.3. When createAnswer is called, a new SDP description must be created 5.3.3.  5.4. 5.5.

Reviewer comments:
ORTA/ORTV can now be set to a number smaller than the number of MSTs, leading to a=sendonly settings. Also allowed VAD to work in CreateAnswer. ()
LGTM
NAME do you have any remaining concerns?
lgtm
LGTM
Per e-mail, I feel like the text around how to not change extant m= sections is confusing. Ignoring recycling, if we have N mediastreams of which O are old and are sendrecv and someone asks for offerToReceive=M, then we end up with: if O >= M: O sendrecv m= lines N - O sendonly m= lines if O < M: M sendrecv m= lines N - M sendonly m= lines I am fine with that, but I feel like the text may not make it entirely clear.

Revised text:
5.2.3.1. If the "OfferToReceiveAudio" option is specified, with an integer  <ins> value of N, and M audio MediaStreamTracks have been added to the PeerConnection, the offer MUST include N non-rejected m= sections with media type "audio", even if N is greater than M.  This allows the offerer to receive audio, including multiple independent streams, even when not sending it; accordingly, the directional attribute on the N-M audio m= sections without associated MediaStreamTracks MUST be set to recvonly. If N is set to a value less than M, the offer MUST mark the m= sections associated with the M-N most recently added (since the last setLocalDescription) MediaStreamTracks as sendonly.  This allows the offerer to indicate that it does not want to receive audio on some or all of its newly created streams.  For m= sections that have previously been negotiated, this setting has no effect.  [TODO: refer to RTCRtpSender in the future] For backwards compatibility with pre-standard versions of this specification, a value of "true" is interpreted as equivalent to N=1, and "false" as N=0. </ins> 5.2.3.2. If the "OfferToReceiveVideo" option is specified, with an integer  <ins> value of N, and M video MediaStreamTracks have been added to the PeerConnection, the offer MUST include N non-rejected m= sections with media type "video", even if N is greater than M.  This allows the offerer to receive video, including multiple independent streams, even when not sending it; accordingly, the directional attribute on the N-M video m= sections without associated MediaStreamTracks MUST be set to recvonly. If N is set to a value less than M, the offer MUST mark the m= sections associated with the M-N most recently added (since the last setLocalDescription) MediaStreamTracks as sendonly.  This allows the offerer to indicate that it does not want to receive video on some or all of its newly created streams.  For m= sections that have previously been negotiated, this setting has no effect.  [TODO: refer to RTCRtpSender in the future] For backwards compatibility with pre-standard versions of this specification, a value of "true" is interpreted as equivalent to N=1, and "false" as N=0. </ins> 5.2.3.3. <ins> If the "IceRestart" option is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC5245, Section 9.1.1.1.  If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated).  Similarly, if the ICE configuration has changed, this option has no effect, since new ufrag and pwd attributes will be generated automatically.  This option is primarily useful for reestablishing connectivity in cases where failures are detected by the application. 5.2.3.4. </ins> If the "VoiceActivityDetection" option is specified, with a value of "true", the offer MUST indicate support for silence suppression in the audio it receives by including comfort noise ("CN") codecs for receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm.  5.3. When createAnswer is called, a new SDP description must be created 5.3.3. <ins> The createOffer method takes as a parameter an RTCAnswerOptions object.  Special processing is performed when generating a SDP description if the following constraints are present. 5.3.3.1. Handling of the "VoiceActivityDetection" option in answers is the same as is indicated for offers in sec.voiceactivitydetection1. </ins> 5.4. 5.5.