jiebi/CodeConvo huggingface dataset:
Code change:
Provisional answers, on the other hand, do no such deallocation results as a result, multiple dissimilar provisional answers can be received and applied during call setup.
Fixe by

Related discussion:
text: resources allocated by the caller can be released, now that the exact session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. <del> Provisional answers, on the other hand, do no such deallocation results; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> Provisional answers, on the other hand, do no such deallocation; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack
Code change:
Fixes issue .
Section 4.2.3: The setDirection method sets the direction of a transceiver, which affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer. [BA] "sets the direction of a transceiver" is a bit confusing because setDirection() doesn't immediately change whether an RtpSender can send or an RtpReceiver can receive. Since setDirection does immediately change the value of the transceiver.direction attribute you might say "sets the transceiver.direction attribute" instead. Also, an application may want to determine the current direction (e.g. whether an RtpSender can send or an RtpReceiver can receive) as opposed to the pending direction (provided by transceiver.direction). Taylor agreed to create a WebRTC 1.0 PR to add the concept of current direction (e.g. by adding a currentDirection attribute). It would therefore be useful to add some text to Section 4.2.3 explaining the distinction. For example: "Note that while setDirection sets the transceiver.direction attribute immediately, this pending direction does not immediately affect whether an RtpSender will send or RtpReceiver will receive. After calls to setLocal/setRemoteDescription, the direction currently in effect is represented by transceiver.currentDirection (the attribute Taylor will be defining)."
As for naming: which of these makes the most sense? "direction"/"currentDirection" "pendingDirection"/"currentDirection" "preferredDirection"/"currentDirection" "preferredDirection"/"negotiatedDirection" I like "preferredDirection" (or something of that nature); "pending" is a bit of a misnomer here because it's possible the set direction may never end up negotiated.
NAME My personal preference would be "direction"/"currentDirection". While "pendingDirection" might be more accurate than "direction", I'm a bit scared of all the spec changes that might be result from changing the attribute name.
Agree with NAME
LGTM (direction + currentDirection).
NAME can this now be closed?
I don't think Bernard's concern was addressed, which is that "sets the direction of a transceiver" is too ambiguous. Now that we have a "currentDirection" to reference, I'll add some clarifying text like he suggested.
Resolved by .

Related discussion:
text: transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below. <ins> Note that while setDirection sets the direction attribute of the transceiver immediately (sec.transceiver-direction), this attribute does not immediately affect whether the transceiver's RtpSender will send or its RtpReceiver will receive.  The direction in effect is represented by the currentDirection attribute, which is only updated when an answer is applied. </ins> 4.2.4. The direction method returns the last value passed into setDirection.
Code change:
LGTM
If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in [RFC5761], Section 5.1.1. If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. I note that there can be difference here between an offer and an answer if the RTCP mux indication may have changed or not between these two description.
Agreed. If we offered rtcp-mux, but it wasn't accepted, the next offer would be without mux. It should only be an error if we accepted mux and already discarded the RTCP ICE component.

Related discussion:
text: If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.1. <del> If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. </del> <ins> If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error. </ins> For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of
Code change:
NAME don't love the way the bit about the pool turned out but I don't have better text. Fixed. Consensus here was this is fine. No, this seems fairly clear. URL Done. Done. Do you mean RTP here? If so, I'm feeling OK about this. Done.
Merging and will tweak post-merge

Related discussion:
text: local description is supplied, and the number of transports currently in use does not match the number of transports needed by the local description, the PeerConnection will create transports as needed and <del> begin gathering candidates for them. </del> <ins> either withdraw an appropriate number of ICE candidates from the candidate pool or begin gathering candidates if sufficient pre- gathered candidates are not available. </ins> If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final),
Code change:
NAME don't love the way the bit about the pool turned out but I don't have better text. Fixed. Consensus here was this is fine. No, this seems fairly clear. URL Done. Done. Do you mean RTP here? If so, I'm feeling OK about this. Done.
Merging and will tweak post-merge

Related discussion:
text: 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 kbps to bps (as required by TIAS), and the 0.95 is to allocate <del> 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </del> <ins> 5% to RTCP.  "TIAS" is used in preference to "AS" because it provides more accurate control of bandwidth. </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.
Code change:
NAME don't love the way the bit about the pool turned out but I don't have better text. Fixed. Consensus here was this is fine. No, this seems fairly clear. URL Done. Done. Do you mean RTP here? If so, I'm feeling OK about this. Done.
Merging and will tweak post-merge

Related discussion:
text: If the media section has been rejected (i.e. port is set to zero in the answer), stop any reception or transmission of media for <del> this section, and discard any associated ICE components, as </del> <ins> this section, and, if there was no accepted media section bundled with this media section, discard any associated ICE components, as </ins> described in Section 9.2.1.3 of RFC5245. If the remote DTLS fingerprint has been changed or the dtls-id has
Code change:
Originally raised by Christer Section 3.2 says: "JSEP also allows for an answer to be treated as provisional by the application. Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order to allow the session to begin, while allowing a final answer to be specified later. This concept of a final answer is important to the offer/answer model; when such an answer is received, any extra resources allocated by the caller can be released, now that the exact session configuration is known." 1) I would like explicit text saying that this is a deviation from RFC 3264, where there is no such thing as a provisional answer. I would like to have a dedicated ³Deviations to RFC3264² (or something similar) section. 2) I would like explicit text saying that the final answer may be completely different (in terms of candidates, codecs, accepted m- line etc) from the provisional answer. 3) Related to 2), the final answer may also require NEW resources to be allocated.
We discussed this and we don't think text is needed for 1) or 3); the offerer doesn't release resources until the final answer. For 2), what kind of text did you have in mind?
Few notes to cullen from talking wtih Christer Christer proposals ... adding section "SDP Offer/Nswer Usage" document variation we make on SAVPF stuff explain how ANSWE / PR answer are used withen paringin multiple to single offer Points to section for details ... follwo proccedures in 3264
Cullen, I think I improved this. PTAL

Related discussion:
text: session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. Provisional answers, on the other hand, do no such deallocation; as a <del> result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> result, multiple dissimilar provisional answers, with their own codec choices, transport parameters, etc., can be received and applied during call setup.  Note that the final answer itself may be different than any received provisional answers. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack
Code change:
All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM

Related discussion:
text: JSEP implementations must comply with the specifications listed below that govern the creation and processing of offers and answers. <del> The first set of specifications is the "mandatory-to-implement" set. All implementations must support these behaviors, but may not use all of them if the remote side, which may not be a JSEP endpoint, does not support them. The second set of specifications is the "mandatory-to-use" set.  The local JSEP endpoint and any remote endpoint must indicate support for these specifications in their session descriptions. </del> 5.1.1. <del> Implementations of JSEP MUST conform to I-D.ietf-rtcweb-rtp-usage. This list of mandatory-to-implement specifications is derived from the requirements outlined in that document and from I-D.ietf-rtcweb- security-arch. RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RFC5764, TCP/DTLS/RTP/SAVPF RFC7850, "UDP/DTLS/SCTP" I-D.ietf- mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE implementation MUST be a Full implementation, not a Lite implementation. RFC5763 MUST be implemented to signal DTLS certificate fingerprints. RFC5888 MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and MediaStreamTracks in a standard way. The bundle mechanism in I-D.ietf-mmusic-sdp-bundle-negotiation MUST be supported to signal the ability to multiplex RTP streams on a single UDP port, in order to avoid excessive use of port number resources. The SDP attributes of "sendonly", "recvonly", "inactive", and "sendrecv" from RFC4566 MUST be implemented to signal information about media direction. RFC5576 MUST be implemented to signal RTP SSRC values and grouping semantics. RFC4585 MUST be implemented to signal RTCP based feedback. RFC5761 MUST be implemented to signal multiplexing of RTP and RTCP. RFC5506 MUST be implemented to signal reduced-size RTCP messages. RFC4588 MUST be implemented to signal RTX payload type associations. RFC3556 MUST be supported for control of RTCP bandwidth limits. The SDES SRTP keying mechanism from RFC4568 MUST NOT be implemented, as discussed in I-D.ietf-rtcweb-security-arch. As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines. 5.1.2. </del> All session descriptions handled by JSEP implementations, both local and remote, MUST indicate support for the following specifications. If any of these are absent, this omission MUST be treated as an
Code change:
All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM

Related discussion:
text: DTLS RFC6347 or DTLS-SRTP RFC5763, MUST be used, as appropriate for the media type, as specified in <del> 5.1.3. </del> <ins> The SDES SRTP keying mechanism from RFC4568 MUST NOT be used, as discussed in I-D.ietf-rtcweb-security-arch. 5.1.2. </ins> <del> For media m= sections, JSEP implementations MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer.  For data m= sections, implementations MUST support both the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two profiles for each data m= line they </del> <ins> For media m= sections, JSEP implementations MUST support the "UDP/TLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate 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 TCP or UDP <del> transport depending on network conditions, both advertisements are </del> <ins> transport depending on network conditions, this advertisement is </ins> consistent with ICE eventually selecting either either UDP or TCP. Unfortunately, in an attempt at compatibility, some endpoints
Code change:
All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM

Related discussion:
text: Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <ins> As required by RFC4566, Section 5.13, unknown attribute lines MUST be ignored. </ins> Once all the session-level lines have been parsed, processing continues with the lines in m= sections.
Code change:
All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM

Related discussion:
text: as specified in I-D.ietf-mmusic-sctp-sdp, Section 6, and the value stored.  Otherwise, use the specified default. <ins> As required by RFC4566, Section 5.13, unknown attribute lines MUST be ignored. </ins> 5.7.3. Assuming parsing completes successfully, the parsed description is
Code change:
o If the m= section is not bundled into another m= section, an "a=rtcp" attribute line MUST be added with of the default RTCP candidate, as indicated in [RFC5761], Section 5.1.3.

Related discussion:
text: section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <del> If the m= section is not bundled into another m= section, an "a=rtcp" attribute line MUST be added with of the default RTCP candidate, as indicated in RFC5761, Section 5.1.3. </del> <ins> If the m= section is not bundled into another m= section, its "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate, as indicated in RFC5761, Section 5.1.3.  If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial offer section above. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering
Code change:
In Section 5.4, JSEP says: " The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription." However in Section 5.8, it says: "First, the parsed parameters are checked to ensure that they are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in Section 5.4; otherwise, processing MUST stop and an error MUST be returned." [BA] So is any change to URL unacceptable (e.g. must be byte for byte identical)? Or is the text trying to say that the parsed representation must be the same (e.g. "a=" lines appearing in a different order shouldn't matter)?
I believe the expectation was that the description is entirely immutable. Verifying isomorphism in the face of minor modifications seems like something that is not entirely trivial, and TBH I don't quite understand why it would be needed.
Thanks. PR URL assumes that URL is immutable.
I will update 5.8 accordingly.

Related discussion:
text: If the type is not correct for the current state, processing MUST stop and an error MUST be returned. <ins> The SessionDescription is then checked to ensure that its contents are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in sec.modifying-sdp; otherwise, processing MUST stop and an error MUST be returned. </ins> Next, the SessionDescription is parsed into a data structure, as described in the sec.parsing-a-desc section below.  If parsing fails for any reason, processing MUST stop and an error MUST be
Code change:
In Section 5.4, JSEP says: " The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription." However in Section 5.8, it says: "First, the parsed parameters are checked to ensure that they are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in Section 5.4; otherwise, processing MUST stop and an error MUST be returned." [BA] So is any change to URL unacceptable (e.g. must be byte for byte identical)? Or is the text trying to say that the parsed representation must be the same (e.g. "a=" lines appearing in a different order shouldn't matter)?
I believe the expectation was that the description is entirely immutable. Verifying isomorphism in the face of minor modifications seems like something that is not entirely trivial, and TBH I don't quite understand why it would be needed.
Thanks. PR URL assumes that URL is immutable.
I will update 5.8 accordingly.

Related discussion:
text: a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. <del> First, the parsed parameters are checked to ensure that they are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in sec.modifying-sdp; otherwise, processing MUST stop and an error MUST be returned. </del> Next, m= sections are processed.  For each m= section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be
Code change:
I fixed the grammar and added some text about "subsequent verification"
Also see URL
What's the issue?
Someone thought we should talk about how to parse SDP with more than one identity line and handle that. I did not look, we may already have whatever we need in the draft but I just opened this so we would at least go check.
JSEP practice is just to put in placeholders and link to the defining draft, so we should punt the actual semantics in security-arch.
See email to rtcweb from Stefan Håkansson subject "Identity in the SDP"
Sayeth Stefan: >[2] URL

Related discussion:
text: An "a=ice-options" line with the "trickle" option MUST be added, as specified in I-D.ietf-ice-trickle, Section 4. <ins> If WebRTC identity is being used, an "a=identity" line as described in I-D.ietf-rtcweb-security-arch, Section 5. </ins> The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped
Code change:
I fixed the grammar and added some text about "subsequent verification"
Also see URL
What's the issue?
Someone thought we should talk about how to parse SDP with more than one identity line and handle that. I did not look, we may already have whatever we need in the draft but I just opened this so we would at least go check.
JSEP practice is just to put in placeholders and link to the defining draft, so we should punt the actual semantics in security-arch.
See email to rtcweb from Stefan Håkansson subject "Identity in the SDP"
Sayeth Stefan: >[2] URL

Related discussion:
text: If present, a single "a=dtls-id" line is parsed as specified in I- D.ietf-mmusic-dtls-sdp Section 5, and the dtls-id value is stored. <ins> Any "a=identity" lines are parsed and the identity values stored for subsequent verification, as specified I-D.ietf-rtcweb- security-arch, Section 5. </ins> Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.
Code change:
Note that the use of CVO in webrtc is described in URL
NAME feel free to rewrite however and merge. I just wanted to get the xref in.
We mention it in the imageattr section. This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic.
NAME , can you look into this? Not WGLC2 blocking.
will do - I seem to recall it is a 3GPP ref but will try and track down.

Related discussion:
text: appropriate).  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 <del> receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. </del> <ins> receive-side rotation (e.g., through CVO TS26.114), as it significantly simplifies the matching logic. </ins> For the purposes of resolution negotiation, only size limits are considered.  Any other values, e.g. picture or sample aspect ratio,
Code change:
I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me

Related discussion:
text: mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. <del> When the call is accepted, the callee uses the createAnswer() API to generate an appropriate answer, applies it using setLocalDescription(), and sends the answer back to the initiator over the signaling channel.  When the offerer gets that answer, it installs it using setRemoteDescription(), and initial setup is complete.  This process can be repeated for additional offer/answer exchanges. </del> <ins> To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it using the setLocalDescription() API, and sends the answer back to the initiator over the signaling channel.  When the initiator gets that answer, it installs it using the setRemoteDescription() API, and initial setup is complete.  This process can be repeated for additional offer/answer exchanges. </ins> Regarding ICE RFC5245, JSEP decouples the ICE state machine from the overall signaling state machine, as the ICE state machine must remain