Change:
Still LGTM
NAME we have consensus on this from the editor team, but please comment here if you see anything else and I'll take a look.
Thanks, I think it looks good in general. Regarding the "par" question NAME raised the current text promotes some picture over correct picture aspect ratio. Having a bullet that one selects one that has PAR that the sending side supports to send can result in more optimal choice but also may result in a slight increase in blocked video where a stretched video may be shown instead.

Discussion:
resolution when needed, or may be locked to a specific output resolution. <del> For each encoding being produced by the RtpSender, the following rules are applied to determine what should be transmitted: First, the most suitable "a=imageattr recv" attribute is selected. This is performed by taking the attribute with the highest "q=" value from the set of attributes that reference the media format that has been selected for the specified encoding.  If multiple attributes have the same "q=" value, the one that appears first in the m= section is used.  Note that while JSEP endpoints will include at most one "a=imageattr recv" attribute per media format, JSEP endpoints may receive session descriptions from non-JSEP endpoints with m= sections that contain multiple such attributes. If there is an applicable "a=imageattr recv" attribute for the encoding, the limits from the attribute are then compared to the encoder resolution.  Only the specific limits mentioned below are </del> <ins> For each encoding being produced by the RtpSender, the set of "a=imageattr recv" attributes in the corresponding m= section of the remote description is processed to determine what should be transmitted.  Only attributes that reference the media format selected for the encoding are considered; each such attribute is evaluated individually, starting with the attribute with the highest "q=" value.  If multiple attributes have the same "q=" value, they are evaluated in the order they appear in their containing m= section.  Note that while JSEP endpoints will include at most one "a=imageattr recv" attribute per media format, JSEP endpoints may receive session descriptions from non-JSEP endpoints with m= sections that contain multiple such attributes. For each "a=imageattr recv" attribute, the following rules are applied.  If this processing is successful, the encoding is transmitted accordingly, and no further attributes are considered for that encoding.  Otherwise, the next attribute is evaluated, in the aforementioned order.  If none of the supplied attributes can be processed successfully, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application. The limits from the attribute are compared to the encoder resolution.  Only the specific limits mentioned below are </ins> considered; any other values, such as picture aspect ratio, MUST be ignored.  When considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the

If the attribute includes a "sar=" (sample aspect ratio) value set to something other than "1.0", indicating the receiver wants to <del> receive non-square pixels, this cannot be satisfied and the sender MUST NOT transmit the encoding. </del> <ins> receive non-square pixels, this cannot be satisfied and the attribute MUST NOT be used. </ins> If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its

picture aspect ratio of the encoding.  For example, if the encoder resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If <del> downscaling cannot be applied, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application. </del> <ins> downscaling cannot be applied, the attribute MUST NOT be used. </ins> If the encoder resolution is less than the minimum size permitted <del> by the attribute, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application; the encoder MUST NOT apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. </del> <ins> by the attribute, the attribute MUST NOT be used; the encoder MUST NOT apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. If the encoder resolution is within the maximum and minimum sizes, no action is needed. </ins> 3.7.