Change:
5.8. <del> TODO </del> <ins> The following steps are performed at the media engine level to apply a remote description. For each media section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. If the description is of type "offer", and the ICE ufrag or password changed from the previous remote description, [TODO: ref], mark that an ICE restart is needed. Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their connectivity checks. Pair any supplied ICE candidates with any gathered local candidates, as described in [TODO: ref] and start connectivity checks with the appropriate credentials. If the media section proto value indicates use of RTP: [TODO: header extensions] For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format.  [TODO: ref] If any indicated payload type is unknown, it MUST be ignored.  [TODO: should fail on answers] For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type.  [TODO: ref] If any referenced primary payload types are not present, this MUST result in an error. For each specified fmtp parameter that is supported by the local implementation, enable them on the associated payload types. For each specified RTCP feedback mechanism that is supported by the local implementation, enable them on the associated payload types. For any specified "TIAS" bandwidth value, set this value as the maximum RTP bitrate to be used when sending media.  If a "TIAS" value is not present, but an "AS" value is, generate a TIAS a value using this formula: [TODO: convert AS to TIAS]. [TODO: handling of CN, telephone-event, "red"] If the media section if of type audio: For any specified "ptime" value, configure the available payload types to use the specified packet size.  If the specified size is not supported for a payload type, use the next closest value instead. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section below. </ins> 5.9. <del> TODO </del> <ins> In addition to the steps mentioned above for processing a local or remote description, the following steps are performed when processing a description of type "pranswer" or "answer". For each media section, the following steps MUST be performed: If the media section has been rejected (i.e. port is set to zero in the answer), stop any reception or transmission of media for this section, and discard any associated ICE components.  [TODO: ref] If the remote DTLS fingerprint has been changed, tear down the existing DTLS connection. If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any underlying ICE components, once they are active. If the media section proto value indicates use of RTP: If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in RFC5761, Section 5.1.3.  Otherwise, transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced- size RTCP, as specified in [TODO: ref] If the directional attribute in the answer is of type "sendrecv" or "sendonly", prepare to start transmitting media using the specified primary SSRC and one of the selected payload types, once the underlying transport layers have been established.  Otherwise, stop transmitting RTP media, although RTCP should still be sent.  [TODO: ref] If the media section proto value indicates use of SCTP: If no SCTP association yet exists, prepare to initiate a SCTP association over the associated ICE component and DTLS connection, using the local SCTP port value from the local description, and the remote SCTP port value from the remote description.  [TODO: ref] If the answer contains valid BUNDLE groups, discard any ICE components for the m= sections that will be bundled onto the primary ICE components in each BUNDLE, and begin muxing these m= sections accordingly.  [TODO: ref] If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true.  Otherwise, set this property to false. </ins> 6.

Discussion:
Still have a bunch of stuff to flesh out, but wanted to get this out for initial review. NAME NAME
Looks like good stuff to me. - The text in start of section 5 seem fine for making it clear that this does not override the referenced specs.
Thanks for the comments. Ran out of time to resolve them today but will take another shot at it Saturday.
Updated based on comments. I'd like to go ahead and merge this ASAP, and then hopefully still get another rev in before the deadline.
I'm fine with merging what we have here right now.
The text relies on the phrase "most recent gathering phase" to describe which candidates are present in SDP. Justin enumerated a few cases where the browser gathers a completely new set of candidates for an m= section (or component thereof): when a new m= section is added (which happens for a new RTCPeerConnection obviously) when an m= section did have a port of 0, but is repurposed for new media (basically the same scenario as above) ICE restart This needs a clearer definition, or maybe just a single clear description of what it means to do this. This can probably tie into the whole process of describing when candidate events fire and the interaction between that and setLocalDescription.
Martin, could you give us a PR that would satisfy you