Original text:
multiplexing or non-multiplexing endpoints. The browser will only gather RTP candidates.  This halves the <del> number of candidates that the offerer needs to gather.  When acting as answerer, the implementation will reject any m= section that does not contain 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 section for this media type or in the same bundle group as the first m= section for this media type. <del> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute. </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 following rules must be followed: not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified.  If this session description is of type "pranswer" or "answer", the following additional checks are applied: exactly match the media type and protocol values in the corresponding m= section in the associated offer.  5.8. The following steps are performed at the media engine level to apply

Reviewer comments:
This will happen when applying either an offer or an answer, for consistency. Also, any "semantics verification" failure will now result in an error, which was assumed but not explicitly stated. Fixes issue .
This is a good start, but you'll also want to update 4.1.1, 5.3.1 to reflect this (new) policy. Note though that this will end up being inconsistent with the handling of max-bundle as it is described in 4.1.1, although I still think this is the right approach.
Updated 4.1.1. I thought I already made the needed change to 5.3.1, what else needs to be changed?
I may be overlooking something, but I don't think this behavior is documented anywhere. I think the choices, in order of harshness, are: Silently fails, and you don't get RTCP negotiationneeded fires, and the m= section is port-zeroed in the next offer setRemoteDescription throws an error I'd lean towards the middle option, but that assumes that applications listen to negotiationneeded.
I lean toward the last option, as a violation of an invariant set by the offerer.
Agree that this should be documented somewhere.
+1 on the throw an error option
The general policy that we discussed here in Seattle was that any spec violation should lead to a setRD exception, not a zero port. For the rtcp-mux-only doc, we probably should have some language that makes rtcp-mux in the answer a MUST.
Resolved by

Revised text:
multiplexing or non-multiplexing endpoints. The browser will only gather RTP candidates.  This halves the  <ins> number of candidates that the offerer needs to gather.  Applying a description with an m= section that does not contain an "a=rtcp- mux" attribute will cause an error to be returned. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to section for this media type or in the same bundle group as the first m= section for this media type.  Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed: not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. <ins> If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied: exactly match the media type and protocol values in the corresponding m= section in the associated offer. <ins> If any of the preceding checks failed, processing MUST stop and an error MUST be returned. </ins> 5.8. The following steps are performed at the media engine level to apply