Change:
event format, this MUST result in an error. For any specified "ptime" value, configure the available <del> media formats to use the specified packet size.  If the specified size is not supported for a media format, use the next closest value instead. </del> <ins> media formats to use the specified packet size when sending. If the specified size is not supported for a media format, use the next closest value instead. </ins> Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section

Discussion:
The paragraph that spans pages 46 and 47 claims that the "VoiceActivityDetection" parameter has no impact on whether the local endpoint does silence suppression for the audio it sends. The paragraph immediately preceding it says that JSEP implementations MUST NOT emit "CN" codecs if this parameter is set to "false." This only makes sense because RFC 3264 allows SDP to specify codecs that you want to receive by do not plan to generate (i.e., you can send CN even if your offer doesn't have CN in it, as long as the answer does). This is slightly counter-intuitive to many implementors, so it probably bears mention.
This is in VoiceActivityDetection in paragraph that says If the "VoiceActivityDetection" option is specified, with a value of "false", the JSEP implementation MUST NOT emit "CN" codecs. For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired. For example, when using the Opus codec, the "usedtx=0" parameter would be specified in the offer. Note that setting the "VoiceActivityDetection" parameter when generating an offer is a request to receive audio with silence suppression. It has no impact on whether the local endpoint does silence suppression for the audio it sends. The "VoiceActivityDetection" option does not have any impact on the setting of the "vad" value in the signaling of the client to mixer audio level header extension described in [RFC6464], Section 4. Need to figure out how to clarify for Adams point.
The intent of the original text was that setting this parameter might affect what you receive, but not what you send (since that's dependent on the other side's use of VoiceActivityDetection). This text is slightly inaccurate since setting VAD to false will result in it not being negotiated (with the current text), and not sent. However, the text is somewhat at odds with Adam's original comment, since it says that you should not send CN codecs if they weren't present in the offer (see see 5.3.3.1). So, we can either change it to more accurately reflect the current intent, or we can change the normative statements to indicate that use of CN is entirely unilateral. NAME do you have an opinion on this?

So to restate what I think the situation is: We agreed a while ago that the answerer can add things that aren't in the offer. Therefore the answerer can add CN Therefore whether CN is in the offer has no impact on what the offerer sends in RTP The flag controls what is in the offer Which means that the flag controls what you receive in RTP but not what you send in RTP. Correct?
That sounds right to me. is for receive preferences, is for send preferences. Similar to being for receive preferences, and being for send preferences.
Just as info to keep in mind on this. Some codecs, like opus, the dtx in the SDP is unidirectional and only is an indication about receiver preferences. Other codecs, like 729, it is bi directionally negotiated and both need to support dtx for either side to use dtx. So we probably need to be careful about how we phrase if voiceActivityDetection impacts the offer / answer
Per discussion on the call, intent is to enforce G.729 symmetrical/bilateral rules so that if either side says VAD=false you don't get VAD. Also need to clarify 5.3.3.1.
May also want to refer to G.729 as an example, as we do with Opus.
Fixed by