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.
This is where JSEP comes into play. Javascript Session Establishment Protocol (JSEP) is part of the WebRTC standard and is defined by the IETF. It defines APIs for interacting with the browser regarding media and ICE. One of the things it allows is modification of SDP. In the IETF meeting last week this topic was discussed at length. A decision may be close that will start the move away from standardizing SDP related APIs.
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:
We plan to remove from JSEP (from the standard) the ability for applications to modify the SDP between the createOffer()/createAnswer() call and the setLocalDescription() call. Obviously we can’t prevent JavaScript code from actually changing the result from createO/createA before sending to setLocalDescription, but the browser will be allowed to reject it.
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.