Original text:
section by setting the value of the RtpTransceiver's mid attribute to the MID of the m= section. <del> 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 - Justin to add more to explain mapping.]  If any indicated payload type is unknown, it MUST be ignored.  [TODO: should fail on answers] </del>  For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload <del> type, as described in RFC4588.  If any referenced primary payload types are not present, this MUST result in an error. </del>  For each specified fmtp parameter that is supported by the <del> local implementation, enable them on the associated payload types. </del>  For each specified RTCP feedback mechanism that is supported by <del> the local implementation, enable them on the associated payload types. </del>  For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending

Reviewer comments:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * 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 - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

Revised text:
section by setting the value of the RtpTransceiver's mid attribute to the MID of the m= section.  <ins> For each specified media format that is also supported by the local implementation, establish a mapping between the specified payload type and the media format, as described in RFC3264, Section 6.1.  Specifically, this means that the implementation records the payload type to be used in outgoing RTP packets when sending each specified media format, as well as the relative preference for each format that is indicated in their ordering.  If any indicated media format is not supported by the local implementation, it MUST be ignored. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload  <ins> type, as described in RFC4588, Section 4.  If any referenced primary payload types are not present, this MUST result in an error. </ins> For each specified fmtp parameter that is supported by the  <ins> local implementation, enable them on the associated media formats. For each specified RTP header extension that is also supported by the local implementation, establish a mapping between the extension ID and URI, as described in RFC5285, Section 5. Specifically, this means that the implementation records the extension ID to be used in outgoing RTP packets when sending each specified header extension.  If any indicated RTP header extension is not supported by the local implementation, it MUST be ignored. </ins> For each specified RTCP feedback mechanism that is supported by  <ins> the local implementation, enable them on the associated media formats. </ins> For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending