Change:
Sure, I can do that.
Justin and I discussed on the call and this is still borked due to some git pilot error.
PTAL now.
LGTM
Section 6 indicates that programmers can edit the SDP and lists changes which can and cannot be made. It explicitly is preliminary and needs to be fleshed out.
There are three categories - must reject, must act on , and ones that the browser can do whatever it wants but if it is not acted on then an error is generated
General approach is most things are in the "browser can do what it wants case"
Discussed in DC: this applies only to changes on the local side; the gap between createOffer/createAnswer and setLocalDescription. Proposed path is to mandate one of two actions: Accept the changes and apply them Reject the changes outright We will enumerate certain changes that fall into either category, but these lists will not be exhaustive. All unspecified changes will either be accepted or rejected, and that decision will be left to the browser, but they cannot be ignored. Obviously, some types of changes will be ignored. For instance, reordering of a= lines might not be detected as a change. These might carry semantics (as a=group-id does), but we can't require perfect detection.

Discussion:
6. <del> Note: This section is still very early and is likely to significantly change as we get a better understanding of a) the use cases for this b) the implications at the protocol level c) feedback from implementors on what they can do. </del> <ins> It is possible to change elements in the SDP returned from createOffer before passing it to setLocalDescription.  When an implementation receives modified SDP it MUST either: Accept the changes and adjust its behavior to match the SDP. Reject the changes and return an error via the error callback. Changes MUST NOT be silently ignored. </ins> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription, since

endpoint are not exceeded (e.g. asking for a resolution greater than what the endpoint can encode): <del> disable BUNDLE (a=group) disable RTCP mux (a=rtcp-mux) change send resolution or frame rate change desired recv resolution or frame rate change maximum total bandwidth (b=) [OPEN ISSUE: need to clarify if this is CT or AS - see section 5.8 of RFC4566] remove desired AVPF mechanisms (a=rtcp-fb) remove RTP header extensions (a=extmap) change media send/recv state (a=sendonly/recvonly/inactive) </del> <ins> [[OPEN ISSUE: This is a placeholder for other modifications, which we may continue adding as use cases appear.]] </ins> <del> For example, an application could implement call hold by adding an a=inactive attribute to its local description, and then applying and signaling that description. </del> <ins> Implementations MAY choose to either honor or reject any elements not listed in the above two categories, but must do so explicitly as described at the beginning of this section.  Note that future standards may add new SDP elements to the list of elements which must be accepted or rejected, but due to version skew, applications must be prepared for implementations to accept changes which must be rejected and vice versa. </ins> The application can also modify the SDP to reduce the capabilities in <del> the offer it sends to the far side in any way the application sees fit, as long as it is a valid SDP offer and specifies a subset of what the browser is expecting to do. </del> <ins> the offer it sends to the far side or the offer that it installs from the far side in any way the application sees fit, as long as it is a valid SDP offer and specifies a subset of what was in the original offer.  This is safe because the answer is not permitted to expand capabilities and therefore will just respond to what is actually in the offer. </ins> As always, the application is solely responsible for what it sends to the other party, and all incoming SDP will be processed by the