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

Commentary: Oh , I see : Issue . 
 Rewrote to remove some typos , and overall simplification 
 From the interim , there was some confusion on whether ignoring a = rtcp prohibited unmuxed RTCP ; the intention here was that a = rtcp is superfluous because the RTCP port / IP information is carried in a = candidate lines . Suggest we just spell out this rationale explicitly . 
 That is , unless we use a = rtcp:0 to indicate exclusive . 
 This appears to be section 5.6.2 's statement : If present , a single " a = rtcp " attribute MUST be parsed as specified in [ RFC3605 ] , Section 2.1 , but its value is ignored . ( This is no longer on page 52 ) Would work ?
Paragraph (version A):
If present, a single "a=rtcp" attribute MUST be parsed as
specified in RFC3605, Section 2.1, but its value is ignored.
Paragraph (version B):
If present, a single "a=rtcp" attribute MUST be parsed as
specified in RFC3605, Section 2.1, but its value is ignored, as
this information is superfluous when using ICE.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 LGTM
Paragraph (version A):
The second SDP line MUST be an "o=" line, as specified in RFC4566,
Section 5.2.  The value of the <username> field SHOULD be "-".
The value of the <sess-id> field SHOULD be a cryptographically
random number.  To ensure uniqueness, this number SHOULD be at
least 64 bits long.  The value of the <sess-version> field SHOULD
be zero.  The value of the <nettype> <addrtype> <unicast-address>
tuple SHOULD be set to a non-meaningful address, such as IN IP4
mentioned in RFC4566, the entire o= line needs to be unique, but
selecting a random number for <sess-id> is sufficient to
accomplish this.
Paragraph (version B):
The second SDP line MUST be an "o=" line, as specified in RFC4566,
Section 5.2.  The value of the <username> field SHOULD be "-".
RFC3264 requires that the <sess-id> be representable as a 64-bit
signed integer.  It is RECOMMENDED that the <sess-id> be generated
as a 64-bit quantity with the high bit being sent to zero and the
remaining 63 bits being cryptographically random.  The value of
the <nettype> <addrtype> <unicast-address> tuple SHOULD be set to
a non-meaningful address, such as IN IP4 0.0.0.0, to prevent
leaking the local address in this field.  As mentioned in RFC4566,
the entire o= line needs to be unique, but selecting a random
number for <sess-id> is sufficient to accomplish this.
Draft: draft-ietf-rtcweb-jsep

Commentary: Fixes 
 LGTM 
 Updated to incorporate feedback from comments . Some more detail needed in the last para , but the narrative should be complete . 
 PTAL 
 LGTM 
 In WebRTC section 5.1 , addTransceiver ( ) , it says ' When setRemoteDescription is called with a corresponding remote description that is able to receive multiple RTP encodings as defined in [  ] , the RTCRtpSender may send multiple RTP encodings and the parameters retrieved via the transceiver ’s sender.getParameters ( ) will reflect the encodings negotiated . ' It is not obvious what to use as the JSEP reference because there does not seem to be a single place that talks about receipt of multiple encodings . 
 The specification of signalling that you can recevie multiple encodings seems to belong in either the RID spec or the JSEP spec . A decision was made some time back that WebRTC entities are only required to support receiving one incoming stream , but all the specs need to be clear on what that means in practice . 
 I think it makes sense for us to add some text in JSEP for this and create a link 
 The plan is to add a new section in JSEP section 3 that would give an overview of simulcast , perhaps a summary of , section 6.2 .
Paragraph (version B):
Applications request support for simulcast by configuring multiple
encodings on an RTPSender, which, upon generation of an offer or
answer, are indicated in SDP markings on the corresponding m=
section, as described below.  Receivers that understand simulcast and
are willing to receive it will also include SDP markings to indicate
their support, and JSEP endpoints will use these markings to
determine whether simulcast is permitted for a given RTPSender.  If
simulcast support is not negotiated, the RTPSender will only use the
first configured encoding.
Paragraph (version B):
JSEP currently does not provide an API to configure receipt of
simulcast.  This means that if simulcast is offered by the remote
endpoint, the answer generated by a JSEP endpoint will not indicate
support for receipt of simulcast, and as such the remote endpoint
will only send a single encoding per m= section.  In addition, when
the JSEP endpoint is the answerer, the permitted encodings for the
RTPSender must be consistent with the offer, but this information is
currently not surfaced through any API.  This means that established
simulcast streams will continue to work through a received re-offer,
but setting up initial simulcast by way of a received offer requires
out-of-band signaling or SDP inspection.  Future versions of this
specification may add additional APIs to provide this control.
Draft: draft-ietf-rtcweb-jsep

Commentary: This is an update of Fippo 's 
 See PR 
 LGTM 
 lgtm with comma
Paragraph (version A):
The 50 is based on 50 packets per second, the 40 is based on an
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".
Paragraph (version B):
The 50 is based on 50 packets per second, the 40 is based on an
estimate of total header size, the 1000 changes the unit from
kbps to bps (as required by TIAS) and the 0.95 is to allocate
5% to RTCP.  If more accurate control of bandwidth is needed,
"TIAS" should be used instead of "AS".
Draft: draft-ietf-rtcweb-jsep

Commentary: b = TIAS is specified in bits per second , b = AS in kbps . Hence the formula needs to multiply by 1000 to change units . Thanks 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
Paragraph (version A):
The 50 is based on 50 packets per second, the 40 is based on an
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".
Paragraph (version B):
The 50 is based on 50 packets per second, the 40 is based on an
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".
Draft: draft-ietf-rtcweb-jsep

Commentary: If a non - bundle offer is received , and "  - bundle " is used , the first m= section should be accepted and all others rejected . This will ensure the same result whether or not the "  - bundle " endpoint is the offerer or answerer ( ignoring some unlikely corner cases ) , and will prevent a lone media description from being rejected if the remote offer did n't contain a bundle group simply because it was n't necessary . Also equivalent rules for the " balanced " bundle policy . 
 This LGTM 
 This is n't exactly what I had in mind for ' balanced ' , but this might not be an issue in practice . If the answerer needs to handle multiple m= lines that are unbundled , it can set    . 
 lgtm
Paragraph (version A):
The first media section of each type (audio, video, or
application) will contain transport parameters, which will allow
an answerer to unbundle that section.  The second and any
subsequent media section of each type will be marked bundle-only.
The result is that if there are N distinct media types, then
candidates will be gathered for for N media streams.  This policy
balances desire to multiplex with the need to ensure basic audio
and video can still be negotiated in legacy cases.
Paragraph (version B):
The first media section of each type (audio, video, or
application) will contain transport parameters, which will allow
an answerer to unbundle that section.  The second and any
subsequent media section of each type will be marked bundle-only.
The result is that if there are N distinct media types, then
candidates will be gathered for for N media streams.  This policy
balances desire to multiplex with the need to ensure basic audio
and video can still be negotiated in legacy cases.  When acting as
answerer, if there is no bundle group in the offer, the
implementation will reject all but the first m= section of each
type.
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, the implementation will
reject any m= section that is not in a bundle group.
Paragraph (version B):
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" and the m= section is not in a
bundle group.
Paragraph (version B):
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 B):
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: Also restructured the " rejecting media descriptions " sections since there are now four things that can cause it to be rejected . 
 I think this does a good job clarifying these edge cases and is the behavior we want . 
 lgtm 
 LGTM 
 I just realized this may not be complete . Even if    is used , should n't one media description be accepted ? This would ensure the same result regardless of whether the  - bundle endpoint is the offerer or answerer . It would also prevent a remote offer from being rejected if it did n't include a " BUNDLE " group simply because there was only one media description . 
 Deficiencies should be addressed by this PR ( apologies for missing them on the first pass ):
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.
Paragraph (version B):
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, the implementation will
reject any m= section that is not in a bundle group.
Paragraph (version A):
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.
Paragraph (version B):
The browser will only gather RTP candidates.  This halves the
number of candidates that the offerer needs to gather.  When
acting as answerer, the implementation will reject any m= section
that does not contain an "a=rtcp-mux" attribute.
Paragraph (version A):
For each offered m= section, if the associated RtpTransceiver has
been stopped, the corresponding m= section in the answer MUST be
marked as rejected by setting the port in the m= line to zero, as
indicated in RFC3264, Section 6., and further processing for this m=
section can be skipped.
Paragraph (version A):
For each offered m= section, if no supported codec is present in the
offer, the corresponding m= section in the answer MUST be marked as
rejected by setting the port in the m= line to zero, as indicated in
RFC3264, Section 6., and further processing for this m= section can
be skipped.
Paragraph (version B):
The associated RtpTransceiver has been stopped.
Paragraph (version B):
No supported codec is present in the offer.
Paragraph (version B):
The bundle policy is "max-bundle" and the m= section is not in a
bundle group.
Paragraph (version B):
The RTP/RTCP multiplexing policy is "require" and the m= section
doesn't contain an "a=rtcp-mux" attribute.
Draft: draft-ietf-rtcweb-jsep

Commentary: I 'd suggest that we try to move forward with this and leave the exact ruleset as an open issue pending  's investigation . 
 OK , I updated the PR to have the MST text . I think we had Cullen 's r+ so ready to merge ? 
 Merging this and will file an issue on the algorithm .
Paragraph (version B):
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
"LS" group when creating an offer or answer.  addTrack attempts to
minimize the number of transceivers as follows: The track will be
attached to the first compatible transceiver (of the same media type)
which has never had a direction of "sendonly" or "sendrecv".  If no
such transceiver exists, then one will be constructed as described in
sec.addTransceiver.
Draft: draft-ietf-rtcweb-jsep

Commentary: Fixes 
 fixed the typos - LGTM 
 The spec is clear on that the MID has precedence over m= line index when coordinating candidates with m= lines . But it is not clear on what would happen if the MID has a value ca n't be matched to an m= line ( while potentially the m= line index is valid ) . 
 I suspect that should result in some sort of invalid value error . 
 Right , I think we should return an error from addIceCandidate in this case . If you wanted a different result , you should have used the correct mid :-) 
 I agree to the above , just want it clarified .
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.  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.  Connectivity
checks will be sent to the new candidate.
Draft: draft-ietf-rtcweb-jsep

Commentary: This is all strictly editorial and I think if either of you give it a quick scan , you can just merge it 
 LGTM - will merge
Paragraph (version A):
D.shieh-rtcweb-ip-handling.
Paragraph (version B):
D.ietf-rtcweb-ip-handling.
Paragraph (version A):
TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid
at session level.
Paragraph (version B):
TODO: identity, rtcp-rsize, rtcp-mux, and any other attributes
valid at session level.
Paragraph (version A):
For each specified payload type, establish a mapping between
the payload type ID and the actual media format, as descibed in
RFC3264.  If any indicated payload type is unknown, this MUST
result in an error.
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-jsep

Commentary: Specifically , " addIceCandidate " and " Applying a Remote Description " . 
 I 'm fine this however it ends up . I will r+ this and people can merge it once it is done . Thanks 
 Just adding a still LGTM 
 lgtm once my comment from today is addressed
Paragraph (version B):
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.
Draft: draft-ietf-rtcweb-jsep

Commentary: Seems like an important distinction . I went with " MUST NOT emit " , though " MUST omit " could work too . 
 wow lgtm
Paragraph (version A):
If the "VoiceActivityDetection" option is specified, with a value of
"false", the browser MUST NOT omit "CN" codecs.  For codecs that have
their own internal silence suppression support, the appropriate fmtp
parameters for that codec MUST be specified to indicate that silence
suppression for received audio is not desired.  For example, when
using the Opus codec, the "usedtx=0" parameter would be specified in
the offer.
Paragraph (version B):
If the "VoiceActivityDetection" option is specified, with a value of
"false", the browser MUST NOT emit "CN" codecs.  For codecs that have
their own internal silence suppression support, the appropriate fmtp
parameters for that codec MUST be specified to indicate that silence
suppression for received audio is not desired.  For example, when
using the Opus codec, the "usedtx=0" parameter would be specified in
the offer.
Draft: draft-ietf-rtcweb-jsep

Commentary: Change position of initial paragraph on handling of bundled m= sections ; simplify some text ; remove discussion of ICE restart option in answers . 
 FYI
Paragraph (version A):
Note that gathering phases only gather the candidates needed by
new/recycled/restarting m= lines; other m= lines continue to use
their existing candidates.
Paragraph (version B):
Note that gathering phases only gather the candidates needed by
new/recycled/restarting m= lines; other m= lines continue to use
their existing candidates.  Also, when bundling is active, candidates
are only gathered (and exchanged) for the m= lines referenced in
BUNDLE-tags, as described in I-D.ietf-mmusic-sdp-bundle-negotiation.
Paragraph (version A):
If the m= section is not bundled into another m= section (i.e., it
is either not bundled or it possesses the sender's BUNDLE-tag)
each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the ICE configuration has changed (either changes to the supported
STUN/TURN servers, or the ICE candidate policy), or the
"IceRestart" option (sec.icerestart was specified.  If the m=
section is bundled into another m= section, it MUST NOT have any
ICE credentials.
Paragraph (version B):
Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the ICE configuration has changed (either changes to the supported
STUN/TURN servers, or the ICE candidate policy), or the
"IceRestart" option (sec.icerestart was specified.  If the m=
section is bundled into another m= section, it still MUST NOT
contain any ICE credentials.
Paragraph (version A):
If the m= section is not bundled into another m= section (i.e., it
is either not bundled or it possesses the sender's BUNDLE-tag)
each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the ICE configuration has changed (either changes to the supported
STUN/TURN servers, or the ICE candidate policy), or the
"IceRestart" option (sec.icerestart was specified.  If the m=
section is bundled into another m= section, it MUST NOT contain
any ICE credentials.
Paragraph (version B):
Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the m= section is restarting, in which case new ICE credentials
must be created as specified in RFC5245, Section 9.2.1.1.  If the
m= section is bundled into another m= section, it still MUST NOT
contain any ICE credentials.
Draft: draft-ietf-rtcweb-jsep

Commentary: lg with comment 
 LGTM 
 lgtm
Paragraph (version B):
If present, a single "a=max-message-size" attribute MUST be parsed
as specified in I-D.ietf-mmusic-sctp-sdp, Section 6, and the value
stored.  Otherwise, use the specified default.
Draft: draft-ietf-rtcweb-jsep

Commentary: First cut . Need to update the examples . 
 Overall LG , a handful of comments 
 LGTM 
 lgtm and merged . Will do a new PR to handle minor tweaks 
 BUNDLE draft 27 ( ) indicates that ICE attributes and candidates in re - offers ( and with    , I 'm guessing ) should only be in the " m= " line associated with the offerer BUNDLE - tag . In other words , the candidates and ICE parameters are not duplicated unnecessarily across m= sections . We should update JSEP to reflect this .
Paragraph (version A):
Upon receipt of trickled candidates, the receiving application will
supply them to its ICE Agent.  This triggers the ICE Agent to start
using the new remote candidates for connectivity checks.  If BUNDLE
is in use, each candidate is only supplied once, and is associated
with the m= section which matches the sender's BUNDLE-tag.
Paragraph (version B):
Upon receipt of trickled candidates, the receiving application will
supply them to its ICE Agent.  This triggers the ICE Agent to start
using the new remote candidates for connectivity checks.
Paragraph (version A):
Each m= section, provided it is not marked as bundle-only, MUST
generate a unique set of ICE credentials and gather its own unique
set of ICE candidates.  Bundle-only m= sections MUST NOT have any ICE
credentials and MUST NOT gather any candidates.
Paragraph (version B):
Each m= section, provided it is not marked as bundle-only, MUST
generate a unique set of ICE credentials and gather its own unique
set of ICE candidates.  Bundle-only m= sections MUST NOT contain any
ICE credentials and MUST NOT gather any candidates.
Paragraph (version B):
If the m= section is not bundled into another m= section (i.e., it
is either not bundled or it possesses the sender's BUNDLE-tag)
each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the ICE configuration has changed (either changes to the supported
STUN/TURN servers, or the ICE candidate policy), or the
"IceRestart" option (sec.icerestart was specified.  If the m=
section is bundled into another m= section, it MUST NOT have any
ICE credentials.
Paragraph (version B):
If the m= section is not bundled into another m= section (i.e., it
is either not bundled or it possesses the sender's BUNDLE-tag)
each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless
the ICE configuration has changed (either changes to the supported
STUN/TURN servers, or the ICE candidate policy), or the
"IceRestart" option (sec.icerestart was specified.  If the m=
section is bundled into another m= section, it MUST NOT contain
any ICE credentials.