Change:
This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.

Discussion:
"sendrecv" from RFC4566 MUST be implemented to signal information about media direction. <del> RFC5576 MUST be implemented to signal RTP SSRC values. </del> <ins> RFC5576 MUST be implemented to signal RTP SSRC values and grouping semantics. </ins> RFC4585 MUST be implemented to signal RTCP based feedback.

RFC5506 MUST be implemented to signal reduced-size RTCP messages. <ins> RFC4588 MUST be implemented to signal RTX payload type associations. </ins> 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

An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as <del> specified in RFC4566, Section 6.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see </del> <ins> specified in RFC4566, Section 6.  The audio and video codecs that MUST be supported are specified in I-D.ietf-rtcweb-audio (see </ins> Section 3) and I-D.ietf-rtcweb-video (see Section 5). If this m= section is for media with configurable frame sizes,

payload type of the primary codec, as specified in RFC4588, Section 8.1. <del> For each supported FEC mechanism, a corresponding "a=rtpmap" line indicating the desired FEC codec. </del> <ins> For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The FEC mechanisms that MUST be supported are specified in I-D.ietf-rtcweb-fec, Section 6, and specific usage for each media type is outlined in Sections 4 and 5. </ins> "a=ice-ufrag" and "a=ice-passwd" lines, as specified in RFC5245, Section 15.4.

the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line <del> with the FEC SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FEC" and including the primary and FEC SSRCs. </del> <ins> with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </ins> [OPEN ISSUE: Handling of a=imageattr]

For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and <del> RFC3264, Section 6.1.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </del> <ins> RFC3264, Section 6.1.  The audio and video codecs that MUST be supported are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the

"a=fmtp" line that references the payload type of the primary codec, as specified in RFC4588, Section 8.1. <del> For each supported FEC mechanism that is present in the offer, a corresponding "a=rtpmap" line indicating the desired FEC codec. </del> <ins> For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The FEC mechanisms that MUST be supported are specified in I-D.ietf-rtcweb-fec, Section 6, and specific usage for each media type is outlined in Sections 4 and 5. </ins> "a=ice-ufrag" and "a=ice-passwd" lines, as specified in RFC5245, Section 15.4.

If a local MediaStreamTrack has been associated, and FEC has been negotiated for this m= section, another "a=ssrc" line with the FEC <del> SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FEC" and including the primary and FEC SSRCs. </del> <ins> SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </ins> [OPEN ISSUE: Handling of a=imageattr]