Draft: draft-ietf-rtcweb-jsep

Commentary: 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 does n'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  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  ) . 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  's original comment , since it says that you should not send CN codecs if they were n'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 . 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 are n'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 do n'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  . 
 Fixed by
Paragraph (version A):
For each specified "CN" media format, enable silence
suppression for all supported media formats with the same
clockrate, as described in RFC3389, Section 5, except for
formats that have their own internal silence suppression
mechanisms.  Silence suppression for such formats (e.g.,
Opus) is controlled via fmtp parameters, as discussed in
sec.voiceactivitydetection1.
Paragraph (version B):
For each specified "CN" media format, configure silence
suppression for all supported media formats with the same
clockrate, as described in RFC3389, Section 5, except for
formats that have their own internal silence suppression
mechanisms.  Silence suppression for such formats (e.g.,
Opus) is controlled via fmtp parameters, as discussed in
sec.voiceactivitydetection1.
Paragraph (version A):
For any specified "ptime" value, configure the available
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.
Paragraph (version B):
For any specified "ptime" value, configure the available
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.
Paragraph (version B):
If the m= section is of type audio, and silence suppression was
configured for the send media format as a result of processing
the remote description, and is also enabled for that format in
the local description, use silence suppression for outgoing
media, in accordance with the guidance in
sec.voiceactivitydetection1.  If these conditions are not met,
silence suppression MUST NOT be used for outgoing media.