Original text:
For each offered "m=" section, if any of the following conditions are true, the corresponding "m=" section in the answer MUST be marked as <del> rejected by setting the port in the "m=" line to zero, as indicated </del>  in RFC3264, and further processing for this "m=" section can be skipped: the specific order and with the specific syntax defined in RFC4566. The "m=" line itself MUST be parsed as described in RFC4566, and the <del> media, port, proto, and fmt values stored. </del>  Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: Specific processing MUST also be applied for the following attribute lines: <del> If the "m=" proto value indicates use of RTP, as described in </del>  sec.profile-names above, the following attribute lines MUST be processed: <del> Otherwise, if the "m=" proto value indicates use of SCTP, the </del>  following attribute lines MUST be processed: Other attributes that are not relevant to JSEP may also be present,

Reviewer comments:
The following changes have been made: changed to "set to zero" from "set to 0", removed comment. formatted media-field subfields consistently, removed comment.

fmt value / "fmt" value Justin: Would we also do media, port, and proto? This one needs more discusison.
RFC 4566 (SDP) was inconsistent in the formatting of fmt (, "fmt"), proto ("proto", ), and port (port, ). For the most part, media was just formatted media. RFC 8866 (SDP), which obsoletes RFC 4566, consistently formats these "m=" line subfields as , , , and . This document uses the following formats: fmt (3 instances) vs (2 instances) proto (7 instances) vs (5 instances) port (31) vs (0 instances) -- most are not referring specifically to the subfield, though I suggest using angle brackets (but not formatting -- I was just working around GitHub's markdown with that) for these terms when discussing "m=" line subfields.
SGTM, let's align with 8866 usage when an instance of these words refers specifically to a m= line subfield.
set to zero / set to 0 >(May we use the latter, because of '"dummy" port value of 9' in Sections 5.2.1 and 5.3.1?) Justin: What's the IETF style guide say on this sort of thing? 'zero' looks more natural to me, and matches RFC 3264's usage of 'zero'.
From our style guide: "In general text, we follow the CMOS guidance that numbers under 10 are written out and those above are represented using digits. However, if a value is followed by a unit of measure (e.g., 8 bytes, 3 octets), it should be in digit form regardless of value." There is one instance of "set to 0" in this document vs four instances of "set to zero". I can change that one instance to match the other four.
LGTM

Revised text:
For each offered "m=" section, if any of the following conditions are true, the corresponding "m=" section in the answer MUST be marked as  <ins> rejected by setting the <port> in the "m=" line to zero, as indicated </ins> in RFC3264, and further processing for this "m=" section can be skipped: the specific order and with the specific syntax defined in RFC4566. The "m=" line itself MUST be parsed as described in RFC4566, and the  <ins> <media>, <port>, <proto>, and <fmt> values stored. </ins> Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: Specific processing MUST also be applied for the following attribute lines:  <ins> If the "m=" <proto> value indicates use of RTP, as described in </ins> sec.profile-names above, the following attribute lines MUST be processed:  <ins> Otherwise, if the "m=" <proto> value indicates use of SCTP, the </ins> following attribute lines MUST be processed: Other attributes that are not relevant to JSEP may also be present,