jiebi/TextFlow huggingface dataset:
Original text:
RFC4568 MUST NOT be implemented to signal SDES SRTP keying information. <del> The RFC5888 grouping framework MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. </del>  I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and

Reviewer comments:
Fixed
Cullen, I did some git history rewriting to remove the unnecessary flip-flop around this bullet entry and push -f ed.
LGTM
Section 5.1.1 R-16: TODOs should be deleted before Last Call :-) Also sugggest renumbering the trailing sentence as R-16. Section 5.1.2: Suggest using a different letter on the numbering. U-1 and U-2?

Revised text:
RFC4568 MUST NOT be implemented to signal SDES SRTP keying information.  <ins> RFC5888 MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. </ins> I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and
Original text:
implementations will not transmit non-square pixels, but SHOULD receive and render such video with the correct aspect ratio. However, sample aspect ratio has no impact on the size negotiation <del> described below; all dimensions assume square pixels. </del>  3.6.1.

Reviewer comments:
LGTM
LGTM
The text says "all dimensions assume square pixels". Given the affordance for non-square pixels elsewhere, I think this should say "all dimensions are measured in pixels, whether square or not".
Agreed.

Revised text:
implementations will not transmit non-square pixels, but SHOULD receive and render such video with the correct aspect ratio. However, sample aspect ratio has no impact on the size negotiation  <ins> described below; all dimensions are measured in pixels, whether square or not. </ins> 3.6.1.
Original text:
3.4.2. RtpSenders allow the application to control how RTP media is sent.  3.4.3. <del> RtpReceivers allows the application to control how RTP media is received. </del>  3.5. If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media are available to </del>  send, this will result in the starting of media transmission. 4.1.9. If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media are available to </del>  send, this will result in the starting of media transmission. 4.1.10.

Reviewer comments:
Attempts to address issue . Also changed "control" to "inspect" in RtpReceiver description, since an RtpReceiver is readonly and doesn't let an application control anything.
LGTM
Originally raised by Christer Section 3.4.1 talks about ³RtpTranceivers², ³RtpSenders² and ³RtpReceivers². 1) I think they should be introduced in their own section (not within the Session Description Protocol section). 2) I think it should be explained what an RtpXXX really is. At a minimum there should be a reference to the appropriate W3C document. But, as there is text on how they related to SDP m- lines etc, 1 or 2 sentences describing what they are would also be useful.
Section 3.4.1 is its own section, and explains what the RtpTransceiver is. Agree that Sections 3.4.2/3.4.3 (on senders/receivers) could be expanded somewhat. NAME FYI
Resolved by

Revised text:
3.4.2. RtpSenders allow the application to control how RTP media is sent. <ins> An RtpSender is conceptually responsible for the outgoing RTP stream(s) described by an m= section.  This includes encoding the attached MediaStreamTrack, sending RTP media packets, and generating/ processing RTCP for the outgoing RTP streams(s). </ins> 3.4.3.  <ins> RtpReceivers allow the application to inspect how RTP media is received.  An RtpReceiver is conceptually responsible for the incoming RTP stream(s) described by an m= section.  This includes processing received RTP media packets, decoding the incoming stream(s) to produce a remote MediaStreamTrack, and generating/ processing RTCP for the incoming RTP stream(s). </ins> 3.5. If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final),  <ins> and the media directions are compatible, and media is available to </ins> send, this will result in the starting of media transmission. 4.1.9. If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final),  <ins> and the media directions are compatible, and media is available to </ins> send, this will result in the starting of media transmission. 4.1.10.
Original text:
For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in <del> Section 5.8 of RFC4566.  The implementation can decide how to allocate the available bandwidth between m= sections to simultaneously meet any limits on individual m= sections, as well as this overall session limit. </del>  For any specified "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.

Reviewer comments:
Originally raised by Magnus: o For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in Section 5.8 of [RFC4566]. The implementation can decide how to allocate the available bandwidth between m= sections to simultaneously meet any limits on individual m= sections, as well as this overall session limit. I think this text can be improved to make it clearer that CT doesn't imply a fixed over time divide of the bandwidth between RTP streams. As long as individual media sources streams stay within other requirements such as b=AS/TIAS they can be changed dynamically.
Makes sense.

Revised text:
For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in  <ins> Section 5.8 of RFC4566.  Within this overall limit, the implementation can dynamically decide how to best allocate the available bandwidth between m= sections, respecting any specific limits that have been specified for individual m= sections. </ins> For any specified "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.
Original text:
RFC4588 MUST be implemented to signal RTX payload type associations. <del> RFC3556 with bandwidth modifiers MAY be supported for specifying RTCP bandwidth as a fraction of the media bandwidth, RTCP fraction allocated to the senders and setting maximum media bit-rate boundaries. </del>  As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.

Reviewer comments:
I agree that this text is correct. I have no strong opinion on whether we should make the change...
Proposed text:
This seems satisfactory to me. You have my preemptive LGTM

Revised text:
RFC4588 MUST be implemented to signal RTX payload type associations.  <ins> RFC3556 MUST be supported for control of RTCP bandwidth limits. </ins> As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.
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 <del> that has been added to the PeerConnection.  This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . </del>  Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique

Reviewer comments:
Originally raised by Magnus: This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . I am bit surprised to see "recycled" on a list of things that may occur in generating an initial offer? Can that really occur?
check this - prob editorial

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  <ins> that has been added to the PeerConnection, excluding any stopped RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique
Original text:
section for all Source RTP Streams using the specified media formats.  Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified <del> in RFC4585, Section 4.2.  When sending RTCP feedback, use the SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC; if no outgoing Source RTP Stream exists, choose a random one. </del>  If the directional attribute is of type "recvonly" or "inactive", stop transmitting all RTP media, but continue

Reviewer comments:
Originally raised by Magnus: When sending RTCP feedback, use the SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC; if no outgoing Source RTP Stream exists, choose a random one. This is okay, but could be slightly more open in regards to sending feedback packets efficiently. Section 5.4.1 in URL is providing more detailed rules for things to consider.
Magnus, what do you think is needed here. Informative ref ?
A reference would be good. I would consider cutting away the explicit recommendation here and only say that "When sending RTCP feedback, follow the rules and recommendations in Section 5.4.1 of [draft-ietf-avtcore-rtp-multi-stream] to select which SSRC to use."

Revised text:
section for all Source RTP Streams using the specified media formats.  Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified  <ins> in RFC4585, Section 4.2.  When sending RTCP feedback, follow the rules and recommendations from I-D.ietf-avtcore-rtp-multi- stream, Section 5.4.1 to select which SSRC to use. </ins> If the directional attribute is of type "recvonly" or "inactive", stop transmitting all RTP media, but continue
Original text:
4.2.2. <del> The stopped method returns "true" if the transceiver has been </del>  stopped, either by a call to stopTransceiver or by applying an answer <del> that rejects the associated m= section, and "false" otherwise. </del>  A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.

Reviewer comments:
stopped The stopped method returns "true" if the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section, and "false" otherwise. [BA] This should be rewritten as follows:
Agree, there is precedent for this regarding the canTrickleIceCandidates property in URL We should make these consistent (note use of 'property' vs 'attribute')

Revised text:
4.2.2.  <ins> The stopped property indicates whether the transceiver has been </ins> stopped, either by a call to stopTransceiver or by applying an answer  <ins> that rejects the associated m= section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </ins> A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.
Original text:
possible forms of initial candidates - host, server reflexive, and relay.  However, in certain cases, applications may want to have more specific control over the gathering process, due to privacy or <del> related concerns.  For example, one may want to suppress the use of host candidates, to avoid exposing information about the local network, or go as far as only using relay candidates, to leak as little location information as possible (note that these choices come with corresponding operational costs).  To accomplish this, the browser MUST allow the application to restrict which ICE candidates are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- D.ietf-rtcweb-ip-handling. </del>  There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime

Reviewer comments:
It’s an API requirement, so the MUST doesn’t belong here. Also remove discussion of application filtering of local addresses, which is no longer believed to be useful.
Originally raised by Christer Section 3.5.3 contains requirements regarding what a browser MUST do - e.g., allowing the application to select what types of ICE candidates are used. 1) I am not sure why such requirements are listed here. But, in any case, is there a mechanism for applications for selecting candidate types etc? If so, what mechanism?
This is ICE policy. Editorial
Suggested revision: to

Revised text:
possible forms of initial candidates - host, server reflexive, and relay.  However, in certain cases, applications may want to have more specific control over the gathering process, due to privacy or  <ins> related concerns.  For example, one may want to only use relay candidates, to leak as little location information as possible (keeping in mind that this choice comes with corresponding operational costs).  To accomplish this, JSEP allows the application to restrict which ICE candidates are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I-D.ietf-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime
Original text:
3.3. <del> In the WebRTC specification, session descriptions are formatted as SDP messages.  While this format is not optimal for manipulation from Javascript, it is widely accepted, and frequently updated with new features.  Any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity.  As a result, JSEP currently uses SDP as the internal representation for its session descriptions. </del>  However, to simplify Javascript processing, and provide for future flexibility, the SDP syntax is encapsulated within a

Reviewer comments:
Also, remove awkward reference to WebRTC spec
Originally raised by Christer Section 3.3 says: "In the WebRTC specification, session descriptions are formatted as SDP messages." 1) To me it is unclear what an ³SDP message² is, so I suggest we say ³SDP syntax², as we also do later in the section.
FWIW, RFC 4566 itself uses the term 'SDP message' in Section 7. However, we could say 'descriptions use SDP syntax' instead.

Revised text:
3.3.  <ins> JSEP's session descriptions use SDP syntax for their internal representation.  While this format is not optimal for manipulation from Javascript, it is widely accepted, and frequently updated with new features; any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity. </ins> However, to simplify Javascript processing, and provide for future flexibility, the SDP syntax is encapsulated within a
Original text:
As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote description and their own local and remote addresses.  The media flow <del> from these sessions can be managed by specifying SDP direction attributes in the descriptions, or the application can choose to play </del>  out the media from all sessions mixed together.  Of course, if the application wants to only keep a single session, it can simply terminate the sessions that it no longer needs.

Reviewer comments:
LGTM
Section 3.8.2 - "the media flow from these sessions can be managed by specifying SDP direction attributes in the descriptions". This seems out of place. Surely flipping URL is a much simpler way of managing them if the problem is what to play to the user? Suggestion: Remove text.

Revised text:
As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote description and their own local and remote addresses.  The media flow  <ins> from these sessions can be managed using setDirection (see sec.transceiver-set-direction), or the application can choose to play </ins> out the media from all sessions mixed together.  Of course, if the application wants to only keep a single session, it can simply terminate the sessions that it no longer needs.
Original text:
5.8. The following steps are performed at the media engine level to apply <del> a local description. </del>  First, the parsed parameters are checked to ensure that they have not been altered after their generation in createOffer/createAnswer, as 5.9.  If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. <del> The following steps are performed at the media engine level to apply a remote description. </del> The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.

Reviewer comments:
Plan is to write the text in the apply local/remote sections to indicate that upon an error, the session state should be restored to the pre-call state.

Revised text:
5.8. The following steps are performed at the media engine level to apply  <ins> a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. </ins> First, the parsed parameters are checked to ensure that they have not been altered after their generation in createOffer/createAnswer, as 5.9. <ins> The following steps are performed to apply a remote description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. </ins> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false.  The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.
Original text:
specific "a=imageattr" attributes MUST be inserted for each payload type. <del> As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this </del>  attribute: <del> a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] </del>  This declaration indicates that the receiver is capable of decoding <del> any image resolution from 16x16 up to 640x360 pixels. </del>  3.6.2.

Reviewer comments:
This is from the Windows HW offload framework, and spells things out more specifically in the surrounding text.

Revised text:
specific "a=imageattr" attributes MUST be inserted for each payload type.  <ins> As an example, consider a system with a multiformat video decoder, which is capable of decoding any resolution from 48x48 to 720p, and where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this </ins> attribute:  <ins> a=imageattr:* recv [x=[48:640],y=[48:360],q=1.0] </ins> This declaration indicates that the receiver is capable of decoding  <ins> any image resolution from 48x48 up to 640x360 pixels. </ins> 3.6.2.
Original text:
setLocalDescription will succeed when it attempts to acquire those resources. <del> Calling this method may do things such as generate new ICE </del>  credentials, but does not result in candidate gathering, or cause <del> media to start or stop flowing. </del>  4.1.7. usable by setLocalDescription; like createOffer, the returned description should reflect the current state of the system. <del> Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media state. </del>  4.1.8.

Reviewer comments:
NAME has given his thumbs up as well.
Originally raised by Christer Section 3.2 says: "To support this, the JSEP media layer can provide an offer via the createOffer() method whenever the Javascript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer. The state machine for this is as follows:" 1) I would like to explicitly note that the generated offer is not applied (and any previously applied offer is not removed) until setLocalDescription() is called.
OK. In this case, we should note this for the provisional answers as well.
I thought about this for a while and came to the conclusion that this is the wrong place for such text; spelling everything out makes the overall message less clear. If we need to be super-prescriptive about the fact that the offer does not take effect until after setLD is called, we should state this in the createOffer/Answer sections (4.1.5/4.1.6), not here. NAME PTAL.
Will update document according to my last comment.
See PR
PR looks ok.

Revised text:
setLocalDescription will succeed when it attempts to acquire those resources.  <ins> Calling this method may do things such as generating new ICE </ins> credentials, but does not result in candidate gathering, or cause  <ins> media to start or stop flowing.  Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.7. usable by setLocalDescription; like createOffer, the returned description should reflect the current state of the system.  <ins> 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 does not become the pending local description, until setLocalDescription is called. </ins> 4.1.8.