jiebi/CodeConvo huggingface dataset:
Code change:
8445 8174 Future documents, not future versions Fix normative refs
Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
LGTM

Related discussion:
text: 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 3. In order to establish a peer-to-peer connection, WebRTC implementations use Interactive Connectivity Establishment (ICE) <del> RFC5245, which attempts to discover multiple IP addresses using </del> <ins> RFC8445, which attempts to discover multiple IP addresses using </ins> techniques such as Session Traversal Utilities for NAT (STUN) RFC5389 and Traversal Using Relays around NAT (TURN) RFC5766, and then checks the connectivity of each local-address-remote-address pair in order
Code change:
8445 8174 Future documents, not future versions Fix normative refs
Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
LGTM

Related discussion:
text: choose stricter modes if desired, e.g., if a user indicates they want all WebRTC traffic to follow the default route. <del> Future versions of this document may define additional modes and/or update the recommended default modes. </del> <ins> Future documents may define additional modes and/or update the recommended default modes. </ins> Note that the suggested defaults can still be used even for organizations that want all external WebRTC traffic to traverse a
Code change:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Related discussion:
text: RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF <del> RFC5764 and TCP/TLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- </del> <ins> RFC5764 and TCP/DTLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- </ins> registration RTP profiles. RFC5245 MUST be implemented for signaling the ICE credentials and
Code change:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Related discussion:
text: 5.1.3. For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ <del> RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of </del> <ins> RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of </ins> these two profiles for each media m= line they produce in an offer. <del> For data m= sections, JSEP endpoints must support both the "UDP/TLS/ SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two </del> <ins> For data m= sections, JSEP endpoints must support both the "UDP/DTLS/ SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two </ins> profiles for each data m= line they produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually
Code change:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Related discussion:
text: compatible mode and use AVP timing, i.e., "trr-int=4". For data m= sections, JSEP endpoints MUST support receiving the <del> "UDP/ TLS/SCTP", "TCP/TLS/SCTP", or "DTLS/SCTP" (for backwards </del> <ins> "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards </ins> compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile
Code change:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Related discussion:
text: To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the <del> default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as </del> <ins> default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as </ins> specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport.
Code change:
URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.

Related discussion:
text: Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" <del> and the <proto> field MUST be set to "UDP/TLS/SCTP" if the default candidate uses UDP transport, or "TCP/TLS/SCTP" if the default </del> <ins> 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 </ins> candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  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
Code change:
LGTM
http://rtcweb-URL mentions its use at media level; this should be clarified.

Related discussion:
text: Specific processing MUST also be applied for the following attribute lines: <del> If present, a single "a=ice-lite" line is parsed as specified in RFC5245, Section 15.3, and a value indicating the presence of ice- lite is stored. </del> If present, a single "a=ice-ufrag" line is parsed as specified in RFC5245, Section 15.4, and the ufrag value is stored.
Code change:
LGTM
Overall looks good - added some minor suggestions
lgtm
F. Section 4.1.1: Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will offer a single BUNDLE group across all media sections. I think this sentence may be a bit misleading without additional sentence(s) to explain that the actual number of established transport streams will depend on the peer's response to the attempt to bundle.
OK. This could be resolved by adding a final sentence of the form "Of course, the answerer can choose whether or not to accept BUNDLE".

Related discussion:
text: BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- bundle-negotiation.  Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will <del> offer a single BUNDLE group across all media sections.  However, by specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non-BUNDLE-aware endpoint. When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: </del> <ins> offer a single BUNDLE group across all media section; use of this single transport is contingent upon the answerer accepting BUNDLE. However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non- BUNDLE-aware endpoint.  When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: </ins> The first media section of each type (audio, video, or application) will contain transport parameters, which will allow
Code change:
b=TIAS is specified in bits per second, b=AS in kbps. Hence the formula needs to multiply by 1000 to change units. Thanks NAME for catching this in code review.
Even though I noticed it in the code review I had not noticed it as an issue in the spec. Good catch!
nice catch - lgtm with minor comment
LGTM
LGTM to me as well. I updated the text in

Related discussion:
text: present, but an "AS" value is specified, generate a "TIAS" value using this formula: <del> TIAS = AS * 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 <del> estimate of total header size, and the 0.95 is to allocate 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </del> <ins> estimate of total header size, the 1000 is to change the unit from kbps to bps and the 0.95 is to allocate 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.
Code change:
LGTM
WFM. NAME PTAL
The current draft suggests moving the discussion of setRemoteDescription: [[OPEN ISSUE: move discussion of setRemoteDescription to the subsequent-offer section.]]

Related discussion:
text: The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver <del> that has been added to the PeerConnection via the addTrack, addTransceiver, and setRemoteDescription methods.  [[OPEN ISSUE: move discussion of setRemoteDescription to the subsequent-offer section.]] This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTranscievers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . </del> <ins> that has been added to the PeerConnection.  This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique
Code change:
NAME
NAME PTAL
LG with nits
para break and typo comment were missed
In the current draft we have addTransceiver [TODO] We need this text before WGLC, so it's being added to the punchlist.

Related discussion:
text: 4.1.3. <del> [TODO] </del> <ins> The addTransceiver method adds a new RTPTransceiver to the PeerConnection.  If a MediaStreamTrack argument is provided, then the transceiver will be configured with that media type and the track will be attached to the transceiver.  Otherwise, the application MUST explicitly specify the type; this mode is useful for creating recvonly transceivers as well as for creating transceivers to which a track can be attached at some later point.  At the time of creation, the application can also specify a transceiver direction attribute, a set of MediaStreams which the transceiver is associated with (allowing LS group assignments), and a set of encodings for the media (used for simulcast as desccribed in sec.simulcast). </ins> 4.1.4.
Code change:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Related discussion:
text: For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of <del> RFC5285.  If any indicated RTP header extension is unknown, this MUST result in an error. </del> <ins> RFC5285.  If any indicated RTP header extension is not supported, this MUST result in an error. </ins> If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension, as described in I-D.ietf-mmusic-msid, Section 3.2. <del> For each specified payload type, establish a mapping between the payload type ID and the actual media format, as described in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </del> <ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in RFC3264, Section 6.1.  If any indicated media format is not supported, this MUST result in an error. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload
Code change:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Related discussion:
text: If the media section proto value indicates use of RTP: <del> [TODO: header extensions] </del> If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by setting its mid attribute to null.
Code change:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Related discussion:
text: [TODO: handling of CN, telephone-event, "red"] <del> If the media section if of type audio: </del> <ins> If the media section is of type audio: </ins> For any specified "ptime" value, configure the available <del> payload types to use the specified packet size.  If the specified size is not supported for a payload type, use the </del> <ins> media formats to use the specified packet size.  If the specified size is not supported for a media format, use the </ins> next closest value instead. Finally, if this description is of type "pranswer" or "answer",
Code change:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Related discussion:
text: If the media section proto value indicates use of RTP: <ins> If the media section references any media formats, RTP header extensions, or RTCP feedback mechanisms that were not present in the corresponding media section in the offer, this indicates a negotiation problem and MUST result in an error. </ins> If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in RFC5761, Section 5.1.3.  Otherwise,
Code change:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Related discussion:
text: the RTCP transmission for this media section to use reduced- size RTCP, as specified in RFC5506. <ins> [TODO: enable appropriate rtcp-fb mechanisms] </ins> If the directional attribute in the answer is of type "sendrecv" or "sendonly", prepare to start transmitting media <del> using the specified primary SSRC and one of the selected payload types, once the underlying transport layers have been established.  If RID values are specified, include the RID header extension in the RTP streams, as indicated in I-D.ietf- mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic- sdp-simulcast, Section 6.2.2.  If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </del> <ins> using 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, once the underlying transport layers have been established.  [TODO: add discusssion of RED/FEC/RTX/CN] The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams.  Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the RID header extension has been negotiated, and RID values are specified, include the RID header extension in the outgoing RTP streams, as indicated in I-D.ietf-mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic-sdp-simulcast, Section 6.2.2. If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </ins> If the media section proto value indicates use of SCTP:
Code change:
This is OK with me
S 5.2.2 says: If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the PeerConnection is still in the "local-offer" state, an offer is generated by following the steps in the "stable" state above, along with these exceptions: o The "s=" and "t=" lines MUST stay the same. o Each "a=mid" line MUST stay the same. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. However, Section 5.2.3.4 says: If the "IceRestart" constraint is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC5245, Section 9.1.1.1. If this constraint is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated).
Yes, if this is an ICE restart, then ufrag/pwd need to change.
Discussed in DC: restart requires a change of credentials. Might want to add text that notes the dangers in doing this (i.e., don't do this).

Related discussion:
text: Each "a=mid" line MUST stay the same. <del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. </del> <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same unless the "IceRestart" option (sec.options-handling was specified.  Note that it's not clear why you would actually want to do this, since at this point ICE has not yet started and is thus unlikely to need a restart. </ins> For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same.