jiebi/TextFlow huggingface dataset:
Original text:
a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0]  3.5.2. RFC6236 defines "a=imageattr" to be an advisory field.  This means of a given MediaStreamTrack, which is producing video of a certain resolution, receives an "a=imageattr recv" attribute, it MUST first check to see if the original resolution meets the criteria specified <del> in the attribute, and transmit it untouched if so.  If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to satisfy the criteria. </del>  If the receiver requires a minimum resolution which is greater than the native resolution of the video, upscaling is needed, but this may

Reviewer comments:
LGTM
C. Section 3.6.1: 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 implemention would generate this attribute: a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] Maybe this example should discuss the minimal aspect of this. What it really is expressing in that it can handle any resolution between 16x16 pixels up to 640x360 as the longest in respective side. No limitations to any picture aspect ratio. That the examples expresses this is missing in the example text.
I think this is a realistic example, so I suggest we just add more descriptive text.

Revised text:
a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] <ins> This declaration indicates that the receiver is capable of decoding any image resolution from 16x16 up to 640x360 pixels. </ins> 3.5.2. RFC6236 defines "a=imageattr" to be an advisory field.  This means of a given MediaStreamTrack, which is producing video of a certain resolution, receives an "a=imageattr recv" attribute, it MUST first check to see if the original resolution meets the criteria specified  <ins> in the attribute, and transmit it untouched if so.  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used.  This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to satisfy the criteria. </ins> If the receiver requires a minimum resolution which is greater than the native resolution of the video, upscaling is needed, but this may
Original text:
a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. <del> Any changes to the ICE candidate policy also affect the next gathering phase.  If the policy is being made more liberal (i.e., more permitted candidates), and an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set.  If the policy is being made more strict, no ICE restart is needed, and the bit will not be set.  Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application 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 immediately; if increased, additional candidates are pre-gathered;

Reviewer comments:
Also making the "need-ice-restart" bit get set for ANY policy change, rather than just more restrictive changes, to go along with this warning.
Needs merge to master
LGTM
lgtm
LGTM
If a candidate is in use and Policy changes such that this candidate is not longer allowed, do we have text that says to stop using that candidate and restart ice?
yes, I think this is covered in the setConfiguration text. Do you want to look and see if there is anything missing?
The current text says no ICE restart happens here, and it's not clear it should, since the cat is already out of the bag. Eric is going to look at adding a warning mentioning this.
Discussed in Kirkland and we think it is simplest to trigger ICE restart regardless of which way the policy changes.

Revised text:
a nonzero size, 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 completed, the 'needs-ice-restart' bit will be set.  Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </ins> Any changes to the ICE candidate pool size take effect immediately; if increased, additional candidates are pre-gathered;
Original text:
the remote VAD algorithm. If the "VoiceActivityDetection" option is specified, with a value of <del> "false", the browser MUST NOT omit "CN" codecs.  For codecs that have </del>  their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired.  For example, when

Reviewer comments:
Seems like an important distinction. I went with "MUST NOT emit", though "MUST omit" could work too.
wow lgtm

Revised text:
the remote VAD algorithm. If the "VoiceActivityDetection" option is specified, with a value of  <ins> "false", the browser MUST NOT emit "CN" codecs.  For codecs that have </ins> their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired.  For example, when
Original text:
and/or pending remote description according to the rules defined for Trickle ICE.  Connectivity checks will be sent to the new candidate.  This call will result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity being established. candidates, as described in Section 5.7 of RFC5245 and start connectivity checks with the appropriate credentials.  If the media section proto value indicates use of RTP: [TODO: header extensions]

Reviewer comments:
Specifically, "addIceCandidate" and "Applying a Remote Description".
I'm fine this however it ends up. I will r+ this and people can merge it once it is done. Thanks
Just adding a still LGTM
lgtm once my comment from today is addressed

Revised text:
and/or pending remote description according to the rules defined for Trickle ICE.  Connectivity checks will be sent to the new candidate. <ins> This method can also be used to provide an end-of-candidates indication (as defined in I-D.ietf-ice-trickle) to the ICE Agent for all media descriptions in the last remote description. </ins> This call will result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity being established. candidates, as described in Section 5.7 of RFC5245 and start connectivity checks with the appropriate credentials. <ins> If an "a=end-of-candidates" attribute is present, process the end- of-candidates indication as described in I-D.ietf-ice-trickle Section 11. </ins> If the media section proto value indicates use of RTP: [TODO: header extensions]
Original text:
D.ietf-ice-trickle, Section 4, is only included if such an option was present in the offer. <del> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one referenced RtpTransceiver, a group of type "LS" MUST be added that contains the mid values for each RtpTransceiver added with that MediaStream.  In some cases this may result in adding a mid to a given LS group that was not in that LS group in the associated offer.  Although this is not allowed by RFC5888, it is allowed when implementing this specification.  [[OPEN ISSUE: This is still under discussion.  See: https://github.com/rtcweb-wg/jsep/issues/162.]] </del>  The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in RFC3264, Section 6.  For

Reviewer comments:
Replaces URL
NAME this just flattens all the changes in last PR to the final thin and puts it onto new base with no merge issue. Still needs changes to align with new sender / receiver objects
PTAL
LGTM
LGTM

Revised text:
D.ietf-ice-trickle, Section 4, is only included if such an option was present in the offer.  <ins> The next step is to generate session-level lip sync groups as defined in RFC5888, Section 7.  For each group of type "LS" present in the offer, determine which of the local RtpTransceivers identified by that group's mid values reference a common local MediaStream (as specified in the addTrack and addTransceiver methods).  If at least two such RtpTransceivers exist, a group of type "LS" with the mid values of these RtpTransceivers MUST be added.  Otherwise, this indicates a difference of opinion between the offerer and answerer regarding lip sync status, and as such, the offered group MUST be ignored and no corresponding "LS" group generated. </ins> The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in RFC3264, Section 6.  For
Original text:
RFC3264, Section 6., and further processing for this m= section can be skipped. <del> Provided that is not the case, 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: </del>  The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates

Reviewer comments:
LG modulo comment
LGTM
Split from URL Something for the "Setting a remote description section"
(For clarity, the proper outcome is for the answerer to reject the m= line in the offer with no matching codecs, as discussed in IETF 95)
NAME asked about how the sendonly case should be handled. The minutes say but I'm not sure if we need to add any text for this. Peter, do you recall the details here?

Revised text:
RFC3264, Section 6., and further processing for this m= section can be skipped.  <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: </ins> The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates
Original text:
The addIceCandidate method provides a remote candidate to the ICE Agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for <del> Trickle ICE.  Connectivity checks will be sent to the new candidate. </del>  This method can also be used to provide an end-of-candidates indication (as defined in I-D.ietf-ice-trickle) to the ICE Agent for

Reviewer comments:
Fixes URL
fixed the typos - LGTM
The spec is clear on that the MID has precedence over m= line index when coordinating candidates with m= lines. But it is not clear on what would happen if the MID has a value can't be matched to an m= line (while potentially the m= line index is valid).
I suspect that should result in some sort of invalid value error.
Right, I think we should return an error from addIceCandidate in this case. If you wanted a different result, you should have used the correct mid :-)
I agree to the above, just want it clarified.

Revised text:
The addIceCandidate method provides a remote candidate to the ICE Agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for  <ins> Trickle ICE.  If the MID, m-line index, or candidate string provided in the ICE candidate is invalid, an error is generated.  Connectivity checks will be sent to the new candidate. </ins> This method can also be used to provide an end-of-candidates indication (as defined in I-D.ietf-ice-trickle) to the ICE Agent for
Original text:
4.1.2. <del> [TODO] </del>  4.1.3.

Reviewer comments:
I'd suggest that we try to move forward with this and leave the exact ruleset as an open issue pending Peter's investigation.
OK, I updated the PR to have the MST text. I think we had Cullen's r+ so ready to merge?
Merging this and will file an issue on the algorithm.

Revised text:
4.1.2.  <ins> The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other tracks in the same MediaStream, so that they can be added to the same "LS" group when creating an offer or answer.  addTrack attempts to minimize the number of transceivers as follows: The track will be attached to the first compatible transceiver (of the same media type) which has never had a direction of "sendonly" or "sendrecv".  If no such transceiver exists, then one will be constructed as described in sec.addTransceiver. </ins> 4.1.3.
Original text:
The result is that if there are N distinct media types, then candidates will be gathered for for N media streams.  This policy balances desire to multiplex with the need to ensure basic audio <del> and video can still be negotiated in legacy cases. </del>  all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints.  When acting as answerer, the implementation will reject any m= section that is not in a bundle group. </del>  As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST No supported codec is present in the offer. <del> The bundle policy is "max-bundle" and the m= section is not in a bundle group. </del>  The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.

Reviewer comments:
If a non-bundle offer is received, and "max-bundle" is used, the first m= section should be accepted and all others rejected. This will ensure the same result whether or not the "max-bundle" endpoint is the offerer or answerer (ignoring some unlikely corner cases), and will prevent a lone media description from being rejected if the remote offer didn't contain a bundle group simply because it wasn't necessary. Also added equivalent rules for the "balanced" bundle policy.
This LGTM
This isn't exactly what I had in mind for 'balanced', but this might not be an issue in practice. If the answerer needs to handle multiple m= lines that are unbundled, it can set max-compat.
lgtm

Revised text:
The result is that if there are N distinct media types, then candidates will be gathered for for N media streams.  This policy balances desire to multiplex with the need to ensure basic audio  <ins> and video can still be negotiated in legacy cases.  When acting as answerer, if there is no bundle group in the offer, the implementation will reject all but the first m= section of each type. </ins> all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy  <ins> endpoints.  When acting as answerer, if there if no bundle group in the offer, the implementation will reject all but the first m= section. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST No supported codec is present in the offer.  <ins> The bundle policy is "max-bundle", the m= section is not in a bundle group, and this is not the first m= section. The bundle policy is "balanced", the m= section is not in a bundle group, and this is not the first m= section for this media type. </ins> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.
Original text:
TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 The 50 is based on 50 packets per second, the 40 is based on an <del> 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". </del>  For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.

Reviewer comments:
This is an update of Fippo's
See PR
LGTM
lgtm with comma

Revised text:
TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 The 50 is based on 50 packets per second, the 40 is based on an  <ins> estimate of total header size, the 1000 changes the unit from kbps to bps (as required by TIAS) 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:
flagged and stored. If present, a single "a=rtcp" attribute MUST be parsed as <del> specified in RFC3605, Section 2.1, but its value is ignored. </del>  If present, a single "a=msid" attribute MUST be parsed as specified in I-D.ietf-mmusic-msid, Section 3.2, and its value

Reviewer comments:
Oh, I see: Issue .
Rewrote to remove some typos, and overall simplification
From the interim, there was some confusion on whether ignoring a=rtcp prohibited unmuxed RTCP; the intention here was that a=rtcp is superfluous because the RTCP port/IP information is carried in a=candidate lines. Suggest we just spell out this rationale explicitly.
That is, unless we use a=rtcp:0 to indicate exclusive.
This appears to be section 5.6.2's statement: If present, a single "a=rtcp" attribute MUST be parsed as specified in [RFC3605], Section 2.1, but its value is ignored. (This is no longer on page 52) Would work?

Revised text:
flagged and stored. If present, a single "a=rtcp" attribute MUST be parsed as  <ins> specified in RFC3605, Section 2.1, but its value is ignored, as this information is superfluous when using ICE. </ins> If present, a single "a=msid" attribute MUST be parsed as specified in I-D.ietf-mmusic-msid, Section 3.2, and its value
Original text:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> TODO: identity, rtcp-rsize, rtcp-mux, and any other attributes valid at session level. </del> Once all the session-level lines have been parsed, processing continues with the lines in media sections. specified in RFC5761, Section 5.1.1, and its presence or absence flagged and stored.  If present, a single "a=rtcp-rsize" attribute MUST be parsed as specified in RFC5506, Section 5, and its presence or absence flagged and stored.

Reviewer comments:
Not ready yet.
LGTM with editorial comment as above.
Please apply same presence/absence treatment for all
http://rtcweb-URL [TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level.]
(session-level, specifically)

Revised text:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.  Once all the session-level lines have been parsed, processing continues with the lines in media sections. specified in RFC5761, Section 5.1.1, and its presence or absence flagged and stored. <ins> If present, a single "a=rtcp-mux-only" attribute MUST be parsed as specified in I-D.ietf-mmusic-mux-exclusive, Section 3, and its presence or absence flagged and stored. </ins> If present, a single "a=rtcp-rsize" attribute MUST be parsed as specified in RFC5506, Section 5, and its presence or absence flagged and stored.
Original text:
the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. <del> A direction attribute for the associated RtpTransceiver as described by sec.offer-dirattr. </del>  For each supported codec, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The audio and video codecs that setting of the "vad" value in the signaling of the client to mixer audio level header extension described in RFC6464, Section 4. <del> 5.2.4. RFC3264 direction attributes (defined in Section 6.1) in offers are chosen according to the states of the RtpSender and RtpReceiver of a given RtpTransceiver, as follows: </del> 5.3. When createAnswer is called, a new SDP description must be created the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. <del> A direction attribute for the associated RtpTransceiver described by sec.answer-dirattr. </del>  For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and VoiceActivityDetection to true would result in an answer with CN codecs and "usedtx=0"). <del> 5.3.4. RFC3264 direction attributes (defined in Section 6.1) in answers are chosen according to the direction attribute in the remote offer and the states of the RtpSender and RtpReceiver of the corresponding RtpTransceiver, as follows: </del> 5.4. When a SessionDescription is supplied to setLocalDescription, the

Reviewer comments:
Can you separate this from the ICE changes that are also in this PR?
Oops, yeah
NAME PTAL
LGTM
See URL

Revised text:
the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered.  <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each supported codec, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The audio and video codecs that setting of the "vad" value in the signaling of the client to mixer audio level header extension described in RFC6464, Section 4.  5.3. When createAnswer is called, a new SDP description must be created the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered.  <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and VoiceActivityDetection to true would result in an answer with CN codecs and "usedtx=0").  5.4. When a SessionDescription is supplied to setLocalDescription, the
Original text:
4.1.4. <del> [TODO] </del>  4.1.5.

Reviewer comments:
NAME See above
LGTM when outstanding comment addressed
JSEP currently has this: createDataChannel [TODO] We need this text before WGLC, so it's being added to the punchlist.

Revised text:
4.1.4.  <ins> The createDataChannel method creates a data channel and attaches it to the PeerConnection.  If no data channel currently exists for this PeerConnection, then a new offer/answer exchange is required.  All data channels on a given PeerConnection share the same SCTP/DTLS association and therefore the same m= section, so subsequent creation of data channels does not have any impact on the JSEP state. The createDataChannel method also includes a number of arguments which are used by the PeerConnection (e.g., maxPacketLifetime) but are not reflected in the SDP and do not affect the JSEP state. </ins> 4.1.5.