jiebi/CodeConvo huggingface dataset:
Change:
Build error looks like travis bustage
PeerConnection is used first at the next to last paragraph of section 3. Please add a reference at that point.
Yes.
Does Robert mean a ref to Section 4, or a ref to the W3C doc? We do have a ref to the W3C doc in Section 1.
That is why I concluded to S 4 (distinguishing between PC and RTCPC)
LGTM

Discussion:
allows the signaling to set up a separate media flow for each peer that it wishes to exchange media with.  In JSEP, this offer used in the UPDATE would be formed by simply creating a new PeerConnection <del> and making sure that the same local media streams have been added into this new PeerConnection.  Then the new PeerConnection object would produce a SDP offer that could be used by the signaling to perform the UPDATE strategy discussed in RFC3960. </del> <ins> (see sec.peerconnection) and making sure that the same local media streams have been added into this new PeerConnection.  Then the new PeerConnection object would produce a SDP offer that could be used by the signaling to perform the UPDATE strategy discussed in RFC3960. </ins> As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote
Change:
NAME PTAL at the reformulation I added.
"LS" (lipsync) is first used at 4.1.2, with no context for what it is. Please add a reference.
OK

Discussion:
The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other tracks in the same MediaStream, so that they can be added to the same <del> "LS" group when creating an offer or answer. addTrack attempts to minimize the number of transceivers as follows: If the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver that was created by the most recent call to setRemoteDescription() and does not have a local track. Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </del> <ins> "LS" group when creating an offer or answer, thus allowing these tracks to be synchronized when played out, as described in RFC5888, Section 7.  addTrack attempts to minimize the number of transceivers as follows: If the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver that was created by the most recent call to setRemoteDescription() and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </ins> 4.1.3.
Change:
Slightly more than minor maybe: The first paragraph of 5.1.2 has at least a reference error. UDP/TLS/RTP/SAVPF is not specified in RFC7850. It's in RFC5764. Assuming that this is only a reference error, then the last sentence seems like a stray. It doesn't seem to be in the right context ("this advertisement" doesn't cast back to the discussion of the two profiles above it, which are both UDP only). Please clarify the sentence, giving it the right context, or remove it.
This text is correct. The point is we are saying "advertise UDP but we can do TCP or UDP". We can try to rewrite.
LGTM

Discussion:
5.1.2. For media m= sections, JSEP implementations MUST support the <del> "UDP/TLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate </del> <ins> "UDP/TLS/RTP/SAVPF" profile specified in RFC5764, and MUST indicate </ins> 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 UDP RFC5245 or TCP RFC6544 transport depending on network conditions, this advertisement is consistent with ICE eventually selecting either either UDP or TCP. </del> <ins> produce in an offer.  Although these profiles are formally associated with UDP, ICE can select either UDP RFC5245 or TCP RFC6544 transport depending on network conditions, even when advertising a UDP profile. </ins> Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of
Change:
Odd edge: The description createAnswer (in 4.1.7) leaves open the possibility that the application could call createAnswer twice (back-to-back with no intervening calls to other APIs) with different values in the options parameter. Is this ok? If not, should there be language that says not to do that somewhere?
This is explicitly OK, and the state machine makes it clear.
Not sure we need to say anything here, though, given the state machine.
NAME I forgot to mark this invalid but I think it may be.
Discussed with team and plan is to amend the paras that talk about cO/cA not changing media state to also mention that they don't change signaling state.
LGTM

Discussion:
resources. Calling this method may do things such as generating new ICE <del> credentials, but does not result in candidate gathering, or cause media to start or stop flowing.  Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </del> <ins> credentials, but does not change the PeerConnection state, trigger candidate gathering, or cause media to start or stop flowing. Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.7.

description should reflect the current state of the system. Calling this method may do things such as generating new ICE <del> credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and does not become the current local description, until setLocalDescription is called. </del> <ins> credentials, but does not change the PeerConnection state, trigger candidate gathering, or or cause a media state change.  Specifically, the answer is not applied, and does not become the current local description, until setLocalDescription is called. </ins> 4.1.8.
Change:
NAME PTAL
The concept of a "pending local description" is used in sections 3.5.1, , and 4.1.7 but isn't really explained until much later in the document. Please provide forward references, or move a description of what a pending description is earlier in the document.
Yah, this does seem like it needs a fix. Probably something about this in S 3.2.
The second paragraph of section 5.4 is confusing. A slight restructuring of the sentences would remove much of the potential confusion, I think. I suggest replacing the first sentence (which is very complex) with this: "After calling setLocalDescription, the application MAY modify the SDP to reduce the capabilities in the offer before sending it to the far side, as long as it remains a valid SDP offer and specifies a subset of what was in the original offer. Likewise, an application that has received an offer from a peer MAY modify the received SDP, subject to those same constraints, before calling setRemoteDescription."
LGTMLG with nits

Discussion:
answerer, who first calls setRemoteDescription(sdp [offer]) and then later setLocalDescription(sdp [answer]). <ins> During the offer/answer exchange, the outstanding offer is considered to be "pending" at the offerer and the answerer, as it may either be accepted or rejected.  If this is a re-offer, each side will also have "current" local and remote descriptions, which reflect the result of the last offer/answer exchange.  Sections sec.pendingLocalDescription, sec.pendingRemoteDescription, sec.currentLocalDescription, and sec.currentRemoteDescription, provide more detail on pending and current descriptions. </ins> 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
Change:
But also clarify that this can be used to modify an offer OR answer, as long as it remains a legal JSEP o/a.
The second paragraph of section 5.4 is confusing. A slight restructuring of the sentences would remove much of the potential confusion, I think. I suggest replacing the first sentence (which is very complex) with this: "After calling setLocalDescription, the application MAY modify the SDP to reduce the capabilities in the offer before sending it to the far side, as long as it remains a valid SDP offer and specifies a subset of what was in the original offer. Likewise, an application that has received an offer from a peer MAY modify the received SDP, subject to those same constraints, before calling setRemoteDescription."
lgtm

Discussion:
the SDP is needed, the aforementioned createOffer/createAnswer options or RtpTransceiver APIs MUST be used. <del> Note that the application MAY modify the SDP to reduce the capabilities in the offer it sends to the far side (post- setLocalDescription) or the offer that it installs from the far side (pre-setRemoteDescription), as long as it remains a valid SDP offer and specifies a subset of what was in the original offer.  This is safe because the answer is not permitted to expand capabilities, and therefore will just respond to what is present in the offer. The application SHOULD NOT modify the SDP in the answer it transmits, as the answer contains the negotiated capabilities, and this can cause the two sides to have different ideas about what exactly was negotiated. </del> <ins> After calling setLocalDescription with an offer or answer, the application MAY modify the SDP to reduce its capabilities before sending it to the far side, as long as it follows the rules above that define a valid JSEP offer or answer.  Likewise, an application that has received an offer or answer from a peer MAY modify the received SDP, subject to the same constraints, before calling setRemoteDescription. </ins> As always, the application is solely responsible for what it sends to the other party, and all incoming SDP will be processed by the JSEP
Change:
NAME PTAL
On page 69, at "If the application attempt to transmit DTMF when using a media format that does not have a corresponding telephone-event format, this MUST result in an error". This sentence is out-of-place. The section is about applying a remote description. If the document needs to retain the sentence, it belongs off in some "processing media" section. In particular, the current placement of text is confusing about what and when an error could be returned, and it could be misread to say that an error should be returned to the setRemoteDescription call.
I agree
Agreed; I don't really feel like we need to create a new "Sending DTMF" section, so my recommendation would be to adjust the text to something like For each specified "telephone-event" media format, enable DTMF transmission for all supported media formats with the same clockrate, as described in [RFC4733], Section 2.5.1.2. If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats.
LGTM

Discussion:
For each specified "telephone-event" media format, enable DTMF transmission for all supported media formats with the same clockrate, as described in RFC4733, Section 2.5.1.2. <del> If the application attempts to transmit DTMF when using a media format that does not have a corresponding telephone- event format, this MUST result in an error. </del> <ins> If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats. </ins> For any specified "ptime" value, configure the available media formats to use the specified packet size when sending.
Change:
talks about setting direction properties, but the values that can be set aren't called out (and even then only by inference from a list in an example) in section 4.2.5. Should there be explicit pointers to the api doc here? (And in section 4.2.6?)
Yes, I think a pointer to the API doc is what's needed here.
The more I look at it, I think it is the SDP, not the API doc that effectively defines the allow values of the direction.
LGTM

Discussion:
The setDirection method sets the direction of a transceiver, which affects the direction property of the associated m= section on future <del> calls to createOffer and createAnswer. </del> <ins> calls to createOffer and createAnswer.  The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive", mirroring the identically-named directional attributes defined in RFC4566, Section 6. </ins> When creating offers, the transceiver direction is directly reflected in the output, even for re-offers.  When creating answers, the
Change:
In section 5.10, the text that says to tear down the old TLS connections seems like it needs a tweek. For the case of a PR_ANS, I would expect it to not get torn down until the resources are freed when the ANS happens.
See: URL
We had a call to discuss and I think reached resolution on the SDP issue. I will prepare a PR and send to the list for approval. Separately we need to close on tls-id size, but that need not hold JSEP if we are willing to have the examples use the longer size (which we all agree is permitted)
Update: we had a call to discuss this and I think have resolution on the SDP semantics. I will prepare a PR for that and send to lists. Separately, we have to discuss the S
JSEP says: values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. But tls-ids are independently generated on each side.
Examples/example generator will also need to get tweaked

Discussion:
m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> Each "a=tls-id" line MUST stay the same unless the offerer's "a=tls-id" line changed, in which case a new "a=tls-id" value MUST be created, as described in I-D.ietf-mmusic-dtls-sdp, Section 5.2. </ins> Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer.

limits specified in RFC5245, Section 15.4. tls-id value, which MUST be set according to I-D.ietf-mmusic- <del> dtls-sdp, Section 5.  If this is a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values.  If this is an answer, the tls-id value, if present, MUST be the same as in the offer. </del> <ins> dtls-sdp, Section 5.  If this is a re-offer or a response to a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. </ins> DTLS setup value, which MUST be set according to the rules specified in RFC5763, Section 5 and MUST be consistent with the

new ICE credentials, an error MUST be generated.  If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE <del> channel. </del> <ins> channel.  Note that although JSEP requires that answerers change the tls-id value if and only if the offerer does, non-JSEP answerers are permitted to change the tls-id as long as the offer contained an ICE restart.  Thus, JSEP implementations which process DTLS data prior to receiving an answer MUST be prepared to receive either a ClientHello or data from the previous DTLS connection. </ins> If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any
Change:
NAME as Justin points out, 3264 explicitly authorizes this.
i'm a bit late but... without this, the following sequence of events is always going to happen: createOffer setLocalDescription onicecandidate(null) / icegatheringstatechange(complete) Executing this snippet in Chrome never shows a candidate. Is that the intended behaviour? Also the ice gathering state stays "new"? My confusion about this is probably related to ;-)
I guess if we need to allow empty SPDs (no m-sections) then ICE related events should fire right away as they know that nothing is going to happen any way.
NAME I don't see why any events need to fire, since ICE gathering never starts in the first place and there are no in that case.
I failed to find any text in webrtc-pc or JSEP which indicates that the createOffer() call should fail if no RtpTransceiver or data channel has been added to a PeerConnection. Webrtc-pc contains the following: But section does not seem to contain any wording indicating to treat the absence of any RtpTransceiver and DataChannel as such an failure. I think such a scenario should be treated as a failure, as I fail to see any value in generating an empty offer.
Good observation. Personally, I'm inclined to allow this, unless it's forbidden by 3264 - we would just generate the session-level values with no m= sections.
3264 indicates that this is OK: The offer will contain zero or more media streams (each media stream is described by an "m=" line and its associated attributes). Zero media streams implies that the offerer wishes to communicate, but that the streams for the session will be added at a later time through a modified offer. I think we should explicitly mention that this is allowed, but otherwise take no action.

Discussion:
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 <del> RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. </del> <ins> RtpTransceivers; this is done in the order the RtpTransceivers were added to the PeerConnection.  If there are no such RtpTransceivers, no m= sections are generated; more can be added later, as discussed in RFC3264, Section 5. </ins> For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m=
Change:
LGTM.
In spite of what was said at the W3C WebRTC WG virtual meeting yesterday I think the aspect ratio preservation can be an issue also in context of . Just to take as example that the video resolution of the track is 595 by 753 (e.g. capturing a part of the screen) and has limited what can be transmitted to 480 by 640. Scaling according to JSEP section 3.6 (if I read right) gives a transmission resolution of 480 by 607.4621.. but since we can't transmit fractional pixels we would transmit 480 by 607 and have a slight aspect ratio mismatch. The spec should clarify what to do in situations like this.
OK, perhaps then we change this text: the encoder SHOULD apply downscaling in order to satisfy the limits, although the downscaling MUST NOT change the picture aspect ratio of the encoding. to allow for rounding.
Makes sense to me.
LGTM

Discussion:
If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its resolution, the encoder SHOULD apply downscaling in order to <del> satisfy the limits, although the downscaling MUST NOT change the picture aspect ratio of the encoding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the attribute MUST NOT be used. </del> <ins> satisfy the limits.  Downscaling MUST NOT change the picture aspect ratio of the encoding, ignoring any trivial differences due to rounding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the attribute MUST NOT be used. </ins> If the encoder resolution is less than the minimum size permitted by the attribute, the attribute MUST NOT be used; the encoder MUST
Change:
I'm sure the RFC editor would have caught this nit: While formally the JSEP interface is an API, it is better to think of it is an Internet protocol s/is an Internet/as an Internet/

Discussion:
security considerations for this document. While formally the JSEP interface is an API, it is better to think of <del> it is an Internet protocol, with the application JavaScript being </del> <ins> it as an Internet protocol, with the application JavaScript being </ins> untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious
Change:
If an answerer rejects the "offerer tagged" m= section (the one listed first in "a=group:BUNDLE"), the BUNDLE spec requires rejecting all m= sections in the BUNDLE group. This means that stopping one transceiver between setting an offer and creating an answer may potentially cause multiple m= sections to be rejected. See: URL

Discussion:
section for this media type or in the same bundle group as the first m= section for this media type. <ins> This m= section is in a bundle group, and the group's offerer tagged m= section is being rejected due to one of the above reasons.  This requires all m= sections in the bundle group to be rejected, as specified in I-D.ietf-mmusic-sdp-bundle-negotiation, Section 7.3.3. </ins> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed:
Change:
LGTM
lgtm
If you know the remote side is going to use BUNDLE and RTCP mux, it's desirable to only gather a single set of ports, since the RTCP ports won't be used. Since max-bundle is already trying to minimize port gathering, it should probably assume rtcp mux. If there is a need to keep max-bundle as is, we could also add a fourth policy, e.g. force-bundle, that differs from max-bundle in that it forces use of RTCP mux.
I think we need another one, since currently max-bundle is minimally compatible with old endpoints and if you force rtcp-mux, then you will have ann interop problem. That's what I have on my slides now. Feel free to comment.
I can go with whatever the WG decides.
WG decision is to add an additional policy. Name will be force-bundle unless someone comes up with a better one.

Discussion:
<ins> The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. </ins> The application will BUNDLE all of its media streams, including data channels, on a single transport.  All streams other than the first will be marked as bundle-only.  This policy aims to minimize

<del> The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. </del> <ins> Similar to max-bundle, but RTCP candidates are not gathered.  This policy reduces the candidates that must be gathered to the absolute minimum, but will not be compatible with legacy endpoints that do not support RTCP mux. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST
Change:
says: The string is not registered in . Presumably, this text should say .
Opened PR .
Fixed in

Discussion:
generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its <del> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". </del> <ins> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". </ins> In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer: