WebRTC - Replacing RTCPeerConnection tracks increases streaming delay on receiver side for a few minutes

In order to be able to seamlessly switch from front to back camera and vice versa during an established RTCPeerConnection I've used the RTCRtpSender.replaceTrack() API as follows:

replaceMediaTracks = (mediaTracks: MediaStreamTrack[]) => {
  if (!mediaTracks || mediaTracks.length < 1) {
    throw this.errorFactory.createError('Failed to replace media tracks of RTC PC: No track to replace provided.');
  }
  this.peerConnections.forEach((peerConnection) => {
    peerConnection.pc.getSenders().forEach((sender) => {
      mediaTracks.forEach((track) => {
        if (track.kind === sender.track.kind) {
          sender.replaceTrack(track);
        }
      });
    });
  });
};

What I've observed is that on the receiver side the video and audio stream will be played with some additional delay for a short period of time (approx. 1 up to 2 minutes) whenever I replace the tracks. While seeking for the reason I've figured out that the jitterBufferDelay/jitterBufferEmittedCount seems to be related to that phenomenom since it is inreasing as well synchronously:

Is there any way to avoid the stream from being delayed when replacing the tracks since it causes bad user experience?

-- Update and solution from 2020-09-06 --

I've also experienced the above mentioned video stream delay on the receiver side on Firefox, too. That might mean that both Firefox and Chrome have a bug here. I did not create a bug ticket yet since I am not sure if it is a bug or not. Nevertheless I've tried to make my actual goal of switching the video from front to back camera and vice versa a bit more efficient by only replacing the video stream instead of replacing both video and audio stream. In terms of code that means that I call replaceMediaTracks as follows replaceMediaTracks(stream.getVideoTracks()) instead of replaceMediaTracks(stream.getTracks()). The stream is fetched by a prior call to navigator.mediaDevices.getUserMedia(...) And voila the delay does not occur anymore:

I've switched the video stream multiple times between 19:24 and 19:27 and there is no significant change in the jitterBufferDelay/jitterBufferEmittedCount ratio.

So that's a solution that is totally fine for my use case.