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

Commentary: This will happen when applying either an offer or an answer , for consistency . Also , any " semantics verification " failure will now result in an error , which was assumed but not explicitly stated . Fixes issue . 
 This is a good start , but you 'll also want to update 4.1.1 , 5.3.1 to reflect this ( new ) policy . Note though that this will end up being inconsistent with the handling of  - bundle as it is described in 4.1.1 , although I still think this is the right approach . 
 Updated 4.1.1 . I thought I already made the needed change to 5.3.1 , what else needs to be changed ? 
 I may be overlooking something , but I do n't think this behavior is documented anywhere . I think the choices , in order of harshness , are : Silently fails , and you do n't get RTCP negotiationneeded fires , and the m= section is port - zeroed in the next offer setRemoteDescription throws an error I 'd lean towards the middle option , but that assumes that applications listen to negotiationneeded . 
 I lean toward the last option , as a violation of an invariant set by the offerer . 
 Agree that this should be documented somewhere . 
 +1 on the throw an error option 
 The general policy that we discussed here in Seattle was that any spec violation should lead to a setRD exception , not a zero port . For the rtcp - mux - only doc , we probably should have some language that makes rtcp - mux in the answer a MUST . 
 Resolved by
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 implementation will reject any m= section
that does not contain 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.  Applying a
description with an m= section that does not contain an "a=rtcp-
mux" attribute will cause an error to be returned.
Paragraph (version A):
The RTP/RTCP multiplexing policy is "require" and the m= section
doesn't contain an "a=rtcp-mux" attribute.
Paragraph (version B):
If the RTP/RTCP multiplexing policy is "require", each m= section
MUST contain an "a=rtcp-mux" attribute.
Paragraph (version B):
If any of the preceding checks failed, processing MUST stop and an
error MUST be returned.
Draft: draft-ietf-rtcweb-jsep

Commentary: Originally raised by Magnus 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 . I think this should say " any RTCP ICE component " .. 
 agreed 
 I have a related question : Should ICEbis describe the procedures for discarding an ICE media stream or component ( as needed for BUNDLE and RTCP mux negotiation ) ? Or is it obvious enough already what this implies ? 
 This LGTM but see comment
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,
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):
If the media section has RTCP mux enabled, discard the RTCP ICE
component, if one exists, and begin or continue muxing RTCP
over the RTP ICE component, as specified in RFC5761,
Section 5.1.3.  Otherwise, prepare to transmit RTCP over the
RTCP ICE component; if no RTCP ICE component exists, because
RTCP mux was previously enabled, this MUST result in an error.
Draft: draft-ietf-rtcweb-jsep

Commentary: Section 3.6.1 " no resolutions .. SHOULD be represented by x=0 and y=0 values " . Is there any reason not to make this a MUST ? 
 Makes sense . 
 +1
Paragraph (version A):
Otherwise, an "a=imageattr" attribute is created with "recv"
direction, and the resulting resolution space formed by intersecting
the decoder limits and constraints is used to specify its minimum and
maximum x= and y= values.  If the intersection is the null set, i.e.,
there are no resolutions that are permitted by both the decoder and
the mandatory constraints, this SHOULD be represented by x=0 and y=0
values.
Paragraph (version B):
Otherwise, an "a=imageattr" attribute is created with "recv"
direction, and the resulting resolution space formed by intersecting
the decoder limits and constraints is used to specify its minimum and
maximum x= and y= values.  If the intersection is the null set, i.e.,
there are no resolutions that are permitted by both the decoder and
the mandatory constraints, this MUST be represented by x=0 and y=0
values.
Draft: draft-ietf-rtcweb-jsep

Commentary: Provisional answers , on the other hand , do no such deallocation results as a result , multiple dissimilar provisional answers can be received and applied during call setup . 
 Fixe by
Paragraph (version A):
JSEP 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.  These "resources" can include things
like extra ICE components, TURN candidates, or video decoders.
Provisional answers, on the other hand, do no such deallocation
results; as a result, multiple dissimilar provisional answers can be
received and applied during call setup.
Paragraph (version B):
JSEP 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.  These "resources" can include things
like extra ICE components, TURN candidates, or video decoders.
Provisional answers, on the other hand, do no such deallocation; as a
result, multiple dissimilar provisional answers can be received and
applied during call setup.
Draft: draft-ietf-rtcweb-jsep

Commentary: The text in -14 says : 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 . This should reference the BUNDLE specification , not the MSID specification , I believe .
Paragraph (version A):
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.
Paragraph (version B):
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-sdp-bundle-
negotiation, Section 14.
Draft: draft-ietf-rtcweb-jsep

Commentary: Section 4.1.5 createOffer : The statement about this being async is either a requirement or out of scope . I 'd suggest out of scope ( it is purely an API property ) ; the alternative is saying " it is an async operation " .
Paragraph (version A):
Session descriptions generated by createOffer must be immediately
usable by setLocalDescription; if a system has limited resources
(e.g. a finite number of decoders), createOffer should return an
offer that reflects the current state of the system, so that
setLocalDescription will succeed when it attempts to acquire those
resources.  Because this method may need to inspect the system state
to determine the currently available resources, it may be implemented
as an async operation.
Paragraph (version B):
Session descriptions generated by createOffer must be immediately
usable by setLocalDescription; if a system has limited resources
(e.g. a finite number of decoders), createOffer should return an
offer that reflects the current state of the system, so that
setLocalDescription will succeed when it attempts to acquire those
resources.
Paragraph (version A):
Session descriptions generated by createAnswer must be immediately
usable by setLocalDescription; like createOffer, the returned
description should reflect the current state of the system.  Because
this method may need to inspect the system state to determine the
currently available resources, it may need to be implemented as an
async operation.
Paragraph (version B):
Session descriptions generated by createAnswer must be immediately
usable by setLocalDescription; like createOffer, the returned
description should reflect the current state of the system.
Draft: draft-ietf-rtcweb-jsep

Commentary: Did we not decide that modifying that offer ( or an answer created by createAnswer ( ) ) is not allowed ? 
 Agreed . This text should be culled .
Paragraph (version A):
JSEP's handling of session descriptions is simple and
straightforward.  Whenever an offer/answer exchange is needed, the
initiating side creates an offer by calling a createOffer() API.  The
application optionally modifies that offer, and then uses it to set
up its local config via the setLocalDescription() API.  The offer is
then sent off to the remote side over its preferred signaling
mechanism (e.g., WebSockets); upon receipt of that offer, the remote
party installs it using the setRemoteDescription() API.
Paragraph (version B):
JSEP's handling of session descriptions is simple and
straightforward.  Whenever an offer/answer exchange is needed, the
initiating side creates an offer by calling a createOffer() API.  The
application then uses that offer to set up its local config via the
setLocalDescription() API.  The offer is finally sent off to the
remote side over its preferred signaling mechanism (e.g.,
WebSockets); upon receipt of that offer, the remote party installs it
using the setRemoteDescription() API.
Draft: draft-ietf-rtcweb-jsep

Commentary: Originally raised by Magnus : Section 5.2.1 : o Session Information ( " i= " ) , URI ( " u= " ) , Email Address ( " e= " ) , Phone Number ( " p= " ) ,  ( " b= " ) , Repeat Times ( " r= " ) , and Time Zones ( " z= " ) lines are not useful in this context and SHOULD NOT be included . Considering that b = CT is not useless , I am a bit surprised to see b= on this list . Yes , b = CT : is only useful is one like to provide a upper total bandwidth limitation . So , maybe some discussion of the possible choice ? 
 This is just a mistake in 5.2.1 - we cover how to deal with it later in section 5 .  need to remove the mention of b= here .
Paragraph (version A):
Session Information ("i="), URI ("u="), Email Address ("e="),
Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and
Time Zones ("z=") lines are not useful in this context and SHOULD
NOT be included.
Paragraph (version B):
Session Information ("i="), URI ("u="), Email Address ("e="),
Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=")
lines are not useful in this context and SHOULD NOT be included.
Draft: draft-ietf-rtcweb-jsep

Commentary: Adding link to 
 Originally raised by Magnus : Otherwise , assume that AVPF is being used in an AVP compatible mode and use AVP timing , i.e. , " trr - int=4 " . I find this sentence confusing . I think this should be clarified to say : Otherwise , assume that AVPF is being used in an AVP compatible mode , i.e. use AVPF timing configured with a " trr - int=4 " . 5.1.3 : Spurious space in : For data m= sections , JSEP endpoints MUST support receiving the " UDP/  / SCTP " , " TCP / DTLS / SCTP " , or " DTLS / SCTP " ( for backwards compatibility ) profiles . 
 PR wanted . 
 the text here was trying to indicate that " AVP timing " was a minimum interval of 4 seconds . With the proposed change , the paragraph becomes confusing , as both parts reference " AVPF timing " . What do you suggest we do ? 
 ping 
 the text you quote appears to be correct . The important aspect is that AVPF becomes compatible with AVP if one uses trr - int=4.0 . Where if AVPF ( SAVPF ) is offered one should use either the default trr - int=0 , or negotiate another value . I assume what you find confusing is this part " assume that AVPF is being used in an AVP compatible mode " . A possible change could be to change that third sentence to read : " If AVP is offered , then use AVPF in an AVP compatible mode , i.e. set trr - int=4000 ( 4 s ) . Does this solve the issue ? 
 I think slight change here would address Justin 's comment
Paragraph (version A):
The use of AVPF or AVP simply controls the timing rules used for
RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute
is present, assume AVPF timing, i.e., a default value of "trr-
int=0".  Otherwise, assume that AVPF is being used in an AVP
compatible mode and use AVP timing, i.e., "trr-int=4".
Paragraph (version A):
For data m= sections, JSEP endpoints MUST support receiving the
"UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards
compatibility) profiles.
Paragraph (version B):
The use of AVPF or AVP simply controls the timing rules used for
RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute
is present, assume AVPF timing, i.e., a default value of "trr-
int=0".  Otherwise, assume that AVPF is being used in an AVP
compatible mode and use a value of "trr-int=4000".
Paragraph (version B):
For data m= sections, JSEP endpoints MUST support receiving the
"UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards
compatibility) profiles.
Draft: draft-ietf-rtcweb-jsep

Commentary: I think there may still be more work to do here , but we can track in the existing bug ( ) rather than a TODO . 
 Raised by Magnus . 
 R-10 ( a = ssrc ) should probably be removed or adjusted to reflect the fact that JSEP wo n't generate these lines . 
 I 'm starting on this one 
 We need to look at the PR started on this and see if this is something we want to do or if we should go the direction of just calling out the non obvious implementation requirements here . 
 This seems fixed . Closing it 
 Cullen to inspect document and ensure all relevant SDP RFCs are cited in the generating / parsing offer / answer sections ( using full list in ) 
 Is this resolved by ? 
 Yes . Closing .
Paragraph (version A):
TODO: any others?
Draft: draft-ietf-rtcweb-jsep

Commentary: Originally raised by Magnus : 5.1.1 : R-2 [ RFC5764 ] MUST be supported for signaling the UDP / TLS / RTP / SAVPF [ RFC5764 ] , TCP / DTLS / RTP / SAVPF [ I - D.nandakumar - mmusic - proto - iana - registration ] , " UDP / DTLS/ SCTP " [ I - D.ietf - mmusic - sctp - sdp ] , and " TCP / DTLS / SCTP " [ I - D.ietf - mmusic - sctp - sdp ] RTP profiles . I would note that [ I - D.nandakumar - mmusic - proto - iana - registration ] is actually published as RFC 7850 . 5.1.1 : R-12 [ RFC5761 ] MUST be implemented to signal multiplexing of RTP and RTCP . This should include the updated as ref also .
Paragraph (version A):
RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF
RFC5764, TCP/DTLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana-
registration, "UDP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp, and
"TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles.
Paragraph (version B):
RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF
RFC5764, TCP/DTLS/RTP/SAVPF RFC7850, "UDP/DTLS/SCTP" I-D.ietf-
mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP
profiles.
Paragraph (version A):
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
default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as
specified in I-D.nandakumar-mmusic-proto-iana-registration if the
default candidate uses TCP transport.
Paragraph (version B):
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
default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as
specified in RFC7850 if the default candidate uses TCP transport.
Draft: draft-ietf-rtcweb-jsep

Commentary: Originally raised by Magnus : Section 3.7 : JSEP supports simulcast of a MediaStreamTrack , where multiple encodings of the source media can be transmitted within the context of a single m= section . I think this should be explcit that it is " simulcast transmission of a MediaStreamTrack " .
Paragraph (version A):
JSEP supports simulcast of a MediaStreamTrack, where multiple
encodings of the source media can be transmitted within the context
of a single m= section.  The current JSEP API is designed to allow
applications to send simulcasted media but only to receive a single
encoding.  This allows for multi-user scenarios where each sending
client sends multiple encodings to a server, which then, for each
receiving client, chooses the appropriate encoding to forward.
Paragraph (version B):
JSEP supports simulcast transmission of a MediaStreamTrack, where
multiple encodings of the source media can be transmitted within the
context of a single m= section.  The current JSEP API is designed to
allow applications to send simulcasted media but only to receive a
single encoding.  This allows for multi-user scenarios where each
sending client sends multiple encodings to a server, which then, for
each receiving client, chooses the appropriate encoding to forward.
Draft: draft-ietf-rtcweb-jsep

Commentary: This distinguishes between the direction which was last set via setDirection ( which simply affects offer / answer generation ) from the direction that was negotiated , which affects whether a transceiver can send / recv media . Addresses issue . 
 According to WebRTC 1.0 Section 5.4 setDirection ( ) does not take effect immediately : " The setDirection method sets the direction of the RTCRtpTransceiver . Calls to setDirection ( ) do not take effect immediately . Instead , future calls to createOffer and createAnswer mark the corresponding media description as sendrecv , sendonly , recvonly or inactive as defined in [  ] ( section 5.2.2 . and section 5.3.2 . ) . Calling setDirection ( ) sets the negotiation - needed flag . " My interpretation of the above is that setDirection immediately sets the transceiver.direction attribute , but that the " current direction " ( distinct from the direction attribute ) is only changed by calls to setLocal / setRemoteDescription . I would like to suggest that JSEP indicate precisely when the " current direction " changes . My reading of JSEP is that this is determined from the currentLocalDescription and currentRemoteDescription . For example : direction provided in the currentLocalDescription ( e.g. the " current direction " ) is " sendrecv " and setDirection("recvonly " ) is called . Since setDirection does not change the direction in currentLocalDescription , the RtpSender does not stop sending . ( ) is called . A " recvonly " offer is generated . ( RecvOnlyOffer ) is called . Now the direction in pendingLocalDescription changes to " recvonly " , but the direction in currentLocalDescription is still " sendrecv " , so the RtpSender does not stop sending . ( SendOnlyAnswer ) is called . Now the direction in currentLocalDescription is " recvonly " , so the RtpSender will stop sending . 
  's description makes sense to me ; currentLocal / Remote indicate the current direction state . 
 Fixed by
Paragraph (version B):
The direction method returns the last value passed into setDirection.
If setDirection has never been called, it returns the direction the
transceiver was initialized with.
Paragraph (version B):
The currentDirection method returns the last negotiated direction for
the transceiver's associated m= section.  More specifically, it
returns the RFC3264 directional attribute of the associated m=
section in the last applied answer, with "send" and "recv" directions
reversed if it was a remote answer.  For example, if the directional
attribute for the associated m= section in a remote answer is
"recvonly", currentDirection returns "sendonly".
Paragraph (version B):
If an answer that references this transceiver has not yet been
applied, or if the transceiver is stopped, currentDirection returns
null.
Draft: draft-ietf-rtcweb-jsep

Commentary: This still refers to RtpSenders being " activated " , a concept that is n't defined anywhere . I replaced this with " track attached to the transceiver " since that 's the terminology that 's used elsewhere .
Paragraph (version A):
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see sec.applying-a-remote-desc and sec.applying-a-local-
desc).  This means that some RtpTransceivers that were previously
associated will no longer be associated with any m= section; in such
cases, the value of the RtpTransceiver's mid attribute MUST be set to
null.  RtpTransceivers that were created by applying a remote offer
that was subsequently rolled back MUST be removed.  However, a
RtpTransceiver MUST NOT be removed if the RtpTransceiver's RtpSender
was activated by the addTrack method.  This is so that an application
may call addTrack, then call setRemoteDescription with an offer, then
roll back that offer, then call createOffer and have a m= section for
the added track appear in the generated offer.
Paragraph (version B):
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see sec.applying-a-remote-desc and sec.applying-a-local-
desc).  This means that some RtpTransceivers that were previously
associated will no longer be associated with any m= section; in such
cases, the value of the RtpTransceiver's mid attribute MUST be set to
null.  RtpTransceivers that were created by applying a remote offer
that was subsequently rolled back MUST be removed.  However, a
RtpTransceiver MUST NOT be removed if a track was attached to the
RtpTransceiver via the addTrack method.  This is so that an
application may call addTrack, then call setRemoteDescription with an
offer, then roll back that offer, then call createOffer and have a m=
section for the added track appear in the generated offer.
Draft: draft-ietf-rtcweb-jsep

Commentary: Also , fixes problem where my previous change to explain the directional attribute for answers was accidentally applied to the offer section . 
 Not clear whether this should be an example , i.e. , in the Examples section , or perhaps just an aside in the setDirection section .
Paragraph (version A):
TODO: Write example showing how this might be used and how it affects
offers/answers/reoffers.  Maybe something like: "sendonly" remote
offer, setDirection("sendonly"), "inactive" answer, "sendonly"
reoffer.
Paragraph (version B):
When creating offers, the transceiver direction is directly reflected
in the output, even for reoffers.  When creating answers, the
transceiver direction is intersected with the offered direction, as
explained in the sec.generating-an-answer section below.
Draft: draft-ietf-rtcweb-jsep

Commentary: LGTM 
 What needs to happen to finish this one ? 
 I think this reflects our discussion in the bug . 
 LGTM 
 back at you 
 Ugh , git push failing due to airplane wifi . Will update when it succeeds 
 done 
 Where are we on this . Is this waiting for justin ? 
 yes , we are waiting for justin
Paragraph (version B):
If the m= section is not bundled into another m= section, an
"a=rtcp" attribute line MUST be added with of the default RTCP
candidate, as indicated in RFC5761, section 5.1.3.
Paragraph (version B):
The "a=rtcp" line MUST be added if the most recent answer did not
include an "a=rtcp-mux" line; otherwise it MUST NOT be added.