jiebi/CodeConvo huggingface dataset:
Change:
The only draft or RFC that uses "UDP/TLS/RTP/AVP" is one typo in URL I just reported an RFC Errata on that. I think the argument here is anyone who was advertising TLS in the label, also put the S in the SAVP so we don't need to worry about any of the cases where we have TLS. The case with TCP it is a bit different. You can take RTP (not SRTP) and send it as unencrypted RTP over a normal TLS (not DTLS-SRTP) tunnel so for that case the label is TCP/TLS/RTP/AVPF. However, this is RTP over 4571 framing so treating it as SRTP is going to not work. Because of this, I think we need to remove all the options from this list that are RTP (not SRTP) framed over 4571. That means remove from the list "TCP/RTP/AVP", "TCP/RTP/AVPF" , "TCP/TLS/RTP/AVP" , "TCP/TLS/RTP/AVPF". For "TCP/RTP/SAVP" and "TCP/RTP/SAVPF", this is SRTP with 4571 framing over TCP ( See URL ). Since this is not DTLS-SRTP, it seems we should also remove theses two labels as well. So what I am proposing is we move the list to be just "RTP/AVP" "RTP/AVPF" "RTP/SAVP" "RTP/SAVPF" "TCP/DTLS/RTP/SAVP" "TCP/DTLS/RTP/SAVPF" "UDP/TLS/RTP/SAVP" "UDP/TLS/RTP/SAVPF" Backing up to first principals on this, the problem we are tying to solve is an offer that is offering RTP or DTLS-SRTP. It is going to have RTP/AVP[F] and a fingerprint so it seems as long as we have that on the list it is good. Of some one, RTP/SAVP is defined in URL(and the RTP/SAVFP version in URL) while the UDP/TLS/RTP/SAVP[F] is in URL )
I added the refs for where these are defined. If that look OK, I think this is ready to merge.
table is at URL
So when I take that table and do grep AVP grep -v MBMS I get RTP/AVP RTP/AVPF RTP/SAVP RTP/SAVPF TCP/DTLS/RTP/SAVP TCP/DTLS/RTP/SAVPF TCP/RTP/AVP TCP/RTP/AVPF TCP/RTP/SAVP TCP/RTP/SAVPF TCP/TLS/RTP/AVP TCP/TLS/RTP/AVPF UDP/TLS/RTP/SAVP UDP/TLS/RTP/SAVPF The diff from what we have now is < TCP/DTLS/RTP/SAVP < TCP/DTLS/RTP/SAVPF < TCP/RTP/AVP < TCP/RTP/AVPF < TCP/RTP/SAVP < TCP/RTP/SAVPF < TCP/TLS/RTP/AVP < TCP/TLS/RTP/AVPF
NAME be sure to check the references for the profiles.

Discussion:
Any profile in the offer matching one of the following MUST be accepted: <del> "RTP/AVP" </del> <ins> "RTP/AVP" (Defined in RFC4566, Section 8.2.2) </ins> <del> "RTP/AVPF" </del> <ins> "RTP/AVPF" (Defined in RFC4585, Section 9) </ins> <del> "RTP/SAVP" </del> <ins> "RTP/SAVP" (Defined in RFC3711, Section 12) </ins> <del> "RTP/SAVPF" </del> <ins> "RTP/SAVPF" (Defined in RFC5124, Section 6) </ins> <del> "UDP/TLS/RTP/AVP" </del> <ins> "TCP/DTLS/RTP/SAVP" (Defined in RFC7850, Section 3.4) </ins> <del> "UDP/TLS/RTP/AVPF" </del> <ins> "TCP/DTLS/RTP/SAVPF" (Defined in RFC7850, Section 3.5) </ins> <del> "UDP/TLS/RTP/SAVP" </del> <ins> "UDP/TLS/RTP/SAVP" (Defined in RFC5764, Section 9) </ins> <del> "UDP/TLS/RTP/SAVPF" "TCP/TLS/RTP/SAVP" "TCP/TLS/RTP/SAVPF" </del> <ins> "UDP/TLS/RTP/SAVPF" (Defined in RFC5764, Section 9) </ins> The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer.
Change:
I like the text in your comment and changed to that.
Worth taking an editorial pass over this if time permits
I prob have time to run this one down.

Discussion:
defined in I-D.ietf-ice-trickle, Section 5.1. I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into <del> different categories.  To avoid unnecessary duplication when bundling I-D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1, specifies that attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections.  This includes m= sections for which bundling has been negotiated and is still desired, as well as m= sections marked as bundle-only. </del> <ins> different categories.  To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections, as specified in I-D.ietf-mmusic-sdp- bundle-negotiation, Section 8.1.  This includes m= sections for which bundling has been negotiated and is still desired, as well as m= sections marked as bundle-only. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:
Change:
any guess on what happened to these that caused them to not go in ?
They were somehow targeted to a branch other than master, and that branch was never merged
LGTM but you have a conflict

Discussion:
media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences. <del> The media formats in the answer MAY include codecs present in the offer that were discarded in a previous offer/answer exchange. This is necessary for compatibility with third- party call control and SIP use cases. </del> Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in RFC7874, Section 3, and RFC7742, Section 5.

the negotiated session descriptions by following the steps mentioned for the "have-local-offer" state above. <del> In addition, for each non-recycled, non-rejected m= section in the new offer, the following adjustments are made based on the contents of the corresponding m= section in the current remote description, if any: </del> <ins> In addition, for each existing, non-recycled, non-rejected m= section in the new offer, the following adjustments are made based on the contents of the corresponding m= section in the current local or remote description, as appropriate: </ins> The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST <del> only include codecs present in the most recent answer which have not been excluded by the codec preferences of the associated transceiver.  Note that non-JSEP endpoints are not subject to these restrictions, and might offer media formats that were not present in the most recent answer, as specified in RFC3264, Section 8.  Therefore, JSEP implementations MUST be prepared to receive such offers. </del> <ins> only include media formats which have not been excluded by the codec preferences of the associated transceiver, and MUST include all currently available formats.  Media formats that were previously offered but are no longer available (e.g., a shared hardware codec) MAY be excluded. </ins> Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in <del> the same order as in the current local description. </del> <ins> the same order as in the most recent answer.  Any media formats that were not present in the most recent answer MUST be added after all existing formats. </ins> The RTP header extensions MUST only include those that are present in the most recent answer. <del> The RTCP feedback extensions MUST only include those that are present in the most recent answer. </del> <ins> The RTCP feedback mechanisms MUST only include those that are present in the most recent answer, except for the case of format- specific mechanisms that are referencing a newly-added media format. </ins> The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line.
Change:
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 DTX 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.

Discussion:
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 <del> 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. </del> <ins> 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. </ins> The "VoiceActivityDetection" option does not have any impact on the setting of the "vad" value in the signaling of the client to mixer

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 <del> codecs and "usedtx=0"). </del> <ins> 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. </ins> 5.4.
Change:
is meant to represent "direction in effect", whereas represents "direction the application wants to negotiate". So, the direction that both inspects and modifies should be ; its purpose is to change the application's desired direction for a transceiver, regardless of the current state of negotiation. Also clarifying that also reflects the direction negotiated in a provisional answer, which was the intent (I believe) but wasn't explicitly stated. This is consistent with it being the direction "in effect", since applying a provisional answer allows the endpoint to start sending/receiving media.
NAME do you want to look at this? I believe this is straightforward.
Section 4.1.3, removeTrack, states: This should say "transceiver.direction". Using "currentDirection" doesn't work because it may be null, and it also may result in un-intuitive behavior, where ends up not having any effect and results in a "sendrecv" or "sendonly" direction being negotiated.
Want to make a PR?

Discussion:
should have its track removed.  The sender's track is cleared, and the sender stops sending.  Future calls to createOffer will mark the m= section associated with the sender as recvonly (if <del> transceiver.currentDirection is sendrecv) or as inactive (if transceiver.currentDirection is sendonly). </del> <ins> transceiver.direction is sendrecv) or as inactive (if transceiver.direction is sendonly). </ins> 4.1.4.

The currentDirection property indicates the last negotiated direction for the transceiver's associated m= section.  More specifically, it indicates the RFC3264 directional attribute of the associated m= <del> section in the last applied answer, with "send" and "recv" directions reversed if it was a remote answer.  For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection is set to "sendonly". </del> <ins> section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer. For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection is set to "sendonly". </ins> If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection is set to
Change:
Fixed my own comment, now LGTM
I think this got all the text from Robert, it was just not a change so it does not show up in diff.
Suggested change to the first sentence of 1.1 OLD: The thinking behind WebRTC call setup has been to fully specify and control the media plane, but to leave the signaling plane up to the application as much as possible. New: WebRTC call setup has been designed to focus on controlling the media plane, leaving signaling plane behavior up to the application as much as possible.
OK

Discussion:
1.1. <del> The thinking behind WebRTC call setup has been to fully specify and control the media plane, but to leave the signaling plane up to the application as much as possible.  The rationale is that different applications may prefer to use different protocols, such as the existing SIP call signaling protocol, or something custom to the particular application, perhaps for a novel use case.  In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the necessary transport and media configuration information necessary to establish the media plane. </del> <ins> WebRTC call setup has been designed to focus on controlling the media plane, leaving signaling plane behavior up to the application as much as possible.  The rationale is that different applications may prefer to use different protocols, such as the existing SIP call signaling protocol, or something custom to the particular application, perhaps for a novel use case.  In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the necessary transport and media configuration information necessary to establish the media plane. </ins> With these considerations in mind, this document describes the JavaScript Session Establishment Protocol (JSEP) that allows for full
Change:
The second paragraph of 6.8 starts "Next, ". I think it should start "First, ".
I agree with this.

Discussion:
a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. <del> Next, m= sections are processed.  For each m= section, the following </del> <ins> First, m= sections are processed.  For each m= section, the following </ins> steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.
Change:
There are two paragraphs on page 50 that start "The next step is to". They are both referring to the same step. I suggest combining the paragraphs.
I think I would just change the second one to "Finally"
LGTM

Discussion:
present in the remote offer, as specified in RFC3264, Section 6.  For the purposes of this discussion, any session-level attributes in the offer that are also valid as media-level attributes are considered to <del> be present in each m= section. The next step is to go through each offered m= section.  Each offered m= section will have an associated RtpTransceiver, as described in sec.applying-a-remote-desc.  If there are more RtpTransceivers than there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. </del> <ins> be present in each m= section.  Each offered m= section will have an associated RtpTransceiver, as described in sec.applying-a-remote- desc.  If there are more RtpTransceivers than there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. </ins> For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as
Change:
Not sure this is correct yet. Have a read of text in bugs.
The fourth sentence of the second bullet of section 5.2.1 is confusing. (It starts "It is RECOMMENDED that the ".) RFC3265 requires the initial sess-id high-order bit to be zero. As written, this can be read to say that setting that bit to zero is only RECOMMENDED, and that it's possible to have sess-ids that are something other than 64 bits. You mean to say "Do what 3265 says to do and make the lower 63 bits random". Here's one possible replacement for the sentence: "RFC 3265 requires that the high-order bit of the initial be zero. It is RECOMMENDED that the remaining 63 bits be initially set to a cryptographically random value."
Yes, this is a reasonable change.
The text from 3264 is The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. The initial value of the version MUST be less than (262)-1, to avoid rollovers. My read of this is the two high order bits need to be zero
Is there some other SDP formatting that requires this number to be positive ?
LGTM

Discussion:
The second SDP line MUST be an "o=" line, as specified in RFC4566, Section 5.2.  The value of the <username> field SHOULD be "-". <del> RFC3264 requires that the <sess-id> be representable as a 64-bit signed integer.  It is RECOMMENDED that the <sess-id> be generated as a 64-bit quantity with the high bit being sent to zero and the remaining 63 bits being cryptographically random.  The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the local address in this field.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </del> <ins> The sess-id MUST be representable by a 64-bit signed integer, and the initial value MUST be less than (2**62)-1, as required by RFC3264.  It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the two highest bits being set to zero and the remaining 62 bits being cryptographically random. The value of the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the local address in this field.  As mentioned in RFC4566, the entire o= line needs to be unique, but selecting a random number for <sess-id> is sufficient to accomplish this. </ins> The third SDP line MUST be a "s=" line, as specified in RFC4566, Section 5.3; to match the "o=" line, a single dash SHOULD be used
Change:
Last paragraph of 3.5.2.1 - "all of these fields" is ambiguous. Please state precisely which fields you mean.
Yeah, OK.

Discussion:
used instead. When creating an IceCandidate object, JSEP implementations MUST <del> populate all of these fields. </del> <ins> populate each of the candidate, ufrag, m= section index, and MID fields.  Implementations MUST also be prepared to receive objects with some fields missing, as mentioned above. </ins> 3.5.3.
Change:
Last paragraph on page 5 - first sentence: at "One way to mitigate this" - "this" has an unclear antecedent. Did you mean "One way to reduce the complexity of the application's responsibilities"?
Agreed. Editorial

Discussion:
protocol, and perform the reverse conversion on the messages it receives from the other side. <del> One way to mitigate this is to provide a JavaScript library that hides this complexity from the developer; said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher level call-oriented interface to the application developer.  For example, libraries exist to adapt the JSEP API into an API suitable for a SIP or XMPP.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </del> <ins> One way to make life easier for the application is to provide a JavaScript library that hides this complexity from the developer; said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher level call-oriented interface to the application developer.  For example, libraries exist to adapt the JSEP API into an API suitable for a SIP or XMPP.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </ins> 1.2.
Change:
The first full bullet on page 18 has a sentence that starts "Note that when considering". Please change that to simply "When considering". As written, there is an implication that this is a consequence of something specified somewhere else.
Yes, this seems rihgt.
To help find it, the whole sentence is is Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks. This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO [TS26.114]), as it significantly simplifies the matching logic.

Discussion:
encoding, the limits from the attribute are then compared to the encoder resolution.  Only the specific limits mentioned below are considered; any other values, such as picture aspect ratio, MUST <del> be ignored.  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks.  This is required regardless of whether the receiver </del> <ins> be ignored.  When considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks.  This is required regardless of whether the receiver </ins> supports performing receive-side rotation (e.g., through CVO TS26.114), as it significantly simplifies the matching logic.
Change:
The last paragraph of 5.1 needs more context. Why woudn't you expect the re-offer to fail, given that you already know the peer is using the older profile strings? It's not clear from the email list and proceedings how the document ended up with this particular text.
Consensus on editor's call is that this is correct. Rationale is that a new offer would have failed in any case, so why complicate things.
LGTM

Discussion:
Note that re-offers by JSEP implementations MUST use the correct profile strings even if the initial offer/answer exchange used an <del> (incorrect) older profile string. </del> <ins> (incorrect) older profile string.  This simplifies JSEP behavior, with minimal downside, as any remote endpoint that fails to handle such a re-offer will also fail to handle a JSEP endpoint's initial offer. </ins> 5.2.
Change:
The verb "surfaced" appears three times in the document without support or definition. Can you replace them with simpler language?
I don't see a reason to change this. It seems like relatively straightforward langauge.
I don't care. FWIW ... I asked a few developers what surfaced in an API meant and it did not seem a common term they used but given context they all read it the way we mean in spec..
The first two, which are about errors, will be changed to "raised" The last one, which is about candidates will be changed to "made available"
LGTM

Discussion:
resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the encoding MUST NOT be <del> transmitted, and an error SHOULD be surfaced to the application. </del> <ins> transmitted, and an error SHOULD be raised to the application. </ins> If the encoder resolution is less than the minimum size permitted by the attribute, the encoding MUST NOT be transmitted, and an <del> error SHOULD be surfaced to the application; the encoder MUST NOT </del> <ins> error SHOULD be raised to the application; the encoder MUST NOT </ins> apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder.

phase.  If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set.  Either way, changes to the policy have no effect on the candidate pool, <del> because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </del> <ins> because pooled candidates are not made available to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </ins> The ICE candidate pool size MUST NOT be changed after applying a local description.  If a local description has not yet been
Change:
In 4.1.7 (create Answer) why would calling setLocalDescription cause the answer to be a pending local description. I think it's the full on local description at that point, not a pending one?
Yes, this is an error in the text.
LGTM

Discussion:
Calling this method may do things such as generating new ICE credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and <del> does not become the pending local description, until </del> <ins> does not become the current local description, until </ins> setLocalDescription is called. 4.1.8.