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

Commentary: It ’s an API requirement , so the MUST does n’t belong here . Also remove discussion of application filtering of local addresses , which is no longer believed to be useful . 
 Originally raised by Christer Section 3.5.3 contains requirements regarding what a browser MUST do - e.g. , allowing the application to select what types of ICE candidates are used . 1 ) I am not sure why such requirements are listed here . But , in any case , is there a mechanism for applications for selecting candidate types etc ? If so , what mechanism ? 
 This is ICE policy . Editorial 
 Suggested revision : to
Paragraph (version A):
Typically, when gathering ICE candidates, the browser will gather all
possible forms of initial candidates - host, server reflexive, and
relay.  However, in certain cases, applications may want to have more
specific control over the gathering process, due to privacy or
related concerns.  For example, one may want to suppress the use of
host candidates, to avoid exposing information about the local
network, or go as far as only using relay candidates, to leak as
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
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.ietf-rtcweb-ip-handling.
Paragraph (version B):
Typically, when gathering ICE candidates, the browser will gather all
possible forms of initial candidates - host, server reflexive, and
relay.  However, in certain cases, applications may want to have more
specific control over the gathering process, due to privacy or
related concerns.  For example, one may want to only use relay
candidates, to leak as little location information as possible
(keeping in mind that this choice comes with corresponding
operational costs).  To accomplish this, JSEP allows the application
to restrict which ICE candidates 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.ietf-rtcweb-ip-handling.
Draft: draft-ietf-rtcweb-jsep

Commentary: stopped The stopped method returns " true " if the transceiver has been stopped , either by a call to stopTransceiver or by applying an answer that rejects the associated m= section , and " false " otherwise . [ BA ] This should be rewritten as follows : 
  , there is precedent for this regarding the canTrickleIceCandidates property in We should make these consistent ( note use of ' property ' vs ' attribute ' )
Paragraph (version A):
The stopped method returns "true" if the transceiver has been
stopped, either by a call to stopTransceiver or by applying an answer
that rejects the associated m= section, and "false" otherwise.
Paragraph (version B):
The stopped property indicates whether the transceiver has been
stopped, either by a call to stopTransceiver or by applying an answer
that rejects the associated m= section.  In either of these cases, it
is set to "true" and otherwise will be set to "false".
Draft: draft-ietf-rtcweb-jsep

Commentary: Originally raised by Magnus : When sending RTCP feedback , use the SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC ; if no outgoing Source RTP Stream exists , choose a random one . This is okay , but could be slightly more open in regards to sending feedback packets efficiently . Section 5.4.1 in is providing more detailed rules for things to consider . 
 Magnus , what do you think is needed here . Informative ref ? 
 A reference would be good . I would consider cutting away the explicit recommendation here and only say that " When sending RTCP feedback , follow the rules and recommendations in Section 5.4.1 of [ draft - ietf - avtcore - rtp - multi - stream ] to select which SSRC to use . "
Paragraph (version A):
Enable the RTCP feedback mechanisms referenced in the media
section for all Source RTP Streams using 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.  When sending RTCP feedback, use the
SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC;
if no outgoing Source RTP Stream exists, choose a random one.
Paragraph (version B):
Enable the RTCP feedback mechanisms referenced in the media
section for all Source RTP Streams using 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.  When sending RTCP feedback, follow
the rules and recommendations from I-D.ietf-avtcore-rtp-multi-
stream, Section 5.4.1 to select which SSRC to use.
Draft: draft-ietf-rtcweb-jsep

Commentary: Originally raised by Magnus : This is done in the order that their associated RtpTransceivers were 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 ) . I am bit surprised to see " recycled " on a list of things that may occur in generating an initial offer ? Can that really occur ? 
 check this - prob editorial
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.  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) .
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, excluding any stopped
RtpTransceivers.  This is done in the order the RtpTransceivers were
added to the PeerConnection.
Draft: draft-ietf-rtcweb-jsep

Commentary: I agree that this text is correct . I have no strong opinion on whether we should make the change ... 
 Proposed text : 
 This seems satisfactory to me . You have my preemptive LGTM
Paragraph (version A):
RFC3556 with bandwidth modifiers MAY be supported for specifying
RTCP bandwidth as a fraction of the media bandwidth, RTCP fraction
allocated to the senders and setting maximum media bit-rate
boundaries.
Paragraph (version B):
RFC3556 MUST be supported for control of RTCP bandwidth limits.
Draft: draft-ietf-rtcweb-jsep

Commentary: Originally raised by Magnus : o For any specified " CT " bandwidth value , set this as the limit for the maximum total bitrate for all m= sections , as specified in Section 5.8 of [ RFC4566 ] . The implementation can decide how to allocate the available bandwidth between m= sections to simultaneously meet any limits on individual m= sections , as well as this overall session limit . I think this text can be improved to make it clearer that CT does n't imply a fixed over time divide of the bandwidth between RTP streams . As long as individual media sources streams stay within other requirements such as b = AS / TIAS they can be changed dynamically . 
 Makes sense .
Paragraph (version A):
For any specified "CT" bandwidth value, set this as the limit for
the maximum total bitrate for all m= sections, as specified in
Section 5.8 of RFC4566.  The implementation can decide how to
allocate the available bandwidth between m= sections to
simultaneously meet any limits on individual m= sections, as well
as this overall session limit.
Paragraph (version B):
For any specified "CT" bandwidth value, set this as the limit for
the maximum total bitrate for all m= sections, as specified in
Section 5.8 of RFC4566.  Within this overall limit, the
implementation can dynamically decide how to best allocate the
available bandwidth between m= sections, respecting any specific
limits that have been specified for individual m= sections.
Draft: draft-ietf-rtcweb-jsep

Commentary: Originally raised by Christer Section 3.2 says : "  also allows for an answer to be treated as provisional by the application . Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer , in order to allow the session to begin , while allowing a final answer to be specified later . This concept of a final answer is important to the offer / answer model ; when such an answer is received , any extra resources allocated by the caller can be released , now that the exact session configuration is known . " 1 ) I would like explicit text saying that this is a deviation from RFC 3264 , where there is no such thing as a provisional answer . I would like to have a dedicated ³Deviations to  ( or something similar ) section . 2 ) I would like explicit text saying that the final answer may be completely different ( in terms of candidates , codecs , accepted m- line etc ) from the provisional answer . 3 ) Related to 2 ) , the final answer may also require NEW resources to be allocated . 
 We discussed this and we do n't think text is needed for 1 ) or 3 ) ; the offerer does n't release resources until the final answer . For 2 ) , what kind of text did you have in mind ? 
 Few notes to cullen from talking wtih   proposals ... adding section " SDP Offer / Nswer Usage " document variation we make on SAVPF stuff explain how ANSWE / PR answer are used withen paringin multiple to single offer Points to section for details ... follwo proccedures in 3264 
 Cullen , I think I improved this . PTAL
Paragraph (version A):
result, multiple dissimilar provisional answers can be received and
applied during call setup.
Paragraph (version B):
result, multiple dissimilar provisional answers, with their own codec
choices, transport parameters, etc., can be received and applied
during call setup.  Note that the final answer itself may be
different than any received provisional answers.
Draft: draft-ietf-rtcweb-jsep

Commentary: do n't love the way the bit about the pool turned out but I do n't have better text . Fixed . Consensus here was this is fine . No , this seems fairly clear . Done . Done . Do you mean RTP here ? If so , I 'm feeling OK about this . Done . 
 Merging and will tweak post - merge
Paragraph (version A):
This API indirectly controls the candidate gathering process.  When a
local description is supplied, and the number of transports currently
in use does not match the number of transports needed by the local
description, the PeerConnection will create transports as needed and
begin gathering candidates for them.
Paragraph (version B):
This API indirectly controls the candidate gathering process.  When a
local description is supplied, and the number of transports currently
in use does not match the number of transports needed by the local
description, the PeerConnection will create transports as needed and
either withdraw an appropriate number of ICE candidates from the
candidate pool or begin gathering candidates if sufficient pre-
gathered candidates are not available.
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 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".
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.  "TIAS" is used in preference to "AS" because it
provides more accurate control of bandwidth.
Paragraph (version A):
If the media section has been rejected (i.e. port is set to zero
in the answer), stop any reception or transmission of media for
this section, and discard any associated ICE components, as
described in Section 9.2.1.3 of RFC5245.
Paragraph (version B):
If the media section has been rejected (i.e. port is set to zero
in the answer), stop any reception or transmission of media for
this section, and, if there was no accepted media section bundled
with this media section, discard any associated ICE components, as
described in Section 9.2.1.3 of RFC5245.
Draft: draft-ietf-rtcweb-jsep

Commentary: Attempts to address issue . Also changed " control " to " inspect " in RtpReceiver description , since an RtpReceiver is readonly and does n't let an application control anything . 
 LGTM 
 Originally raised by Christer Section 3.4.1 talks about ³RtpTranceivers² , ³RtpSenders² and ³RtpReceivers² . 1 ) I think they should be introduced in their own section ( not within the Session Description Protocol section ) . 2 ) I think it should be explained what an RtpXXX really is . At a minimum there should be a reference to the appropriate W3C document . But , as there is text on how they related to SDP m- lines etc , 1 or 2 sentences describing what they are would also be useful . 
 Section 3.4.1 is its own section , and explains what the RtpTransceiver is . Agree that Sections 3.4.2/3.4.3 ( on senders / receivers ) could be expanded somewhat . FYI 
 Resolved by
Paragraph (version A):
RtpSenders allow the application to control how RTP media is sent.
Paragraph (version A):
RtpReceivers allows the application to control how RTP media is
received.
Paragraph (version B):
RtpSenders allow the application to control how RTP media is sent.
An RtpSender is conceptually responsible for the outgoing RTP
stream(s) described by an m= section.  This includes encoding the
attached MediaStreamTrack, sending RTP media packets, and generating/
processing RTCP for the outgoing RTP streams(s).
Paragraph (version B):
RtpReceivers allow the application to inspect how RTP media is
received.  An RtpReceiver is conceptually responsible for the
incoming RTP stream(s) described by an m= section.  This includes
processing received RTP media packets, decoding the incoming
stream(s) to produce a remote MediaStreamTrack, and generating/
processing RTCP for the incoming RTP stream(s).
Paragraph (version A):
If setRemoteDescription was previously called with an offer, and
setLocalDescription is called with an answer (provisional or final),
and the media directions are compatible, and media are available to
send, this will result in the starting of media transmission.
Paragraph (version B):
If setRemoteDescription was previously called with an offer, and
setLocalDescription is called with an answer (provisional or final),
and the media directions are compatible, and media is available to
send, this will result in the starting of media transmission.
Paragraph (version A):
If setLocalDescription was previously called with an offer, and
setRemoteDescription is called with an answer (provisional or final),
and the media directions are compatible, and media are available to
send, this will result in the starting of media transmission.
Paragraph (version B):
If setLocalDescription was previously called with an offer, and
setRemoteDescription is called with an answer (provisional or final),
and the media directions are compatible, and media is available to
send, this will result in the starting of media transmission.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 If RTCP mux is indicated , prepare to demux RTP and RTCP from the RTP ICE component , as specified in [ RFC5761 ] , Section 5.1.1 . If RTCP mux is not indicated , but was indicated in a previous description , this MUST result in an error . I note that there can be difference here between an offer and an answer if the RTCP mux indication may have changed or not between these two description . 
 Agreed . If we offered rtcp - mux , but it was n't accepted , the next offer would be without mux . It should only be an error if we accepted mux and already discarded the RTCP ICE component .
Paragraph (version A):
If RTCP mux is indicated, prepare to demux RTP and RTCP from
the RTP ICE component, as specified in RFC5761, Section 5.1.1.
If RTCP mux is not indicated, but was indicated in a previous
description, this MUST result in an error.
Paragraph (version B):
If RTCP mux is indicated, prepare to demux RTP and RTCP from
the RTP ICE component, as specified in RFC5761, Section 5.1.1.
If RTCP mux is not indicated, but was previously negotiated,
i.e., the RTCP ICE component no longer exists, this MUST result
in an error.
Draft: draft-ietf-rtcweb-jsep

Commentary: Fixes issue . 
 Section 4.2.3 : The setDirection method sets the direction of a transceiver , which affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer . [ BA ] " sets the direction of a transceiver " is a bit confusing because setDirection ( ) does n't immediately change whether an RtpSender can send or an RtpReceiver can receive . Since setDirection does immediately change the value of the transceiver.direction attribute you might say " sets the transceiver.direction attribute " instead . Also , an application may want to determine the current direction ( e.g. whether an RtpSender can send or an RtpReceiver can receive ) as opposed to the pending direction ( provided by transceiver.direction ) .  agreed to create a WebRTC 1.0 PR to add the concept of current direction ( e.g. by adding a currentDirection attribute ) . It would therefore be useful to add some text to Section 4.2.3 explaining the distinction . For example : " Note that while setDirection sets the transceiver.direction attribute immediately , this pending direction does not immediately affect whether an RtpSender will send or RtpReceiver will receive . After calls to setLocal / setRemoteDescription , the direction currently in effect is represented by transceiver.currentDirection ( the attribute  will be defining ) . " 
 As for naming : which of these makes the most sense ? " direction"/"currentDirection " " pendingDirection"/"currentDirection " " preferredDirection"/"currentDirection " " preferredDirection"/"negotiatedDirection " I like " preferredDirection " ( or something of that nature ) ; " pending " is a bit of a misnomer here because it 's possible the set direction may never end up negotiated . 
 My personal preference would be " direction"/"currentDirection " . While " pendingDirection " might be more accurate than " direction " , I 'm a bit scared of all the spec changes that might be result from changing the attribute name . 
 Agree with 
 LGTM ( direction + currentDirection ) . 
 can this now be closed ? 
 I do n't think  's concern was addressed , which is that " sets the direction of a transceiver " is too ambiguous . Now that we have a " currentDirection " to reference , I 'll add some clarifying text like he suggested . 
 Resolved by .
Paragraph (version B):
Note that while setDirection sets the direction attribute of the
transceiver immediately (sec.transceiver-direction), this attribute
does not immediately affect whether the transceiver's RtpSender will
send or its RtpReceiver will receive.  The direction in effect is
represented by the currentDirection attribute, which is only updated
when an answer is applied.
Draft: draft-ietf-rtcweb-jsep

Commentary: Changed back as Justin suggested . 
 So I reviewed RFC 8035 and RFC 5761 and came to the conclusion that RFC 5761 , S 5.1.3 already says everything we need , and RFC 8035 only changes S 5.1.1 of RFC 5761 , so it 's not useful in this context ( 5.1.1 is only when ICE is not used ) . As such I simply changed this PR to refer to 5761 , S 5.1.3 , and removed the 8035 reference . PTAL 
 LGTM 
 Should also have a ref to draft - ietf - avtcore-5761 - update 
 Which section needs this ref ? 
 Fixed by 
 This seems fine once you fix your merge conflict
Paragraph (version B):
When using JSEP to transmit multiple encodings from a RTPSender, the
techniques from I-D.ietf-mmusic-sdp-simulcast and I-D.ietf-mmusic-rid
are used.  Specifically, when multiple encodings have been configured
for a RTPSender, the m= section for the RTPSender will include an
"a=simulcast" attribute, as defined in I-D.ietf-mmusic-sdp-simulcast,
Section 6.2, with a "send" simulcast stream description that lists
each desired encoding, and no "recv" simulcast stream description.
The m= section will also include an "a=rid" attribute for each
encoding, as specified in I-D.ietf-mmusic-rid, Section 4; the use of
RID identifiers allows the individual encodings to be disambiguated
even though they are all part of the same m= section.
Paragraph (version B):
The SDP returned from createOffer or createAnswer MUST NOT be changed
before passing it to setLocalDescription.  If precise control over
the SDP is needed, the aforementioned createOffer/createAnswer
options or RTPSender APIs MUST be used.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 LGTM 
 The text says " all dimensions assume square pixels " . Given the affordance for non - square pixels elsewhere , I think this should say " all dimensions are measured in pixels , whether square or not " . 
 Agreed .
Paragraph (version A):
Note that certain codecs support transmission of samples with aspect
ratios other than 1.0 (i.e., non-square pixels).  JSEP
implementations will not transmit non-square pixels, but SHOULD
receive and render such video with the correct aspect ratio.
However, sample aspect ratio has no impact on the size negotiation
described below; all dimensions assume square pixels.
Paragraph (version B):
Note that certain codecs support transmission of samples with aspect
ratios other than 1.0 (i.e., non-square pixels).  JSEP
implementations will not transmit non-square pixels, but SHOULD
receive and render such video with the correct aspect ratio.
However, sample aspect ratio has no impact on the size negotiation
described below; all dimensions are measured in pixels, whether
square or not.
Draft: draft-ietf-rtcweb-jsep

Commentary: Fixed 
 Cullen , I did some git history rewriting to remove the unnecessary flip - flop around this bullet entry and push -f ed . 
 LGTM 
 Section 5.1.1 R-16 : TODOs should be deleted before Last Call :-) Also sugggest renumbering the trailing sentence as R-16 . Section 5.1.2 : Suggest using a different letter on the numbering . U-1 and U-2 ?
Paragraph (version A):
The RFC5888 grouping framework MUST be implemented for signaling
grouping information, and MUST be used to identify m= lines via
the a=mid attribute.
Paragraph (version B):
RFC5888 MUST be implemented for signaling grouping information,
and MUST be used to identify m= lines via the a=mid attribute.