jiebi/CodeConvo huggingface dataset:
Change:
BLOCKER: The second bullet on page 43 ("If an RtpTranceiver has been stopped and is associated..." is normative and redundant with (and slightly contradictory to) the bullet on page 44 starting "If any RtpTranceiver has been slopped...") which is also normative. Remove one.
Looks like an editorial oversight. I'm inclined to remove the second instance. NAME as FYI
BLOCKER: The bullet at the bottom of of page 42 ("If any RtpTranceiver has been added...") is normative and redundant with the bullet in the middle of page 44 ("If any RtpTranceiver has been added..."), which is also normative. Remove one.
Agreed. Let's remove the second one. NAME as FYI

Discussion:
section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating an m= section for the added RtpTransceiver as if the m= <del> section were being added to the session description, placed at the same index as the m= section with a zero port. </del> <ins> section were being added to the session description (including a new MID value), and placing it at the same index as the m= section with a zero port. </ins> If an RtpTransceiver is stopped and is not associated with an m= section, an m= section MUST NOT be generated for it.  This

For RtpTransceivers that are still present, any "a=simulcast" line MUST stay the same. <del> If any RtpTransceiver has been stopped, the port MUST be set to zero and all "a=msid" lines MUST be removed. If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating a m= section for the added RtpTransceiver as if the m= section were being added to session description, except that instead of adding it, the generated m= section replaces the m= section with a zero port.  The new m= section MUST contain a new MID. </del> If the initial offer was applied using setLocalDescription, and an answer from the remote side has been applied using setRemoteDescription, meaning the PeerConnection is in the "remote-
Change:
BLOCKER: The final bullet of page 68 refers to answer directionality of "sendrecv" and "sendonly." These are incorrect when applying remote answers, for which these should be "sendrecv" and "recvonly." Please rephrase in terms of whether media is to be sent, or fix in some other way that doesn't get the sense reversed for remote answers.

Discussion:
RTCP transmission for this m= section to use reduced-size RTCP, as specified in RFC5506. <del> If the directional attribute in the answer is of type "sendrecv" or "sendonly", choose the media format to send as the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </del> <ins> If the directional attribute in the answer indicates that the JSEP implementation should be sending media ("sendonly" for local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </ins> specified in RFC7160, Section 3.1. The payload type mapping from the remote description is used to
Change:
The bullet in the middle of page 66 (starting "For each specified media format...") states that unsupported media formats must be ignored. The following bullet specifies that "rtx" media formats that refer to "primary payload types [that] are not present" MUST result in an error. Read naïvely, implementors may very well discard a payload type for lack of understanding, and then discover an "rtx" for that discarded PT, and generate an error ("it's not present!"). These bullets need additional text regarding how they interact with each other.
LGTM with comment

Discussion:
between the RTX payload type and its associated primary payload type, as described in RFC4588, Section 4.  If any referenced primary payload types are not present, this MUST result in an <del> error. </del> <ins> error.  Note that RTX payload types may refer to primary payload types which are not supported by the local media implementation, in which case, the RTX payload type MUST also be ignored. </ins> For each specified fmtp parameter that is supported by the local implementation, enable them on the associated media
Change:
The bullets on page 45 use the construct "MUST only" three times. This is confusing, and likely to lead to implementors doing the wrong thing. Please rewrite in the form "The 'a=rtcp' line MUST NOT be added unless..."
In the section "Subsequent Offers" we have the text o The RTCP feedback extensions MUST only include those that are present in the most recent answer. o The "a=rtcp" line MUST only be added if the most recent answer did not include an "a=rtcp-mux" line. o The "a=rtcp-mux" line MUST only be added if present in the most recent answer. Next step - Rewrite as adam suggested.
This works for me.

Discussion:
The RTCP feedback extensions MUST only include those that are present in the most recent answer. <del> The "a=rtcp" line MUST only be added if the most recent answer did not include an "a=rtcp-mux" line. </del> <ins> The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line. </ins> <del> The "a=rtcp-mux" line MUST only be added if present in the most </del> <ins> The "a=rtcp-mux" line MUST NOT be added unless present in the most </ins> recent answer. The "a=rtcp-mux-only" line MUST NOT be added. <del> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer. </del> <ins> The "a=rtcp-rsize" line MUST NOT be added unless present in the most recent answer. </ins> An "a=bundle-only" line MUST NOT be added, as indicated in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 6.  Instead, JSEP
Change:
BLOCKER: The first bullet on page 70 exhibits the same error.
Maybe I am just dumb but I am not seeing this in the text.
Sorry, I mis-entered this one. This is regarding media directionality again.
NAME PTAL and see if there's anything from that we need to do here.

Discussion:
the rules and recommendations from I-D.ietf-avtcore-rtp-multi- stream, Section 5.4.1 to select which SSRC to use. <del> If the directional attribute is of type "recvonly" or "inactive", stop transmitting all RTP media, but continue sending RTCP, as described in RFC3264, Section 5.1. </del> <ins> If the directional attribute in the answer indicates that the JSEP implementation should not be sending media ("recvonly" for local answers, "sendonly" for remote answers, or "inactive" for either type of answer) stop transmitting all RTP media, but continue sending RTCP, as described in RFC3264, Section 5.1. </ins> If the m= section proto value indicates use of SCTP:
Change:
BLOCKER: The first bullet on page 37 says that port 9 "MUST be used," which contradicts the behavior required of BUNDLE-only sections (for which port 0 MUST be used). Clarify.
Yes - we need to indicate that bundle-only sections use 0 instead of 9.

Discussion:
Section 5.14.  For the m= line itself, the following rules MUST be followed: <del> The port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </del> <ins> If the m= section is marked as bundle-only, then the port value MUST be set to 0.  Otherwise, the port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </ins> To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8.
Change:
Section 3.2 has a paragraph starting "Lastly, while the actual media parameters are only know after an offer..."; the entire contents of this paragraph appear to be actually false if both ICE and DTLS are in use. I know there's conversation underway on MMUSIC and the WebRTC mailing lists on this topic, but none of them have yet described a situation in which this paragraph is actually true. Please remove it or add a sequence diagram showing how it arises.
It may not be able to receive media (due to lack of DTLS fingerprint), but it can certainly receive ICE checks. We should clarify accordingly.

Discussion:
exact same number as the offer. Lastly, while the exact media parameters are only known only after an <del> offer and an answer have been exchanged, it is possible for the offerer to receive media after they have sent an offer and before they have received an answer.  To properly process incoming media in this case, the offerer's media handler must be aware of the details of the offer before the answer arrives. </del> <ins> offer and an answer have been exchanged, the offerer may receive ICE checks, and possibly media (e.g., in the case of a re-offer after a connection has been established) before it receives an answer.  To properly process incoming media in this case, the offerer's media handler must be aware of the details of the offer before the answer arrives. </ins> Therefore, in order to handle session descriptions properly, the user agent needs:

calls to createOffer and createAnswer. When creating offers, the transceiver direction is directly reflected <del> in the output, even for reoffers.  When creating answers, the </del> <ins> in the output, even for re-offers.  When creating answers, the </ins> transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below.
Change:
Page 37 contains a statement that "attributes of category IDENTICAL or TRANSPORT should not be repeated in bundled m= sections". Two issues: this reads as normative, so consider "SHOULD NOT" rather than "should not." Also, I think this is true of bundle-only sections, not bundled sections in general.
If we are going to use normative language, seems like we should match the language from BUNDLE, which probably says 'MUST NOT'. The statement is correct regarding any actively bundled sections (which includes bundle-only), but this part of the text has caused enough confusion that some extra explanation is probably warranted.

Discussion:
I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, Section 8.1 of I-D.ietf-mmusic-sdp-bundle-negotiation <del> specifies that attributes of category IDENTICAL or TRANSPORT should not be repeated in bundled m= sections. </del> <ins> 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. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section:
Change:
I tried to clarify bundle-only while Iw as in here.
BLOCKER: The final paragraph in section 3.5.1 says that candidates are only gathered for m= sections referenced in BUNDLE tags. Section 3.5.4 talks about gathering more candidates than that under certain circumstances. Please make these consistent with each other.
Agree this needs to be rewritten; with BUNDLE, # of media streams is not the number of ICE components.

Discussion:
Note that gathering phases only gather the candidates needed by new/recycled/restarting m= sections; other m= sections continue to <del> use their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= sections referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp- bundle-negotiation. </del> <ins> use their existing candidates.  Also, if an m= section is bundled (either by a successful bundle negotiation or by being marked as bundle-only), then candidates will be gathered and exchanged for that m= section if and only if its MID is a BUNDLE-tag, as described in I- D.ietf-mmusic-sdp-bundle-negotiation. </ins> 3.5.2.

JSEP applications typically inform the JSEP implementation to begin ICE gathering via the information supplied to setLocalDescription, as <del> this is where the app specifies the number of media streams, and thereby ICE components, for which to gather candidates.  However, to accelerate cases where the application knows the number of ICE </del> <ins> the local description indicates the number of ICE components which will be needed and for which candidates must be gathered.  However, to accelerate cases where the application knows the number of ICE </ins> components to use ahead of time, it may ask the implementation to gather a pool of potential ICE candidates to help ensure rapid media setup.
Change:
I did add a MUST here, but I think it's just a restatement of what is already true.
BLOCKER: Several of the SDP-building procedures in this document call out addition of "a=fingerprint" to individual media sections, while the canonical definition of "a=fingerprint" allows these to be added at either the session level or the media level. The same is true of ice-pwd and ice-ufrag. While the process of SDP building in this document appears to be prescriptive on purpose, one assumes that it is allowed some variation so as to accommodate deployment of future SDP extensions. Because of this state of affairs, it is unclear whether implementations that consolidate these attributes at the session level when they would otherwise be identical among all media sections is such an allowable variation. Ambiguity in specifications is never a good thing, so I believe that the draft needs to do one of: (a) specifically call out this kind of aggregation as allowed; (b) specifically call out this kind of aggregation as disallowed; or (c) include a blanket statement that implementations are allowed to emit SDP that is semantically equivalent to that which is generated by the procedures in this document, but which may vary in exact structure. I have a strong preference for (c) -- implementations will be required to deal with such variations anyway to interop with legacy SDP, so prohibiting JSEP clients from generating them serves no goal.
My suggestion would be to expand the para below to say (a), i.e. that applications that wish to aggregate may do so, even though we recommend not aggregating. Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical. This promotes readability, especially if one of a set of initially identical attributes is subsequently changed.
(and also fine with suggestions Justin is suggesting)

Discussion:
identical.  This assists development and debugging by making it easier to understand individual media sections, especially if one of a set of initially identical attributes is subsequently changed. <ins> However, implementations MAY choose to aggregate attributes at the session level and JSEP implementations MUST be prepared to receive attributes in either location. </ins> Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically
Change:
PTAL
Section 3.5.1 talks about a "recycled m= section" without any context for what this means. Please provide a forward reference to the section that discusses m= section recycling.
is where m= section recycling is first defined, but it's as a bullet point in how to generate an offer, which makes a direct reference problematic. I guess we could say "as spelled out in [ref]"

Discussion:
section if its mid property is non-null; otherwise it is said to be disassociated.  The associated m= section is determined using a mapping between transceivers and m= section indices, formed when <del> creating an offer or applying a remote offer.  An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. </del> <ins> creating an offer or applying a remote offer. An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver.  However, in certain cases where a m= section has been rejected, as discussed in sec.subsequent-offers below, that m= section will be "recycled" and associated with a new RtpTransceiver with a new mid value. </ins> RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds
Change:
NAME done. NAME still waiting for you.
Section 1.2 uses the term "glare" without describing it. This term may be unfamiliar to readers, and should be explained or cited.
Agreed.
See URL for a definition.
LGTM, but see comment

Discussion:
descriptions to the API, the API would produce and consume messages from this protocol.  While providing a more high-level API, this put more control of signaling within the JSEP implementation, forcing it <del> to have to understand and handle concepts like signaling glare.  In addition, it prevented the application from driving the state machine to a desired state, as is needed in the page reload case. </del> <ins> to have to understand and handle concepts like signaling glare (see RFC3264, Section 4). </ins> A second approach that was considered but not chosen was to decouple the management of the media control objects from session
Change:
I think I got all the things Justin mentioned.
Will take a final look once Eric's comments are resolved.
Made a slight change to one sentence to mention user agents. PTAL.
For the examples, please expand the acronyms "JS" and "UA".
I think we're going to want to do it once.
I think I want to define some of theses instead of replace all of them because we can't stay in the column limit if they are expanded.

Discussion:
of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to <del> Bob's endpoint.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server.  The JS on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used.  Both Alice and Bob are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". </del> <ins> Bob's endpoint.  The messages from the Javascript application in Alice's browser to the Javascript in Bob's browser, abbreviated as AliceJS and BobJS respectively, are assumed to flow over some signaling protocol via a web server.  The Javascript on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used.  The user agents (JSEP implementations) in Alice and Bob's browsers, abbreviated as AliceUA and BobUA respectively, are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". </ins> The SDP for |offer-A1| looks like:
Change:
BLOCKER: Section 5.7.1, first paragraph: this claims that a= lines are order insensitive. Nothing in SDP's base definition makes this true, and nothing precludes specific attributes from assigning meaning to the order in which they appear. See draft-ietf-slim-negotiating-human-language-08 for an example of an SDP extension that does apply meaning to the order in which attributes appear (for better or worse).
Section Session-Level Parsing Text is First, the session-level lines are checked and parsed. These lines MUST occur in a specific order, and with a specific syntax, as defined in [RFC4566], Section 5. Note that while the specific line types (e.g. "v=", "c=") MUST occur in the defined order, lines of the same type (typically "a=") can occur in any order, and their ordering is not meaningful. Remove the text "and their ordering is not meaningful." from above para
FWIW ... some of SDP implementations I work with save a lines in non ordered sets and I never knew this was a bug. Bummer
Agree with proposal.
LGTM

Discussion:
MUST occur in a specific order, and with a specific syntax, as defined in RFC4566, Section 5.  Note that while the specific line types (e.g. "v=", "c=") MUST occur in the defined order, lines of the <del> same type (typically "a=") can occur in any order, and their ordering is not meaningful. </del> <ins> same type (typically "a=") can occur in any order. </ins> The following non-attribute lines are not meaningful in the JSEP context and MAY be discarded once they have been checked.
Change:
BLOCKER: The first bullet on page 35 has a normative statement about the AVT profile strings that must be accepted, but uses an unspecified grammar to actually specify the string. If this is normative, it needs to be formal. Either specify the string using a formal and cited grammar, or provide an exhaustive list.
Proposal on editor's call is to use POSIX extended regular expressions. URL I believe this would give us the expressions. (UDP|TCP)/TLS/RTP/SAVPF? and: RTP/S?AVPF?
You're sure you want to pull in another reference for regexes instead of just listing all eight valid values?

Discussion:
generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its <del> willingness to support "(UDP,TCP)/TLS/RTP/SAVPF".  In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer: </del> <ins> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer: </ins> <del> Any profile in the offer matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP|TCP)/TLS/RTP/SAVP[F]". </del> <ins> Any profile in the offer matching one of the following MUST be accepted: "RTP/AVP" "RTP/AVPF" "RTP/SAVP" "RTP/SAVPF" "UDP/TLS/RTP/AVP" "UDP/TLS/RTP/AVPF" "UDP/TLS/RTP/SAVP" "UDP/TLS/RTP/SAVPF" "TCP/TLS/RTP/SAVP" "TCP/TLS/RTP/SAVPF" </ins> The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer.
Change:
certificate. This was updated in RFC 8122.
NAME PTAL
NAME PTAL
Section 5.2.1 (creating an offer) still has this paragraph: In RFC4572-update, this requirement doesn't exist. So should this be changed to reference RFC4572-update, removing the second half of this paragraph?
Related webrtc-pc issue: URL

Discussion:
"a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC8122, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </del> <ins> For each desired digest algorithm, one or more "a=fingerprint" lines for each of the endpoint's certificates, as specified in RFC8122, Section 5. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.