Original text:
all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints. </del>  As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST The browser will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather.  When <del> acting as answerer, the browser will reject any m= section that does not provide an "a=rtcp-mux" attribute. </del>  The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. <del> For each offered m= section, if the associated RtpTransceiver has been stopped, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6., and further processing for this m= section can be skipped. For each offered m= section, if no supported codec is present in the offer, 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 in RFC3264, Section 6., and further processing for this m= section can <del> be skipped. </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

Reviewer comments:
Also restructured the "rejecting media descriptions" sections since there are now four things that can cause it to be rejected.
I think this does a good job clarifying these edge cases and is the behavior we want.
lgtm
LGTM
I just realized this may not be complete. Even if max-bundle is used, shouldn't one media description be accepted? This would ensure the same result regardless of whether the max-bundle endpoint is the offerer or answerer. It would also prevent a remote offer from being rejected if it didn't include a "BUNDLE" group simply because there was only one media description.
Deficiencies should be addressed by this PR (apologies for missing them on the first pass): URL

Revised text:
all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy  <ins> endpoints.  When acting as answerer, the implementation will reject any m= section that is not in a bundle group. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST The browser will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather.  When  <ins> acting as answerer, the implementation will reject any m= section that does not contain an "a=rtcp-mux" attribute. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer.  <ins> 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 in RFC3264, Section 6., and further processing for this m= section can  <ins> be skipped: The associated RtpTransceiver has been stopped. No supported codec is present in the offer. The bundle policy is "max-bundle" and the m= section is not in a bundle group. The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute. </ins> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the