Original text:
is always associated with exactly one RtpTransceiver.  However, in certain cases where an "m=" section has been rejected, as discussed in sec.subsequent-offers below, that "m=" section will be "recycled" <del> and associated with a new RtpTransceiver with a new mid value. </del>  RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds in RFC5888.  For each MediaStream referenced by more than one RtpTransceiver (by passing those MediaStreams as arguments to the addTrack and addTransceiver methods), a group of type "LS" MUST be <del> added that contains the mid values for each RtpTransceiver. </del>  Attributes that SDP permits to be at either the session level or the media level SHOULD generally be at the media level even if they are addTrack/addTransceiver used to create them) or have no MediaStream to reference because they were not created by addTrack/ addTransceiver.  If at least two such RtpTransceivers exist, a group <del> of type "LS" with the mid values of these RtpTransceivers MUST be </del>  added.  Otherwise, the offered "LS" group MUST be ignored and no corresponding group generated in the answer.

Reviewer comments:
Has the following updates: made MID value consistent, 60.2) tagged pseudocode as artwork. artwork is ascii-art. 52) fixed 8843 section xref, 44) updated text in Section 5.2.2 ok, removed comment. 35) fixed xref in Section 5.2.1, 26) updated ICE text in Section 5.1.1 with Justin's proposed text. 4) This change adds normative text, requires AD approval NAME added keywords, 1)
Justin: RFC 5888 defines it as Media Stream Identification, and later uses "Mid Value", but I agree we should probably go with MID/mid values. Justin: MID is not quoted in other RFCs ,I believe. Jean: Thread on the EMAIL mailing list discussing these terms: URL
NAME has this been taken care of yet? I thought an earlier PR addressed this issue.
The summary of the ML discussion [URL] suggests the following formatting changes to 8829: mid value --> MID value "mid" value --> MID value
LGTM
52) [rfced] Throughout: has been converted to as applicable and we set the "type" attribute. Please review and let us know corrections are needed.
This does look quite right. Section 2.5.7 of RFC 7991 makes me think the callflow's should be done with type artwork with type "call-flow" not sourcecode. And the type for the ascii art should be "ascii-art" instead of ""
Should I make a PR or RFC-ED ?
NAME for input
I can see how the callflows in Sections 7.1, 7.2, and 7.3 were labeled pseudocode, since they look more like inputs for a callflow diagram generator (complete with comments), but I'm ok with them being labeled as artwork with type="ascii-art" (the type attribute has evolved to provide info to the output renderers. There's some discussion about it in Section 2.6.7 of this update to RFC 7991: URL)
NAME can you advise here?
I really don't care - I am happy with whatever NAME wants to use
I will convert the call flows labeled with to . is being deprecated. See Section 2.6.7: URL
works for me - thanks
44) [rfced] Sections 5.9, 5.10, 5.11, and 6: RFC 8843 [I-D.ietf-mmusic-sdp-bundle-negotiation] does not have a Section 8.2 or a Section 10.2. We have updated these to refer to 7.2 and 9.2, respectively. Please review. Original: In addition, prepare to demux RTP streams intended for this m= section based on the media formats supported by this m= section, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. ... For each specified SSRC that is signaled in the m= section, prepare to demux RTP streams intended for this m= section using that SSRC, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. ... If the answer contains valid bundle groups, discard any ICE components for the m= sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these m= sections accordingly, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2. ... When bundling, associating incoming RTP/RTCP with the proper m= section is defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2.
Need section updates for BUNDLE.
Moving 10.2 to 9.2 looks right to me. However, 8.2 I think should be updated to 7.4.
35) [rfced] Section 5.2.2: We found this RFC Editor Note on : OLD: NEW: Please note that the "OLD" text does not match what we found in the provided draft (i.e., "[RFC5245], Section 4.3., paragraph 3" versus "[I-D.ietf-mmusic-ice-sip-sdp], Section 4.1"): Please review, and let us know if further changes are needed. (Note: "[RFC8839]" and "[RFC8840]" are the RFC numbers assigned to [I-D.ietf-mmusic-ice-sip-sdp] and [I-D.ietf-mmusic-trickle-ice-sip], respectively.) Currently:
Need to verify the references for the current text are correct.
Current text LGTM.
26) [rfced] Section 5.2.1: Please confirm that this citation is correct; we could not see a relationship between Section 14 of RFC 8843 [I-D.ietf-mmusic-sdp-bundle-negotiation] and the RTP header extension. Original: All MID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 14.
Need to review latest BUNDLE doc
I think the reference should be to section 15.2 (not 14 ) URL
Agreed. There may be some other citation around MID generation (that suggests starting at 0) that would be even better to reference, if we can find it.
Section 17 of BUNDLE (URL) mentions a per-bundle-group counter. However I tend to think we should just update the ref to what Cullen mentions and close this out.
4) [rfced] Adam Roach previously requested that "All other documents in Cluster 238 that currently reference RFC 5245 should be updated to reference RFC 8445. ... any other references to RFC 5245 that I may have overlooked should also be updated." We believe this document intentionally refers to both RFCs. Please let us know if any updates are needed.
I reviewed this and it seems correct, although S 5.1.1 is a bit confusing when it says that , even though we explicitly allow 5245-ICE in S 3.5.5. NAME thoughts on this?
I think that what we probably want here is something like: NAME any further thoughts? Planning to mark this as editor-ready.
NAME in case he has thoughts on this
Get me back up to speed on all this ... My recollection is this 1) this was widely discussed in th WG and adam was on one end of the fence. 2) the connection performance and RFC8445 is worse than RFC5245 and thus Cisco does not plan to move to RFC8445 until there is a new version that brings it back to 5245 performance. We want it to be OK to use either and specifically we do not want JSEP to require 8445. This is a major and significant change and certainly not something the AD should do in auth48. Is that about right
Just for clarity, this wasn't a unilateral AUTH48 change. The current state of ICE support in the documents is the result of a 55-message, 8-week consultation with the community in the late summer/early fall of 2018. I'd really rather not re-litigate this; but, if that's what needs to happen, then it's a matter of getting NAME or Barry to bring it back to the ART community again rather than the few of us working through it in github (which would be a very opaque and cliquish way to handle things). The proposal that had broad buy-in from the community [1] was around the specific text: Accompanied by the specific note that "RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative." So, to the crux of this ticket: yes, JSEP would reference both. 8445 normatively, and 5285 informatively. If the contents of this document vary substantively from that community-vetted text I cite above, then you'd definitely need sign-off by the current ART ADs. (Tagging NAME on this statement for her awareness.) _ for details
OK - thanks and I agree.
NAME in the following sentence: You meant RFC 5485 (ICE) instead of 5285 (A General Mechanism for RTP Header Extensions), correct? The document currently lists 8445 (ICE) normatively and 5485 (ICE) informatively. So no change there. It's my understanding that I should change the following: Current (Section 5.1.1, Usage Requirements): ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use a lite implementation; implementations MUST properly handle remote endpoints that do ICE-lite. Proposed (text from NAME with small tweaks): ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use an older version of ICE or ICE Lite; implementations MUST properly handle remote endpoints that use ICE or ICE Lite as specified in [RFC5245].
NAME -- Yep, that is all consistent with my understanding. (And apparently I'm going to carry that 5284/5485 typo around pretty much forever. )
This mostly SGTM. For the specific text, I think we'll need to ensure that the reader is clear that remote endpoints may use RFC 5245 ICE and also ICE Lite (regardless of version). Perhaps something like the following:
That looks good to me and make things very clear
1) [rfced] Please insert any keywords (beyond those that appear in the title) for use on URL
Should probably add webrtc and sdp
agreed. also: negotiation signaling peerconnection api ice rtp offer answer

Revised text:
is always associated with exactly one RtpTransceiver.  However, in certain cases where an "m=" section has been rejected, as discussed in sec.subsequent-offers below, that "m=" section will be "recycled"  <ins> and associated with a new RtpTransceiver with a new MID value. </ins> RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds in RFC5888.  For each MediaStream referenced by more than one RtpTransceiver (by passing those MediaStreams as arguments to the addTrack and addTransceiver methods), a group of type "LS" MUST be  <ins> added that contains the MID values for each RtpTransceiver. </ins> Attributes that SDP permits to be at either the session level or the media level SHOULD generally be at the media level even if they are addTrack/addTransceiver used to create them) or have no MediaStream to reference because they were not created by addTrack/ addTransceiver.  If at least two such RtpTransceivers exist, a group  <ins> of type "LS" with the MID values of these RtpTransceivers MUST be </ins> added.  Otherwise, the offered "LS" group MUST be ignored and no corresponding group generated in the answer.