VP8 simulcast Producer fails on second creation (setLocalDescription error) after webcam toggle (Chrome 143)

mediasoup libraries
1

Hi, I’m running into a reproducible VP8 simulcast issue in Chrome when a user turns their webcam on/off. I’d like to understand whether this is a known Chrome/libwebrtc issue, a mediasoup-client behavior, or something in my flow.

Environment

  • mediasoup: 3.19.13

  • mediasoup-client: 3.18.1

  • Browsers tested:

  • Chrome 143 → problem occurs

  • Firefox 145 → works correctly

  • Video codec: VP8 with simulcast enabled

  • One WebRtcTransport for sending

  • No SDP munging

The problem

When a user:

  1. Enters the room with webcam ON, creating the first VP8 simulcast producer

  2. Turns webcam OFF (I close the producer)

  3. Turns webcam ON again (new VP8 simulcast producer on the same send transport)

Chrome fails during its internal negotiation with:

InvalidAccessError: Failed to execute ‘setLocalDescription’ on ‘RTCPeerConnection’:

Failed to set local offer sdp: The media section with MID=‘0’ negotiates simulcast

but does not negotiate the RID RTP header extension.

This error happens before any interaction with the mediasoup server — Chrome rejects its own offer inside mediasoup-client.

Important additional observation

  • The same flow works perfectly in Firefox 145.

  • The issue appears only in Chrome 143, which suggests something Chrome/libwebrtc-specific.

Strange behavior

  • If the user joins with webcam OFF, then turns webcam ON → OFF → ON, everything works in Chrome.

  • The error happens only when the first producer is created during join, and then a second is created later on the same RTCPeerConnection.

Reproduction steps (Chrome 143)

  1. Create send transport

  2. produce() with VP8 simulcast

  3. .close() that producer

  4. produce() again with VP8 simulcast on the same RTCPeerConnection

  5. Chrome throws the error above inside setLocalDescription()

If I use pause/resume instead of closing the producer → no error.

Firefox does not have this issue even when closing/recreating producers.

What I checked

  • No SDP munging

  • No custom RTP header extensions

  • Router uses the default mediasoup rtpCapabilities

  • The failure originates inside Chrome/libwebrtc before any signaling is sent to the server

  • Firefox 145 handles the exact same flow without issues

Questions

  1. Is this a Chrome/libwebrtc bug triggered by renegotiating VP8 RID simulcast after closing a sender?

  2. Is this a known mediasoup-client v3 behavior or limitation when recreating VP8 simulcast producers on the same transport?

  3. Is the recommended approach for webcam toggling to use pause/resume instead of closing producers to avoid renegotiation entirely?

  4. Has anyone found a reliable workaround that allows a VP8 simulcast producer to be closed and recreated cleanly on Chrome?

2

Can you reproduce the issue in https://demo.mediasoup.org?

Note: This is not a limitation at all and shouldn’t happen. Don’t try to bypass it by pausing/resuming the webcam producer which is a hack since the camera light in the computer will remain on even when paused.

If you can reproduce the same issue in the demo please report the issue in GitHub mediasoup-client project.

3

I’ve tested in the mediasoup demo app with Chrome 143 using your STR and cannot reproduce the issue. The demo by default uses VP8 simulcast as well and immediately creates the webcam once joined.

NOTE: “join” is not a mediasoup thing but a high level application concept, so I fail to see why it fails in your app only when camera is enabled at join time. You may want to check chrome://webrtc-internals when using your app and compare the output with the one generated when using the mediasoup-demo app.

4

Thanks for the idea. I have compared my join code with the demo v3 and also had a look at the webRTC internals. What I have noticed is that I am first starting the video producer, then the mic producer. You are starting first mic producer then video producer.

So I had in webRTC internals:

kind=video, mid=0, rid=r0

kind=video, mid=0, rid=r1

kind=audio, mid=1

You have:

kind=audio, mid=0

kind=video, mid=1, rid=r0

kind=video, mid=1, rid=r1

I have changed the order of creating the producers to get your order and the bug stopped happening. Magic.

Also, when I had my old order, when closing the video producer only

kind=video, mid=0, rid=r1

became grayed out in webRTC internals and

kind=video, mid=0, rid=r0

not. So maybe there is some problem for mid=0 rid=0.

Maybe you can try in your demo code changing in RoomClient.js lines in block 2399 to 2427 and run this.enableWebcam(); before running this.enableMic(); on the latest Chrome 143.0.7499.41 on Windows. Maybe you can reproduce it. It might be a bug of Chrome though.

5

The issue will probably happen doing that modification. Could you please open an issue in GitHub project of mediasoup-client?

6

Hello, just wanted to chime in to say that we’re seeing this same error for a small number of our users on Chrome and Edge 143 as well. I don’t have a consistent repro yet unfortunately, but can test changes and see if they fix it for our users.

This is presumably related to this change from the Chrome 143 release notes: Chrome 143  |  Release notes  |  Chrome for Developers which links to this issue in the WebRTC issue tracker: WebRTC

7

I will open a issue at git hub , but in the evening. I’m travelling today.

8

Hello. I am able to reproduce this error on demo.mediasoup.org . To do this, add &mic=false&webcam=false&datachannel=false to the url and turn on the camera first after joining the room. The main thing is that the camera should be the first producer. Then turn off the camera, turn it on again and catch the error. It seems that the error happens not only with VP8, but with H264 also.

9

HI Mediasoup,

We are facing the same issue where if joined meeting with audio and video disabled, and after entering into meeting, we do mute→unmute→mute of video, last unmute fails.
And, if unmute the audio as the first action into meeting, before touching video, it all works.

Looks like in the sdp we are missing the required extmap of rtp-stream-id.

10

I have opened a issue on GitHub
https://github.com/versatica/mediasoup-client/issues/353

11

We are also facing the same issue and could reproduce with demo url as well.

12

Thanks guys. Please subscribe to the issue, I know (75%) why it happens. Explained in the updated ticket description here: VP8 simulcast Producer fails on second creation (setLocalDescription error) after webcam toggle (Chrome 143) · Issue #353 · versatica/mediasoup-client · GitHub