jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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
Change:
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

Discussion:
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> <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
Change:
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

Discussion:
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> <ins> underlying transport layers have been established.  If an SSRC </ins> has not already been chosen for this outgoing RTP stream, <del> choose a random one. </del> <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
Change:
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?

Discussion:
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> <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
Change:
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.

Discussion:
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:
Change:
Late breaking, so if we decide to hold this until after Toronto, no worries
LGTM
Close enough for me. Merge it.

Discussion:
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> <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.
Change:
NAME PTAL at this. I realized the answer section also needed to be updated to match the new offer text, so I made some changes there which involved a bit of massaging of the text added in .
LGTM

Discussion:
sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. <del> As discussed above, the following attributes are included only if the m= section either has a unique address or is associated with the bundle-tag: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </del> <ins> As discussed above, the following attributes of category IDENTICAL or TRANSPORT are included only if the data m= section either has a unique address or is associated with the bundle-tag (e.g., if it is the only m= section): "a=ice-ufrag" "a=ice-pwd" "a=fingerprint" "a=setup" "a=dtls-id" </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST

If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to <del> "application" and the <proto> and "fmt" fields MUST be set to exactly match the fields in the offer.  Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp- mux"). </del> <ins> "application" and the <proto> and <fmt> fields MUST be set to exactly match the fields in the offer. </ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line

sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. <del> As discussed above, the following attributes are included only if the m= section is not bundled into another m= section: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </del> <ins> As discussed above, the following attributes of category IDENTICAL or TRANSPORT are included only if the data m= section is not bundled into another m= section: "a=ice-ufrag" "a=ice-pwd" "a=fingerprint" "a=setup" "a=dtls-id" Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may also appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux"). </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as
Change:
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

Discussion:
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> <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.
Change:
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.

Discussion:
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> <ins> follow the following rules when processing the media m= sections in a received offer: </ins> <del> The profile in any "m=" line in any answer MUST exactly match the profile provided in the offer. </del> <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> <del> Any profile matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" </del> <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
Change:
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.

Discussion:
present, but an "AS" value is specified, generate a "TIAS" value using this formula: <del> TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 </del> <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
Change:
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.

Discussion:
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> <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
Change:
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

Discussion:
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> <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 <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> <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:
Change:
…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.

Discussion:
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> <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=")
Change:
It seems like there are two implementation strategies here: Keep a parsed version Re-parse. I think we probably could dispense with this sentence, but I don't object to it, because I think of "lookup in cache" as "parse".
Knowing how things go in the real world, I'm a bit reluctant to make this change, but it should address Adam's concern.

Discussion:
MUST be returned. Next, the SessionDescription is parsed into a data structure, as <del> described in the sec.parsing-a-desc section below.  If parsing fails for any reason, processing MUST stop and an error MUST be returned. </del> <ins> described in the sec.parsing-a-desc section below. </ins> Finally, the parsed SessionDescription is applied as described in the sec.applying-a-local-desc section below.
Change:
Page 41 contains a statement reading "This promotes readability," which might be read by some as promoting machine parsing rather than troubleshooting. I propose replacing "readability" with "troubleshooting."
Full text: 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. I'm not sure that 'troubleshooting' is the exact word we're looking for here, but I think we can come up with something.

Discussion:
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 <del> identical.  This promotes readability, especially if one of a set of initially identical attributes is subsequently changed. </del> <ins> identical.  This assists development and debugging by making it easier to understand individual media sections, 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
Change:
Adam's concern here was that the local description could never be invalid, since it was generated by the implementation.
Correct. I think you need to either remove setLocal or do: parse and (if setRemote, choke one error).
Editor discussion: this paragraph seems redundant so just remove it? NAME to look.
NAME NAME - ready for re-review
Section 5.7, first paragraph: similar to above, change "setLocal/RemoteDescription" to "setRemoteDescription."
Section Parsing a Session Description Text is When a SessionDescription of any type is supplied to setLocal/ RemoteDescription, the implementation must parse it and reject it if it is invalid. The exact details of this process are explained below. Fix as adam sugested

Discussion:
5.7. <del> When a SessionDescription of any type is supplied to setLocal/ RemoteDescription, the implementation must parse it and reject it if it is invalid.  The exact details of this process are explained below. </del> The SDP contained in the session description object consists of a sequence of text lines, each containing a key-value expression, as described in RFC4566, Section 5.  The SDP is read, line-by-line, and
Change:
Not sure I love what I have done here.
Section 5.7.2 should include a statement (probably at the end) that implementations may know and process attributes other than those described in this section.
Section Media Section Parsing Text As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. proposal update that text to say something about OK to process things are known but not specified in JSEP.

Discussion:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> As required by RFC4566, Section 5.13, unknown attribute lines MUST be </del> <ins> Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize.  As required by RFC4566, Section 5.13, unknown attribute lines MUST be </ins> ignored. Once all the session-level lines have been parsed, processing

as specified in I-D.ietf-mmusic-sctp-sdp, Section 6, and the value stored.  Otherwise, use the specified default. <del> As required by RFC4566, Section 5.13, unknown attribute lines MUST be </del> <ins> Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize.  As required by RFC4566, Section 5.13, unknown attribute lines MUST be </ins> ignored. 5.7.3.
Change:
Section 7 does not acknowledge IPv6. The IAB statement on IPv6 has a recommendation that all protocol specifications have IPv6 examples in them. Since we have a separate example document, and Suhas has indicated that he will be including some IPv6 examples in it, I think you can get away in this document by amending the final paragraph of section 7 as: "More examples of SDP for WebRTC call flows, including examples of IPv6 addresses, can be found in [I-D.ietf-rtcweb-sdp]." I make no promise that other IESG members will find this sufficient, but I'm personally okay with it.

Discussion:
continuation of the previous line.  In addition, some blank lines have been added to improve readability but are not valid in SDP. <del> More examples of SDP for WebRTC call flows can be found in I- D.nandakumar-rtcweb-sdp. </del> <ins> More examples of SDP for WebRTC call flows, including examples with IPv6 addresses, can be found in I-D.nandakumar-rtcweb-sdp. </ins> 7.1.