jiebi/CodeConvo huggingface dataset:
Change:
Line 2589: "I don't think this is quite right. I imagine this should probably echo the above, e.g. MUST only be added if present in the most recent answer."
So re-review this one and see if you are OK with it as is.
This seems fine.
JSEP should probably point at the draft and include the attribute on every (applicable) media section.
Agreed

Discussion:
An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. <ins> An "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux- exclusive Section 4, if and only if the RTP/RTCP multiplexing policy is "require". </ins> An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. For each supported RTP header extension, an "a=extmap" line, as

The "a=rtcp-mux" line MUST only be added if present in the most recent answer. <ins> The "a=rtcp-mux-only" line MUST only be added if present in the most recent answer. </ins> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.

m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. <ins> If present in the offer, an "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4.3. </ins> If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5.
Change:
…sane peer.
NAME PTAL.
Just a quick drive-by review. LGTM with nits

Discussion:
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 <del> in the ICE candidate is invalid, an error is generated.  Connectivity checks will be sent to the new candidate. </del> <ins> in the ICE candidate is invalid, an error is generated.  If present, ufrag is used to determine which generation of ICE candidates the candidate belongs to; this resolves ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is present and does not match any remote description, an error is generated.  If the ufrag is absent, the candidate MUST be assumed to belong to the most recently applied remote description.  Connectivity checks will be sent to the new candidate. </ins> 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
Change:
LGTM
PTAL
In the WebRTC 1.0 spec we have text talking about generating a mid if the remote description is missing one. That text has a faulty link to a JSEP (as described in issue w3c/webrtc-pc/issues/698). I can't seem to find any text in JSEP about this. Should there be such text? I did find text that said that an answer only should have a mid if the offer did.
OK, I agree we need some additional text in 3.5.2.1 to indicate that if a MID is not negotiated in SDP, a MID is locally generated (but not included in SDP).
Fixed by
Thank you!

Discussion:
line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations <del> creating an ICE Candidate object MUST populate both of these fields. Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (as it could have come from a non-JSEP endpoint). </del> <ins> creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a-remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (the non-JSEP remote endpoint case). </ins> 3.5.3.

Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid <del> attribute to the MID of the m= section. </del> <ins> attribute to the MID of the m= section.  If the m= section does not include a MID (i.e., the remote side does not support the MID extension), generate a value for the RtpTransceiver mid attribute, following the guidance for "a=mid" mentioned in sec.initial-offers. </ins> For each specified payload type that is also supported by the local implementation, establish a mapping between the payload
Change:
and
whoops, didn't realize that eric hadn't reviewed before I merged. NAME want to take a quick look?
This updates 4572 so needs to be referenced. Also see URL
This changes the requirements around use of .
Dup of
Minor nits.

Discussion:
set of ICE candidates.  Bundle-only m= sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. <del> For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they MUST all have the same RFC4572 fingerprint value, or this value MUST be a session-level attribute. </del> <ins> For DTLS, all m= sections MUST use all the certificate(s) that have been specified for the PeerConnection; as a result, they MUST all have the same I-D.ietf-mmusic-4572-update fingerprint value(s), or these value(s) MUST be session-level attributes. </ins> Each m= section should be generated as specified in RFC4566, Section 5.14.  For the m= line itself, the following rules MUST be

"a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </del> <ins> One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.
Change:
IDENTICAL-PT or SPECIAL which means that they should be in all the m= sections.
NAME can you look into this? Should be straightforward to resolve.

Discussion:
An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. <del> [TODO: rtcp-fb?] </del> Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default
Change:
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.

Discussion:
affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer. <del> 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. </del> <ins> 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. </ins> 4.2.4.

header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <del> A direction attribute, determined by applying the rules regarding the offered direction specified in RFC3264, Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. </del> <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264,

in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. <del> A direction attribute which is the same as that of the associated transceiver. </del> <ins> A direction attribute, determined by applying the rules regarding the offered direction specified in RFC3264, Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. </ins> For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264,
Change:
This still refers to RtpSenders being "activated", a concept that isn't defined anywhere. I replaced this with "track attached to the transceiver" since that's the terminology that's used elsewhere.

Discussion:
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 <del> 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. </del> <ins> 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:
This is OK with me but fine if we want to call out identity or anything that is different.
How's this?
LGTM
S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST

Discussion:
have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. <del> Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. </del> <ins> Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical.  This promotes readability, especially if one of a set of initially identical attributes is subsequently changed. </ins> Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically
Change:
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.
URL
R-10 (a=ssrc) should probably be removed or adjusted to reflect the fact that JSEP won'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.

Discussion:
allocated to the senders and setting maximum media bit-rate boundaries. <del> TODO: any others? </del> As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.
Change:
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". Section 5.1.3: Spurious space in: For data m= sections, JSEP endpoints MUST support receiving the "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles.
NAME PR wanted.
NAME 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 NAME
NAME 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

Discussion:
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 <del> compatible mode and use AVP timing, i.e., "trr-int=4". </del> <ins> compatible mode and use a value of "trr-int=4000". </ins> For data m= sections, JSEP endpoints MUST support receiving the <del> "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards </del> <ins> "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards </ins> compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile
Change:
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".

Discussion:
(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 <del> 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. </del> <ins> resources. </ins> Calling this method may do things such as generate new ICE credentials, but does not result in candidate gathering, or cause

Session descriptions generated by createAnswer must be immediately usable by setLocalDescription; like createOffer, the returned <del> 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. </del> <ins> description should reflect the current state of the system. </ins> Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media
Change:
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.

Discussion:
If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header <del> extension, as described in I-D.ietf-mmusic-msid, Section 3.2. </del> <ins> extension, as described in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 14. </ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in
Change:
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

Discussion:
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 <del> the mandatory constraints, this SHOULD be represented by x=0 and y=0 </del> <ins> the mandatory constraints, this MUST be represented by x=0 and y=0 </ins> values. The rules here express a single set of preferences, and therefore,
Change:
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

Discussion:
in the corresponding media section in the offer, this indicates a negotiation problem and MUST result in an error. <del> 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. </del> <ins> 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. </ins> If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced-
Change:
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 max-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 don't think this behavior is documented anywhere. I think the choices, in order of harshness, are: Silently fails, and you don'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

Discussion:
multiplexing or non-multiplexing endpoints. The browser will only gather RTP candidates.  This halves the <del> 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. </del> <ins> 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. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to

section for this media type or in the same bundle group as the first m= section for this media type. <del> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute. </del> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed:

not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. <ins> If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:

exactly match the media type and protocol values in the corresponding m= section in the associated offer. <ins> If any of the preceding checks failed, processing MUST stop and an error MUST be returned. </ins> 5.8. The following steps are performed at the media engine level to apply
Change:
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?

Discussion:
RFC4568 MUST NOT be implemented to signal SDES SRTP keying information. <del> The RFC5888 grouping framework MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. </del> <ins> RFC5888 MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. </ins> I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and
Change:
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.

Discussion:
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 <del> described below; all dimensions assume square pixels. </del> <ins> described below; all dimensions are measured in pixels, whether square or not. </ins> 3.6.1.