jiebi/TextFlow huggingface dataset:
Original text:
of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. <del> However, not all parameters follow this rule; for example, the DTLS- SRTP parameters RFC5763 sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive; the remote party will have to accept these parameters, with no option to choose different values. </del>  In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an

Reviewer comments:
Originally raised by Christer Section 3.2 says: "the DTLS-SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup" 1) I am not sure what "parameters" the text is referring to. If it¹s the fingerprint, I think the text should reference RFC 4572. 2) I think we should simply have a generic statement that, following the rules in RFC3264, parameters indicate receiving capabilities - unless explicitly indicated otherwise.
The parameters include a=setup and a=fingerprint. 5763 seems like it covers both.
NAME thoughts?
Authors believe this text is fine. NAME please send us a PR with the specific change you want if you disagree.
NAME said in email: certificate the local side will use in DTLS setup". >So, I would suggest to replace: “However, not all parameters follow this rule; for example, the DTLS- SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive;” >…with: “However, not all parameters follow this rule; for example, the fingerprints sent to a remote party are calculated based on the local certificate(s) offered;” >If you agree with that understanding, I’m happy to submit a pull request.
OK, I now see what you are saying, and I think the text you propose looks reasonable. Thanks for offering to submit a PR!
[waiting on PR from NAME
It seems like I don't have rights to submit new branches (needed for the PR).
cd4u: fork the repo and push the branch to your fork, then submit the PR from there.
PR created: URL
Fixed by

Revised text:
of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send.  <ins> However, not all parameters follow this rule; for example, the fingerprints I-D.ietf-mmusic-4572-update sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an
Original text:
The SDP for |offer-B1| looks like: <del> The SDP for |candidate-B1| looks like: </del>  <del> The SDP for |candidate-B2| looks like: </del>  The SDP for |answer-B1| looks like: <del> The SDP for |candidate-B3| looks like: </del>  <del> The SDP for |candidate-B4| looks like: </del>  The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate

Reviewer comments:
a=rtcp-mux-only LS groups
Relevant to , although there are a few nits remaining which will be handled in a followup PR
FWIW, this is atop
Added machine-filling of candidate artwork tags as well in this PR.
Follow new rules for a=rtcp, duplication of attributes Add dtls-id, rtcp-mux-only Maybe add imageattr
adds dtls-id, and I think follows the new rules for a=rtcp and attrib duplication. It doesn't yet handle the second example or do rtcp-mux-only.
Fixed by

Revised text:
The SDP for |offer-B1| looks like:  <ins> The SDP for |offer-B1-candidate-1| looks like: </ins>  <ins> The SDP for |offer-B1-candidate-2| looks like: </ins> The SDP for |answer-B1| looks like:  <ins> The SDP for |answer-B1-candidate-1| looks like: </ins>  <ins> The SDP for |answer-B1-candidate-2| looks like: </ins> The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate
Original text:
The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.  The "a=group:BUNDLE" attribute MUST include the mid identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or

Reviewer comments:
BUNDLE S 6.
I think we should hold this until Taylor's mmusic comments are resolved.
cf. URL
It doesn't seem like BUNDLE is going to change at this point; the disadvantages of using "bundle-only" in subsequent offers are that non-BUNDLE-aware middleboxes may be unhappy with a port of "0", and also, the answerer can't reject the offerer BUNDLE-tag section without rejecting the whole group (URL). I think the latter restriction is unnecessary (and it actually breaks some WebRTC max-bundle corner cases), but it doesn't sound like it's going to be changed. Speaking of which, if we're being thorough, we should address those corner cases. In "creating an answer", we should specify that if the answer rejects all the offerered m= sections with nonzero ports, it must also reject the m= sections with "a=bundle-only". So, if you're offered transceivers A, B and C with "a=bundle-only", and you do , the answer will reject A and B/C.
talked to chairs and advice from chairs on this and similar things that depend on mmusic outcomes. We put in JSEP now what our best gueses is of how mmusic will end up and publish JSEP. At the same time we log a bug to check if we need to make any changes to line up with what mmusic decides. We can take changes to line up with mmusic as Last Call comments later on.
NAME NAME I think this should resolve it.
NAME this revised version needs your signoff + merge In an initial offer, if we want to communicate "this 'm=' section must be either bundled or rejected", that's accomplished with "a=bundle-only": a=group:BUNDLE A B m=audio 10000 ... a=mid:A ... m=video 0 ... a=mid:B a=bundle-only In subsequent offers, this is accomplished by duplicating the IP address/port (see section 8.3.3): a=group:BUNDLE A B m=audio 10000 ... a=mid:A ... m=video 10000 ... a=mid:B Is this initial vs. subsequent offer difference necessary? Both blobs of SDP are communicating the same information, so the "shared address" rules seem to only add complexity. Also, the approach of using a "shared address" to communicate something isn't extensible to protocols that don't use an address for identification, like ICE. We'd need to define additional rules for those cases, or allow them specifically to use "a=bundle-only" in subsequent offers.

Revised text:
The "a=rtcp-rsize" line MUST only be added if present in the most recent answer. <ins> An "a=bundle-only" line MUST NOT be added, as indicated in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 6.  Instead, JSEP implementations MUST simply omit parameters in the IDENTICAL and TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1. </ins> The "a=group:BUNDLE" attribute MUST include the mid identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or
Original text:
this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they <del> produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, this advertisement is consistent with ICE eventually selecting either either UDP or TCP. </del>  Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of

Reviewer comments:
NAME I cleaned up as you suggested.
this is TCP Candidates with Interactive Connectivity Establishment (ICE)
We could have an informative reference for S 5.1.3 where we mention ICE can use UDP or TCP.
LGTM

Revised text:
this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they  <ins> produce in an offer.  Because ICE can select either UDP RFC5245 or TCP RFC6544 transport depending on network conditions, this advertisement is consistent with ICE eventually selecting either either UDP or TCP. </ins> Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of
Original text:
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, and start transmitting RTP media once the <del> underlying transport layers have been established.  If a SSRC </del>  has not already been chosen for this outgoing RTP stream, <del> choose a random one. </del>  The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams, including

Reviewer comments:
URL
This doesn't affect SDP, but we could add some text to the para below indicating a SSRC switch is needed when changing to a codec with a different clockrate: If the directional attribute in the answer is of type "sendrecv" or "sendonly", choose the media format to send as 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, and start transmitting RTP media once the underlying transport layers have been established. If a SSRC has not already been chosen for this outgoing RTP stream, choose a random one.
(and add a reference)
Closing per

Revised text:
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, and start transmitting RTP media once the  <ins> underlying transport layers have been established.  If an SSRC </ins> has not already been chosen for this outgoing RTP stream,  <ins> choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as specified in RFC7160, Section 3.1. </ins> The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams, including
Original text:
support.  For codecs that have 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 <del> desired.  For example, when using the Opus codec, the "usedtx=1" parameter would be specified in the offer.  This option allows the endpoint to significantly reduce the amount of audio bandwidth it receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. </del>  If the "VoiceActivityDetection" option is specified, with a value of "false", the JSEP implementation MUST NOT emit "CN" codecs.  For

Reviewer comments:
Since the second ref is so close to the first, I decided it wasn't needed.
Yes, we need a reference for 7587, since we talk about usedtx. It might make sense to have one for 6716 as well in S 5.2.3.2.
Looks good. Do you think we need a similar ref to 7587 in the para that discusses dtx=0?

Revised text:
support.  For codecs that have 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  <ins> desired.  For example, when using the Opus codec RFC6716, the "usedtx=1" parameter, specified in RFC7587, would be used in the offer.  This option allows the endpoint to significantly reduce the amount of audio bandwidth it receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. </ins> If the "VoiceActivityDetection" option is specified, with a value of "false", the JSEP implementation MUST NOT emit "CN" codecs.  For
Original text:
minimizing perceived post-dial-delay.  The second offer/answer exchange can also change the preferred codecs or other information.  The SDP for |offer-C1| looks like: The SDP for |offer-C1-candidate-1| looks like:

Reviewer comments:
Good way of getting ICE going quickly, and shows off IceTransportPolicy. Consider ICE restart for second offer (shows off ICE restart handling). Could also go into complex example.
Started on this.

Revised text:
minimizing perceived post-dial-delay.  The second offer/answer exchange can also change the preferred codecs or other information. <ins> This example also makes use of the "relay" ICE candidate policy described in sec.ice-candidate-policy to minimize the ICE gathering and checking needed. </ins> The SDP for |offer-C1| looks like: The SDP for |offer-C1-candidate-1| looks like:
Original text:
If the "VoiceActivityDetection" option is specified, with a value of "true", the offer MUST indicate support for silence suppression in the audio it receives by including comfort noise ("CN") codecs for <del> each supported clock rate, as specified in RFC3389, Section 5.1. This option allows for significant bandwidth reductions with codecs such as G.711. </del>  5.2.3.4.

Reviewer comments:
Late breaking, so if we decide to hold this until after Toronto, no worries
LGTM
Close enough for me. Merge it.

Revised text:
If the "VoiceActivityDetection" option is specified, with a value of "true", the offer MUST indicate support for silence suppression in the audio it receives by including comfort noise ("CN") codecs for  <ins> each offered audio codec, as specified in RFC3389, Section 5.1, except for codecs that have their own internal silence suppression support.  For codecs that have 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 desired.  For example, when using the Opus codec, the "usedtx=1" parameter would be specified in the offer.  This option allows the endpoint to significantly reduce the amount of audio bandwidth it receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. </ins> 5.2.3.4.
Original text:
MUST be parsed as described in RFC4566, Section 6, and its value stored. <del> Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as specified in RFC5576, Sections 4.1-4.2, and their values stored. </del>  Any "a=extmap" attributes MUST be parsed as specified in RFC5285, Section 5, and their values stored.

Reviewer comments:
removes parsing of a=ssrc and a=ssrc-group. The createOffer parts were removed in the -17 draft.
Wouldn't it make more sense to add the ssrc-group back into the draft to allow proper handling of RTX.
I'm fine with removing this
Not sure why we need to remove this since this can be used to indicate how to init the demux table.
I do think removing ssrc-group would be a good idea though since we don't plan to use it. We should also make clear that a=ssrc is only used for seeding the demux table.
To be specific: 5.9 (remote desc) should be updated to indicate that any a=ssrc values are supplied to the demuxer, and we should remove discussion of a=ssrc-group here.
You arguments to keep this make sense. I'm fine with keeping it.
Changed it to only remove a=ssrc-group, since IIUC the demux algorithm does not consider it. NAME does this seem reasonable to you? Separately I will add text in 5.9 to say that the a=ssrc values should be supplied to the demuxer.
It was non-obvious to me that RTX has to use the same MID RTP header extension values as the RTP stream it covers. Now the same argument for priming the demuxer could be made for the SSRC learned from ssrc-group. But if we assume that RTX packets will not be the first packets which you receive it's probably fine.
Remaining task from

Revised text:
MUST be parsed as described in RFC4566, Section 6, and its value stored.  <ins> Any "a=ssrc" attributes MUST be parsed as specified in RFC5576, Section 4.1, and their values stored. </ins> Any "a=extmap" attributes MUST be parsed as specified in RFC5285, Section 5, and their values stored.
Original text:
but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its willingness to support "(UDP,TCP)/TLS/RTP/SAVPF".  In order to simplify compatibility with such endpoints, JSEP implementations MUST <del> follow the following rules when processing the media m= sections in an offer: </del>  <del> The profile in any "m=" line in any answer MUST exactly match the profile provided in the offer. </del>  <del> Any profile matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" </del>  Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no effect; support for DTLS-SRTP is determined by the presence of one

Reviewer comments:
Proposal for how to clarify that when JSEP implementation generates an answer it needs to have the proto value identical to what is in the offer.
NAME do you want to take a look at this one?
BLOCKER: The first bullet on page 35 has a normative statement about the AVT profile strings that must be accepted, but uses an unspecified grammar to actually specify the string. If this is normative, it needs to be formal. Either specify the string using a formal and cited grammar, or provide an exhaustive list.
Proposal on editor's call is to use POSIX extended regular expressions. URL I believe this would give us the expressions. (UDP|TCP)/TLS/RTP/SAVPF? and: RTP/S?AVPF?
You're sure you want to pull in another reference for regexes instead of just listing all eight valid values?
I suggest we merge this without dealing with the formal grammar issue.

Revised text:
but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its willingness to support "(UDP,TCP)/TLS/RTP/SAVPF".  In order to simplify compatibility with such endpoints, JSEP implementations MUST  <ins> follow the following rules when processing the media m= sections in a received offer: </ins>  <ins> Any profile in the offer matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP|TCP)/TLS/RTP/SAVP[F]". </ins>  <ins> The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer. </ins> Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no effect; support for DTLS-SRTP is determined by the presence of one
Original text:
present, but an "AS" value is specified, generate a "TIAS" value using this formula: <del> TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 </del>  The 50 is based on 50 packets per second, the 40 is based on an estimate of total header size, the 1000 changes the unit from

Reviewer comments:
I object to shit sort of crap, if you are too short to do grade 3 math, you are too short to implement this spec.

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 estimate of total header size, the 1000 changes the unit from
Original text:
The candidate details are specified in an IceCandidate field, using the same SDP syntax as the "candidate-attribute" field defined in <del> RFC5245, Section 15.1.  For example: </del>  The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in RFC5245, Section 15.4.  This

Reviewer comments:
Since it has been the cause of actual interop issues in the field, it is probably worth mentioning, in section 3.5.2.1, that the IceCandidate strings explicitly do not start with "a=".
Sure.

Revised text:
The candidate details are specified in an IceCandidate field, using the same SDP syntax as the "candidate-attribute" field defined in  <ins> RFC5245, Section 15.1.  Note that this field does not contain an "a=" prefix, as indicated in the following example: </ins> The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in RFC5245, Section 15.4.  This
Original text:
usage, Section 5.2.  Any header extensions that require encryption MUST be specified as indicated in RFC6904, Section 4. <del> For each supported RTCP feedback mechanism, an "a=rtcp-fb" mechanism, as specified in RFC4585, Section 4.2.  The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. </del>  If the RtpTransceiver has a sendrecv or sendonly direction: in RFC6904, Section 4. For each supported RTCP feedback mechanism that is present in the <del> offer, an "a=rtcp-fb" mechanism, as specified in RFC4585, Section 4.2.  The list of RTCP feedback mechanisms that SHOULD/ MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. </del>  If the RtpTransceiver has a sendrecv or sendonly direction:

Reviewer comments:
Page 51, bullet starting "For each supported RTCP feedback...": replace "an 'a=rtcp-fb' mechanism" with "an 'a=rtcp-fb' line".
Section Initial Answers Text is For each supported RTCP feedback mechanism that is present in the offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. Fix trivial typo
Page 38, second-to-last bullet refers to "an 'a=rtcp-fb' mechanism" where it should say "an 'a=rtcp-fb' line".
Agreed

Revised text:
usage, Section 5.2.  Any header extensions that require encryption MUST be specified as indicated in RFC6904, Section 4.  <ins> For each supported RTCP feedback mechanism, an "a=rtcp-fb" line, as specified in RFC4585, Section 4.2.  The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf- rtcweb-rtp-usage, Section 5.1. </ins> If the RtpTransceiver has a sendrecv or sendonly direction: in RFC6904, Section 4. For each supported RTCP feedback mechanism that is present in the  <ins> offer, an "a=rtcp-fb" line, as specified in RFC4585, Section 4.2. The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. </ins> If the RtpTransceiver has a sendrecv or sendonly direction:
Original text:
Section 5.3; to match the "o=" line, a single dash SHOULD be used as the session name, e.g. "s=-".  Note that this differs from the advice in RFC4566 which proposes a single space, but as both "o=" <del> and "s=" are meaningless, having the same meaningless value seems clearer. </del>  Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=")

Reviewer comments:
…eless.
Section 5.2.1 contains the statement "both 'o=' and 's=' are meaningless" -- this should be qualified with "in JSEP." These fields are not generally meaningless in all uses of SDP.
Sure.

Revised text:
Section 5.3; to match the "o=" line, a single dash SHOULD be used as the session name, e.g. "s=-".  Note that this differs from the advice in RFC4566 which proposes a single space, but as both "o="  <ins> and "s=" are meaningless in JSEP, having the same meaningless value seems clearer. </ins> Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=")