Change:
NAME NAME Is this approximately right?
Looks close enough to me - lets land this then tune with future PRs
LG with nits

Discussion:
gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. <del> Each m= section MUST include the following attribute lines: </del> <ins> I-D.ietf-mmusic-sdp-mux-attributes groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, Section 8.1 of I-D.ietf-mmusic-sdp-bundle-negotiation specifies that attributes of category IDENTICAL or TRANSPORT should not be repeated in bundled m= sections. The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section: </ins> An "a=mid" line, as specified in RFC5888, Section 4.  When generating mid values, it is RECOMMENDED that the values be 3

specific usage for each media type is outlined in Sections 4 and 5. <del> "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the offer MUST be "actpass". An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. 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". An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. </del> For each supported RTP header extension, an "a=extmap" line, as specified in RFC5285, Section 5.  The list of header extensions that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-

Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. <ins> The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag.  (In initial offers, this means those "m=" sections which do not contain an "a=bundle-only" attribute. "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. 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. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the offer MUST be "actpass". An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. [TODO: rtcp-fb?] </ins> 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

If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being bundled must use unique ICE credentials and candidates.  Each m= <del> section MUST include the following: </del> <ins> section MUST contain the following attributes (which are of attribute types other than IDENTICAL and TRANSPORT): </ins> If and only if present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that

specific usage for each media type is outlined in Sections 4 and 5. <del> "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the answer MUST be "active" or "passive"; the "active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. If present in the offer, an "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4.3. If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. </del> For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in RFC5285, Section 5. The list of header extensions that SHOULD/MUST be supported is

simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <ins> Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. 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. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the answer MUST be "active" or "passive"; the "active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. </ins> If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> and "fmt" fields MUST be set to exactly

Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included <del> as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del> <ins> under the conditions described above, along with an "a=fmtp:webrtc- datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as