jiebi/CodeConvo huggingface dataset:
Change:
lgtm
need to be to "an" like in line 854?? URL
Fixed by
The word Blob is missing? URL

Discussion:
the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a <del> response to a "offer", or an update to a previously sent "pranswer". </del> <ins> response to an "offer", or an update to a previously sent "pranswer". </ins> The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that

4.1.5. The setLocalDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as its local configuration.  The type field indicates whether the blob should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </del> <ins> the supplied session description as its local configuration.  The type field indicates whether the description should be processed as an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </ins> This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to

4.1.6. The setRemoteDescription method instructs the PeerConnection to apply <del> the supplied SDP blob as the desired remote configuration.  As in setLocalDescription, the type field of the indicates how the blob should be processed. </del> <ins> the supplied session description as the desired remote configuration. As in setLocalDescription, the type field of the description indicates how it should be processed. </ins> This API changes the local media state; among other things, it sets up local resources for sending and encoding media.
Change:
...14
LGTM
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed

Discussion:
offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. <del> The browser will only gather RTP candidates.  [[OPEN ISSUE: how should the answerer behave.  https://github.com/rtcweb-wg/jsep/ issues/114]] This halves the number of candidates that the offerer needs to gather. </del> <ins> The browser will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather.  When acting as answerer, the browser will reject any m= section that does not provide an "a=rtcp-mux" attribute. </ins> 4.1.2.
Change:
NAME is this OK? NAME
lgtm with the one comment above
Ignored is the wrong word to use here. The value is not used is true but ignored is just simply not true.
Hmm.... We're not checking it and not doing anything with it. I'm happy to use another word, but I'm going to need you to suggest one. , Cullen Jennings EMAIL wrote:
NAME please r+ if you are happy. NAME please merge if you are happy.
I really don't care but it like 1 of the 3 things I raised got fixed
I see I missed the trickle thing. What else is there? , Cullen Jennings EMAIL wrote:
Around line 2216 I had another change "SHOULD be ignored" to "is not used". I think we are running into the limitations of using github for review here.
Indeed, I think I missed it. , Cullen Jennings EMAIL wrote:
NAME I think this is ready to merge if you are still happy.
LGTM
lgtm with minor change
When JSEP recommends that lines are ignored (absent some syntax validation), it violates a rule in RFC 5245 regarding mismatch processing. 5245 requires that the values for port and IP address in and correspond to a candidate that appears in the media section. Consensus in Dallas was to prohibit checking of the value in against and , which requires an explicit mention in the draft, since this is different to what 5245 says.
The sole point of mismatch processing is to allow applications to see if some SBC messed with their addresses: If the agent is not proceeding with ICE because there were a=candidate attributes, but none that matched the default destination of the media stream, the agent MUST include an a=ice- mismatch attribute in its answer. Not proceeding with ICE isn't an option here, and this is somewhat problematic with trickle ice (at least the initial 0.0.0.0 candidate), so I think ignoring makes sense.

Discussion:
not meaningful in the JSEP context and MAY be discarded once they have been checked. <ins> The "c=" line MUST be checked for syntax but its value is not used.  This supersedes the guidance in RFC5245, Section 6.1, to use "ice-mismatch" to indicate mismatches between "c=" and the candidate lines; because JSEP always uses ICE, "ice-mismatch" is not useful in this context. </ins> TODO The remaining lines are processed as follows: <del> The "c=" line MUST be parsed and stored. </del> [OPEN ISSUE: For example, because session-level bandwidth is ambiguous when multiple media streams are present, a "b=" line at session level is not useful and its value SHOULD be ignored.

Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: <del> The "c=" line, if present, MUST be parsed as specified in RFC4566, Section 5.7, and its contents stored. </del> <ins> As with the "c=" line at the session level, the "c=" line MUST be parsed according to RFC4566, Section 5.7, but its value is not used. </ins> The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored.
Change:
LGTM - I think that makes it clear what can and can not work.
lgtm

Discussion:
MediaStreamTrack.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing <del> createAnswer call.  For the offerer, since it does not know about any remote MediaStreamTracks until it receives theanswer, this implies that it can only set these constraints after the initial offer-answer exchange is complete, and as a result, a new offer-answer is needed to communicate them. </del> <ins> createAnswer call.  Any constraints set after setLocalDescription is used to set the answer will result in a new offer-answer exchange. For the offerer, because it does not know about any remote MediaStreamTracks until it receives the answer, the offer can only reflect decoder hard limits.  If the offerer wishes to set mandatory constraints on video resolution, it must do so after receiving the answer and the result will be a new offer-answer to communicate them. </ins> The resulting resolution space formed by intersecting the decoder hard limits with any mandatory constraints will be used as the x= and
Change:
LGTM
G. Section 5.2.1: This section contains the following: Each m= section MUST include the following attribute lines: o If this m= section is for video media, an "a=imageattr" line, as specified in Section 3.6. But, Section 3.6 does not mandate that a=imageattr always is included. Thus the text must be modified to allow the selective inclusion of the attribute based on what needs to be said.
Agreed; although 3.6 allows it to be omitted, we should update the text in 5.2.1 to avoid confusion.

Discussion:
maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6. <del> If this m= section is for video media, an "a=imageattr" line, as specified in sec.imageattr. </del> <ins> If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate
Change:
LGTM
lgtm
In URL 'certificates' is a set, and the PeerConnection selects which certificate to use. The SDP should have one 'a=fingerprint' line per certificate, and that is not reflected in the JSEP draft AFAICU.
Prague: One a=fingerprint line per cert, but we can go down to a single cert one DTLS has been established. The DTLS cert has to match one of the supplied a=fingerprints. (NAME correct as necessary)
PR added for allowing multiples. Processing rules go in the TBD applying section

Discussion:
"RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no <del> effect; support for DTLS-SRTP is determined by the presence of the "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. </del> <ins> effect; support for DTLS-SRTP is determined by the presence of one or more "a=fingerprint" attribute.  Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. </ins> The use of AVPF or AVP simply controls the timing rules used for RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute

An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. <del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature. </del> <ins> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4. <del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature. </del> <ins> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.
Change:
Did not carefully review but looks fine to me
lgtm
Section 5.2.1 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. [OPEN ISSUE: the -01 of this document is missing this information.]
According to -07, a=sctpmap is no more, and replaced with a=fmtp, plus a=sctp-port. We still need to reference the appropriate string for the m= line.

Discussion:
and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" <del> value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </del> <ins> value MUST be set to "webrtc-datachannel" as specified in I-D.ietf- mmusic-sctp-sdp, Section 4.1. </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an <del> "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in I-D.ietf-rtcweb-data-protocol. [OPEN ISSUE: the -01 of this document is missing this information.] </del> <ins> "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp- sdp, Section 4.1. </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> field MUST be set to exactly match the field in the offer; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </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, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an <del> "a=sctpmap" line referencing the SCTP port number and specifying the application protocol indicated in I-D.ietf-rtcweb-data-protocol. [OPEN ISSUE: the -01 of this document is missing this information.] </del> <ins> "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp- sdp, Section 4.1. </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as
Change:
LGTM with the change indicated above.
I rearranged the text a bit to make the policy concept more clear. PTAL.
LGTM
LGTM
For example, some decoders may have min limits, expressed in imageattr. By default, upscaling can be used for this, but there should be some control to turn this off (e.g. don't want to send "HD" video that is just upscaled to HD)
Thoughts on if default should be upscale is allowed or not allowed ?
Generally it seems like a bad practice so I would default to not.

Discussion:
in the attribute, and transmit it untouched if so.  If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to <del> satisfy the criteria.  In rare cases, where a receiver requires a minimum resolution which is greater than the native resolution of the video, the sender SHOULD apply upscaling in order to provide that resolution.  The sender SHOULD NOT apply upscaling in any other cases. If there is no appropriate scaling mechanism that allows the received criteria to be satisfied, the sender MUST NOT transmit the track. </del> <ins> satisfy the criteria. If the receiver requires a minimum resolution which is greater than the native resolution of the video, upscaling is needed, but this may not be appropriate in all cases.  To address this concern, the application can set an upscaling policy for each sent track.  For this case, if upscaling is permitted by policy, the sender SHOULD apply upscaling in order to provide the desired resolution. Otherwise, the sender MUST NOT apply upscaling.  The sender SHOULD NOT upscale in other cases, even if the policy permits it. If there is no appropriate and permitted scaling mechanism that allows the received criteria to be satisfied, the sender MUST NOT transmit the track. </ins> In the special case of receiving a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the track.
Change:
It goes something like and so on. But it is not clear if the answer can contain an line if there was none in the offer.
Quoth RFC 5888: Mid Value in Answers The "mid" attribute is an identifier for a particular media stream. Therefore, the "mid" value in the offer MUST be the same as the "mid" value in the answer. Besides, subsequent offers (e.g., in a re-INVITE) SHOULD use the same "mid" value for the already existing media streams. So the answer seems to be "no"
Given the quote from 5888, is it fair to conclude that URL should be resolved with "null" for the mid property on the transceiver if there has been no mid in the SDP? .mid was just an example, the same text is present for e.g. rtcp-mux, ice-option:trickle, rtcp-size.

Discussion:
BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following: <del> If present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. </del> <ins> If and only if present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. </ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet
Change:
Not sure if this is done but what is there LGTM
Yes, I think this is complete.
LGTM
URL talks about browser local policy. It should make this more concrete by referring to URL as the source of this policy.
Do you see it as normatively depending on that or more just "useful implementor advice can be found in ..."
I guess it depends on what we think the purpose of the ip-handling draft is. If we think all browsers should implement this, then it should be a normative dependency. I'll make a PR as such and we can debate the details there.
I think if it is something all browser need to implement, then we probably just want to move the normative text into this draft.
I think there is enough text that it warrants being in its own document.

Discussion:
little location information as possible (note that these choices come with corresponding operational costs).  To accomplish this, the browser MUST allow the application to restrict which ICE candidates <del> are used in a session.  In addition, administrators may also wish to control the set of ICE candidates, and so the browser SHOULD also allow control via local policy, with the most restrictive policy prevailing. </del> <ins> are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- D.shieh-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime

the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level. <del> Although it can be overridden by local policy, the default ICE candidate policy MUST be set to allow all candidates, as this minimizes use of application STUN/TURN server resources. </del> <ins> The default ICE candidate policy MUST be set to allow all candidates, as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </ins> If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-
Change:
LGTM
lgtm
From URL "public" is probably something the browser should control, not the application. "none" was previously removed, but apparently Firefox has implemented it.
Keep in mind that anything less than all means that mobile apps will work better than browser apps. Public tries to just reveal what is already revealed simply by browsing the web with no webrtc.
Right, but that's what "all" does when the browser is configured as recommended by draft-rtcweb-shieh-ip-handling. It's not clear why a "public" mode also needs to exist; the point of this draft is to protect the user from the application, so we can't really give the app the ability to choose whether it wants non-public addresses. I think the real remaining question is whether "none" is worth keeping.
I think the motivation for "none" was a lot stronger when we had automatic gathering prior to setLD() in some situations. Now, it seems like you can just get the same effect by deferring setLD(). I agree that "public" is silly.

Discussion:
If an ICE candidate policy is specified, it functions as described in sec.ice-candidate-policy, causing the browser to only surface the <del> permitted candidates to the application, and only use those candidates for connectivity checks.  The set of available policies is as follows: </del> <ins> permitted candidates (including any internal browser filtering) to the application, and only use those candidates for connectivity checks.  The set of available policies is as follows: </ins> <del> All candidates will be gathered and used. Candidates with private IP addresses [RFC1918] will be filtered out.  This prevents exposure of internal network details, at the cost of requiring relay usage even for intranet calls, if the NAT does not allow hairpinning as described in [RFC4787], section 6. </del> <ins> All candidates permitted by browser policy will be gathered and used. </ins>

the application deploys its relay servers, this could obfuscate location to a metro or possibly even global level. <del> The default ICE candidate policy MUST be set to allow all candidates, as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </del> <ins> The default ICE candidate policy MUST be set to "all" as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. </ins> If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for.  Because pre-
Change:
LGTM
C. Section 3.6.1: As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to at most 360p. In this case, the implemention would generate this attribute: a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] Maybe this example should discuss the minimal aspect of this. What it really is expressing in that it can handle any resolution between 16x16 pixels up to 640x360 as the longest in respective side. No limitations to any picture aspect ratio. That the examples expresses this is missing in the example text.
I think this is a realistic example, so I suggest we just add more descriptive text.

Discussion:
a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] <ins> This declaration indicates that the receiver is capable of decoding any image resolution from 16x16 up to 640x360 pixels. </ins> 3.5.2. RFC6236 defines "a=imageattr" to be an advisory field.  This means

of a given MediaStreamTrack, which is producing video of a certain resolution, receives an "a=imageattr recv" attribute, it MUST first check to see if the original resolution meets the criteria specified <del> in the attribute, and transmit it untouched if so.  If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to satisfy the criteria. </del> <ins> in the attribute, and transmit it untouched if so.  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 receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. If the original resolution is too large for the attribute criteria, the sender SHOULD apply downscaling to the output of the MediaStreamTrack in order to satisfy the criteria. </ins> If the receiver requires a minimum resolution which is greater than the native resolution of the video, upscaling is needed, but this may