jiebi/TextFlow huggingface dataset:
Original text:
4.2.4.  The setCodecPreferences method sets the codec preferences of a transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and

Reviewer comments:
This distinguishes between the direction which was last set via setDirection (which simply affects offer/answer generation) from the direction that was negotiated, which affects whether a transceiver can send/recv media. Addresses issue .
According to WebRTC 1.0 Section 5.4 setDirection() does not take effect immediately: "The setDirection method sets the direction of the RTCRtpTransceiver. Calls to setDirection() do not take effect immediately. Instead, future calls to createOffer and createAnswer mark the corresponding media description as sendrecv, sendonly, recvonly or inactive as defined in [JSEP] (section 5.2.2. and section 5.3.2.). Calling setDirection() sets the negotiation-needed flag." My interpretation of the above is that setDirection immediately sets the transceiver.direction attribute, but that the "current direction" (distinct from the direction attribute) is only changed by calls to setLocal/setRemoteDescription. I would like to suggest that JSEP indicate precisely when the "current direction" changes. My reading of JSEP is that this is determined from the currentLocalDescription and currentRemoteDescription. For example: The direction provided in the currentLocalDescription (e.g. the "current direction") is "sendrecv" and setDirection("recvonly") is called. Since setDirection does not change the direction in currentLocalDescription, the RtpSender does not stop sending. createOffer() is called. A "recvonly" offer is generated. setLocalDescription(RecvOnlyOffer) is called. Now the direction in pendingLocalDescription changes to "recvonly", but the direction in currentLocalDescription is still "sendrecv", so the RtpSender does not stop sending. setRemoteDescription(SendOnlyAnswer) is called. Now the direction in currentLocalDescription is "recvonly", so the RtpSender will stop sending.
Bernard's description makes sense to me; currentLocal/Remote indicate the current direction state.
Fixed by

Revised text:
4.2.4. <ins> The direction method returns the last value passed into setDirection. If setDirection has never been called, it returns the direction the transceiver was initialized with. 4.2.5. The currentDirection method returns the last negotiated direction for the transceiver's associated m= section.  More specifically, it returns the RFC3264 directional attribute of the associated m= section in the last applied answer, with "send" and "recv" directions reversed if it was a remote answer.  For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection returns "sendonly". If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection returns null. 4.2.6. </ins> The setCodecPreferences method sets the codec preferences of a transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and
Original text:
3.7. <del> JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </del>  Applications request support for simulcast by configuring multiple encodings on an RTPSender, which, upon generation of an offer or

Reviewer comments:
Originally raised by Magnus: Section 3.7: JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section. I think this should be explcit that it is "simulcast transmission of a MediaStreamTrack".

Revised text:
3.7.  <ins> JSEP supports simulcast transmission of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </ins> Applications request support for simulcast by configuring multiple encodings on an RTPSender, which, upon generation of an offer or
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, TCP/DTLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- registration, "UDP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. </del>  RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE

Reviewer comments:
Originally raised by Magnus: Section 5.1.1: R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF [RFC5764], TCP/DTLS/RTP/SAVPF [I-D.nandakumar-mmusic-proto-iana-registration], "UDP/DTLS/ SCTP" [I-D.ietf-mmusic-sctp-sdp], and "TCP/DTLS/SCTP" [I-D.ietf-mmusic-sctp-sdp] RTP profiles. I would note that [I-D.nandakumar-mmusic-proto-iana-registration] is actually published as RFC 7850. Section 5.1.1: R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and RTCP. This should include the updated as ref also.

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, TCP/DTLS/RTP/SAVPF RFC7850, "UDP/DTLS/SCTP" I-D.ietf- mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. </ins> RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE
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 default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as <del> specified in I-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport. </del>  If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and

Reviewer comments:
Originally raised by Magnus: Section 5.1.1: R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF [RFC5764], TCP/DTLS/RTP/SAVPF [I-D.nandakumar-mmusic-proto-iana-registration], "UDP/DTLS/ SCTP" [I-D.ietf-mmusic-sctp-sdp], and "TCP/DTLS/SCTP" [I-D.ietf-mmusic-sctp-sdp] RTP profiles. I would note that [I-D.nandakumar-mmusic-proto-iana-registration] is actually published as RFC 7850. Section 5.1.1: R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and RTCP. This should include the updated as ref also.

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 default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as  <ins> specified in RFC7850 if the default candidate uses TCP transport. </ins> If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and
Original text:
clearer. Session Information ("i="), URI ("u="), Email Address ("e="), <del> Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </del>  Encryption Keys ("k=") lines do not provide sufficient security and MUST NOT be included.

Reviewer comments:
Originally raised by Magnus: Section 5.2.1: o Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. Considering that b=CT is not useless, I am a bit surprised to see b= on this list. Yes, b=CT: is only useful is one like to provide a upper total bandwidth limitation. So, maybe some discussion of the possible choice?
This is just a mistake in 5.2.1 - we cover how to deal with it later in section 5. Prob need to remove the mention of b= here.

Revised text:
clearer. Session Information ("i="), URI ("u="), Email Address ("e="),  <ins> Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </ins> Encryption Keys ("k=") lines do not provide sufficient security and MUST NOT be included.
Original text:
JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer() API.  The <del> application optionally modifies that offer, and then uses it to set up its local config via the setLocalDescription() API.  The offer is then sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </del>  To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it

Reviewer comments:
Did we not decide that modifying that offer (or an answer created by createAnswer()) is not allowed?
Agreed. This text should be culled.

Revised text:
JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer() API.  The  <ins> application then uses that offer to set up its local config via the setLocalDescription() API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </ins> To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it
Original text:
the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the <del> remaining candidates are gathered as usual. </del>  One example of where this concept is useful is an application that expects an incoming call at some point in the future, and wants to

Reviewer comments:
The pool is only used in the first offer/answer exchange. After applying a local description, the pool size is frozen and changing the ICE servers will not result in new candidates being pooled. After an answer is applied, any leftover candidates are discarded. This only happens when applying an answer so that candidates aren't prematurely discarded for use cases that involve pranswer, or multiple offers.
I can live with this as is. Want to read again if we end up making changes to address EKR comments
Updated PR and its description based on our discussion.

Revised text:
the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the  <ins> remaining candidates are gathered as usual.  This only occurs for the first offer/answer exchange, after which the candidate pool is emptied and no longer used. </ins> One example of where this concept is useful is an application that expects an incoming call at some point in the future, and wants to
Original text:
createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used.  If the ICE candidate pool has <del> a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </del>  Any change to the ICE candidate policy affects the next gathering phase.  If an ICE gathering phase has already started or

Reviewer comments:
The pool is only used in the first offer/answer exchange. After applying a local description, the pool size is frozen and changing the ICE servers will not result in new candidates being pooled. After an answer is applied, any leftover candidates are discarded. This only happens when applying an answer so that candidates aren't prematurely discarded for use cases that involve pranswer, or multiple offers.
I can live with this as is. Want to read again if we end up making changes to address EKR comments
Updated PR and its description based on our discussion.

Revised text:
createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used.  If the ICE candidate pool has  <ins> a nonzero size, and a local description has not yet been applied, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </ins> Any change to the ICE candidate policy affects the next gathering phase.  If an ICE gathering phase has already started or
Original text:
until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. <del> Any changes to the ICE candidate pool size take effect </del>  immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded.

Reviewer comments:
The pool is only used in the first offer/answer exchange. After applying a local description, the pool size is frozen and changing the ICE servers will not result in new candidates being pooled. After an answer is applied, any leftover candidates are discarded. This only happens when applying an answer so that candidates aren't prematurely discarded for use cases that involve pranswer, or multiple offers.
I can live with this as is. Want to read again if we end up making changes to address EKR comments
Updated PR and its description based on our discussion.

Revised text:
until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates.  <ins> The ICE candidate pool size MUST NOT be changed after applying a local description.  If a local description has not yet been applied, any changes to the ICE candidate pool size take effect </ins> immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded.
Original text:
accordingly, as described in I-D.ietf-mmusic-sdp-bundle-negotiation, Section 8.2.  6. Note: The following algorithm does not yet have WG consensus but is

Reviewer comments:
The pool is only used in the first offer/answer exchange. After applying a local description, the pool size is frozen and changing the ICE servers will not result in new candidates being pooled. After an answer is applied, any leftover candidates are discarded. This only happens when applying an answer so that candidates aren't prematurely discarded for use cases that involve pranswer, or multiple offers.
I can live with this as is. Want to read again if we end up making changes to address EKR comments
Updated PR and its description based on our discussion.

Revised text:
accordingly, as described in I-D.ietf-mmusic-sdp-bundle-negotiation, Section 8.2. <ins> If the description is of type "answer", and there are still remaining candidates in the ICE candidate pool, discard them. </ins> 6. Note: The following algorithm does not yet have WG consensus but is
Original text:
but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. <del> The JSEP implementation will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather. Applying a description with an m= section that does not contain an "a=rtcp-mux" attribute will cause an error to be returned. </del>  The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to

Reviewer comments:
I applied the following principles, which unfortunately are somewhat inconsistent with the current mux-exclusive draft. You use a=rtcp-mux to negotiate mux a=rtcp-mux-only is used by the offerer to say "I really mean it" To that end, offers contain a=rtcp-mux-only if the policy is require. Answers don't contain it because you don't need it to negotiate mux.
Those principles are consistent with bundle-only, although I wrote the mux-only examples as if mux-only should always be included whenever a=rtcp-mux is present.
NAME back at you
NAME ping
LG

Revised text:
but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints.  <ins> The JSEP implementation will only gather RTP candidates and will insert an "a=rtcp-mux-only" indication into any offers it generates.  This halves the number of candidates that the offerer needs to gather.  Applying a description with an m= section that does not contain an "a=rtcp-mux" attribute will cause an error to be returned. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to
Original text:
An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.3.  An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. Lastly, if a data channel has been created, a m= section MUST be

Reviewer comments:
I applied the following principles, which unfortunately are somewhat inconsistent with the current mux-exclusive draft. You use a=rtcp-mux to negotiate mux a=rtcp-mux-only is used by the offerer to say "I really mean it" To that end, offers contain a=rtcp-mux-only if the policy is require. Answers don't contain it because you don't need it to negotiate mux.
Those principles are consistent with bundle-only, although I wrote the mux-only examples as if mux-only should always be included whenever a=rtcp-mux is present.
NAME back at you
NAME ping
LG

Revised text:
An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.3. <ins> If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4. </ins> An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. Lastly, if a data channel has been created, a m= section MUST be
Original text:
The "a=rtcp-mux" line MUST only be added if present in the most recent answer. <del> The "a=rtcp-mux-only" line MUST only be added if present in the most recent answer. </del> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.

Reviewer comments:
I applied the following principles, which unfortunately are somewhat inconsistent with the current mux-exclusive draft. You use a=rtcp-mux to negotiate mux a=rtcp-mux-only is used by the offerer to say "I really mean it" To that end, offers contain a=rtcp-mux-only if the policy is require. Answers don't contain it because you don't need it to negotiate mux.
Those principles are consistent with bundle-only, although I wrote the mux-only examples as if mux-only should always be included whenever a=rtcp-mux is present.
NAME back at you
NAME ping
LG

Revised text:
The "a=rtcp-mux" line MUST only be added if present in the most recent answer.  The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.
Original text:
attribute MUST NOT be specified. If the RTP/RTCP multiplexing policy is "require", each m= section <del> MUST contain an "a=rtcp-mux" attribute. </del>  If this session description is of type "pranswer" or "answer", the following additional checks are applied:

Reviewer comments:
I applied the following principles, which unfortunately are somewhat inconsistent with the current mux-exclusive draft. You use a=rtcp-mux to negotiate mux a=rtcp-mux-only is used by the offerer to say "I really mean it" To that end, offers contain a=rtcp-mux-only if the policy is require. Answers don't contain it because you don't need it to negotiate mux.
Those principles are consistent with bundle-only, although I wrote the mux-only examples as if mux-only should always be included whenever a=rtcp-mux is present.
NAME back at you
NAME ping
LG

Revised text:
attribute MUST NOT be specified. If the RTP/RTCP multiplexing policy is "require", each m= section  <ins> MUST contain an "a=rtcp-mux" attribute.  If an "m=" section contains an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:
Original text:
excluded by subsequent calls to createOffer and createAnswer, in which case the corresponding media formats in the associated m= section will be excluded.  The codec preferences cannot add media <del> formats that would otherwise not be present.  This includes codecs that were not negotiated in a previous offer/answer exchange that included the transceiver. </del>  The codec preferences of an RtpTransceiver can also determine the order of codecs in subsequent calls to createOffer and createAnswer,

Reviewer comments:
LGTM and if Justin wants to tie in the stuff from my comment a bit more that is great
NAME PTAL
seems like it's generally right,LGTM

Revised text:
excluded by subsequent calls to createOffer and createAnswer, in which case the corresponding media formats in the associated m= section will be excluded.  The codec preferences cannot add media  <ins> formats that would otherwise not be present. </ins> The codec preferences of an RtpTransceiver can also determine the order of codecs in subsequent calls to createOffer and createAnswer,
Original text:
For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in <del> RFC3264, Section 6., and further processing for this m= section can be skipped: </del>  The associated RtpTransceiver has been stopped. <del> No supported codec is present in the offer. </del>  The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section.

Reviewer comments:
LGTM and if Justin wants to tie in the stuff from my comment a bit more that is great
NAME PTAL
seems like it's generally right,LGTM

Revised text:
For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in  <ins> RFC3264, Section 6, and further processing for this m= section can be skipped: </ins> The associated RtpTransceiver has been stopped.  <ins> None of the offered media formats are supported and, if applicable, allowed by codec preferences. </ins> The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section.