Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 I am going to land this and then make a followup PR for S 5.9 . 
 You 'll also need to update S 5.9 to ensure CN is only enabled when support is bilateral : For each specified " CN " media format , enable  for all supported media formats with the same clockrate , as described in [ RFC3389 ] , Section 5 , except for formats that have their own internal DTX mechanisms . DTX for such formats ( e.g. , Opus ) is controlled via fmtp parameters , as discussed in Section 5.2.3.2 .
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.  In addition, the implementation
MUST NOT use silence suppression for media it generates, regardless
of whether the "CN" codecs or related fmtp parameters appear in the
peer's description.  The impact of these rules is that silence
suppression in JSEP depends on mutual agreement of both sides, which
ensures consistent handling regardless of which codec is used.
Paragraph (version A):
Silence suppression in the answer is handled as described in
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").
Paragraph (version B):
Silence suppression in the answer is handled as described in
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").  The impact of this rule is that an answerer
will not try to use silence suppression with any endpoint that does
not offer it, making silence suppression support bilateral even with
non-JSEP endpoints.