jiebi/CodeConvo huggingface dataset:
Change:
Attempts to address issue . Also changed "control" to "inspect" in RtpReceiver description, since an RtpReceiver is readonly and doesn'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. NAME FYI
Resolved by

Discussion:
3.4.2. RtpSenders allow the application to control how RTP media is sent. <ins> 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). </ins> 3.4.3. <del> RtpReceivers allows the application to control how RTP media is received. </del> <ins> 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). </ins> 3.5.

If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media are available to </del> <ins> and the media directions are compatible, and media is available to </ins> send, this will result in the starting of media transmission. 4.1.9.

If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media are available to </del> <ins> and the media directions are compatible, and media is available to </ins> send, this will result in the starting of media transmission. 4.1.10.
Change:
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 doesn'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.

Discussion:
For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in <del> 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. </del> <ins> 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. </ins> For any specified "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.
Change:
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

Discussion:
RFC4588 MUST be implemented to signal RTX payload type associations. <del> 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. </del> <ins> RFC3556 MUST be supported for control of RTCP bandwidth limits. </ins> As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.
Change:
Originally raised by Magnus: 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) . 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

Discussion:
The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver <del> that has been added to the PeerConnection.  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) . </del> <ins> that has been added to the PeerConnection, excluding any stopped RtpTransceivers.  This is done in the order the RtpTransceivers were added to the PeerConnection. </ins> Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique
Change:
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 URL 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."

Discussion:
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 <del> 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. </del> <ins> 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. </ins> If the directional attribute is of type "recvonly" or "inactive", stop transmitting all RTP media, but continue
Change:
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:
Agree, there is precedent for this regarding the canTrickleIceCandidates property in URL We should make these consistent (note use of 'property' vs 'attribute')

Discussion:
4.2.2. <del> The stopped method returns "true" if the transceiver has been </del> <ins> The stopped property indicates whether the transceiver has been </ins> stopped, either by a call to stopTransceiver or by applying an answer <del> that rejects the associated m= section, and "false" otherwise. </del> <ins> that rejects the associated m= section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </ins> A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.
Change:
It’s an API requirement, so the MUST doesn’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

Discussion:
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 <del> 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. </del> <ins> 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. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime
Change:
Also, remove awkward reference to WebRTC spec
Originally raised by Christer Section 3.3 says: "In the WebRTC specification, session descriptions are formatted as SDP messages." 1) To me it is unclear what an ³SDP message² is, so I suggest we say ³SDP syntax², as we also do later in the section.
FWIW, RFC 4566 itself uses the term 'SDP message' in Section 7. However, we could say 'descriptions use SDP syntax' instead.

Discussion:
3.3. <del> In the WebRTC specification, session descriptions are formatted as SDP messages.  While this format is not optimal for manipulation from Javascript, it is widely accepted, and frequently updated with new features.  Any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity.  As a result, JSEP currently uses SDP as the internal representation for its session descriptions. </del> <ins> JSEP's session descriptions use SDP syntax for their internal representation.  While this format is not optimal for manipulation from Javascript, it is widely accepted, and frequently updated with new features; any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity. </ins> However, to simplify Javascript processing, and provide for future flexibility, the SDP syntax is encapsulated within a
Change:
LGTM
Section 3.8.2 - "the media flow from these sessions can be managed by specifying SDP direction attributes in the descriptions". This seems out of place. Surely flipping URL is a much simpler way of managing them if the problem is what to play to the user? Suggestion: Remove text.

Discussion:
As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote description and their own local and remote addresses.  The media flow <del> from these sessions can be managed by specifying SDP direction attributes in the descriptions, or the application can choose to play </del> <ins> from these sessions can be managed using setDirection (see sec.transceiver-set-direction), or the application can choose to play </ins> out the media from all sessions mixed together.  Of course, if the application wants to only keep a single session, it can simply terminate the sessions that it no longer needs.
Change:
Plan is to write the text in the apply local/remote sections to indicate that upon an error, the session state should be restored to the pre-call state.

Discussion:
5.8. The following steps are performed at the media engine level to apply <del> a local description. </del> <ins> a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. </ins> First, the parsed parameters are checked to ensure that they have not been altered after their generation in createOffer/createAnswer, as

5.9. <ins> The following steps are performed to apply a remote description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. </ins> If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. <del> The following steps are performed at the media engine level to apply a remote description. </del> The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.
Change:
This is from the Windows HW offload framework, and spells things out more specifically in the surrounding text.

Discussion:
specific "a=imageattr" attributes MUST be inserted for each payload type. <del> As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this </del> <ins> As an example, consider a system with a multiformat video decoder, which is capable of decoding any resolution from 48x48 to 720p, and where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this </ins> attribute: <del> a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] </del> <ins> a=imageattr:* recv [x=[48:640],y=[48:360],q=1.0] </ins> This declaration indicates that the receiver is capable of decoding <del> any image resolution from 16x16 up to 640x360 pixels. </del> <ins> any image resolution from 48x48 up to 640x360 pixels. </ins> 3.6.2.
Change:
Is there any other action to be taken for the issues mentioned in ?
NAME I concluded no.
Grouping these as one bug. Section 4.1.7.1 - the term "inactive" final answer is introduced without a defintion. Need to either define "inactive" or use another term. Section 4.1.7.2 Rollback - "and possibly the answerer as well" is wishy-washy. Suggest "and the answerer if it has done set-remote-description". Section 4.1.7.2 This is the first mention of "pending local / remote description". Suggest link to definition. Section 4.1.7.2 "RTPTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed". The term "removed" is undefined. Deleted, discarded, destroyed or detached from the PeerConnection? Suggestion: "stopped and removed from the PeerConnection". (if the JS app still has a reference to them, it may still inspect the object).
LG % nit

Discussion:
A rollback discards any proposed changes to the session, returning the state machine to the stable state, and setting the pending local <del> and/or remote description back to null.  Any resources or candidates </del> <ins> and/or remote description (see sec.pendinglocaldescription and sec.pendingremotedescription) to null.  Any resources or candidates </ins> that were allocated by the abandoned local description are discarded; any media that is received will be processed according to the previous local and remote descriptions.  Rollback can only be used to

associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to null.  RtpTransceivers that were created by applying a remote offer <del> 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. </del> <ins> that was subsequently rolled back MUST be stopped and removed from the PeerConnection.  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. </ins> A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or
Change:
NAME has given his thumbs up as well.
Originally raised by Christer Section 3.2 says: "To support this, the JSEP media layer can provide an offer via the createOffer() method whenever the Javascript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer. The state machine for this is as follows:" 1) I would like to explicitly note that the generated offer is not applied (and any previously applied offer is not removed) until setLocalDescription() is called.
OK. In this case, we should note this for the provisional answers as well.
I thought about this for a while and came to the conclusion that this is the wrong place for such text; spelling everything out makes the overall message less clear. If we need to be super-prescriptive about the fact that the offer does not take effect until after setLD is called, we should state this in the createOffer/Answer sections (4.1.5/4.1.6), not here. NAME PTAL.
Will update document according to my last comment.
See PR
PR looks ok.

Discussion:
setLocalDescription will succeed when it attempts to acquire those resources. <del> Calling this method may do things such as generate new ICE </del> <ins> Calling this method may do things such as generating new ICE </ins> credentials, but does not result in candidate gathering, or cause <del> media to start or stop flowing. </del> <ins> media to start or stop flowing.  Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.7.

usable by setLocalDescription; like createOffer, the returned description should reflect the current state of the system. <del> Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media state. </del> <ins> Calling this method may do things such as generating new ICE credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.8.
Change:
Originally raised by Christer Section 3.2 says: "the DTLS-SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup" 1) I am not sure what "parameters" the text is referring to. If it¹s the fingerprint, I think the text should reference RFC 4572. 2) I think we should simply have a generic statement that, following the rules in RFC3264, parameters indicate receiving capabilities - unless explicitly indicated otherwise.
The parameters include a=setup and a=fingerprint. 5763 seems like it covers both.
NAME thoughts?
Authors believe this text is fine. NAME please send us a PR with the specific change you want if you disagree.
NAME said in email: certificate the local side will use in DTLS setup". >So, I would suggest to replace: “However, not all parameters follow this rule; for example, the DTLS- SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive;” >…with: “However, not all parameters follow this rule; for example, the fingerprints sent to a remote party are calculated based on the local certificate(s) offered;” >If you agree with that understanding, I’m happy to submit a pull request.
OK, I now see what you are saying, and I think the text you propose looks reasonable. Thanks for offering to submit a PR!
[waiting on PR from NAME
It seems like I don't have rights to submit new branches (needed for the PR).
cd4u: fork the repo and push the branch to your fork, then submit the PR from there.
PR created: URL
Fixed by

Discussion:
of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. <del> However, not all parameters follow this rule; for example, the DTLS- SRTP parameters RFC5763 sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive; the remote party will have to accept these parameters, with no option to choose different values. </del> <ins> However, not all parameters follow this rule; for example, the fingerprints I-D.ietf-mmusic-4572-update sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an
Change:
a=rtcp-mux-only LS groups
Relevant to , although there are a few nits remaining which will be handled in a followup PR
FWIW, this is atop
Added machine-filling of candidate artwork tags as well in this PR.
Follow new rules for a=rtcp, duplication of attributes Add dtls-id, rtcp-mux-only Maybe add imageattr
adds dtls-id, and I think follows the new rules for a=rtcp and attrib duplication. It doesn't yet handle the second example or do rtcp-mux-only.
Fixed by

Discussion:
The SDP for |offer-B1| looks like: <del> The SDP for |candidate-B1| looks like: </del> <ins> The SDP for |offer-B1-candidate-1| looks like: </ins> <del> The SDP for |candidate-B2| looks like: </del> <ins> The SDP for |offer-B1-candidate-2| looks like: </ins> The SDP for |answer-B1| looks like: <del> The SDP for |candidate-B3| looks like: </del> <ins> The SDP for |answer-B1-candidate-1| looks like: </ins> <del> The SDP for |candidate-B4| looks like: </del> <ins> The SDP for |answer-B1-candidate-2| looks like: </ins> The SDP for |offer-B2| looks like: (note the increment of the version number in the o= line, and the c= and a=rtcp lines, which indicate