Change:
We reviewed the handling for G.729 and it's similar to Opus; there's a dtx=foo fmtp parameter to control receipt of DTX. I suggest we leave this parameter to createOffer as an indication on whether you want the remote side to use DTX, and add a frob on RtpSender (TBD exactly where) to directly control whether you use DTX. That frob is out of scope for this PR. For the PSAP/E911 case, the call will typically be over PCMU, and so it's covered through either of a) setting this parameter (which drops CN from the offered codecs), or b) the PSAP not responding with CN in the answer. So that's not an issue. We may need to add some text in the handling-a-remote-description section to make it clear that if the remote side says to use DTX (either through presence of CN, or usedtx=1), DTX MUST be engaged by the browser. We could also spell out the no-DTX case, if desired.
So plan is make this just about SDP, both offer and answer, along lines of Justin text. Then file issue to deal with happens with RTP sender.
Put in all Justin's comments from prev review.
In some codecs (e.g., Opus) requests to not do silence suppression are advisory. We should consider whether we require browsers to respect them so that counterparties which need the browser to not do silence suppression can force that.
I think it would make the most sense for this to behave identically regardless of codec. IOW, if not offered, it can't be indicated in the answer. The answer can of course reject a proposal to use VAD (currently via AnswerOptions), but there could perhaps be another surface for this.
Decision in Kirkland: if offer indicates no VAD (either through lack of CN, or usedtx=0), answer MUST not specify VAD. This is done on a per-codec basis, e.g. if answerer receives CN + usedtx=0, and answerer says Vad:True, answer will have CN + usedtx=0.
Fixed by

Discussion:
receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. <ins> If the "VoiceActivityDetection" option is specified, with a value of "false", the browser MUST NOT omit "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. </ins> 5.3. When createAnswer is called, a new SDP description must be created

5.3.3.1. Silence suppression in the answer is handled as described in <del> sec.voiceactivitydetection1. </del> <ins> sec.voiceactivitydetection1, with one exception: if support for silence suppression was not indicated in the offer, the VoiceActivityDetection parameter has no effect, and the answer should be generated as if VoiceActivityDetection was set to false.  This is done on a per-codec basis (e.g., if the offerer somehow offered support for CN but set "usedtx=0" for Opus, setting VoiceActivityDetection to true would result in an answer with CN codecs and "usedtx=0"). </ins> 5.4.