Change:
Still needs updates to createOffer/Answer.
Travis still seems sad.
Since I won't be on the call, I give this my preemptive LGTM, provided you at least look at my comments (and maybe reject them) and fix the build
Eric, did you want to take another look at this?
There one sentence I think we need to deal with (see other comment) but rest of this LGTM
It still seems like my proposed change of replacing "the initial offer-answer exchange is complete, and as a result, a new offer-answer is needed to communicate them" with "receiving the initial answer or pr-answer. " would make this more or less right for both cases and as the API developers, or does not develop, for this then we can fill in more details
Well, as far as I can tell, you can't do it after the pr-answer, since you can't do an offer at that stage.
NAME PTAL at PR . I think with this change we are ready to go. If that makes you happy, merge in PR into here and then merge this PR.
With EKR's this LGTM
OK, I will push the buttons now.
OK, I worked this over a bit to incorporate PR and also handle the case where the decoder hard limits are not known. The changes are minor but I will hold off for the next few hours to get a sanity check from one of you.
LGTM
I will read it and get back to you I 30 minutes
LGTM
Fixed merge conflict and merged.

Discussion:
In order to determine the limits on what video resolution a receiver wants to receive, it will intersect its decoder hard limits with any mandatory constraints that have been applied to the associated <del> MediaStreamTrack.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing createAnswer call.  For the offerer, since it does not know about any remote MediaStreamTracks until it receives theanswer, this implies that it can only set these constraints after the initial offer-answer exchange is complete, and as a result, a new offer-answer is needed to communicate them. The resulting resolution space formed by intersecting the decoder hard limits with any mandatory constraints will be used as the x= and y= values for the generated "a=imageattr" attribute for the associated MediaStreamTrack.  With only one set of preferences expressed, the q= value is not important; it SHOULD be set to 1.0. If the intersection is the null set, i.e., there are no resolutions that are permitted by both the decoder and the mandatory constraints, this SHOULD be represented using x=0 and y=0 values. </del> <ins> MediaStreamTrack.  If the decoder limits are unknown, e.g. when using a software decoder, the mandatory constraints are used directly.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing createAnswer call. Any constraints set after setLocalDescription is used to set the answer will result in a new offer-answer exchange.  For the offerer, because it does not know about any remote MediaStreamTracks until it receives the answer, the offer can only reflect decoder hard limits. If the offerer wishes to set mandatory constraints on video resolution, it must do so after receiving the answer, and the result will be a new offer-answer to communicate them. If there are no known decoder limits or mandatory constraints, the "a=imageattr" attribute SHOULD be omitted. Otherwise, an "a=imageattr" attribute is created with "recv" direction, and the resulting resolution space formed by intersecting the decoder limits and constraints is used to specify its minimum and maximum x= and y= values.  If the intersection is the null set, i.e., there are no resolutions that are permitted by both the decoder and the mandatory constraints, this SHOULD be represented by x=0 and y=0 values. The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important.  It SHOULD be set to 1.0. </ins> The "a=imageattr" field is payload type specific.  When all video codecs supported have the same capabilities, use of a single attribute, with the wildcard payload type (*), is RECOMMENDED. However, when the supported video codecs have differing capabilities, <del> a specific "a=imageattr" attribute is inserted for each payload type. </del> <ins> specific "a=imageattr" attributes MUST be inserted for each payload type. </ins> As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to