jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rtcweb-jsep

Commentary: Also remove unnecessary placeholder 
 [ TODO : enable appropriate rtcp - fb mechanisms ]
Paragraph (version A):
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,
transmit RTCP over the RTCP component; if no RTCP component
exists, because RTCP mux was previously enabled, this MUST
result in an error.
Paragraph (version B):
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,
prepare to transmit RTCP over the RTCP component; if no RTCP
component exists, because RTCP mux was previously enabled, this
MUST result in an error.
Paragraph (version B):
Enable the RTCP feedback mechanisms referenced in the media
section for the specified media formats.  Specifically, begin
or continue sending the requested feedback types and reacting
to received feedback, as specified in RFC4585, Section 4.2.
Draft: draft-ietf-rtcweb-jsep

Commentary: Rewrite intro to be clearer Move table to appendix Fix some parsing instructions that were in the wrong place 
 LGTM ( other than the little bad xml issue )
Paragraph (version A):
If the line is not well-formed, or cannot be parsed as described, the
parser MUST stop with an error and reject the session description.
This ensures that implementations do not accidentally misinterpret
ambiguous SDP.
Paragraph (version B):
The SDP contained in the session description object consists of a
sequence of text lines, each containing a key-value expression, as
described in RFC4566, Section 5.  The SDP is read, line-by-line, and
converted to a data structure that contains the deserialized
information.  However, SDP allows many types of lines, not all of
which are relevant to JSEP applications.  For each line, the
implementation will first ensure it is syntactically correct
according to its defining ABNF, check that it conforms to RFC4566 and
RFC3264 semantics, and then either parse and store or discard the
provided value, as described below.
Paragraph (version B):
If any line is not well-formed, or cannot be parsed as described, the
parser MUST stop with an error and reject the session description,
even if the value is to be discarded.  This ensures that
implementations do not accidentally misinterpret ambiguous SDP.
Paragraph (version A):
For non-attribute (non-"a=") lines, their sequencing, syntax, and
semantics, are checked, as mentioned above.  The following lines are
not meaningful in the JSEP context and MAY be discarded once they
have been checked.
Paragraph (version B):
The following non-attribute lines are not meaningful in the JSEP
context and MAY be discarded once they have been checked.
Paragraph (version B):
Any "a=candidate" attributes MUST be parsed as specified in
RFC5245, Section 15.1, and their values stored.
Paragraph (version B):
Any "a=remote-candidates" attributes MUST be parsed as specified
in RFC5245, Section 15.2, but their values are ignored.
Paragraph (version A):
Any "a=candidate" attributes MUST be parsed as specified in
RFC5245, Section 4.3, and their values stored.
Paragraph (version A):
Any "a=remote-candidates" attributes MUST be parsed as specified
in RFC5245, Section 4.3, but their values are ignored.
Draft: draft-ietf-rtcweb-jsep

Commentary: Is this approximately right ? 
 Looks close enough to me - lets land this then tune with future PRs 
 LG with nits
Paragraph (version B):
I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into
different categories.  To avoid unnecessary duplication when
bundling, Section 8.1 of I-D.ietf-mmusic-sdp-bundle-negotiation
specifies that attributes of category IDENTICAL or TRANSPORT should
not be repeated in bundled m= sections.
Paragraph (version A):
An "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux-
exclusive Section 4, if and only if the RTP/RTCP multiplexing
policy is "require".
Paragraph (version B):
The following attributes, which are of category IDENTICAL or
TRANSPORT, MUST appear only in "m=" sections which either have a
unique address or which are associated with the bundle-tag.  (In
initial offers, this means those "m=" sections which do not contain
an "a=bundle-only" attribute.
Paragraph (version A):
If present in the offer, an "a=rtcp-mux-only" line, as specified
in I-D.ietf-mmusic-mux-exclusive, Section 4.3.
Paragraph (version A):
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=candidate", "a=fingerprint", and "a=setup" lines MUST be included
as mentioned above, along with an "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.
Paragraph (version B):
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd",
"a=candidate", "a=fingerprint", and "a=setup" lines MUST be included
under the conditions described above, along with an "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.
Draft: draft-ietf-rtcweb-jsep

Commentary: LG with nit
Paragraph (version A):
The addIceCandidate method provides a remote candidate to the ICE
Agent, which, if parsed successfully, will be added to the current
and/or pending remote description according to the rules defined for
Trickle ICE.  If the MID, m-line index, or candidate string provided
in the ICE candidate is invalid, an error is generated.  If present,
ufrag is used to determine which generation of ICE candidates the
candidate belongs to; this resolves ambiguities when trickle ICE is
in progress during an ICE restart.  If the ufrag is present and does
not match any remote description, an error is generated.  If the
ufrag is absent, the candidate MUST be assumed to belong to the most
recently applied remote description.  Connectivity checks will be
sent to the new candidate.
Paragraph (version A):
This method can also be used to provide an end-of-candidates
indication (as defined in I-D.ietf-ice-trickle) to the ICE Agent for
all media descriptions in the last remote description.
Paragraph (version B):
The addIceCandidate method provides a remote candidate to the ICE
Agent, which, if parsed successfully, will be added to the current
and/or pending remote description according to the rules defined for
Trickle ICE.  The pair of MID and ufrag is used to determine the m=
section and ICE candidate generation to which the candidate belongs.
If the MID is not present, the m= line index is used to look up the
locally generated MID (see sec.applying-a-remote-desc), which is used
in place of a supplied MID.  If these values or the candidate string
are invalid, an error is generated.
Paragraph (version B):
The purpose of the ufrag is to resolve ambiguities when trickle ICE
is in progress during an ICE restart.  If the ufrag is absent, the
candidate MUST be assumed to belong to the most recently applied
remote description.  Connectivity checks will be sent to the new
candidate.
Paragraph (version B):
This method can also be used to provide an end-of-candidates
indication to the ICE Agent, as defined in I-D.ietf-ice-trickle).
The MID and ufrag are used as described above to determine the m=
section and ICE generation for which candidate gathering is complete.
If the ufrag is not present, then the end-of-candidates indication
MUST be assumed to apply to the relevant m= section in the most
recently applied remote description.  If neither the MID nor the m=
index is present, then the indication MUST be assumed to apply to all
m= sections in the most recently applied remote description.
Draft: draft-ietf-rtcweb-jsep

Commentary: and 
 whoops , did n't realize that  had n't reviewed before I merged . want to take a quick look ? 
 This updates 4572 so needs to be referenced . Also see 
 This changes the requirements around use of . 
 Dup of 
 Minor nits .
Paragraph (version A):
For DTLS, all m= sections MUST use the certificate for the identity
that has been specified for the PeerConnection; as a result, they
MUST all have the same RFC4572 fingerprint value, or this value MUST
be a session-level attribute.
Paragraph (version B):
For DTLS, all m= sections MUST use all the certificate(s) that have
been specified for the PeerConnection; as a result, they MUST all
have the same I-D.ietf-mmusic-4572-update fingerprint value(s), or
these value(s) MUST be session-level attributes.
Draft: draft-ietf-rtcweb-jsep

Commentary: PTAL 
 From Berlin : " A clarification to that rule was found when an offer is received with some m= lines bundled and some not ; you accept all m= lines that are possible to bundle with the first m= line . " 
 I think we 'll also have to update section 5.3.1 ( Initial Answers ) where it lists conditions for rejecting an m= section . Also , do we need to make similar modifications for the " balanced " bundle policy ? LG with nits
Paragraph (version A):
Only the first media section will contain transport parameters;
all streams other than the first will be marked as bundle-only.
This policy aims to minimize candidate gathering and maximize
multiplexing, at the cost of less compatibility with legacy
endpoints.  When acting as answerer, if there if no bundle group
in the offer, the implementation will reject all but the first m=
section.
Paragraph (version A):
The bundle policy is "max-bundle", the m= section is not in a
bundle group, and this is not the first m= section.
Paragraph (version A):
The bundle policy is "balanced", the m= section is not in a bundle
group, and this is not the first m= section for this media type.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 PTAL 
 In the WebRTC 1.0 spec we have text talking about generating a mid if the remote description is missing one . That text has a faulty link to a  ( as described in issue w3c / webrtc - pc / issues/698 ) . I ca n't seem to find any text in JSEP about this . Should there be such text ? I did find text that said that an answer only should have a mid if the offer did . 
 OK , I agree we need some additional text in 3.5.2.1 to indicate that if a MID is not negotiated in SDP , a MID is locally generated ( but not included in SDP ) . 
 Fixed by 
 Thank you !
Paragraph (version A):
The IceCandidate object also contains fields to indicate which m=
line it should be associated with.  The m= line can be identified in
one of two ways; either by a m= line index, or a MID.  The m= line
index is a zero-based index, with index N referring to the N+1th m=
line in the SDP sent by the entity which sent the IceCandidate.  The
MID uses the "media stream identification" attribute, as defined in
RFC5888, Section 4, to identify the m= line.  JSEP implementations
creating an ICE Candidate object MUST populate both of these fields.
Implementations receiving an ICE Candidate object MUST use the MID if
present, or the m= line index, if not (as it could have come from a
non-JSEP endpoint).
Paragraph (version B):
The IceCandidate object also contains fields to indicate which m=
line it should be associated with.  The m= line can be identified in
one of two ways; either by a m= line index, or a MID.  The m= line
index is a zero-based index, with index N referring to the N+1th m=
line in the SDP sent by the entity which sent the IceCandidate.  The
MID uses the "media stream identification" attribute, as defined in
RFC5888, Section 4, to identify the m= line.  JSEP implementations
creating an ICE Candidate object MUST populate both of these fields,
using the MID of the associated RtpTransceiver object (which may be
locally generated by the answerer when interacting with a non-JSEP
remote endpoint that does not support the MID attribute, as discussed
in sec.applying-a-remote-desc below).  Implementations receiving an
ICE Candidate object MUST use the MID if present, or the m= line
index, if not (the non-JSEP remote endpoint case).
Paragraph (version A):
Associate the found or created RtpTransceiver with the m=
section by setting the value of the RtpTransceiver's mid
attribute to the MID of the m= section.
Paragraph (version B):
Associate the found or created RtpTransceiver with the m=
section by setting the value of the RtpTransceiver's mid
attribute to the MID of the m= section.  If the m= section
does not include a MID (i.e., the remote side does not
support the MID extension), generate a value for the
RtpTransceiver mid attribute, following the guidance for
"a=mid" mentioned in sec.initial-offers.
Draft: draft-ietf-rtcweb-jsep

Commentary: 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 do n’t know about in an answer , 
 LGTM 
 PTAL at my responses 
 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 were n't present in the offer ? ) 
 Fixed by 
 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 
 1 ) If the media section proto value indicates use of RTP : [ TODO : header extensions ] 
 LGTM
Paragraph (version A):
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.
Paragraph (version B):
If the directional attribute in the answer is of type
"sendrecv" or "sendonly", prepare to start transmitting media
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.
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-jsep

Commentary: … sane peer . 
 PTAL . 
 Just a quick drive - by review . LGTM with nits
Paragraph (version A):
The addIceCandidate method provides a remote candidate to the ICE
Agent, which, if parsed successfully, will be added to the current
and/or pending remote description according to the rules defined for
Trickle ICE.  If the MID, m-line index, or candidate string provided
in the ICE candidate is invalid, an error is generated.  Connectivity
checks will be sent to the new candidate.
Paragraph (version B):
The addIceCandidate method provides a remote candidate to the ICE
Agent, which, if parsed successfully, will be added to the current
and/or pending remote description according to the rules defined for
Trickle ICE.  If the MID, m-line index, or candidate string provided
in the ICE candidate is invalid, an error is generated.  If present,
ufrag is used to determine which generation of ICE candidates the
candidate belongs to; this resolves ambiguities when trickle ICE is
in progress during an ICE restart.  If the ufrag is present and does
not match any remote description, an error is generated.  If the
ufrag is absent, the candidate MUST be assumed to belong to the most
recently applied remote description.  Connectivity checks will be
sent to the new candidate.
Draft: draft-ietf-rtcweb-jsep

Commentary: Line 2589 : " I do n't think this is quite right . I imagine this should probably echo the above , e.g. MUST only be if present in the most recent answer . " 
 So re - review this one and see if you are OK with it as is . 
 This seems fine . 
  should probably point at the draft and include the attribute on every ( applicable ) media section . 
 Agreed
Paragraph (version B):
An "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux-
exclusive Section 4, if and only if the RTP/RTCP multiplexing
policy is "require".
Paragraph (version B):
If present in the offer, an "a=rtcp-mux-only" line, as specified
in I-D.ietf-mmusic-mux-exclusive, Section 4.3.
Draft: draft-ietf-rtcweb-jsep

Commentary: See above 
 LGTM when outstanding comment addressed 
 JSEP currently has this : createDataChannel [ TODO ] We need this text before WGLC , so it 's being to the punchlist .
Paragraph (version B):
The createDataChannel method creates a data channel and attaches it
to the PeerConnection.  If no data channel currently exists for this
PeerConnection, then a new offer/answer exchange is required.  All
data channels on a given PeerConnection share the same SCTP/DTLS
association and therefore the same m= section, so subsequent creation
of data channels does not have any impact on the JSEP state.
Paragraph (version B):
The createDataChannel method also includes a number of arguments
which are used by the PeerConnection (e.g., maxPacketLifetime) but
are not reflected in the SDP and do not affect the JSEP state.
Draft: draft-ietf-rtcweb-jsep

Commentary: 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 to the punchlist .
Paragraph (version B):
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).
Draft: draft-ietf-rtcweb-jsep

Commentary: Can you separate this from the ICE changes that are also in this PR ? 
 Oops , yeah 
 PTAL 
 LGTM 
 See
Paragraph (version A):
A direction attribute for the associated RtpTransceiver as
described by sec.offer-dirattr.
Paragraph (version A):
A direction attribute for the associated RtpTransceiver described
by sec.answer-dirattr.
Draft: draft-ietf-rtcweb-jsep

Commentary: Not ready yet . 
 LGTM with editorial comment as above . 
 Please apply same presence / absence treatment for all 
  [ TODO : identity , rtcp - rsize , rtcp - mux , and any other attribs valid at session level . ] 
 ( session - level , specifically )
Paragraph (version A):
TODO: identity, rtcp-rsize, rtcp-mux, and any other attributes
valid at session level.
Draft: draft-ietf-rtcweb-jsep

Commentary: From meeting minutes " SDP o= line increment [ ] While the proposed solution on the slide was accepted , it was noted that the proposal on the slide goes against what was agreed at last meeting . Emil Ivov also commented that Trickle ICE for SIP does exactly what is described on the slide .   said that we should make sure this is compatible with whatever is done in trickle ICE SIP stacks . " 
 This algorithm becomes correct once we decide to not allow o= modification . Editorial comments follow . 
 Discussion in - room : 1 ) add example to make it clear that there is a separate counter ( other than current o= ) which is what increments . 2 ) change text about & lt;session - version&gt ; to be more of a " note that " for an edge case , as opposed to normative text about a mainline case . 
 Updated this branch . PTAL 
 LGTM 
 2349 : " might differ " is creepy . " differs " perhaps . 2359 : " N + 2 " -must be greater than N + 1 This is basically OK modulo the above
Paragraph (version B):
The fields of the "o=" line MUST stay the same except for the
<session-version> field, which MUST increment by one on each call
to createOffer if the offer might differ from the output of the
previous call to createOffer; implementations MAY opt to increment
<session-version> on every call.  The value of the generated
<session-version> is independent of the <session-version> of the
current local description; in particular, in the case where the
current version is N, an offer is created with version N+1, and
then that offer is rolled back so that the current version is
again N, the next generated offer will still have version N+2.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 WFM . PTAL 
 The current draft suggests moving the discussion of setRemoteDescription : [ [ OPEN ISSUE : move discussion of setRemoteDescription to the subsequent - offer section . ] ]
Paragraph (version A):
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 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) .
Paragraph (version B):
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.  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) .
Draft: draft-ietf-rtcweb-jsep

Commentary: See outstanding comment from 
 Moved this section from its own Section 6 to a new section 5.4 , and fixed up the  accordingly . PTAL 
 - have a quick review of this . I think you will be fine with justin 's changes so just fix what you want and merge 
 The text you mention was mostly previous text , but I agreed with what you suggested , and a new paragraph accordingly . 
 Section 6 has a placeholder open issue : o [ [ OPEN ISSUE : This is a placeholder for other modifications , which we may continue adding as use cases appear . ] ] this should be removed before WGLC 
 I think we agreed that there were n't any more . So can we just remove ? 
 Will be resolved by
Paragraph (version A):
The generated MID attributes (a=mid).
Paragraph (version A):
The contents of bundle groups, bundle-only parameters, or "a=rtcp-
mux" parameters.