jiebi/TextFlow huggingface dataset:
Original text:
An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1.  An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. For each supported RTP header extension, an "a=extmap" line, as 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. m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6.  If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5.

Reviewer comments:
Line 2589: "I don't think this is quite right. I imagine this should probably echo the above, e.g. MUST only be added if present in the most recent answer."
So re-review this one and see if you are OK with it as is.
This seems fine.
JSEP should probably point at the draft and include the attribute on every (applicable) media section.
Agreed

Revised text:
An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. <ins> An "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux- exclusive Section 4, if and only if the RTP/RTCP multiplexing policy is "require". </ins> An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. For each supported RTP header extension, an "a=extmap" line, as The "a=rtcp-mux" line MUST only be added if present in the most recent answer. <ins> The "a=rtcp-mux-only" line MUST only be added if present in the most recent answer. </ins> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer. m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. <ins> If present in the offer, an "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4.3. </ins> If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5.
Original text:
Agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for Trickle ICE.  If the MID, m-line index, or candidate string provided <del> in the ICE candidate is invalid, an error is generated.  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:
…sane peer.
NAME PTAL.
Just a quick drive-by review. LGTM with nits

Revised text:
Agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for Trickle ICE.  If the MID, m-line index, or candidate string provided  <ins> in the ICE candidate is invalid, an error is generated.  If present, ufrag is used to determine which generation of ICE candidates the candidate belongs to; this resolves ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is present and does not match any remote description, an error is generated.  If the ufrag is absent, the candidate MUST be assumed to belong to the most recently applied remote description.  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:
line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations <del> creating an ICE Candidate object MUST populate both of these fields. Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (as it could have come from a non-JSEP endpoint). </del>  3.5.3. Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid <del> attribute to the MID of the m= section. </del>  For each specified payload type that is also supported by the local implementation, establish a mapping between the payload

Reviewer comments:
LGTM
PTAL
In the WebRTC 1.0 spec we have text talking about generating a mid if the remote description is missing one. That text has a faulty link to a JSEP (as described in issue w3c/webrtc-pc/issues/698). I can't seem to find any text in JSEP about this. Should there be such text? I did find text that said that an answer only should have a mid if the offer did.
OK, I agree we need some additional text in 3.5.2.1 to indicate that if a MID is not negotiated in SDP, a MID is locally generated (but not included in SDP).
Fixed by
Thank you!

Revised text:
line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations  <ins> creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a-remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (the non-JSEP remote endpoint case). </ins> 3.5.3. Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid  <ins> attribute to the MID of the m= section.  If the m= section does not include a MID (i.e., the remote side does not support the MID extension), generate a value for the RtpTransceiver mid attribute, following the guidance for "a=mid" mentioned in sec.initial-offers. </ins> For each specified payload type that is also supported by the local implementation, establish a mapping between the payload
Original text:
set of ICE candidates.  Bundle-only m= sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. <del> For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they MUST all have the same RFC4572 fingerprint value, or this value MUST be a session-level attribute. </del>  Each m= section should be generated as specified in RFC4566, Section 5.14.  For the m= line itself, the following rules MUST be "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </del>  An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

Reviewer comments:
and
whoops, didn't realize that eric hadn't reviewed before I merged. NAME want to take a quick look?
This updates 4572 so needs to be referenced. Also see URL
This changes the requirements around use of .
Dup of
Minor nits.

Revised text:
set of ICE candidates.  Bundle-only m= sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates.  <ins> For DTLS, all m= sections MUST use all the certificate(s) that have been specified for the PeerConnection; as a result, they MUST all have the same I-D.ietf-mmusic-4572-update fingerprint value(s), or these value(s) MUST be session-level attributes. </ins> Each m= section should be generated as specified in RFC4566, Section 5.14.  For the m= line itself, the following rules MUST be "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4.  <ins> One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.
Original text:
An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. <del> [TODO: rtcp-fb?] </del> Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default

Reviewer comments:
IDENTICAL-PT or SPECIAL which means that they should be in all the m= sections.
NAME can you look into this? Should be straightforward to resolve.

Revised text:
An "a=rtcp-rsize" line, as specified in RFC5506, Section 5.  Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default
Original text:
affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer. <del> TODO: Write example showing how this might be used and how it affects offers/answers/reoffers.  Maybe something like: "sendonly" remote offer, setDirection("sendonly"), "inactive" answer, "sendonly" reoffer. </del>  4.2.4. header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <del> A direction attribute, determined by applying the rules regarding the offered direction specified in RFC3264, Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. </del>  For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264, in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. <del> A direction attribute which is the same as that of the associated transceiver. </del>  For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264,

Reviewer comments:
Also, fixes problem where my previous change to explain the directional attribute for answers was accidentally applied to the offer section.
Not clear whether this should be an example, i.e., in the Examples section, or perhaps just an aside in the setDirection section.

Revised text:
affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer.  <ins> When creating offers, the transceiver direction is directly reflected in the output, even for reoffers.  When creating answers, the transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below. </ins> 4.2.4. header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11.  <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264, in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer.  <ins> A direction attribute, determined by applying the rules regarding the offered direction specified in RFC3264, Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. </ins> For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264,
Original text:
cases, the value of the RtpTransceiver's mid attribute MUST be set to null.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a <del> RtpTransceiver MUST NOT be removed if the RtpTransceiver's RtpSender was activated by the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </del>  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or

Reviewer comments:
This still refers to RtpSenders being "activated", a concept that isn't defined anywhere. I replaced this with "track attached to the transceiver" since that's the terminology that's used elsewhere.

Revised text:
cases, the value of the RtpTransceiver's mid attribute MUST be set to null.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a  <ins> RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </ins> A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or
Original text:
have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. <del> Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. </del>  Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically

Reviewer comments:
This is OK with me but fine if we want to call out identity or anything that is different.
How's this?
LGTM
S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST

Revised text:
have semantics "BUNDLE", and MUST include the mid identifiers of each m= section.  <ins> Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical.  This promotes readability, especially if one of a set of initially identical attributes is subsequently changed. </ins> Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically
Original text:
allocated to the senders and setting maximum media bit-rate boundaries. <del> TODO: any others? </del> As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.

Reviewer comments:
I think there may still be more work to do here, but we can track in the existing bug () rather than a TODO.
Raised by Magnus.
URL
R-10 (a=ssrc) should probably be removed or adjusted to reflect the fact that JSEP won't generate these lines.
I'm starting on this one
We need to look at the PR started on this and see if this is something we want to do or if we should go the direction of just calling out the non obvious implementation requirements here.
This seems fixed. Closing it
Cullen to inspect document and ensure all relevant SDP RFCs are cited in the generating/parsing offer/answer sections (using full list in )
Is this resolved by ?
Yes. Closing.

Revised text:
allocated to the senders and setting maximum media bit-rate boundaries.  As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.
Original text:
RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e., a default value of "trr- int=0".  Otherwise, assume that AVPF is being used in an AVP <del> compatible mode and use AVP timing, i.e., "trr-int=4". </del>  For data m= sections, JSEP endpoints MUST support receiving the <del> "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards </del>  compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile

Reviewer comments:
Adding link to
Originally raised by Magnus: Otherwise, assume that AVPF is being used in an AVP compatible mode and use AVP timing, i.e., "trr-int=4". I find this sentence confusing. I think this should be clarified to say: Otherwise, assume that AVPF is being used in an AVP compatible mode, i.e. use AVPF timing configured with a "trr-int=4". Section 5.1.3: Spurious space in: For data m= sections, JSEP endpoints MUST support receiving the "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles.
NAME PR wanted.
NAME the text here was trying to indicate that "AVP timing" was a minimum interval of 4 seconds. With the proposed change, the paragraph becomes confusing, as both parts reference "AVPF timing". What do you suggest we do?
ping NAME
NAME the text you quote appears to be correct. The important aspect is that AVPF becomes compatible with AVP if one uses trr-int=4.0. Where if AVPF (SAVPF) is offered one should use either the default trr-int=0, or negotiate another value. I assume what you find confusing is this part "assume that AVPF is being used in an AVP compatible mode". A possible change could be to change that third sentence to read: "If AVP is offered, then use AVPF in an AVP compatible mode, i.e. set trr-int=4000 (4 s). Does this solve the issue?
I think slight change here would address Justin's comment

Revised text:
RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e., a default value of "trr- int=0".  Otherwise, assume that AVPF is being used in an AVP  <ins> compatible mode and use a value of "trr-int=4000". </ins> 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:
(e.g. a finite number of decoders), createOffer should return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those <del> resources.  Because this method may need to inspect the system state to determine the currently available resources, it may be implemented as an async operation. </del>  Calling this method may do things such as generate new ICE credentials, but does not result in candidate gathering, or cause Session descriptions generated by createAnswer must be immediately usable by setLocalDescription; like createOffer, the returned <del> description should reflect the current state of the system.  Because this method may need to inspect the system state to determine the currently available resources, it may need to be implemented as an async operation. </del>  Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media

Reviewer comments:
Section 4.1.5 createOffer: The statement about this being async is either a requirement or out of scope. I'd suggest out of scope (it is purely an API property); the alternative is saying "it is an async operation".

Revised text:
(e.g. a finite number of decoders), createOffer should return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those  <ins> resources. </ins> Calling this method may do things such as generate new ICE credentials, but does not result in candidate gathering, or cause Session descriptions generated by createAnswer must be immediately usable by setLocalDescription; like createOffer, the returned  <ins> description should reflect the current state of the system. </ins> Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media
Original text:
If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header <del> extension, as described in I-D.ietf-mmusic-msid, Section 3.2. </del>  For each specified media format, establish a mapping between the payload type and the actual media format, as described in

Reviewer comments:
The text in -14 says: 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. This should reference the BUNDLE specification, not the MSID specification, I believe.

Revised text:
If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header  <ins> extension, as described in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 14. </ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in
Original text:
the decoder limits and constraints is used to specify its minimum and maximum x= and y= values.  If the intersection is the null set, i.e., there are no resolutions that are permitted by both the decoder and <del> the mandatory constraints, this SHOULD be represented by x=0 and y=0 </del>  values. The rules here express a single set of preferences, and therefore,

Reviewer comments:
Section 3.6.1 "no resolutions .. SHOULD be represented by x=0 and y=0 values". Is there any reason not to make this a MUST?
Makes sense.
+1

Revised text:
the decoder limits and constraints is used to specify its minimum and maximum x= and y= values.  If the intersection is the null set, i.e., there are no resolutions that are permitted by both the decoder and  <ins> the mandatory constraints, this MUST be represented by x=0 and y=0 </ins> values. The rules here express a single set of preferences, and therefore,
Original text:
in the corresponding media section in the offer, this indicates a negotiation problem and MUST result in an error. <del> 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, prepare to transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. </del>  If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced-

Reviewer comments:
Originally raised by Magnus 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, prepare to transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. I think this should say "any RTCP ICE component"..
agreed
I have a related question: Should ICEbis describe the procedures for discarding an ICE media stream or component (as needed for BUNDLE and RTCP mux negotiation)? Or is it obvious enough already what this implies?
This LGTM but see comment

Revised text:
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 the RTCP ICE component, if one exists, and begin or continue muxing RTCP over the RTP ICE component, as specified in RFC5761, Section 5.1.3.  Otherwise, prepare to transmit RTCP over the RTCP ICE component; if no RTCP ICE component exists, because RTCP mux was previously enabled, this MUST result in an error. </ins> If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced-