jiebi/TextFlow huggingface dataset:
Original text:
For each specified "telephone-event" media format, enable DTMF transmission for all supported media formats with the same clockrate, as described in RFC4733, Section 2.5.1.2. <del> If the application attempts to transmit DTMF when using a media format that does not have a corresponding telephone- event format, this MUST result in an error. </del>  For any specified "ptime" value, configure the available media formats to use the specified packet size when sending.

Reviewer comments:
NAME PTAL
On page 69, at "If the application attempt to transmit DTMF when using a media format that does not have a corresponding telephone-event format, this MUST result in an error". This sentence is out-of-place. The section is about applying a remote description. If the document needs to retain the sentence, it belongs off in some "processing media" section. In particular, the current placement of text is confusing about what and when an error could be returned, and it could be misread to say that an error should be returned to the setRemoteDescription call.
I agree
Agreed; I don't really feel like we need to create a new "Sending DTMF" section, so my recommendation would be to adjust the text to something like For each specified "telephone-event" media format, enable DTMF transmission for all supported media formats with the same clockrate, as described in [RFC4733], Section 2.5.1.2. If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats.
LGTM

Revised text:
For each specified "telephone-event" media format, enable DTMF transmission for all supported media formats with the same clockrate, as described in RFC4733, Section 2.5.1.2.  <ins> If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats. </ins> For any specified "ptime" value, configure the available media formats to use the specified packet size when sending.
Original text:
The setDirection method sets the direction of a transceiver, which affects the direction property of the associated m= section on future <del> calls to createOffer and createAnswer. </del>  When creating offers, the transceiver direction is directly reflected in the output, even for re-offers.  When creating answers, the

Reviewer comments:
talks about setting direction properties, but the values that can be set aren't called out (and even then only by inference from a list in an example) in section 4.2.5. Should there be explicit pointers to the api doc here? (And in section 4.2.6?)
Yes, I think a pointer to the API doc is what's needed here.
The more I look at it, I think it is the SDP, not the API doc that effectively defines the allow values of the direction.
LGTM

Revised text:
The setDirection method sets the direction of a transceiver, which affects the direction property of the associated m= section on future  <ins> calls to createOffer and createAnswer.  The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive", mirroring the identically-named directional attributes defined in RFC4566, Section 6. </ins> When creating offers, the transceiver direction is directly reflected in the output, even for re-offers.  When creating answers, the
Original text:
The next step is to generate m= sections, as specified in RFC4566, Section 5.14.  An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped <del> RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. </del>  For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m=

Reviewer comments:
NAME as Justin points out, 3264 explicitly authorizes this.
i'm a bit late but... without this, the following sequence of events is always going to happen: createOffer setLocalDescription onicecandidate(null) / icegatheringstatechange(complete) Executing this snippet in Chrome never shows a candidate. Is that the intended behaviour? Also the ice gathering state stays "new"? My confusion about this is probably related to ;-)
I guess if we need to allow empty SPDs (no m-sections) then ICE related events should fire right away as they know that nothing is going to happen any way.
NAME I don't see why any events need to fire, since ICE gathering never starts in the first place and there are no in that case.
I failed to find any text in webrtc-pc or JSEP which indicates that the createOffer() call should fail if no RtpTransceiver or data channel has been added to a PeerConnection. Webrtc-pc contains the following: But section does not seem to contain any wording indicating to treat the absence of any RtpTransceiver and DataChannel as such an failure. I think such a scenario should be treated as a failure, as I fail to see any value in generating an empty offer.
Good observation. Personally, I'm inclined to allow this, unless it's forbidden by 3264 - we would just generate the session-level values with no m= sections.
3264 indicates that this is OK: The offer will contain zero or more media streams (each media stream is described by an "m=" line and its associated attributes). Zero media streams implies that the offerer wishes to communicate, but that the streams for the session will be added at a later time through a modified offer. I think we should explicitly mention that this is allowed, but otherwise take no action.

Revised text:
The next step is to generate m= sections, as specified in RFC4566, Section 5.14.  An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped  <ins> RtpTransceivers; this is done in the order the RtpTransceivers were added to the PeerConnection.  If there are no such RtpTransceivers, no m= sections are generated; more can be added later, as discussed in RFC3264, Section 5. </ins> For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m=
Original text:
If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its resolution, the encoder SHOULD apply downscaling in order to <del> satisfy the limits, although the downscaling MUST NOT change the picture aspect ratio of the encoding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the attribute MUST NOT be used. </del>  If the encoder resolution is less than the minimum size permitted by the attribute, the attribute MUST NOT be used; the encoder MUST

Reviewer comments:
LGTM.
In spite of what was said at the W3C WebRTC WG virtual meeting yesterday I think the aspect ratio preservation can be an issue also in context of . Just to take as example that the video resolution of the track is 595 by 753 (e.g. capturing a part of the screen) and has limited what can be transmitted to 480 by 640. Scaling according to JSEP section 3.6 (if I read right) gives a transmission resolution of 480 by 607.4621.. but since we can't transmit fractional pixels we would transmit 480 by 607 and have a slight aspect ratio mismatch. The spec should clarify what to do in situations like this.
OK, perhaps then we change this text: the encoder SHOULD apply downscaling in order to satisfy the limits, although the downscaling MUST NOT change the picture aspect ratio of the encoding. to allow for rounding.
Makes sense to me.
LGTM

Revised text:
If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its resolution, the encoder SHOULD apply downscaling in order to  <ins> satisfy the limits.  Downscaling MUST NOT change the picture aspect ratio of the encoding, ignoring any trivial differences due to rounding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the attribute MUST NOT be used. </ins> If the encoder resolution is less than the minimum size permitted by the attribute, the attribute MUST NOT be used; the encoder MUST
Original text:
security considerations for this document. While formally the JSEP interface is an API, it is better to think of <del> it is an Internet protocol, with the application JavaScript being </del>  untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious

Reviewer comments:
I'm sure the RFC editor would have caught this nit: While formally the JSEP interface is an API, it is better to think of it is an Internet protocol s/is an Internet/as an Internet/

Revised text:
security considerations for this document. While formally the JSEP interface is an API, it is better to think of  <ins> it as an Internet protocol, with the application JavaScript being </ins> untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious
Original text:
section for this media type or in the same bundle group as the first m= section for this media type.  Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed:

Reviewer comments:
If an answerer rejects the "offerer tagged" m= section (the one listed first in "a=group:BUNDLE"), the BUNDLE spec requires rejecting all m= sections in the BUNDLE group. This means that stopping one transceiver between setting an offer and creating an answer may potentially cause multiple m= sections to be rejected. See: URL

Revised text:
section for this media type or in the same bundle group as the first m= section for this media type. <ins> This m= section is in a bundle group, and the group's offerer tagged m= section is being rejected due to one of the above reasons.  This requires all m= sections in the bundle group to be rejected, as specified in I-D.ietf-mmusic-sdp-bundle-negotiation, Section 7.3.3. </ins> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed:
Original text:
 The application will BUNDLE all of its media streams, including data channels, on a single transport.  All streams other than the first will be marked as bundle-only.  This policy aims to minimize <del> The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. </del>  As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST

Reviewer comments:
LGTM
lgtm
If you know the remote side is going to use BUNDLE and RTCP mux, it's desirable to only gather a single set of ports, since the RTCP ports won't be used. Since max-bundle is already trying to minimize port gathering, it should probably assume rtcp mux. If there is a need to keep max-bundle as is, we could also add a fourth policy, e.g. force-bundle, that differs from max-bundle in that it forces use of RTCP mux.
I think we need another one, since currently max-bundle is minimally compatible with old endpoints and if you force rtcp-mux, then you will have ann interop problem. That's what I have on my slides now. Feel free to comment.
I can go with whatever the WG decides.
WG decision is to add an additional policy. Name will be force-bundle unless someone comes up with a better one.

Revised text:
<ins> The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. </ins> The application will BUNDLE all of its media streams, including data channels, on a single transport.  All streams other than the first will be marked as bundle-only.  This policy aims to minimize  <ins> Similar to max-bundle, but RTCP candidates are not gathered.  This policy reduces the candidates that must be gathered to the absolute minimum, but will not be compatible with legacy endpoints that do not support RTCP mux. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST
Original text:
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/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". </del>  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:

Reviewer comments:
says: The string is not registered in . Presumably, this text should say .
Opened PR .
Fixed in

Revised text:
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  <ins> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". </ins> 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:
Original text:
An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as <del> specified in RFC4566, Section 6.  For audio, the codecs specified in I-D.ietf-rtcweb-audio, Section 3, MUST be be supported. </del>  If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and <del> RFC3264, Section 6.1.  For audio, the codecs specified in I- D.ietf-rtcweb-audio, Section 3, MUST be supported.  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </del>  If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the

Reviewer comments:
lgtm with justin's comments.
Ping on this
overall this LG for consistency with the surrounding text, I would change the usage of "[XXXX] (see Section 3)" to "[XXXX], Section 3"

Revised text:
An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as  <ins> specified in RFC4566, Section 6.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5). </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and  <ins> RFC3264, Section 6.1.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the
Original text:
the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are declarative, and the remote side MUST either accept them or reject <del> them altogether.  An example of such a parameter is the DTLS fingerprints RFC8122, which are calculated based on the local certificate(s) offered and are not subject to negotiation. </del>  In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an

Reviewer comments:
clarified TLS fingerprints, removed comments, issue 7
7) [rfced] Section 3.2: We do not see any mention of DTLS in RFC 8122; we only see "TLS." Will this citation be clear to readers? Original: An example of such a parameter is the DTLS fingerprints [RFC8122], which are calculated based on the local certificate(s) offered, and are not subject to negotiation. Possibly: An example of such a parameter is the TLS fingerprints [RFC8122] as used in the context of DTLS [RFC6347]; these fingerprints are calculated based on the local certificate(s) offered and are not subject to negotiation.
Comment is correct, suggestion seems reasonable.
NAME please close this issue once you consider it resolved.

Revised text:
the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are declarative, and the remote side MUST either accept them or reject  <ins> them altogether.  An example of such a parameter is the TLS fingerprints RFC8122 as used in the context of DTLS RFC6347; these fingerprints are calculated based on the local certificate(s) offered and are not subject to negotiation. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an
Original text:
setup. When setLocalDescription is eventually called and the JSEP <del> implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the </del>  application immediately via the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components are used or because the pool has not had enough time to

Reviewer comments:
use 'prepares to gather' instead of 'goes to gather', removed comments, issue 9
9) [rfced] We suggest clarifying "goes to gather" - perhaps "gathers", "starts to gather", "prepares to gather", etc. "goes to gather" may be confusing for some readers. Original: When setLocalDescription is eventually called, and the JSEP implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.
'prepares to gather' seems like the right choice.
NAME please close this issue once you consider it resolved.

Revised text:
setup. When setLocalDescription is eventually called and the JSEP  <ins> implementation prepares to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool. If there are candidates in the pool, they SHOULD be handed to the </ins> application immediately via the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components are used or because the pool has not had enough time to
Original text:
actually accepts the call, the application can plug in the real MediaStreamTrack and create a new "sendrecv" offer to update the previous offer/answer pair and start bidirectional media flow.  While <del> this could also be done with a "sendonly" pranswer, followed by a </del>  "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.

Reviewer comments:
used suggestion 2, deleted comments, issue 12
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right

Revised text:
actually accepts the call, the application can plug in the real MediaStreamTrack and create a new "sendrecv" offer to update the previous offer/answer pair and start bidirectional media flow.  While  <ins> this could also be done with a "sendonly" pranswer followed by a </ins> "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
Original text:
This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE <del> is used in full trickle mode with a policy of max-bundle-and-rtcpmux </del>  and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's The SDP for |answer-B1| looks like: <del> The SDP for |offer-B2| looks like: </del>  <del> The SDP for |answer-B2| looks like: </del>  8.

Reviewer comments:
NAME NAME PTAL
This LGTM. Have you run it through a parser? If not, I'm going to give that a shot.
Addressed all comments, save the parser. PTAL.
LGTM. Fluffy?
LGTM - I did not really have time to review it but again, looks close enough I'd like to see it merged into the draft and that will make it easier to fix any nits.

Revised text:
This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE  <ins> is used in full trickle mode with a policy of max-bundle-and-rtcp-mux </ins> and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's The SDP for |answer-B1| looks like:  <ins> The SDP for |candidate-B4| looks like: </ins>  <ins> The SDP for |candidate-B5| looks like: The SDP for |candidate-B6| looks like: The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate the local candidate that was selected) The SDP for |answer-B2| looks like: (note the use of setup:passive to maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way) </ins> 8.