As of today, I feel a better approach for your case would be to use the RTCRtpSender.replaceTrack method.
Assuming your camera stream is "camStream", you can obtain the required RTCRtpSender object using the following:
var camVideoTrack = camStream.getVideoTracks()[0];
var camAudioTrack = camStream.getAudioTracks()[0];
var videoSender = peerConnection.addTrack(camVideoTrack, camStream);
var audioSender = peerConnection.addTrack(camAudioTrack, camStream);
...
The last two lines add video and audio capability to the connection.
...
Assuming your screen stream is "screenStream", then you can switch from camera to screen share video like this:
var screenVideoTrack = screenStream.getVideoTracks()[0];
videoSender.replaceTrack(screenVideoTrack);
...
No need to replace audio track since we are only interested in changing the visual while keeping the audio input the same.
Using this approach has the benefit of not requiring peer renegotiation to switch the video sources.
Another benefit of this approach is that you don't need to stop your camStream. When you are done sharing your screen, you can switch back the video source using:
videoSender.replaceTrack(camStream.getVideoTracks()[0]);
You can check out the documentation for replaceTrack here
I have a working webrtc meetings solution which supports screen sharing and screen recording using these similar steps. you can check it out here
It works out of the box on firefox, but to make it work on chrome, you need to enable "Experimental Web Platform" flag (go to chrome://flags/ )