Original text:
are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I- <del> D.shieh-rtcweb-ip-handling. </del>  There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to <del> at most 360p.  In this case, the implemention would generate this </del>  attribute: a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level. </del>  Once all the session-level lines have been parsed, processing continues with the lines in media sections. If present, a single "a=setup" line is parsed as specified in RFC4145, Section 4, and the setup value is stored. <del> If the "m=" proto value indicates use of RTP, as decribed in the </del>  sec.profile-names section above, the following attribute lines MUST be processed: extension, as described in I-D.ietf-mmusic-msid, Section 3.2. For each specified payload type, establish a mapping between <del> the payload type ID and the actual media format, as descibed in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </del>  For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload

Reviewer comments:
This is all strictly editorial and I think if either of you give it a quick scan, you can just merge it
LGTM - will merge

Revised text:
are used in a session.  Note that this filtering is applied on top of any restrictions the browser chooses to enforce regarding which IP addresses are permitted for the application, as discussed in I-  <ins> D.ietf-rtcweb-ip-handling. </ins> There may also be cases where the application wants to change which types of candidates are used while the session is active.  A prime As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to  <ins> at most 360p.  In this case, the implementation would generate this </ins> attribute: a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.  <ins> TODO: identity, rtcp-rsize, rtcp-mux, and any other attributes valid at session level. </ins> Once all the session-level lines have been parsed, processing continues with the lines in media sections. If present, a single "a=setup" line is parsed as specified in RFC4145, Section 4, and the setup value is stored.  <ins> If the "m=" proto value indicates use of RTP, as described in the </ins> sec.profile-names section above, the following attribute lines MUST be processed: extension, as described in I-D.ietf-mmusic-msid, Section 3.2. For each specified payload type, establish a mapping between  <ins> the payload type ID and the actual media format, as described in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload