As we all know, signaling was left out of scope of WebRTC. Applications may decide to use a standard protocol such as SIP or any other proprietary protocol. But, regardless of how media information is exchanged between session participants, this information must somehow be fed into the browser and received from it.
More about this in the details section below.
Once this ability to change local SDP is removed from the standard it will eventually occur in the browser implementations as well. Be prepared.
Because this could be a major change for applications, the RTCWEB chairs will actively seek input on the mailing list. However, if no concerns are raised this will be finalized, and soon.
A very significant decision was made last week in the IETF RTCWEB meeting. This decision must still be confirmed on the mailing list and, as such, may undergo revision or be undone altogether. However, after a good amount of discussion and explanation, the consensus of those participating in the RTCWEB meeting was:
Note that the application can still modify any SDP before it sends it to the remote WebRTC endpoint and still modify any SDP it receives from the remote WebRTC endpoint before calling setRemoteDescription().
The motivation for this decision is the belief that all of the use cases that people have presented for modifying the local-browser-generated SDP before calling setLocalDescription() either have already been addressed in the standards or will be by APIs in progress to be added to the standards. Obviously we all understand that browser implementations lag behind the standards definitions, and the expectation is that browsers will not begin rejecting changed SDP until they fully support all the APIs intended for the specs.
Nevertheless, this is a major decision and a strong indication that the group is finally ready to move away from SDP itself being an approved API surface.