Original text:
header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <del> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. </del> A direction attribute which is the same as that of the associated transceiver. An "a=dtls-id" line, as specified in I-D.ietf-mmusic-dtls-sdp Section 5.2.  An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. in active use, then that pair MUST be used, even if ICE has not yet completed.  Note that this differs from the guidance in RFC5245, Section 9.1.2.2, which only refers to offers created when <del> ICE has completed.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </del>  Each "a=mid" line MUST stay the same. section is bundled into another m= section, it still MUST NOT contain any ICE credentials.  If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be The RTCP feedback extensions MUST only include those that are present in the most recent answer.  The "a=rtcp-mux" line MUST only be added if present in the most recent answer. in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. <del> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. </del> A direction attribute which is the same as that of the associated transceiver. Section 5.3. If present in the offer, an "a=rtcp-mux" line, as specified in <del> RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. </del>  If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. RFC5245, Section 4.3.  Note, however, that the m= line protocol need not match the default candidate, because this protocol value must instead match what was supplied in the offer, as described <del> above.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is enabled in the answer.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described in the initial answer section </del> above. The media formats on the m= line MUST be generated in the same m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials.  If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be

Reviewer comments:
LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin

Revised text:
header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11.  A direction attribute which is the same as that of the associated transceiver. An "a=dtls-id" line, as specified in I-D.ietf-mmusic-dtls-sdp Section 5.2. <ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. </ins> An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. in active use, then that pair MUST be used, even if ICE has not yet completed.  Note that this differs from the guidance in RFC5245, Section 9.1.2.2, which only refers to offers created when  <ins> ICE has completed.  In each case, if no RTP candidates have yet been gathered, dummy values MUST be used, as described above. </ins> Each "a=mid" line MUST stay the same. section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> If the m= section is not bundled into another m= section, an "a=rtcp" attribute line MUST be added with of the default RTCP candidate, as indicated in RFC5761, section 5.1.3. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be The RTCP feedback extensions MUST only include those that are present in the most recent answer. <ins> The "a=rtcp" line MUST be added if the most recent answer did not include an "a=rtcp-mux" line; otherwise it MUST NOT be added. </ins> The "a=rtcp-mux" line MUST only be added if present in the most recent answer. in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer.  A direction attribute which is the same as that of the associated transceiver. Section 5.3. If present in the offer, an "a=rtcp-mux" line, as specified in  <ins> RFC5761, Section 5.1.1.  Otherwise, an "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0" (because no candidates have yet been gathered). </ins> If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. RFC5245, Section 4.3.  Note, however, that the m= line protocol need not match the default candidate, because this protocol value must instead match what was supplied in the offer, as described  above. The media formats on the m= line MUST be generated in the same m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> If the m= section is not bundled into another m= section and RTCP multiplexing is not active, an "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate. If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial answer section above. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be