jiebi/TextFlow huggingface dataset:
Original text:
RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF <del> RFC5764 and TCP/TLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- </del>  registration RTP profiles. RFC5245 MUST be implemented for signaling the ICE credentials and

Reviewer comments:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Revised text:
RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF  <ins> RFC5764 and TCP/DTLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- </ins> registration RTP profiles. RFC5245 MUST be implemented for signaling the ICE credentials and
Original text:
5.1.3. For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ <del> RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of </del>  these two profiles for each media m= line they produce in an offer. <del> For data m= sections, JSEP endpoints must support both the "UDP/TLS/ SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two </del>  profiles for each data m= line they produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually

Reviewer comments:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Revised text:
5.1.3. For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/  <ins> RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of </ins> these two profiles for each media m= line they produce in an offer.  <ins> For data m= sections, JSEP endpoints must support both the "UDP/DTLS/ SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two </ins> profiles for each data m= line they produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually
Original text:
compatible mode and use AVP timing, i.e., "trr-int=4". For data m= sections, JSEP endpoints MUST support receiving the <del> "UDP/ TLS/SCTP", "TCP/TLS/SCTP", or "DTLS/SCTP" (for backwards </del>  compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile

Reviewer comments:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Revised text:
compatible mode and use AVP timing, i.e., "trr-int=4". For data m= sections, JSEP endpoints MUST support receiving the  <ins> "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards </ins> compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile
Original text:
To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the <del> default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as </del>  specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport.

Reviewer comments:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Revised text:
To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the  <ins> default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as </ins> specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport.
Original text:
Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" <del> and the <proto> field MUST be set to "UDP/TLS/SCTP" if the default candidate uses UDP transport, or "TCP/TLS/SCTP" if the default </del>  candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in

Reviewer comments:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Revised text:
Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application"  <ins> and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default </ins> candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in
Original text:
Specific processing MUST also be applied for the following attribute lines: <del> If present, a single "a=ice-lite" line is parsed as specified in RFC5245, Section 15.3, and a value indicating the presence of ice- lite is stored. </del> If present, a single "a=ice-ufrag" line is parsed as specified in RFC5245, Section 15.4, and the ufrag value is stored.

Reviewer comments:
LGTM
http://rtcweb-URL mentions its use at media level; this should be clarified.

Revised text:
Specific processing MUST also be applied for the following attribute lines:  If present, a single "a=ice-ufrag" line is parsed as specified in RFC5245, Section 15.4, and the ufrag value is stored.
Original text:
BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- bundle-negotiation.  Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will <del> offer a single BUNDLE group across all media sections.  However, by specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non-BUNDLE-aware endpoint. When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: </del>  The first media section of each type (audio, video, or application) will contain transport parameters, which will allow

Reviewer comments:
LGTM
Overall looks good - added some minor suggestions
lgtm
F. Section 4.1.1: Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will offer a single BUNDLE group across all media sections. I think this sentence may be a bit misleading without additional sentence(s) to explain that the actual number of established transport streams will depend on the peer's response to the attempt to bundle.
OK. This could be resolved by adding a final sentence of the form "Of course, the answerer can choose whether or not to accept BUNDLE".

Revised text:
BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- bundle-negotiation.  Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will  <ins> offer a single BUNDLE group across all media section; use of this single transport is contingent upon the answerer accepting BUNDLE. However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non- BUNDLE-aware endpoint.  When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: </ins> The first media section of each type (audio, video, or application) will contain transport parameters, which will allow
Original text:
present, but an "AS" value is specified, generate a "TIAS" value using this formula: <del> TIAS = AS * 0.95 - 50 * 40 * 8 </del>  The 50 is based on 50 packets per second, the 40 is based on an <del> estimate of total header size, and the 0.95 is to allocate 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </del>  For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.

Reviewer comments:
b=TIAS is specified in bits per second, b=AS in kbps. Hence the formula needs to multiply by 1000 to change units. Thanks NAME for catching this in code review.
Even though I noticed it in the code review I had not noticed it as an issue in the spec. Good catch!
nice catch - lgtm with minor comment
LGTM
LGTM to me as well. I updated the text in

Revised text:
present, but an "AS" value is specified, generate a "TIAS" value using this formula:  <ins> TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 </ins> The 50 is based on 50 packets per second, the 40 is based on an  <ins> estimate of total header size, the 1000 is to change the unit from kbps to bps and the 0.95 is to allocate 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.
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 via the addTrack, addTransceiver, and setRemoteDescription methods.  [[OPEN ISSUE: move discussion of setRemoteDescription to the subsequent-offer section.]] This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTranscievers 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:
LGTM
WFM. NAME PTAL
The current draft suggests moving the discussion of setRemoteDescription: [[OPEN ISSUE: move discussion of setRemoteDescription to the subsequent-offer section.]]

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.  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) . </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:
4.1.3. <del> [TODO] </del>  4.1.4.

Reviewer comments:
NAME
NAME PTAL
LG with nits
para break and typo comment were missed
In the current draft we have addTransceiver [TODO] We need this text before WGLC, so it's being added to the punchlist.

Revised text:
4.1.3.  <ins> The addTransceiver method adds a new RTPTransceiver to the PeerConnection.  If a MediaStreamTrack argument is provided, then the transceiver will be configured with that media type and the track will be attached to the transceiver.  Otherwise, the application MUST explicitly specify the type; this mode is useful for creating recvonly transceivers as well as for creating transceivers to which a track can be attached at some later point.  At the time of creation, the application can also specify a transceiver direction attribute, a set of MediaStreams which the transceiver is associated with (allowing LS group assignments), and a set of encodings for the media (used for simulcast as desccribed in sec.simulcast). </ins> 4.1.4.
Original text:
For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of <del> RFC5285.  If any indicated RTP header extension is unknown, this MUST result in an error. </del>  If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension, as described in I-D.ietf-mmusic-msid, Section 3.2. <del> For each specified payload type, establish a mapping between the payload type ID and the actual media format, as described in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </del>  For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload

Reviewer comments:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Revised text:
For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of  <ins> RFC5285.  If any indicated RTP header extension is not supported, this MUST result in an error. </ins> If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension, as described in I-D.ietf-mmusic-msid, Section 3.2.  <ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in RFC3264, Section 6.1.  If any indicated media format is not supported, this MUST result in an error. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload
Original text:
If the media section proto value indicates use of RTP: <del> [TODO: header extensions] </del> If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by setting its mid attribute to null.

Reviewer comments:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Revised text:
If the media section proto value indicates use of RTP:  If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by setting its mid attribute to null.
Original text:
[TODO: handling of CN, telephone-event, "red"] <del> If the media section if of type audio: </del>  For any specified "ptime" value, configure the available <del> payload types to use the specified packet size.  If the specified size is not supported for a payload type, use the </del>  next closest value instead. Finally, if this description is of type "pranswer" or "answer",

Reviewer comments:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Revised text:
[TODO: handling of CN, telephone-event, "red"]  <ins> If the media section is of type audio: </ins> For any specified "ptime" value, configure the available  <ins> media formats to use the specified packet size.  If the specified size is not supported for a media format, use the </ins> next closest value instead. Finally, if this description is of type "pranswer" or "answer",
Original text:
If the media section proto value indicates use of RTP:  If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in RFC5761, Section 5.1.3.  Otherwise,

Reviewer comments:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Revised text:
If the media section proto value indicates use of RTP: <ins> If the media section references any media formats, RTP header extensions, or RTCP feedback mechanisms that were not present in the corresponding media section in the offer, this indicates a negotiation problem and MUST result in an error. </ins> If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in RFC5761, Section 5.1.3.  Otherwise,
Original text:
the RTCP transmission for this media section to use reduced- size RTCP, as specified in RFC5506.  If the directional attribute in the answer is of type "sendrecv" or "sendonly", prepare to start transmitting media <del> using the specified primary SSRC and one of the selected payload types, once the underlying transport layers have been established.  If RID values are specified, include the RID header extension in the RTP streams, as indicated in I-D.ietf- mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic- sdp-simulcast, Section 6.2.2.  If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </del>  If the media section proto value indicates use of SCTP:

Reviewer comments:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Revised text:
the RTCP transmission for this media section to use reduced- size RTCP, as specified in RFC5506. <ins> [TODO: enable appropriate rtcp-fb mechanisms] </ins> If the directional attribute in the answer is of type "sendrecv" or "sendonly", prepare to start transmitting media  <ins> using 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, once the underlying transport layers have been established.  [TODO: add discusssion of RED/FEC/RTX/CN] The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams.  Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the RID header extension has been negotiated, and RID values are specified, include the RID header extension in the outgoing RTP streams, as indicated in I-D.ietf-mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic-sdp-simulcast, Section 6.2.2. If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </ins> If the media section proto value indicates use of SCTP: